On Mon, 2018-12-17 at 13:16 +0100, Enrico Weigelt, metux IT consult wrote:
> On 15.12.18 16:37, Ben Hutchings wrote:
>
> Hi,
>
> > > while trying to build a debian kernel w/ some minor config changes>> (actually, just need the gpio keyboard modules), I've stumpled
> across>> several strange problems and finally found out that the
> patches>> haven't been applied on the main tree (in contrast to rt tree)
> .. this>> ate up a lot of time, as the build takes so long
> (unfortunately, I don't>> have the luxory of possessing a 120 core
> machine ;-)).> > There is a script to do what you want,
> debian/bin/test-patches.
> Shouldn't the patches be automatically applied when calling the 'binary'
> rule (./debian/rules) ? If not, this doesn't seem to make much sense :o
If you build from git, the patches are applied by "debian/rules orig",
or if you build from a source package they are applied by
"dpkg-source -x" (by default).
debian/bin/test-patches is a simplified way to add more patches and
build a single kernel flavour, for testing purposes.
> I'm still in the middle of hacking, what I did so far is changing the
> build tree for 'none' to a separate directory, just like for 'rt', using
> the same rules. (essentially dropping special rules for
> $(STAMPS_DIR)/source_none, etc) - now the patches are applied.
>
> The only downside of this change I see so far is that I get yet another
> temporary copy of the full source tree. OTOH, I'm thinking about
> dropping the initial unpack (in the root dir) and change these rules
> to directly unpack from tarball (or optionally pull a git repo).
What would be the benefit of this?
> > > When I look at the build rules, I really wonder why it's all so complex.>>>> Some things that IMHO contribute to that complexity:>>>> * several
> source trees - rt vs none:>> --> can't we do this with one tree ?>>
> --> if necessary, fixup the rt patches, so they don't do anything in>>
> non-rt build (eg. proper #ifdef's) ?> > That would be a huge amount
> of work to maintain.
> Initial work or permanent maintenance ?
> I agree that this takes some initial effort, and I'd like to volounteer
> for that.
>
> BTW: On a quick look, I've seen that patches from
> 'debian/patches/series' are not included in in series-rt. Are they
> supposed to be
> already applied, before the rt tree copy is made ?
Correct. The "$(STAMPS_DIR)/source" target in debian/rules.real has a
check for this.
> > > * auxillary tools>> --> can't we build them completely separately ?>> (IMHO,
> shouldn't have an hard dependency on currently running>> kernel)>
> > They can be disabled with the "pkg.linux.notools" profile.
> Yes, but then they aren't built at all. Fine for my current local case,
> but the distro still needs them. So, my proposal is making them
> completely own source packages - then we wouldn't need play around w/
> profiles anymore and therefore reduce complexity.
We used to do this (linux-tools source package). It required more work
to maintain.
> > > If it's just a matter of resources, I'd like to join in and do the job.> > If you want to help simplify - and I'm sure some simplification is>
> possible - you have to start by understanding why the complexity is>
> there in the first place.
> Yes, that's why I've started this thread: to ask you guys what that's
> really all about :)
OK. Many of your questions are likely to be answered in
debian/README.source or in the debian-kernel-handbook, so you should at
least browse through those.
Ben.
--
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.
::
Re: [devuan-dev] why is the build s…
