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.
Attachment:
signature.asc
Description: This is a digitally signed message part