[Mageia-dev] (second attempt) suggesting sectool be dropped

Fri Nov 18 11:37:10 CET 2011

'Twas brillig, and Claire Robinson at 17/11/11 12:49 did gyre and gimble:
+> On 17/11/11 10:26, Michael scherer wrote:
+>> On Tue, Nov 15, 2011 at 11:39:29AM +0100, Florian Hubold wrote:
+>>> Am 15.11.2011 07:29, schrieb Michael Scherer:
+>>>> Le lundi 14 novembre 2011 à 22:09 -0800, Robert M. Riches Jr. a écrit :
+>>>>> (New list subscriber...needed to fix registered email address to
+>>>>> post...)
+>>>>>
+>>>>> I was asked to submit this suggestion to the mailing list:
+>>>>>
+>>>>> As a Mageia user, I believe msec was much better off with_OUT_
+>>>>> sectool.  In its present state, sectool is BADLY broken.  It
+>>>>> whines for pages about file permissions that are exactly as they
+>>>>> should be.
+>>>> Can you be more specific ?
+>>> It think he means this: https://bugs.mageia.org/show_bug.cgi?id=2808
+>>> or https://bugs.mageia.org/show_bug.cgi?id=2255#c21 or
+>>> https://bugs.mageia.org/show_bug.cgi?id=2255#c22
+>>>
+>>> I've also become supportive of this, sectool is basically duplicating
+>>> partly msec functionality, there was no adaption for Mageia,
+>>> currently it's
+>>> checking on Mageia with the upstream Fedora configuration.
+>>>
+>>> Honestly this should have been done when importing it, as
+>>> tmb already mentioned. msec should be patched to not require it.
+>>>
+>>> When we can't even get our default security tool to work properly,
+>>> what's the point in adding a second one which needs even more
+>>> maintenance?
+>>
+>> As you say, the question is again "why was it uploaded in the first
+>> place".
+>> It seems some packages were uploaded, and there seemed to have not enough
+>> tests. While that's hard or impossible to avoid totally, that's not
+>> really
+>> the way to achieve a good distribution :/
+>>
+>> I neither use msec or sectool, so I personnaly do not care that much.
+>> Afaik, sectool was created by a ex mandriva/mandrake guy ( vincent
+>> danen ),
+>> because he was ( rightfully ) wanting to rewrite  msec, who is/was
+>> a mess of bash + python + perl code ( and rather ugly code, afaik,
+>> last time
+>> I took a look ), but if msec is supported, and sectool is not, then I
+>> guess
+>> we could drop. However, I still think we should first attempt to
+>> collaborate
+>> and fix it. ( ie, always have the reflex of "try to fix and
+>> collaborate" ).
+>>
+> 
+> 
+> As one of the people who tested it and the one who filed the bug linked
+> to above which expresses the need for it to be configured, I object to
+> this being blamed on QA! It seems we are kicked whenever anything is wrong.
+> 
+> I believe it is assigned to those higher up to provide a proper
+> configuration.
+> 
+> The bug was dated 22nd September and as yet no configuration exists.
+> That does not reflect well on the distribution, not that QA haven't
+> performed sufficient testing, which we obviously did.
+
+Knowing misc a little bit I don't think for a second he was intending to
+blame QA team here.
+
+More the initial "blind import" (which was a hard time to do overly much
+testing as I'm sure all will agree!) without properly checking things then.
+
+So please don't take it personally, I really don't think he was
+targeting you :)
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited http://www.tribalogic.net/
+Open Source:
+  Mageia Contributor http://www.mageia.org/
+  PulseAudio Hacker http://www.pulseaudio.org/
+  Trac Hacker http://trac.edgewall.org/
+