Re: breaking modules

From: Julian H. Stacey <jhs_at_berklix.com>
Date: Tue, 03 May 2022 16:24:24 UTC
Hi, Reference:
> From:		Eugene Grosbein <eugen@grosbein.net>
> Date:		Tue, 3 May 2022 22:13:26 +0700

Eugene Grosbein wrote:
> 03.05.2022 21:46, Julian H. Stacey wrote:
> 
> > Hi, Reference:
> >> From:		"Julian H. Stacey" <jhs@berklix.com>
> >> Date:		Fri, 29 Apr 2022 23:57:02 +0200
> > 
> > "Julian H. Stacey" wrote:
> >> Ed Maste wrote:
> >>> On Thu, 28 Apr 2022 at 11:28, Julian H. Stacey <jhs@berklix.com> wrote:
> >>>>
> >>>> but that's crude. It's nice to be able to build most modules ready
> >>>> in case wanted later, so how about a DUDS env. mechanism like ports/ ?
> >>>
> >>> I'd rather not add additional complexity to our build infrastructure
> >>> to address a situation that shouldn't exist. Modules should build &
> >>> function on an ongoing basis (and, I believe they generally do). CI
> >>> doesn't report any issues on either stable branch or main at present.
> >>
> >> I'm building stable-12 not stable-13. It's broken here. I've seen modules break
> >> for years, I used to suspect modules werent built by default by
> >> build engines as often as main src/, so modules had more time to rot against
> >> changing includes & libs, maybe now build engines might compile
> >> them as often as eg bin/ls/ ? I don't know; But I'm seeing modules breaks.
> >>
> >> I just refetched with git this mid Friday afternoon (TZ=+02:00) 12.3-STABLE
> >> & the 2 breaks are still present. See below.
> >>
> >> Setting a MODULE_DUDS would save work rather than repetitively retro
> >> patching out the same modules in Makefile after each git pull --ff-only.
> >>
> >> I'd happily develop a patch for sys/modules/, but if someone
> >> else prefers to, that might increase the chance of it being commited.
> >> I'd be happy to test or develop a fix for sys/modules/Makefile.
> > 
> > Eugene Grosbein wrote:
> >> Unfortunately, CI does not catch stand-alone module build failures,
> >> out of kernel build directory.
> >>
> >> For example:
> >>
> >> if_em		https://cgit.freebsd.org/src/commit/?id=c0460cf2e42d2819c1f191a1d6e1b3dc0c7ea010
> >> if_epair	https://cgit.freebsd.org/src/commit/?id=7a382e744b0b0ba9b51dc34bfa0cd1515f744f25
> >> linuxkpi	https://cgit.freebsd.org/src/commit/?id=f5a2e7b0e8483bf51519046fd149a6a31acef6b1
> > 
> > 
> > I developed a fix, patch appended, mastered inc. a mini test Makefile at
> >  http://berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/sys/modules/
> > 
> > Filed with https://bugs.freebsd.org/bugzilla/enter_bug.cgi as
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758
> > 
> > I added cc: current@, Would someone like to try it please ?
> > 
> > BTW I've not yet but will later read how DUDS is implemented in
> > 	/usr/ports/Mk/bsd.port.subdir.mk
> 
> I filled https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263750
> with a patch fixing standalone build of random_fortuna and random_other.
> 
> Please test the patch in the PR 263750 and report back if it fixes the problem for you, too.

Yes, I confirm the logic of your patch marked Comment2 2022-05-03 09:12:25 UTC 
lets both random_fortuna and random_other compile on my 12.3-STABLE. 
Thanks !

However, a patch quibble:
First I saved the page with firefox, scissored the pre & post HTML crud,
	cd /sys/modules ; patch -p2 < ~/Downloads/263750.diff
failed, so I hand patched.
The patch command failed as excess spaces in the patch, original tabs lost.
	fetch 'https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263750'
confirms unwanted spaces in the patch.
There are tabs in 12.3-STABLE.

Cheers,
-- 
Julian Stacey  http://berklix.com/jhs/ http://StolenVotes.UK  
Kill / remove Putin: He kills innocents & causes global grain & fuel shortage.