Hi Stephen, hello everyone,
I installed the two libraries you said: * docbook-xsl * libxml2-utils
And also the ones indicated before: * libtalloc-dev * tdb-dev * libtevent-dev * libldb-dev * cvs * libpopt-dev * libpam-dev * libldap2-dev * libpcre3-dev * krb5-config * libkrb5-dev * libc-ares-dev * libdbus-1-dev * libnss3-dev
Hit configure once more: ./configure --prefix=/opt/sssd | tee ../configure.12.log
... and then make: make | tee ../make.1.log
I still get the same problem. Seems to be an ldap build dep that doesnt work fine. Do we need 389DS libs to build it?
I attach logs.
M*
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Miguel, please make sure to update to the latest SSSD sources. The fix only went in today.
I have built it successfully in a Karmic VM.
On 08/05/2009 05:05 PM, Miguel P.C. wrote:
Hi Stephen, hello everyone,
I installed the two libraries you said:
- docbook-xsl
- libxml2-utils
And also the ones indicated before:
- libtalloc-dev
- tdb-dev
- libtevent-dev
- libldb-dev
- cvs
- libpopt-dev
- libpam-dev
- libldap2-dev
- libpcre3-dev
- krb5-config
- libkrb5-dev
- libc-ares-dev
- libdbus-1-dev
- libnss3-dev
Hit configure once more: ./configure --prefix=/opt/sssd | tee ../configure.12.log
... and then make: make | tee ../make.1.log
I still get the same problem. Seems to be an ldap build dep that doesnt work fine. Do we need 389DS libs to build it?
I attach logs.
M*
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi Stephen, hola everyone,
Miguel, please make sure to update to the latest SSSD sources. The fix only went in today.
I updated sources (2009.08.07 15:45) of SSSD and gave another try to its build without updating Karmic (2009.08.04).
It does build fine and even installs ok. (Beware! logs attached with this mail).
Can we include the build-dep list I sent in my former mail in "BUILD.txt" or maybe "BUILD-Debian.txt"? I think it's useful info that I would have loved to have when I started the tests.
I'll probably be unreachable for the next two weeks. If I find time, I'll keep on working in ubuntu/debian packaging (not very likely, though). Anyway, the way SSSD behaves now, looks like appropiate for a 0.5.0 version to me.
I have built it successfully in a Karmic VM.
As you read, me too :-)
M*
Oh my! ...
I have just realized that the logs I'm sending are partly in spanish ... I'll try to use LANG=C for the next builds unless we need int'l testing.
At least we know it bnuilds in a non-english environment.
M*
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/07/2009 10:03 AM, Miguel P.C. wrote:
Oh my! ...
I have just realized that the logs I'm sending are partly in spanish ... I'll try to use LANG=C for the next builds unless we need int'l testing.
At least we know it bnuilds in a non-english environment.
M* _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
International testing is always a good thing. On a related note, if you would like to try your hand at translating the SSSD tools to Spanish, feel free to send a patch for the server/po/es.po (you need to first run 'make dist' to have it update the es.po to match the current source files.
I'm glad to hear that everything is building. As I said in my previous email, the prerequisites are all *supposed* to be caught by configure, but the two needed for the manpages are trickier to test for. Do you have any ideas how we can make configure detect whether the appropriate docbook tools are in place?
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi again,
International testing is always a good thing. On a related note, if you would like to try your hand at translating the SSSD tools to Spanish, feel free to send a patch for the server/po/es.po (you need to first run 'make dist' to have it update the es.po to match the current source files.
That sounds like something I could add to my TODO list. May I suggest that, if we want to multiply the number of people translating SSSD, we can use Rosetta in Launchpad to do so. I still dont know hot to import ".po" into it or how to get the results from there but ... the translating teams behind it (I'm part of one), work really nice and are really accurate (although this means terrible discussions on one single word in the mailing lists, hehehe). I do appreciate the effort you are doing and maybe your policy does not let you do so but, I think is something worth considering. One thrid option, now that Launchpad is Open/Free Software you can set up a "Rosetta" for the project.
Sorry if I'm adding too much noise to this thread but, as I said, I think it's worth considering.
I'm glad to hear that everything is building. As I said in my previous email, the prerequisites are all *supposed* to be caught by configure, but the two needed for the manpages are trickier to test for. Do you have any ideas how we can make configure detect whether the appropriate docbook tools are in place?
No. But sounds like something interesting. Normally there is a file (or some) that _needs_ to be there and you just check for it to exist. (I have sure said something you all already now ...)
M*
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/07/2009 10:40 AM, Miguel P.C. wrote:
Hi again,
International testing is always a good thing. On a related note, if you would like to try your hand at translating the SSSD tools to Spanish, feel free to send a patch for the server/po/es.po (you need to first run 'make dist' to have it update the es.po to match the current source files.
That sounds like something I could add to my TODO list. May I suggest that, if we want to multiply the number of people translating SSSD, we can use Rosetta in Launchpad to do so. I still dont know hot to import ".po" into it or how to get the results from there but ... the translating teams behind it (I'm part of one), work really nice and are really accurate (although this means terrible discussions on one single word in the mailing lists, hehehe). I do appreciate the effort you are doing and maybe your policy does not let you do so but, I think is something worth considering. One thrid option, now that Launchpad is Open/Free Software you can set up a "Rosetta" for the project.
Sorry if I'm adding too much noise to this thread but, as I said, I think it's worth considering.
Well, we're definitely open to expanding out translation community. Our original plan was to use Fedora's Transifex system, but it doesn't mesh with our development style. (Transifex requires direct access to our upstream repository, while we prefer to receive everything in patches that must be approved by a gatekeeper such as Simo, Sumit or myself).
The latest upstream release of Transifex supposedly has support for patch-generation instead of repository-integration, but there is no clear view when the Fedora Infrastructure will upgrade.
Does Rosetta have support for generating patches for upstream, or does it require repository integration?
I'm glad to hear that everything is building. As I said in my previous email, the prerequisites are all *supposed* to be caught by configure, but the two needed for the manpages are trickier to test for. Do you have any ideas how we can make configure detect whether the appropriate docbook tools are in place?
No. But sounds like something interesting. Normally there is a file (or some) that _needs_ to be there and you just check for it to exist. (I have sure said something you all already now ...)
The problem is that there's no platform-agnostic way to test for the presence of a specific file. It could be located in any directory. For all of the other configure tests, we're able to rely on built-in autoconfig macros or on pkg-config.
If you have suggestions, I'm all ears :)
M* _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
On Fri, Aug 7, 2009 at 11:25 AM, Stephen Gallaghersgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/07/2009 10:40 AM, Miguel P.C. wrote:
Hi again,
International testing is always a good thing. On a related note, if you would like to try your hand at translating the SSSD tools to Spanish, feel free to send a patch for the server/po/es.po (you need to first run 'make dist' to have it update the es.po to match the current source files.
That sounds like something I could add to my TODO list. May I suggest that, if we want to multiply the number of people translating SSSD, we can use Rosetta in Launchpad to do so. I still dont know hot to import ".po" into it or how to get the results from there but ... the translating teams behind it (I'm part of one), work really nice and are really accurate (although this means terrible discussions on one single word in the mailing lists, hehehe). I do appreciate the effort you are doing and maybe your policy does not let you do so but, I think is something worth considering. One thrid option, now that Launchpad is Open/Free Software you can set up a "Rosetta" for the project.
Sorry if I'm adding too much noise to this thread but, as I said, I think it's worth considering.
Well, we're definitely open to expanding out translation community. Our original plan was to use Fedora's Transifex system, but it doesn't mesh with our development style. (Transifex requires direct access to our upstream repository, while we prefer to receive everything in patches that must be approved by a gatekeeper such as Simo, Sumit or myself).
The latest upstream release of Transifex supposedly has support for patch-generation instead of repository-integration, but there is no clear view when the Fedora Infrastructure will upgrade.
Does Rosetta have support for generating patches for upstream, or does it require repository integration?
Launchpad Translations does not generate patches automatically, but it allows for translations to be automatically commited to a bzr branch (http://blog.launchpad.net/general/exporting-translations-to-a-bazaar-branch), where they can then be fetched from and integrated to the upstream project. It seems to me that this could work well with your workflow, where only the reviewers or gatekeepers can approve the changes.
The main benefit of Launchpad Translations though, is that it allows building and growing translation communities by lowering the entry barrier for translators and allowing them to work in a collaborative way.
-- Mathias Gug Ubuntu Developer http://www.ubuntu.com
On Mon, 2009-08-10 at 17:22 -0400, Mathias Gug wrote:
Hi,
On Fri, Aug 7, 2009 at 11:25 AM, Stephen Gallaghersgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/07/2009 10:40 AM, Miguel P.C. wrote:
Hi again,
International testing is always a good thing. On a related note, if you would like to try your hand at translating the SSSD tools to Spanish, feel free to send a patch for the server/po/es.po (you need to first run 'make dist' to have it update the es.po to match the current source files.
That sounds like something I could add to my TODO list. May I suggest that, if we want to multiply the number of people translating SSSD, we can use Rosetta in Launchpad to do so. I still dont know hot to import ".po" into it or how to get the results from there but ... the translating teams behind it (I'm part of one), work really nice and are really accurate (although this means terrible discussions on one single word in the mailing lists, hehehe). I do appreciate the effort you are doing and maybe your policy does not let you do so but, I think is something worth considering. One thrid option, now that Launchpad is Open/Free Software you can set up a "Rosetta" for the project.
Sorry if I'm adding too much noise to this thread but, as I said, I think it's worth considering.
Well, we're definitely open to expanding out translation community. Our original plan was to use Fedora's Transifex system, but it doesn't mesh with our development style. (Transifex requires direct access to our upstream repository, while we prefer to receive everything in patches that must be approved by a gatekeeper such as Simo, Sumit or myself).
The latest upstream release of Transifex supposedly has support for patch-generation instead of repository-integration, but there is no clear view when the Fedora Infrastructure will upgrade.
Does Rosetta have support for generating patches for upstream, or does it require repository integration?
Launchpad Translations does not generate patches automatically, but it allows for translations to be automatically commited to a bzr branch (http://blog.launchpad.net/general/exporting-translations-to-a-bazaar-branch), where they can then be fetched from and integrated to the upstream project. It seems to me that this could work well with your workflow, where only the reviewers or gatekeepers can approve the changes.
The main benefit of Launchpad Translations though, is that it allows building and growing translation communities by lowering the entry barrier for translators and allowing them to work in a collaborative way.
Given we use git it doesn't seem a great match. If the Fedora facility do upgrade to the newer Transifex, then maybe that's going to be easier for us as we will not need to make any bzr to git transformation and use 2 separate account systems, etc...
Simo.
On Tue, Aug 11, 2009 at 06:09:24AM -0400, Simo Sorce wrote:
Given we use git it doesn't seem a great match. If the Fedora facility do upgrade to the newer Transifex, then maybe that's going to be easier for us as we will not need to make any bzr to git transformation and use 2 separate account systems, etc...
I just checked on this, it's in progress. I'll send along the Trac ticket when it's generated so anyone can watch it. Diego is working on the 0.7 upgrade, and he needs a db dump that cannot happen until after Fedora 12 Alpha freeze (Fedora Infrastructure freezes changes and certain activities around release times.) That would make it "after a few weeks", since Alpha was pushed back a week.
He asked that we file a ticket on Transifex.org that explains what we would be looking for in a l10n workflow so that it fits with the SSSD development model. I can file the ticket, but need a solid idea of what SSSD would want (I'll run the same concept by the rest of FreeIPA, figuring there it's identical?) These would be features that could appear in 0.8 if they do not exist currently in a way you can use.
Another idea, btw, is to use the instance at Transifex.net instead of translate.fedoraproject.org. It depends, I suppose, on which group you want to get a new account (presuming they don't have a Transifex.net account yet) -- Fedora l10n community who don't have a Transifex.net account, or non-Fedora l10n community who don't have a Fedora Account. :) In the end, I think the effect on SSSD is the same, but it may be different in the longer term depending on where you see the bulk and growth of your l10n community to be.
- Karsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/13/2009 07:34 PM, Karsten Wade wrote:
On Tue, Aug 11, 2009 at 06:09:24AM -0400, Simo Sorce wrote:
Given we use git it doesn't seem a great match. If the Fedora facility do upgrade to the newer Transifex, then maybe that's going to be easier for us as we will not need to make any bzr to git transformation and use 2 separate account systems, etc...
I just checked on this, it's in progress. I'll send along the Trac ticket when it's generated so anyone can watch it. Diego is working on the 0.7 upgrade, and he needs a db dump that cannot happen until after Fedora 12 Alpha freeze (Fedora Infrastructure freezes changes and certain activities around release times.) That would make it "after a few weeks", since Alpha was pushed back a week.
He asked that we file a ticket on Transifex.org that explains what we would be looking for in a l10n workflow so that it fits with the SSSD development model. I can file the ticket, but need a solid idea of what SSSD would want (I'll run the same concept by the rest of FreeIPA, figuring there it's identical?) These would be features that could appear in 0.8 if they do not exist currently in a way you can use.
Another idea, btw, is to use the instance at Transifex.net instead of translate.fedoraproject.org. It depends, I suppose, on which group you want to get a new account (presuming they don't have a Transifex.net account yet) -- Fedora l10n community who don't have a Transifex.net account, or non-Fedora l10n community who don't have a Fedora Account. :) In the end, I think the effect on SSSD is the same, but it may be different in the longer term depending on where you see the bulk and growth of your l10n community to be.
- Karsten
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Sorry for the long delay in my reply. We've been busy getting SSSD 0.5.0 ready for release.
I've been thinking about how we can sort out the translations without requiring major architecture changes to Transifex, and I've come up with the following set of our requirements, and then some suggestions on how to implement them.
We really have only one unbreakable rule: All submissions to the upstream git repository must be approved by a "gatekeeper" (At present, this means Simo Sorce, Sumit Bose or myself). This is absolutely necessary in a low-level security feature such as the SSSD. There must be no possibility that, through a security vulnerability in Transifex, a user could submit code to the SSSD without security review.
In our typical (non-translation) development process, we submit our patches to the public mailing list and receive a review from one or more of our peers on the project. Once that code is "acked", one of the gatekeepers will then do a final review and apply the path to our upstream git repository. (This final review is generally waived if a gatekeeper was the primary reviewer)
As I understand it, the way Transifex works is that we are required to add the "transifex" user to our gatekeepers list and trust that the Transifex system will allow only translation changes to be made.
What we originally discussed as our needs in Transifex was that, once a translation was made, that the Transifex server should automatically email that patch to the sssd-devel list, where it would then be treated as any other development patch.
As I thought more about it, I began thinking that a more reasonable approach (within the existing Transifex process) would be to have Transifex add an approval process into the system. Instead of needing to mail out patches, Transifex should be configurable with a set of users authorized to approve submissions to git. When a translation is made, it should auto-notify either the sssd-devel mailing list or possibly just the list of gatekeepers for the project.
The project gatekeeper would then be able to log into Transifex, inspect the change to ensure it doesn't look suspicious and then sign off on the change. Then and only then, should Transifex have permission to submit the patch directly to git. (Ideally, it should also add the --signoff argument to note which gatekeeper approved the change)
I'm not sure how much of this is available in the current release of Transifex, and how much would be needed in 0.8.
Karsten, please CC me on the ticket when you create it.
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/17/2009 10:30 AM, Stephen Gallagher wrote:
On 08/13/2009 07:34 PM, Karsten Wade wrote:
On Tue, Aug 11, 2009 at 06:09:24AM -0400, Simo Sorce wrote:
Given we use git it doesn't seem a great match. If the Fedora facility do upgrade to the newer Transifex, then maybe that's going to be easier for us as we will not need to make any bzr to git transformation and use 2 separate account systems, etc...
I just checked on this, it's in progress. I'll send along the Trac ticket when it's generated so anyone can watch it. Diego is working on the 0.7 upgrade, and he needs a db dump that cannot happen until after Fedora 12 Alpha freeze (Fedora Infrastructure freezes changes and certain activities around release times.) That would make it "after a few weeks", since Alpha was pushed back a week.
He asked that we file a ticket on Transifex.org that explains what we would be looking for in a l10n workflow so that it fits with the SSSD development model. I can file the ticket, but need a solid idea of what SSSD would want (I'll run the same concept by the rest of FreeIPA, figuring there it's identical?) These would be features that could appear in 0.8 if they do not exist currently in a way you can use.
Another idea, btw, is to use the instance at Transifex.net instead of translate.fedoraproject.org. It depends, I suppose, on which group you want to get a new account (presuming they don't have a Transifex.net account yet) -- Fedora l10n community who don't have a Transifex.net account, or non-Fedora l10n community who don't have a Fedora Account. :) In the end, I think the effect on SSSD is the same, but it may be different in the longer term depending on where you see the bulk and growth of your l10n community to be.
- Karsten
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Sorry for the long delay in my reply. We've been busy getting SSSD 0.5.0 ready for release.
I've been thinking about how we can sort out the translations without requiring major architecture changes to Transifex, and I've come up with the following set of our requirements, and then some suggestions on how to implement them.
We really have only one unbreakable rule: All submissions to the upstream git repository must be approved by a "gatekeeper" (At present, this means Simo Sorce, Sumit Bose or myself). This is absolutely necessary in a low-level security feature such as the SSSD. There must be no possibility that, through a security vulnerability in Transifex, a user could submit code to the SSSD without security review.
In our typical (non-translation) development process, we submit our patches to the public mailing list and receive a review from one or more of our peers on the project. Once that code is "acked", one of the gatekeepers will then do a final review and apply the path to our upstream git repository. (This final review is generally waived if a gatekeeper was the primary reviewer)
As I understand it, the way Transifex works is that we are required to add the "transifex" user to our gatekeepers list and trust that the Transifex system will allow only translation changes to be made.
What we originally discussed as our needs in Transifex was that, once a translation was made, that the Transifex server should automatically email that patch to the sssd-devel list, where it would then be treated as any other development patch.
As I thought more about it, I began thinking that a more reasonable approach (within the existing Transifex process) would be to have Transifex add an approval process into the system. Instead of needing to mail out patches, Transifex should be configurable with a set of users authorized to approve submissions to git. When a translation is made, it should auto-notify either the sssd-devel mailing list or possibly just the list of gatekeepers for the project.
The project gatekeeper would then be able to log into Transifex, inspect the change to ensure it doesn't look suspicious and then sign off on the change. Then and only then, should Transifex have permission to submit the patch directly to git. (Ideally, it should also add the --signoff argument to note which gatekeeper approved the change)
I'm not sure how much of this is available in the current release of Transifex, and how much would be needed in 0.8.
Karsten, please CC me on the ticket when you create it.
Good news/Bad news on the translation front.
Good news: Transifex 0.7.x will now support submission of translations to an email inbox. This means we will be able to configure our Transifex project to submit the patches to our sssd-devel list for approval.
Bad news: The upgrade on translate.fedoraproject.org is not likely to occur before Fedora 12 translation freeze on September 22.
I will keep an eye on the server upgrade and get us set up as soon as it becomes possible. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi Miguel,
2009/8/7 Miguel P.C. mpcolino@gmail.com:
Miguel, please make sure to update to the latest SSSD sources. The fix only went in today.
I updated sources (2009.08.07 15:45) of SSSD and gave another try to its build without updating Karmic (2009.08.04).
It does build fine and even installs ok. (Beware! logs attached with this mail).
Could you push your debian/ packaging code somewhere?
I'd suggest to branch the sssd git-import from LP:
bzr branch lp:sssd/
Add the debian/ directory and push your local branch to your LP account under the sssd project:
bzr push lp:~migpc/sssd/karmic-packaging/
Thanks for your work,
Hi Miguel,
Hi Mathias!
Could you push your debian/ packaging code somewhere?
No changes to what I uploaded yet, as I couldn't build it. Whenever I get anything I'll try to push it. (Release early, release often!).
I'd suggest to branch the sssd git-import from LP:
bzr branch lp:sssd/
OK. I don't have much experience with bzr (yet).
Add the debian/ directory and push your local branch to your LP account under the sssd project:
bzr push lp:~migpc/sssd/karmic-packaging/
OK. I'll do it as soon as I can publish anything new.
Thanks for your work,
Thank you too.
M*
On Fri, Aug 7, 2009 at 3:30 PM, Miguel P.C.mpcolino@gmail.com wrote:
Add the debian/ directory and push your local branch to your LP account under the sssd project:
bzr push lp:~migpc/sssd/karmic-packaging/
OK. I'll do it as soon as I can publish anything new.
Could you push a branch with the already *existing* code (ie the tar ball you've sent earlier this week)?
Thanks,
sssd-devel@lists.fedorahosted.org
-
Karsten Wade -
Mathias Gug -
Miguel P.C. -
Simo Sorce -
Stephen Gallagher