07.11.2010 19:13, KP Kirchdoerfer пишет:
> Am Sonntag, 7. November 2010, 17:11:30 schrieb Andrew:
>> 07.11.2010 18:02, davidMbrooke пишет:
>>> On Sun, 2010-11-07 at 16:35 +0100, KP Kirchdoerfer wrote:
>>>> Am Sonntag, 7. November 2010, 16:19:58 schrieb davidMbrooke:
>>>>> Hi,
>>>>>
>>>>> I have just run a full rebuild and buildall.sh failed on "kmodules":
>>>>>
>>>>> calling buildpacket for kmodules
>>>>> Generating package moddb-geode
>>>>> cp: cannot stat
>>>>> `/home/leaf/src/bering-uclibc4/buildtool/staging/lib/modules/2.6.35.8-g
>>>>> eode /net/pptp.ko': No such file or directory Copying
>>>>> file
>>>>> /home/leaf/src/bering-uclibc4/buildtool/staging/lib/modules/2.6.35.8-ge
>>>>> ode /net/pptp.ko failed. No such file or directory at ./buildpacket.pl
>>>>> line 461 main::system_exec('cp
>>>>> -r /home/leaf/src/bering-uclibc4/buildtool/staging/lib/mod...',
>>>>> 'Copying file /home/leaf/src/bering-uclibc4/buildtool/staging/...')
>>>>> called at ./buildpacket.pl line 565
>>>>>
>>>>> main::copyBinariesToPackageStaging('HASH(0x2a5a4c8)',
>>>>>
>>>>> '/home/leaf/src/bering-uclibc4/buildtool/staging') called
>>>>> at ./buildpacket.pl line 1215
>>>>>
>>>>>
>>>>> dMb
>>>> Try again again after you've run buildclean accel-pptp and build
>>>> accel-pptp.
>>>>
>>>> I guess we have had a misunderstanding about what to do with modules
>>>> like pptp from accel-pptp. I think they should not provided in the
>>>> package (accel-pptp) in this case, but with the modules tarball. Andrew
>>>> put it into moddb (kmodules).
>>>> This way moddb may grow too much in the long run, and we start to make
>>>> things complicated due to (unnecessary) dependencies. Unnecessary cause
>>>> the whole build process fails if accel-pptp is not (re)builded, but
>>>> it's basically a special, which can be build later or neverever, if the
>>>> module is just in the tarball and not in moddb.
>>>>
>>>> kp
>>> Thanks kp. That fixed it, as a workaround until Andrew (or someone else)
>>> can give this some attention. I remember Andrew saying he is busy for
>>> the next few days...
>>>
>>> dMb
>> You may include accel-pptp into dependencies for moddb. It'll fix trouble.
> Yep, I know how to solve that, but my main question was, what's the reason to
> add it to moddb at all?
> Even if we are not as space constrained than we was with the floppy, pls let
> us
> be careful, what to add to the base files and what can be added by the users
> who really need the modules.
> accel-pptp is something not everyone needs and adding (and loading) the module
> by default is IMHO unnecessary. If we do that we should have a good reason to
> do so. To explain it further - I think we should add the via-rhine driver,
> cause it's needed by Alix boards, which are more or less officially supported
> with the geode-images. I won't add tun.ko even it's widely used for aiccu
> and/or openvpn. We also don't add any wifi driver right from the start....
>
The reason is same as reason for other ppp-related modules. Accel-pptp
is up to some times faster than user-level pptp client/server, so it's
preferred as default pptp client/server. However, if in scripts will be
realized automatic module extraction from tarball, we may exclude these
modules.
About via-rhine - agreed, it also usable for VIA-based K7/K8 boards.
>> This trouble will be fixed radically when distro will be moved to newer
>> kernel - because in 2.6.36 pptp module is already in the kernel.
> And therefor in the modules tarball as most of the current kernel modules.
>
Hm, I missed about PPTP kernel support - it'll be in 2.6.37, which is
planned for January.
>> And
>> IMHO it will be done before we do 4.0 release :) In 2.6.36 kernel a lot
>> of obsolete/unused code was removed - so kernel will be smaller.
>> Now I don't want to switch to fresh kernel because it can be not enough
>> stable - so I want to wait for 2.6.36.2 or higher patch.
> Well, I do have objections:
> First I don't think its a good idea to switch the kernel (and related
> packages) between beta1 and the final release. In that time we should try to
> fix
> bugs and update packages only if needed to do so.
Ok, so we will stay on 2.6.35 kernel branch on 4.0, just updating
periodically kernel to fresher patchset(extraversion) (IMHO this will
not break anything even if users will have older modules with fresher
kernel - because modifications mostly are bugfixes), and when we will
see that 2.6.37 kernel is released and is enough stable - it'll be time
to develop 4.1 version. Especially because there are enough things to do
after 4.0 release - for ex., assembling busybox as separate executables
instead single file.
Or, we can include into beta release 2.6.36 kernel. Main features of it
- IMHO smaller code (due to clean-ups) and included LIRC modules. But I
doubt about it's stability.
> Second, we may have an eye on the "embedded flag" proposal
> (http://lwn.net/Articles/413341/rss), though I don't know yet, if it really
> helps us. Interestingly enough, it will flag 2.6.35, and I think if there is
> intersting "embedded kernel development" it will be targeted to this "flagged"
> version.
>
> kp
This is useful for long-term supported branch, which may be developed
for years. - something like 2.6.16 kernel, which support was dropped by
kernel.org not so far, or currently 2.6.27 kernel.Possible it will not
be enough useful - it seems that currently Linux kernel is developed
enough fast, and each 2nd-3rd release has enough fresh and useful
features to switch on it.
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
