Hello Mina,
thanks for the PR, I can confirm that this bugfix is working.
@Warner, could you commit it?
I think creating a differential for the small change isn't neccessary.
--Gordon
On Thu, Feb 23, 2023 at 10:05:25AM +, Mina Galić wrote:
> taking Simon off the list, cuz his auto - reply
taking Simon off the list, cuz his auto - reply indicates he's very busy.
Either way, t should do it: https://github.com/freebsd/freebsd-src/pull/657
Mina Galić
Try PkgBase: https://alpha.pkgbase.live/
Original Message
On 23 Feb 2023, 09:57, Mina Galić wrote:
> given that thi
given that this isn't contrib code, we can just fix it in our tree:
https://github.com/freebsd/freebsd-src/blob/main/sbin/veriexec/veriexec.c#L52
Mina Galić
Try PkgBase: https://alpha.pkgbase.live/
Original Message
On 23 Feb 2023, 09:27, Gordon Bergling wrote:
> Hi Simon, On
Hi Simon,
On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote:
> This has been fixed upstream, I'll look at importing an update.
Thanks for merging the upstream fix. BearSSL is now compiling, but I get a
different error now while building veriexec.
/boiler/nfs/src/sbin/veriexec/ve
This has been fixed upstream, I'll look at importing an update.
; >
> > >> Hi,
> > >>
> > >> I am currently seeing a build breakage when building -CURRENT with
> > >> WITH_BEARSSL=1.
> > >>
> > >> The error is the following
> > >>
> > >> make[5]: "/boiler/
Stephane Rochoy wrote:
> It may be worth contacting BearSSL's maintainer directly: Thomas
> Pornin . The guy was very responsive and helpful
> back in 2020 :)
Indeed.
Warner Losh 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.
I can reach out to the author, I don't know that he has a bug tracker.
What is
--- Original Message ---
On Thursday, February 16th, 2023 at 08:30, Stephane Rochoy
wrote:
> Warner Losh i...@bsdimp.com writes:
>
> > On Wed, Feb 15, 2023, 1:09 PM Mina Galić free...@igalic.co
> > wrote:
> >
> > > Would be nice if we could get upstream to actually fix this,
> > > b
Warner Losh writes:
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.
Hi,
It may be worth contacti
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
;
> 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 1
h 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
>>>
>&
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
>
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:
On Sun, 12 Feb 2023 11:54:47 +0100
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:
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
On Tue, Mar 7, 2017 at 12:36 PM, Chris H wrote:
> On Tue, 7 Mar 2017 09:13:58 -0800 Kevin Oberman wrote
>
>> On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov wrote:
>>
>> > On 06.03.2017 20:10, Lev Serebryakov wrote:
>> >
>> > > I've got this error when tried to update my -CURRENT VM to r314772:
On Tue, 7 Mar 2017 09:13:58 -0800 Kevin Oberman wrote
> On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov wrote:
>
> > On 06.03.2017 20:10, Lev Serebryakov wrote:
> >
> > > I've got this error when tried to update my -CURRENT VM to r314772:
> > >
> > > /data/src/sys/cam/cam_xpt.c:84:1: error: st
On Mon, Mar 6, 2017 at 9:18 AM, Lev Serebryakov wrote:
> On 06.03.2017 20:10, Lev Serebryakov wrote:
>
> > I've got this error when tried to update my -CURRENT VM to r314772:
> >
> > /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
> > "XPT_PRINT_LEN is too large"
> > _Static_assert
On 06.03.2017 20:10, Lev Serebryakov wrote:
> I've got this error when tried to update my -CURRENT VM to r314772:
>
> /data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
> "XPT_PRINT_LEN is too large"
> _Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
> large");
I've got this error when tried to update my -CURRENT VM to r314772:
/data/src/sys/cam/cam_xpt.c:84:1: error: static_assert failed
"XPT_PRINT_LEN is too large"
_Static_assert(XPT_PRINT_LEN <= XPT_PRINT_MAXLEN, "XPT_PRINT_LEN is too
large");
^ ~
I did
On Fri, Feb 26, 2016 at 09:23:16AM -0500, Shawn Webb wrote:
> Hey All,
>
> It looks like a recent commit to HEAD broke the `real-release` target in
> /usr/src/release. I suspect it's the capserd-related commits, but I
> haven't confirmed, yet. I'm going to spend some time trying to nail down
> whi
Hey All,
It looks like a recent commit to HEAD broke the `real-release` target in
/usr/src/release. I suspect it's the capserd-related commits, but I
haven't confirmed, yet. I'm going to spend some time trying to nail down
which commit.
Here's the build log:
http://jenkins.hardenedbsd.org:8180/j
Heads up, seems compiling a kernel as of tonights broken
CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE
-DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq
-I/usr/obj/usr/src/sys/GENERIC -std=iso9899:1999
/usr/src/sys/modules/cpufreq/../../dev/cpufreq/ichss.c
/usr/src/sys/mo
With this morning's sources, my kernel build is failing in the "en"
module:
/a/src/sys/dev/en/midway.c: In function `en_get_vccs':
/a/src/sys/dev/en/midway.c:1474: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1474: dereferencing pointer to incomplete type
/a/src/sys/dev/en/m
[ Data: 2002-10-26 ]
> [ Subjecte: possible kernel build breakage. ]
> >
> > I'm about to do a make world
> > so it's possible a gcc change I've not yet picked up
> > may fix this, but in the meanwhile, I can't compile a kernel
> > be
On Sat, Oct 26, 2002 at 05:08:39PM -0700, Juli Mallett wrote:
> You need a recompile of GCC. This change was made to accomodate the POSIX
> %z by renaming the DDB %z to %y, and GCC had to be made aware.
The recommended upgrade procedure (buildworld, followed by buildkernel
etc) should automatical
You need a recompile of GCC. This change was made to accomodate the POSIX
%z by renaming the DDB %z to %y, and GCC had to be made aware.
* De: Julian Elischer <[EMAIL PROTECTED]> [ Data: 2002-10-26 ]
[ Subjecte: possible kernel build breakage. ]
>
> I'm about to do
I'm about to do a make world
so it's possible a gcc change I've not yet picked up
may fix this, but in the meanwhile, I can't compile a kernel
because of:
ref3# make
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
>From a tree that I updated last night, building on a 4.7-stable
system:
as -o boot2.o boot2.s
as --defsym SIOPRT=0x3f8 --defsym SIOFMT=0x3 --defsym SIOSPD=9600
/home/imp/FreeBSD/src/sys/boot/i386/boot2/sio.s -o sio.o
ld -nostdlib -static -N -Ttext 0x2000 -o boot2.out
/usr/obj/home/imp/Fre
On Fri, 2002-03-22 at 22:27, Maxim Konovalov wrote:
> > Fresh (todays) -current not builds on current machine:
...
> Did you read
>
> 20020225:
> Warnings are now errors in the kernel. Unless you are a developer,
> you should add -DNO_WERROR to your make line.
No, It seems I h
On 22:14+0300, Mar 22, 2002, Vladimir B. Grebenschikov wrote:
>
> Fresh (todays) -current not builds on current machine:
>
> vbook#/sys/i386/compile/VBOOK 142_> make kernel-depend && make kernel
> rm -f .olddep
> if [ -f .depend ]; then mv .depend .olddep; fi
> make _kernel-depend
> if [ -f .old
Fresh (todays) -current not builds on current machine:
vbook#/sys/i386/compile/VBOOK 142_> make kernel-depend && make kernel
rm -f .olddep
if [ -f .depend ]; then mv .depend .olddep; fi
make _kernel-depend
if [ -f .olddep ]; then mv .olddep .depend; fi
rm -f .newdep
make -V CFILES -V SYSTEM_CFIL
I think it is necessary to add the notice to UPDATING because it's been
half an year since the incident day. If it were like within last few
days, I definitely would've gotten some hints about the fix by scanning
-current (which I did). But I had to scratch my heads helplessly until
I asked the
On Sat, Dec 01, 2001 at 01:26:11PM -0800, Eugene M. Kim wrote:
> Oh, never mind. I just re-read the thread you pointed (thanks) and
> saw it affects the systems *installed around the breakage date*.
>
> UPDATING does not mention about this fact (it simply says `Building
> perl was broken'); perh
Oh, never mind. I just re-read the thread you pointed (thanks) and saw
it affects the systems *installed around the breakage date*.
UPDATING does not mention about this fact (it simply says `Building perl
was broken'); perhaps it should be updated to mention the misfortune of
the installed syste
Well, I *did* read UPDATING, and I saw the perl breakage notice. But it
seems not to be relevant to me, as my source code is current (I mean, up
to date); I cvsupped it just before starting make world. Only my host
system is built around May 1.
Thanks,
Eugene
On Sat, Dec 01, 2001 at 05:18:45PM
On Thu, Nov 29, 2001 at 10:42:45AM -0800, Eugene M. Kim wrote:
> Hello,
>
> I am getting the following error in the make depend stage; could anyone
> shed a light?
>
> (The host system is 5-current as of around May 1.)
>From UPDATING (you do read UPDATING, don't you?):
20010502:
Perl b
Hello,
I am getting the following error in the make depend stage; could anyone
shed a light?
(The host system is 5-current as of around May 1.)
Thanks,
Eugene
snip snip
===> libperl
===> miniperl
===> perl
Extracting config.h (with
In article <[EMAIL PROTECTED]>,
Mike Meyer <[EMAIL PROTECTED]> wrote:
>
> Yes, the version I have is out of date. It came from
> cvsup5.freebsd.org over 24 hours after the commit.
Everybody, if you find that a CVSup mirror site is running that far
behind, please drop a note to the site's mainta
In message <[EMAIL PROTECTED]> Mike Meyer writes:
: Pointing fingers isn't the difference I was talking about. It's more
: in the attitude after the fact. On FreeBSD, it's "Ok, I fixed
: it." Elsewhere, people apologize for breaking the bulid.
I sent out a message at the time saying I'm sorry for
Warner Losh writes:
> So we're down to stale sources at one of the mirrors, I think. My
> kernel tree here is completely clean and checked out from the my local
> cvs tree. Where do you get your sources from? What revision of
> src/sys/dev/pccard/card_if.m do you have? The following changed f
On Sun, 13 Aug 2000, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Mike Meyer <[EMAIL PROTECTED]> wrote:
>
> > Won't the 'cvs diff' command tell you about such things?
>
> No, but "cvs -nq update" will, and it's a lot faster too.
I normally use that, but "cvs status | grep Status" m
In article <[EMAIL PROTECTED]>,
Mike Meyer <[EMAIL PROTECTED]> wrote:
> Won't the 'cvs diff' command tell you about such things?
No, but "cvs -nq update" will, and it's a lot faster too.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra &
In message <06e001c004fa$39e94d60$[EMAIL PROTECTED]> "Leif Neland" writes:
: What if the machine building snapshots took a note of the time it cvsup'ped.
: Then if the build succeded, it would append this date to a file.
: We could then feed this date to our cvsup, to get a version which at least
In message <[EMAIL PROTECTED]> Mike Meyer writes:
: Hmm - you mean 'cvs diff' can't be pointed at sys to get a list of
: everything you've touched?
No, I mean that I have NEWCARD changes as well, that usually never get
touched. And it is sometimes easy to get things confused.
: I just now grab
In message <[EMAIL PROTECTED]> "David O'Brien" writes:
: On Sun, Aug 13, 2000 at 01:14:09AM -0600, Warner Losh wrote:
: > : Won't the 'cvs diff' command tell you about such things? If not,
: > : that's yet another argument for ditching cvs in favor of something
: > : without so many flaws (like Pe
Warner Losh writes:
> In message <[EMAIL PROTECTED]> Mike Meyer writes:
> : Warner Losh writes:
> : > In message <[EMAIL PROTECTED]> Mike Meyer writes:
> : > : The nasty downside of the the module system is that people who don't
> : > : adequately test module code before checking it in will screw
On Sun, Aug 13, 2000 at 01:14:09AM -0600, Warner Losh wrote:
> : Won't the 'cvs diff' command tell you about such things? If not,
> : that's yet another argument for ditching cvs in favor of something
> : without so many flaws (like Perforce).
>
> Not when the files are in multiple different dire
> I didn't mean to finger you particularly. It's just a bit upsetting to
> realize that I can't remember the last time I managed to do an update
> to -current without some kind of breakage. I realize that -current
> isn't guaranteed to build, but that's a bit ridiculous. I mean - I was
> pleasant
In message <[EMAIL PROTECTED]> Mike Meyer writes:
: Warner Losh writes:
: > In message <[EMAIL PROTECTED]> Mike Meyer writes:
: > : The nasty downside of the the module system is that people who don't
: > : adequately test module code before checking it in will screw up kernel
: > : builds for ker
Warner Losh writes:
> In message <[EMAIL PROTECTED]> Mike Meyer writes:
> : The nasty downside of the the module system is that people who don't
> : adequately test module code before checking it in will screw up kernel
> : builds for kernels that don't need that code.
> But I did test it. But I
With USA_RESIDENT=YES NOINFO=true NOGAMES=true NODESCRYPTLINKS=true
NO_OPENSSH=true, I get this on a buildworld when updating a Jan 15th box.
===> libpam/modules/pam_ssh
cc -pipe -O -Wall -I/FBSD/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh
-I/usr/obj/FBSD/src/i386/usr/include -c
Matthew Dillon wrote:
>
> The compile dies with prototype-missing errors on osig*() routines
> in kern/kern_sig.c and i386/i386/machdep.c if COMPAT_43 is not defined.
This is a known problem. We need to introduce something like
COMPAT_FBSD3 and make the code conditional on that. It's now
The compile dies with prototype-missing errors on osig*() routines
in kern/kern_sig.c and i386/i386/machdep.c if COMPAT_43 is not defined.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body
cc -O -pipe -D_GNU_SOURCE -I- -I. -I/usr/src/gnu/usr.bin/binutils/gasp -I/usr/sr
c/gnu/usr.bin/binutils/gasp/../libbfd/alpha -I/usr/src/gnu/usr.bin/binutils/gasp
/../../../../contrib/binutils/include -I/usr/src/gnu/usr.bin/binutils/gasp/../..
/../../contrib/binutils -I/usr/src/gnu/usr.bin/binutils
sh ../../conf/newvers.sh ZIPPY
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
-nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf
-mpreferred-stack
58 matches
Mail list logo
