Started looking at the ticket #107 related to traverse functions. Realized that the return values are not consistent. That overlapped with the work that I wanted to do for ticket #103 - errno cleanup. So I (across collection, INI and ELAPI): * Made the return codes consistent (where found) * Removed errno where it is not needed While was testing used valgrind and found a nasty problem when the value was added to collection with overwriting duplicates the count was decreased improperly. Fixing collection.c to not decrease count made valgrind happy. While I was debugging this I also spotted several build warnings in trace statements when the " exp ? v1 : v2 " was used. Fixed those. In ini_config.c there was a trace statement that used variable after it was freed. Removed trace statement.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/14/2009 11:09 PM, Dmitri Pal wrote:
Started looking at the ticket #107 related to traverse functions. Realized that the return values are not consistent. That overlapped with the work that I wanted to do for ticket #103 - errno cleanup. So I (across collection, INI and ELAPI):
- Made the return codes consistent (where found)
- Removed errno where it is not needed
While was testing used valgrind and found a nasty problem when the value was added to collection with overwriting duplicates the count was decreased improperly. Fixing collection.c to not decrease count made valgrind happy. While I was debugging this I also spotted several build warnings in trace statements when the " exp ? v1 : v2 " was used. Fixed those. In ini_config.c there was a trace statement that used variable after it was freed. Removed trace statement.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
I am not reviewing this patch at this time, as it depends on another patch that was nacked. Please resubmit both when the original patch has been reviewed.
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/14/2009 11:09 PM, Dmitri Pal wrote:
Started looking at the ticket #107 related to traverse functions. Realized that the return values are not consistent. That overlapped with the work that I wanted to do for ticket #103 - errno cleanup. So I (across collection, INI and ELAPI):
- Made the return codes consistent (where found)
- Removed errno where it is not needed
While was testing used valgrind and found a nasty problem when the value was added to collection with overwriting duplicates the count was decreased improperly. Fixing collection.c to not decrease count made valgrind happy. While I was debugging this I also spotted several build warnings in trace statements when the " exp ? v1 : v2 " was used. Fixed those. In ini_config.c there was a trace statement that used variable after it was freed. Removed trace statement.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Ack and pushed to master.
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Please check - this one could have fixed the ticket #128. It got pushed so the build will have it tomorrow.
Stephen Gallagher wrote:
On 08/14/2009 11:09 PM, Dmitri Pal wrote:
Started looking at the ticket #107 related to traverse functions. Realized that the return values are not consistent. That overlapped with the work that I wanted to do for ticket #103 - errno cleanup. So I (across collection, INI and ELAPI):
- Made the return codes consistent (where found)
- Removed errno where it is not needed
While was testing used valgrind and found a nasty problem when the value was added to collection with overwriting duplicates the count was decreased improperly. Fixing collection.c to not decrease count made valgrind happy. While I was debugging this I also spotted several build warnings in trace statements when the " exp ? v1 : v2 " was used. Fixed those. In ini_config.c there was a trace statement that used variable after it was freed. Removed trace statement.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Ack and pushed to master.
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Steve,
I re-based my source and used the commit value of 93c02400b6075f0a4784e87229102bf751f27815 in the tickets but when I tried to follow the automatically created link the track complained that the commit doe not exist. Is this Ok? Some synch delay?
Stephen Gallagher wrote:
On 08/14/2009 11:09 PM, Dmitri Pal wrote:
Started looking at the ticket #107 related to traverse functions. Realized that the return values are not consistent. That overlapped with the work that I wanted to do for ticket #103 - errno cleanup. So I (across collection, INI and ELAPI):
- Made the return codes consistent (where found)
- Removed errno where it is not needed
While was testing used valgrind and found a nasty problem when the value was added to collection with overwriting duplicates the count was decreased improperly. Fixing collection.c to not decrease count made valgrind happy. While I was debugging this I also spotted several build warnings in trace statements when the " exp ? v1 : v2 " was used. Fixed those. In ini_config.c there was a trace statement that used variable after it was freed. Removed trace statement.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Ack and pushed to master.
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2009 06:03 PM, Dmitri Pal wrote:
Steve,
I re-based my source and used the commit value of 93c02400b6075f0a4784e87229102bf751f27815 in the tickets but when I tried to follow the automatically created link the track complained that the commit doe not exist. Is this Ok? Some synch delay?
No, you used the wrong commit id. The correct one is: 1069fb127a38d875d0ca2f56bfc936a97a964380
Sometimes they change when they're pushed to master because they might have required trivial (or non-trivial) merges based on the order they were applied. You should always check gitweb at http://git.fedorahosted.org/git/sssd.git for the correct commit id once it's pushed.
Stephen Gallagher wrote:
On 08/14/2009 11:09 PM, Dmitri Pal wrote:
Started looking at the ticket #107 related to traverse functions. Realized that the return values are not consistent. That overlapped with the work that I wanted to do for ticket #103 - errno cleanup. So I (across collection, INI and ELAPI):
- Made the return codes consistent (where found)
- Removed errno where it is not needed
While was testing used valgrind and found a nasty problem when the value was added to collection with overwriting duplicates the count was decreased improperly. Fixing collection.c to not decrease count made valgrind happy. While I was debugging this I also spotted several build warnings in trace statements when the " exp ? v1 : v2 " was used. Fixed those. In ini_config.c there was a trace statement that used variable after it was freed. Removed trace statement.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Ack and pushed to master.
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/
Stephen Gallagher wrote:
On 08/20/2009 06:03 PM, Dmitri Pal wrote:
Steve,
I re-based my source and used the commit value of 93c02400b6075f0a4784e87229102bf751f27815 in the tickets but when I tried to follow the automatically created link the track complained that the commit doe not exist. Is this Ok? Some synch delay?
No, you used the wrong commit id. The correct one is: 1069fb127a38d875d0ca2f56bfc936a97a964380
Sometimes they change when they're pushed to master because they might have required trivial (or non-trivial) merges based on the order they were applied. You should always check gitweb at http://git.fedorahosted.org/git/sssd.git for the correct commit id once it's pushed.
But when I rebase it should have updated in my git, right?
Stephen Gallagher wrote:
On 08/14/2009 11:09 PM, Dmitri Pal wrote:
Started looking at the ticket #107 related to traverse functions. Realized that the return values are not consistent. That overlapped with the work that I wanted to do for ticket #103 - errno cleanup. So I (across collection, INI and ELAPI):
- Made the return codes consistent (where found)
- Removed errno where it is not needed
While was testing used valgrind and found a nasty problem when the value was added to collection with overwriting duplicates the count was decreased improperly. Fixing collection.c to not decrease count made valgrind happy. While I was debugging this I also spotted several build warnings in trace statements when the " exp ? v1 : v2 " was used. Fixed those. In ini_config.c there was a trace statement that used variable after it was freed. Removed trace statement.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Ack and pushed to master.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/21/2009 09:04 AM, Dmitri Pal wrote:
Stephen Gallagher wrote:
On 08/20/2009 06:03 PM, Dmitri Pal wrote:
Steve,
I re-based my source and used the commit value of 93c02400b6075f0a4784e87229102bf751f27815 in the tickets but when I tried to follow the automatically created link the track complained that the commit doe not exist. Is this Ok? Some synch delay?
No, you used the wrong commit id. The correct one is: 1069fb127a38d875d0ca2f56bfc936a97a964380
Sometimes they change when they're pushed to master because they might have required trivial (or non-trivial) merges based on the order they were applied. You should always check gitweb at http://git.fedorahosted.org/git/sssd.git for the correct commit id once it's pushed.
But when I rebase it should have updated in my git, right?
It should, yes. I'm not sure why it wouldn't have. In any case, always use the gitweb as the authoritative source for that information.
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Stephen Gallagher