Overview
Request 629739 accepted
- Fix slapd segfaults in mdb_env_reader_dest
+ with patch 0016-Clear-shared-key-only-in-close-function.patch
+ (bsc#1089640)
- Created by ckowalczyk
- In state accepted
-
Package maintainers:
jengelh and
jmcdough
Loading...
Request History
ckowalczyk created request
- Fix slapd segfaults in mdb_env_reader_dest
+ with patch 0016-Clear-shared-key-only-in-close-function.patch
+ (bsc#1089640)
stroeder declined request
Public information, preferrably an OpenLDAP ITS entry, is needed to determine whether this patch is really correct.
pluskalm reopened request
pluskalm accepted request
I need more info about the bug. E.g. is there also an OpenLDAP ITS for this bug? But "You are not authorized to access bug #1089640."
Please bear in mind that you are one of several maintainers of this package - you are in no position to authoritatively decide and enforce self appointed rules, such as that patch has to be publicly acked and reviewed by you.
I'm aware of this fact. But if you want others to act in a responsible manner, e.g. cooperate transparently and not break things, you have to act according to this yourself.
I Dont follow what you are trying to say.
It just means: Act as a good citizen in the free software world.
A good citizen wouldn’t decline a submit request made in good faith just to ask a question.
We have a review phase for a reason.
I consider an decline of a package before asking questions the act of a bad citizen
Just as I consider the acceptance of a package while there are open questions from co-maintainers to be a bad act
Please review your behaviours in the future
That would be of course unfortunate, sadly original decline did not contain question, just statement.
Ah right first comment - I did not notice it before accepting sr
I have no idea what "OpenLDAP ITS", but yes - I am going to present this change to upstream if this is what you have in mind.
If you patch OpenLDAP source you should know where to file tickets at OpenLDAP and clarify the issue with OpenLDAP upstream devs before sending a patch to openSUSE:Factory.
https://www.openldap.org/its/
No, I disagree here
openSUSE should be open to drive by contributors to submit changes before they understand such stuff
It might be your responsibility to know and interact with upstream openLDAP in such a way but I will not support any suggestion that openSUSE will exclude contributions until people understand the respective upstreams
One of the whole points of an open distribution project is so we can be MORE accessible to more contributions than all the various upstreams, but we also have good, informed, upstream contributors like yourself to aid and educate
But I consider a contributors lack of such an education to be a failure on the part of our established maintainers and not a valid reason to decline a contribution
If you or any openSUSE contributor needs information about a private SUSE bug please email opensuse-bugshare@opensuse.org with the bug number and reason and we will do our best to give you the details.
In this case A SUSE customer reported a crash, then confirmed that the above patch fixes the crash, as such the patch has been submitted into SUSE Enterprise and according to SUSE's policy's it now must also be applied to tumbleweed / factory to make sure its not missed in the next SUSE release.
Luckily I can access this bug.
That's great for you. But I need more info too. Thus I consider your behaviour rather offensive.
Please don't get me wrong. I heavily rely on OpenLDAP myself. Therefore I definitely want to have all possible fixes. But the way you're dealing with it is plain wrong.
In general I'm reluctant regarding such backport patches because during the next updates the patch might fail and one therefore needs information about a patch (drop or update). At least I also want to see some evidence that the OpenLDAP upstream developers would also accept your patch and that it does not cause some other damage.
Why would that be offensive?
Also I find blocking valid sr rather problematic.
I would appreciate if you would read the patch. If you are not able to assess such patch and rely only on upstream developers I am fine with it, but as already said - don't force consequences of such deficiencies on others.
Also if you want to see the bug you can just plainly ask for access.
Thanks pluskalm, I really appreciate your intervention. Good to know that not only I was disappointed by what had happened here..
This is not about somebody being personally disappointed. This is only about quality.
I read the patch. But there was no information about the analysis leading to exactly this patch. I asked Howard Chu who in the mean-time responded that this patch seems like a no-op to him and he wants more info.
I simply don't want patches to reach the OpenLDAP packages which were not thoroughly reviewed. The reason: If openSUSE packages contain lots of random patches openSUSE users asking for help on upstream mailing lists will be pushed back which is very annoying for them. I know what I'm talking about because I'm living there since 20 years. Everybody should understand this reasoning.
Second there are already obscure patches in there. E.g. 0008-In-monitor-backend-do-not-return-Connection0-entries.patch does IMO not make sense and there's no further information linked why it's there. Even the patch author is not available at SUSE anymore. This is not a good package maintenance in the even-not-so-long run.
Hello All, I have just opened an Issue in Upstream, with proposed solution: https://www.openldap.org/its/index.cgi/Incoming?id=8901;selectid=8901 Thank you for sharing the url, stroeder.