I had a discussion with debian maintainer on IRC:
04:07 < tjaalton> hmm, is adding symlinks to python modules a fedora thing? like pysss.so -> _py2sss.so
04:08 < tjaalton> looks like current debian python tools rename them, breaking the symlink
04:10 < lslebodn> it's not a fedora thing but it works on fedora
04:11 < lslebodn> It was the simplest way have to build python2 and python3 bindings in the same time
04:14 < tjaalton> ok
04:15 < lslebodn> _py2sssbecause there have to be the name of module in init function
04:15 < lslebodn> this is a reason why import _py2sss will fail
04:16 < lslebodn> if the debian python tool rename symbolic links then you can rename _py2sss.so after
04:16 < lslebodn> mv _py2sss.so pysss.so
04:17 < lslebodn> instead of ln -s _py2sss.so pysss.so
04:18 < lslebodn> hmm, why I didn't do that in makefile? :-)
04:21 < lslebodn> tjaalton: If you have a probelm with symbolic links. You can try
04:22 < lslebodn> but I didn't test the patch. I'm not sure if modules could be imported with such
change. But there shoudl not be a difference between mv and ln -s
04:24 < tjaalton> ok I'll try that, thanks
Attached is an updated version of patch from previous fpaste link.
I was reprodicing other bug and it took me some time to find out why I was not
able to resolve user. RID was bigger than range size.
I saw just general message about id mapping failer
[sdap_save_user] (0x0400): Processing user matthewbe
[sdap_save_user] (0x1000): Mapping user [matthewbe] objectSID
[S-1-5-21-2997650941-1802118864-3094776726-200065] to unix ID
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
[S-1-5-21-2997650941-1802118864-3094776726-200065] to a UNIX ID
Default range size is 200000
[sdap_save_user] (0x0020): Failed to save user [matthewbe]
[sdap_save_users] (0x0040): Failed to store user 0. Ignoring.
Feel free to propose better debug message. I think it would simplify debugging.
Hi guys, I spent some time working at this ticket
https://fedorahosted.org/sssd/ticket/1108 and I think it's finally
ready to be reviewed by others.
Description of the problem and scope of the changes can be found in
the commit message. I also wrote some unit tests but the patch is a
quite long already so I think it would be better to send the tests as
an another patch. Or should I create a patch for each modified file?
Here are the integration test code improvement patches taken out of the
"intg: Add more LDAP tests" patch set to speed up merging.
These are supposed to have PEP8 errors/warnings fixed.