Re: Build breakage with WITH_BEARSSL=1
Hi Warner,
On Wed, Feb 15, 2023 at 10:07:08AM -0700, Warner Losh wrote:
> On Sun, Feb 12, 2023, 3:18 PM Warner Losh wrote:
> > On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling wrote:
> >
> >> Hi,
> >>
> >> I am currently seeing a build breakage when building -CURRENT with
> >> WITH_BEARSSL=1.
> >>
> >> The error is the following
> >>
> >> make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
> >> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls' -1 *.pem t*.asc 2>
> >> /dev/null" returned non-zero status
> >> /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error:
> >> a function declaration without a prototype is deprecat ed in all versions
> >> of C [-Werror,-Wstrict-prototypes]
> >> br_rsa_i62_keygen_get()
> >>^
> >> void
> >> 1 error generated.
> >> --- rsa_i62_keygen.pico ---
> >>
> >>
> >> When disabling BEARSSL in the src.conf the build succeeds as usual.
> >>
> >> Has anyone also seen this build error. Sources are very recent and the
> >> src.conf is the following:
> >>
> >> WITH_EXTRA_TCP_STACKS=1
> >> #WITH_BEARSSL=1
> >> WITH_PIE=1
> >> WITH_RETPOLINE=1
> >> WITH_INIT_ALL_ZERO=1
> >> WITH_OPENSSL_KTLS=1
> >> WITHOUT_CLEAN=1
> >>
> >> Any help is very appreciated.
> >>
> >>
> > What does the following do for you? It's a cut and pasted patch, but it
> > should be clear enough what to do if the mailer mangles it.
> >
> > diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
> > index dd0e242c8ef0..2af4864d8441 100644
> > --- a/lib/libbearssl/Makefile.inc
> > +++ b/lib/libbearssl/Makefile.inc
> > @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
> > BEARSSL_SRC= ${BEARSSL}/src
> >
> > CFLAGS+= -I${BEARSSL}/inc
> > -
> > +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
> >
>
> I went ahead and committed this. Please let me know if the problem persists.
Sorry for the late reply. I just tried a fresh build and it still fails with
[..]/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a function
declaration without a prototype is deprecated in all versions of C
[-Werror,-Wstrict-prototypes]
br_rsa_i62_keygen_get()
Did you see any other possibilty to fix this?
--Gordon
signature.asc
Description: PGP signature
Re: 1 year src-patch anniversary!
On Mon, 30 Jan 2023 03:54:48 +0100
"Julian H. Stacey" wrote:
> Jamie Landeg-Jones wrote:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
> > to an admittedly trivial issue, but it's soon going to hit one year old,
> > and has not had any feedback. Not even "this is rubbish. close ticket"
> >
> > | jamie@catwalk:~ % stat 'so good they named it twice'
> > | stat: so good they named it twice: stat: No such file or directory
> >
> > As such, it's the oldest of my patches to be completely ignored, but then,
> > most of my fixes I haven't even submitted, because, what's the point?
> > I've instead spent time writing something so the patches are automatically
> > aplied to my src tree, and distributed to all my servers.
>
> I wrote a tool in 1993 I still use
> http://www.berklix.com/~jhs/bin/.csh/customise
> to apply trees of generic & personal diffs to src & ports, for multi releases
> http://www.berklix.com/~jhs/src/
> to apply diffs, where some are submitted, some committed
> for some versions, some diffs still needed for older versions, &
> some not submitted or committed.
>
> I guess many, especially non-commiters, maintain trees of uncommited
> diffs & there's probably other applicator scripts, numerous
> re-inventing of wheels for decades, 'cos send-pr /
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & volunteer unpaid
> commiters can't keep up with submissions.
>
> & non committers can't afford to wait months or years, remembering
> what's been seen commited to Release X.Y & what still needs to be
> kept to apply to other inc. older releases. Probably lots of
> re-invented wheels: trees of diffs & applicator scripts, but to
> different standards, not uniformly exportable, not immediately
> familiar to & usable by others.
>
> While retaining the model of "This generic src/ ports/ doc/ tree
> has been built from patches blessed by commiters as fit for all"
>
> FreeBSD hackers(especially non commiters who must wait for commits
> to reduce their heap of candidate diffs) would benefit from a unified
> set of tools & directory formats to allow individuals to maintain
> & export trees of candidate diffs etc to some common standards.
>
> It wouldnt obviate / replace send-pr &
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & git etc, but would
> be an optional normalied convenience, especially beneficial to those
> who are Not commiters but who have growing heaps of uncommited patches.
>
> Maybe a summer of code or other person might look at Jamie's & my
> applicator scripts, & diff tree shapes, not for our actual current diffs,
> but to design common unified standards to export trees of candidate diffs
> that can be applied by one common applicator tool ?
>
> Hacker who are not committers presumably accumulate an an ever
> growing heap of diffs, a burden best normalised & automated.
>
> > I know it's a volunteer effort, but I've been here 25 years, and whilst
> > I could (and should) take on more port-maintainership, any other offers
> > of help have fallen on deaf ears.
> >
> > *shrug* I miss Mark Linimon.
>
> Cheers,
> --
> Julian Stacey http://StolenVotes.UK/jhs/ Arm Ukraine, Zap Putin.
Just FYI:
Attached is the sh script I've been using for years to apply/revert
multiple patches at once, basically for patches uploaded on bugzilla.
I know it's far from perfect, but maybe handy for casual users who have
any problem with genuine base or ports and needs multiple patches
uploaded on bugzilla, phabricator or anywhere else.
The attachement itself should have been stripped by the ML server,
but maybe you can see it via "Original text of this message" link
at the bottom of the mail archive of this message.
--
Tomoaki AOKI
#!/bin/sh
# multipatch: Apply / revert multiple patches at once.
# Copyright (C) Mar. 16, 2017 by Tomoaki AOKI all rights reserved.
IGNORE_OPT="-p"
DRY_OPT="-C"
REV_OPT="-R -E"
DFL_OPT="-i"
OPTION=""
TMPFILE=/tmp/multipatch00
__usage() {
cat << EOF
Usage: multipatch (-fc | -f | -rc | -r | -h) filename
multipatch: Apply / revert multiple patches listed in filename.
The list file shall list one patchfile per line, lead by ignored depth.
Parameters:
-r : Revert listed patches.
-rc: Revert listed patches (dry run).
-f : Apply listed patches.
-fc: Apply listed patches (dry run).
-h: show this help
File format example:
1 ~/LocalPatches/patch1.diff
0 ~/LocalPatches/patch2.patch
where src filenames in patch1.diff is like a/sys/kernel/init_sysent.c
and src filenames in patch2.patch is like sys/amd64/conf/GENERIC
EOF
exit 0
}
if [ 0 -eq $# ]
then
__usage
fi
case "$1" in
"-rc")
MODE="REVDRY"
OPTION="${REV_OPT} ${DRY_OPT}"
;;
"-r")
MODE="REV"
OPTION="${REV_OPT}"
;;
"-fc")
MODE="FWDDRY"
OPTION="${DRY_OPT}"
;;
"-f")
MODE="FWD"
OPTION=""
;;
"-c")
MODE="DRY"
OPTION="${DRY_OPT}"
;;
"-h"|"--help")
__usage
;;
*)
__usage
;;
esac
shift
LSTFILE=$1
echo ${LSTFILE}
if [ -e
Re: Build breakage with WITH_BEARSSL=1
On Wed, Feb 15, 2023, 1:09 PM Mina Galić wrote:
> Would be nice if we could get upstream to actually fix this, but i don't
> even know how to submit bugs there…
>
Agreed. I didn't recall off of the top of my head, so I did the quick
bandaid.
Warner
Mina Galić
>
> Try PkgBase: https://alpha.pkgbase.live/
>
>
>
>
>
>
> Original Message
> On 15 Feb 2023, 17:07, Warner Losh < i...@bsdimp.com> wrote:
>
>
>
>
> On Sun, Feb 12, 2023, 3:18 PM Warner Losh wrote:
>
>>
>>
>> On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling wrote:
>>
>>> Hi,
>>>
>>> I am currently seeing a build breakage when building -CURRENT with
>>> WITH_BEARSSL=1.
>>>
>>> The error is the following
>>>
>>> make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
>>> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls' -1 *.pem t*.asc 2>
>>> /dev/null" returned non-zero status
>>> /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error:
>>> a function declaration without a prototype is deprecat ed in all versions
>>> of C [-Werror,-Wstrict-prototypes]
>>> br_rsa_i62_keygen_get()
>>>^
>>> void
>>> 1 error generated.
>>> --- rsa_i62_keygen.pico ---
>>>
>>>
>>> When disabling BEARSSL in the src.conf the build succeeds as usual.
>>>
>>> Has anyone also seen this build error. Sources are very recent and the
>>> src.conf is the following:
>>>
>>> WITH_EXTRA_TCP_STACKS=1
>>> #WITH_BEARSSL=1
>>> WITH_PIE=1
>>> WITH_RETPOLINE=1
>>> WITH_INIT_ALL_ZERO=1
>>> WITH_OPENSSL_KTLS=1
>>> WITHOUT_CLEAN=1
>>>
>>> Any help is very appreciated.
>>>
>>>
>> What does the following do for you? It's a cut and pasted patch, but it
>> should be clear enough what to do if the mailer mangles it.
>>
>> diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
>> index dd0e242c8ef0..2af4864d8441 100644
>> --- a/lib/libbearssl/Makefile.inc
>> +++ b/lib/libbearssl/Makefile.inc
>> @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
>> BEARSSL_SRC= ${BEARSSL}/src
>>
>> CFLAGS+= -I${BEARSSL}/inc
>> -
>> +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
>>
>
> I went ahead and committed this. Please let me know if the problem
> persists.
>
> Warner
>
>>
Re: Build breakage with WITH_BEARSSL=1
Would be nice if we could get upstream to actually fix this, but i don't even
know how to submit bugs there…
Mina Galić
Try PkgBase: https://alpha.pkgbase.live/
Original Message
On 15 Feb 2023, 17:07, Warner Losh wrote:
> On Sun, Feb 12, 2023, 3:18 PM Warner Losh wrote:
>
>> On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling wrote:
>>
>>> Hi,
>>>
>>> I am currently seeing a build breakage when building -CURRENT with
>>> WITH_BEARSSL=1.
>>>
>>> The error is the following
>>>
>>> make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
>>> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls' -1 *.pem t*.asc 2>
>>> /dev/null" returned non-zero status
>>> /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a
>>> function declaration without a prototype is deprecat ed in all versions of
>>> C [-Werror,-Wstrict-prototypes]
>>> br_rsa_i62_keygen_get()
>>> ^
>>> void
>>> 1 error generated.
>>> --- rsa_i62_keygen.pico ---
>>>
>>> When disabling BEARSSL in the src.conf the build succeeds as usual.
>>>
>>> Has anyone also seen this build error. Sources are very recent and the
>>> src.conf is the following:
>>>
>>> WITH_EXTRA_TCP_STACKS=1
>>> #WITH_BEARSSL=1
>>> WITH_PIE=1
>>> WITH_RETPOLINE=1
>>> WITH_INIT_ALL_ZERO=1
>>> WITH_OPENSSL_KTLS=1
>>> WITHOUT_CLEAN=1
>>>
>>> Any help is very appreciated.
>>
>> What does the following do for you? It's a cut and pasted patch, but it
>> should be clear enough what to do if the mailer mangles it.
>>
>> diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
>> index dd0e242c8ef0..2af4864d8441 100644
>> --- a/lib/libbearssl/Makefile.inc
>> +++ b/lib/libbearssl/Makefile.inc
>> @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
>> BEARSSL_SRC= ${BEARSSL}/src
>>
>> CFLAGS+= -I${BEARSSL}/inc
>> -
>> +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
>
> I went ahead and committed this. Please let me know if the problem persists.
>
> Warner
>
>>
Re: Build breakage with WITH_BEARSSL=1
On Sun, Feb 12, 2023, 3:18 PM Warner Losh wrote:
>
>
> On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling wrote:
>
>> Hi,
>>
>> I am currently seeing a build breakage when building -CURRENT with
>> WITH_BEARSSL=1.
>>
>> The error is the following
>>
>> make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109:
>> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls' -1 *.pem t*.asc 2>
>> /dev/null" returned non-zero status
>> /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error:
>> a function declaration without a prototype is deprecat ed in all versions
>> of C [-Werror,-Wstrict-prototypes]
>> br_rsa_i62_keygen_get()
>>^
>> void
>> 1 error generated.
>> --- rsa_i62_keygen.pico ---
>>
>>
>> When disabling BEARSSL in the src.conf the build succeeds as usual.
>>
>> Has anyone also seen this build error. Sources are very recent and the
>> src.conf is the following:
>>
>> WITH_EXTRA_TCP_STACKS=1
>> #WITH_BEARSSL=1
>> WITH_PIE=1
>> WITH_RETPOLINE=1
>> WITH_INIT_ALL_ZERO=1
>> WITH_OPENSSL_KTLS=1
>> WITHOUT_CLEAN=1
>>
>> Any help is very appreciated.
>>
>>
> What does the following do for you? It's a cut and pasted patch, but it
> should be clear enough what to do if the mailer mangles it.
>
> diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc
> index dd0e242c8ef0..2af4864d8441 100644
> --- a/lib/libbearssl/Makefile.inc
> +++ b/lib/libbearssl/Makefile.inc
> @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl
> BEARSSL_SRC= ${BEARSSL}/src
>
> CFLAGS+= -I${BEARSSL}/inc
> -
> +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE}
>
I went ahead and committed this. Please let me know if the problem persists.
Warner
>
Re: 1 year src-patch anniversary!
Warner Losh wrote: > Bugzilla is inefficient for small patches. Yes, I can see that bugzilla is unsuitable for things like that. > I'm trying an experiment on github: any smallish, almost ready patches will > be landed, redirected or rejected quickly Thanks Warner! That sounds great! - I'll be taking you up on that! Another thing - my last port maintainer update was converted to a phabricator post, as was the recent patch that delphij committed. Should I have posted them there instead to save the committers time? I always thought new phabricator posts were for committers only, as it seems to me to be a way for committers to get their code reviewed and passed prior to committing. Cheers, Jamie
Re: 1 year src-patch anniversary!
"Julian H. Stacey" wrote: Firstly, apolgies for the delay in replying. > I wrote a tool in 1993 I still use > http://www.berklix.com/~jhs/bin/.csh/customise > to apply trees of generic & personal diffs to src & ports, for multi releases > http://www.berklix.com/~jhs/src/ > to apply diffs, where some are submitted, some committed > for some versions, some diffs still needed for older versions, & > some not submitted or committed. Thanks, I'll look at that. > I guess many, especially non-commiters, maintain trees of uncommited > diffs & there's probably other applicator scripts, numerous > re-inventing of wheels for decades, 'cos send-pr / > https://bugs.freebsd.org/bugzilla/enter_bug.cgi & volunteer unpaid > commiters can't keep up with submissions. Yep :-( And to the committers: I'm not meaning to complain - I know it's a volunteer effort, but sometimes it can be frustrating. This particular bug I've highlighted is laughably trivial and inconsequential, but as Julian says, there must be many people who end up doing the same thing, and that all adds up to lots of wasted work that could be better channeled. What can we do to help? > FreeBSD hackers(especially non commiters who must wait for commits > to reduce their heap of candidate diffs) would benefit from a unified > set of tools & directory formats to allow individuals to maintain > & export trees of candidate diffs etc to some common standards. > > It wouldnt obviate / replace send-pr & > https://bugs.freebsd.org/bugzilla/enter_bug.cgi & git etc, but would > be an optional normalied convenience, especially beneficial to those > who are Not commiters but who have growing heaps of uncommited patches. > > Maybe a summer of code or other person might look at Jamie's & my > applicator scripts, & diff tree shapes, not for our actual current diffs, > but to design common unified standards to export trees of candidate diffs > that can be applied by one common applicator tool ? > > Hacker who are not committers presumably accumulate an an ever > growing heap of diffs, a burden best normalised & automated. That's a good idea. I'm happy to describe/publish my mechanisms - I've been meaning to publish all my tools in case they help anyone, but time keeps getting in the way! As for the patches, it's quite basic: for src, all patch-files in a common directory-tree (synced to my machines along with other common directories/tools) are applied after each git sync. The tree contains directories for "all versions" patches, and then directories for differing FreeBSD versions. For ports, I have 3 sets of common patch directories: 1) Patches to the port-templates (i.e. the build files under /usr/ports) 2) Patches to the ports source itself. 3) "Overrides" - directories containing the port-templates for a port that are installed after a port-sync. These are usually "deleted" ports that I actually still use, local-port hacks that no-one else would care about, and less-often complete overrides of ports for various reasons. There is glue code to ensure these are all automatically actioned. I'd love to get involved with anything that can help streamline this, whether src or ports. Cheers, Jamie
Re: 1 year src-patch anniversary!
On Wed, Feb 15, 2023, 7:11 AM Jamie Landeg-Jones wrote: > Mateusz Guzik wrote: > > > Well I was not aware of it. > > Apologies for the delay in replying. Fair enough you weren't aware, but the > thing is, how do we make people aware? > > If bugs.freebsd.org is no longer the way to go, what's the alternative? > Bugzilla is inefficient for small patches. I'm trying an experiment on github: any smallish, almost ready patches will be landed, redirected or rejected quickly Warner > mail me with git format-patch result and I'll commit. > > Thanks! However, in this case, "delphij" has already done it. > > Cheers, Jamie > >
Re: 1 year src-patch anniversary!
Mateusz Guzik wrote: > Well I was not aware of it. Apologies for the delay in replying. Fair enough you weren't aware, but the thing is, how do we make people aware? If bugs.freebsd.org is no longer the way to go, what's the alternative? > mail me with git format-patch result and I'll commit. Thanks! However, in this case, "delphij" has already done it. Cheers, Jamie
