Am Sonntag, 7. November 2010, 19:14:20 schrieb Andrew:
> 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.
They can always added as every other module, if someone needs those. I assume
pptp is not as widely used as ppp - maybe I'm wrong.
> About via-rhine - agreed, it also usable for VIA-based K7/K8 boards.
> >> 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),
Agreed.
> 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.
I'd say let us go with 2.6.35 and start to release beta1 ASAP.
(btw: I do have one outstanding issue "apkg -u" :))
> > 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.
I myself not shure if it will be a benefit for us, but let's not forget it
seems users also uses LEAF distros for years. I guess they'll welcome non-
intrusive updates more than switching to a new kernel. But that's something to
think about later.
kp
------------------------------------------------------------------------------
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
