[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mandrake-cooker
Subject:    Re: [Cooker] OT: Plf policy ( was:  A mirror for Buchan dkms packages
From:       Stefan van der Eijk <stefan () eijk ! nu>
Date:       2004-12-31 17:11:36
Message-ID: 41D58848.9020408 () eijk ! nu
[Download RAW message or body]


Michael Scherer wrote:

>Le vendredi 31 Décembre 2004 00:03, Stefan van der Eijk a écrit :
>  
>
>>Michael Scherer wrote:
>>    
>>
>>>Le jeudi 30 Décembre 2004 20:09, Stefan van der Eijk a écrit :
>>>      
>>>
>>>>Zeb wrote:
>>>>        
>>>>
>>>>>Austin wrote:
>>>>>          
>>>>>
>>>>>>On Thu, 2004-12-30 at 17:35 +0100, Michael Scherer wrote:
>>>>>>            
>>>>>>
>>>>>>>And we could call it backport.zarb.org ?
>>>>>>>It think it could be added to the backport project, in order to
>>>>>>>redeuce duplication of repository.
>>>>>>>              
>>>>>>>
>>>>>>But providing current and working dkms system could be a major step for
>>>>>>Mandrake: usability, longevity, added value, marketing.  This would
>>>>>>require that the packages be on Mandrake mirrors, but preferably not in
>>>>>>contribs.  I think the user should have an obvious and easy way to
>>>>>>select whether (s)he wants dkms updates or not.
>>>>>>
>>>>>>Austin
>>>>>>            
>>>>>>
>>>>>Yes, dkms for nvidia and ati drivers would be fantastic for the club.
>>>>>Everybody would be able to update its drivers easily.
>>>>>          
>>>>>
>>>>Oh yeah... for the club... *cough* *cough*
>>>>
>>>>Just remembered the nice discussion on the plf list about the nvidia
>>>>packages. Wasn't this software free to redistributed?
>>>>
>>>>http://www.nvidia.com/object/nv_swlicense.html
>>>>
>>>>2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of
>>>>Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or
>>>>FreeBSD operating systems, or other operating systems derived from the
>>>>source code to these operating systems, may be copied and redistributed,
>>>>provided that the binary files thereof are not modified in any way
>>>>(except for unzipping of compressed files).
>>>>
>>>>Besides being protective of the Mandrakesoft business and therefore
>>>>giving them the "monopoly" on providing these drivers through club, can
>>>>anybody point out why we shouldn't put it on PLF / some other site? What
>>>>in NV's license doesn't allow us to do so?
>>>>        
>>>>
>>>Well, as you said, this has been discussed on plf mailling list, so i can
>>>summarize the discussion, the first and the secund :
>>>      
>>>
>>/secund/second/
>>
>>Too bad that ML wasn't archived...
>>    
>>
>
>It is archived, as i have restored the archive from my mailbox, if i remeber 
>correctly. I will take a look when the server will be back.
>
>In the meantime, there is :
>
>http://dir.gmane.org/gmane.linux.mandrake.plf.general
>
>And plenty of other online archives.
>
>  
>
>>>Plf people do not want mostly for principles reasons, and because it was
>>>not technicaly achievable at the moment.
>>>      
>>>
>>Uhm?
>>
>>So it wasn't a principal issue, but a technical one? Strange.
>>    
>>
>
>You misread, let me explain again :
>mostly for principal and also for technical issue.
>  
>
Quite funny how you say "PLF people" and I was a member of that group, a 
voiceless member, that is.

About something not being technically achieveable --> perhaps this was 
so at the time, but since when does the PLF (or Mandrakesoft for that 
part) exclude innovations that may lead to solving technical 
impossibilities from the repositories?

> >And also the fact it was uploaded for a silly reason that thac fail to
>  
>
>>>explain,
>>>      
>>>
>>Which Thac did explain. The reason was to build mythfrontend packages
>>that would run with the nvidia kernel modules.
>>    
>>
>
>He didn't explain :
>1) how it react when there is no nvidia.
>2) how he plan to build package as a simple user, with a non nvidia kernel.
>3) why he cannot patch or add runtime detection.
>  
>
Hum... he didn't even get a chance to explain it before you (or was it 
the other guy?) removed his packages from the mirror.

>He posted only 4 or 5 emails on the list, mainly to say that the pacakge were 
>moved to his own website, and didn't answer to this question :
>  
>
What do you expect? With the way his packages were removed, I guess most 
people will just say such a thing. As the outcome of the so-called 
*discusion* was obvious from the start.

>============
>Me 
>  
>
>>The question is 'if a package need a kernel module to be loaded, how do 
>>we compile it as simple user ? 
>>If plf set a build host, we will then be forced to load a binary module 
>>driver that taint the kernel , on a machine that surely do not have a 
>>nvidia card ?
>>
>>Or we should load it only when needed, and then give limited root 
>>access, and potentialy ability to load kernel rootkit ?
>>
>>If a kernel driver is a dependancy of a package, then the package should 
>>be fixed to be buildable as simple user, the security risk is too 
>>great, and is not worth the gain. 
>>    
>>
>
>Thac :
>
>in this case its not a problem mythtv can be built for several different 
>hardware versions not only
>nvidia but ati and others.
>The problem exists for thoose versions also.
>So the mythtv version on plf is built without any special hardware 
>support at all.
>and it will of course be several different versions of mythtv for 
>different hardware versions.
>i have other apps that could be built in this way and none of them is 
>provided by mandrake.
>
>===============
>
>I still read the answer and fail to see where he answer to the question :
>"how do we compile it as a simple user".
>  
>
Well, he didn't get much chance either, did he?

To counter this:
1/ I could name a number of ways that this could be done;
2/ Why would end-users need to be able to build these packages anyway? 
Quite often packages don't build to start with (see my lbd outputs). 
When innovation is given a chance these possible issues (they weren't 
proven in your post) may be solved.

>So, since the package is flawed ( depending on the hardware is worst than 
>missing buildrequires, as you know ),
>
No, I don't agree.
1/ You don't *need* the hardware to *build* the package, only to use 
that *specific* package;
2/ The end result would have been *multiple* myth-frontend packages 
(from one src.rpm), one package for generic systems, one package for 
nvidia systems, and one package for epia based systems.

>i guess it should be removed.
>
No:
1/ you didn't guess;
2/ you didn't dicuss;
3/ the package was removed, while being inconsitant regarding to other 
PLF packages (win32-codecs, etc).

>However, 
>you still insisted on having it in the archive, and thus requiring nvidia 
>kernel driver, removing all hope of automated rebuilding. As you say, 
>"seems rather inconsistant"
>  
>
The statement above is FUD, as I'm confident that it can be done.

>>>as if he did it without being conscious of the various problem we
>>>highlighted during the discussion.
>>>      
>>>
>>Problem?
>>
>>Discussion?
>>
>>The packages were just removed, the discussion followed afterwards.
>>    
>>
>
>The discussion should have occured before. Having a package requiring a non 
>standard kernel module to be build is just wrong, imho. Having it in Requires 
>is wrong too, to a lesser extend, if we want to be clean.
>  
>
Then you should have discussed that instead of removing the packages. 
But it's not too late, we can always go back and discuss how to do these 
things the "right" way.

>>The real reason why the packages were removed was because they were not
>>considered to "fit" within PLF's (unwritten and undefined) so called
>>"policies". The fact that one of the packages involved is also provided
>>by club, and seems to be a major selling point for the club (read: $$$).
>>In order to not conflict with Club's business interests this package was
>>removed, hence blocking the NV-enabled mythfrontend package.
>>    
>>
>
>There was other issues surrounding the mythfrontend package, like, the 
>question i have asked before.
>A runtime detection should have been added, but none  asked for help about 
>this. But i am not astonished, as Thac is not know for his packaging skills, 
>nor for his team spirit.
>  
>
Wow... I'm really disgusted to read your statement about somebody elses 
skills. How can you judge? Have you ever met in IRL? What have *you* 
done to change this?

I'm ashamed to see this kind of lack of respect on this list.

>So, if the mythfrontend was removed, why keep the ugly hack made by thac, as 
>it was clearly bad from a packaging point of view, bad from a philosohical 
>point of view ( as i already explained ), and uploaded without discussion on 
>any of this two point ?
>  
>
Well, I would see this as "innovation", and sometimes innovation needs 
some tweaking. If there were ugly hacks in his packages, these should 
have been discussed, in an open and fair way. Removing the packages does 
not constitute of a fair & open discussion.

>But well, the past showed mean that some people do not easyly change their 
>mind, i guess i am battling against a wall.
>  
>
...

>>PLF doesn't have any "relationship" with Mandrakesoft (PLF claimed to be
>>independant and even distribution independant), but under the table it
>>seems that some of the PLF maintainers felt they needed to do this.
>>Seems rather Inconsitant to me.
>>    
>>
>
>Being independant doesn't mean to always do the opposite of something to show 
>your independance.
>  
>
IMHO, it shouldn't matter. And in this case there was nothing that was 
doing hurting Club in any way.

>>Conflicting with the arguments that were brought up about the nvidia
>>package being "closed source", "non-free" and other evilness, is the
>>excellent example of the win32-codecs package. This is closed-source,
>>non-free, and non-free-to-redistribute as well. Again, this seems rather
>>inconsitant to me....
>>    
>>
>
>However, no one tell anything when it was uploaded.
>And you didn't said anything before we refused thac nvidia package.
>  
>
Sometimes things get uploaded, as part of the innovative process. Do I 
need to ask Warly, Lenny or a maintainer every time I upload something 
to Mandrakesoft? I don't think so. Yes, I screw up at times (the -24mdk 
bash package for example), but these errors (caused or not caused by me 
directly) can and will be solved.


>>>A split have been decided but we still have some works to do.
>>>      
>>>
>>Seems so. Glad to see you're involved again.
>>
>>    
>>
>>>>Along those lines, but quite off-topic for this list: has the PLF
>>>>project decided on what they're policy will be? Wouldn't it be nice to
>>>>get this cleared up before then end of the year?
>>>>        
>>>>
>>>I would say to search the archives, but our server is down at the moment,
>>>and as you guess, we have some priorities, like salvaging the server,
>>>finishing the migration before doing what have been decided ( splitting
>>>free and non free, as far as i remember ).
>>>      
>>>
>>Have the definitions of "free" and "non-free" been made explicit (ie
>>written down somewhere)?
>>    
>>
>
>Yes.
>But for now, we have more urgent thing to do than to polish the document. We 
>will announce it we it is ready.
>  
>
Excellent. I'm looking forward to it...

Anyway, as the technical issues that we were facing when trying to 
introduce these hardware-specific mythfrontend packages seem to have 
been solved (dkms, etc), would PLF now be willing to accept these packages?

>>Anyway... happy new year!
>>
>>regards,
>>
>>Stefan
>>    
>>

Happy new year,

Stefan

["smime.p7s" (application/x-pkcs7-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]