Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 May 2022 22:13:26 +0700
From:      Eugene Grosbein <eugen@grosbein.net>
To:        "Julian H. Stacey" <jhs@berklix.com>, freebsd-stable@FreeBSD.org
Cc:        freebsd-current@FreeBSD.org, Ed Maste <emaste@FreeBSD.org>
Subject:   Re: breaking modules
Message-ID:  <1143af76-e4fe-6169-0cc8-9397b54c2afd@grosbein.net>
In-Reply-To: <202205031447.243EkmY5077471@fire.js.berklix.net>
References:  <202205031447.243EkmY5077471@fire.js.berklix.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1143af76-e4fe-6169-0cc8-9397b54c2afd>