Broken world (was Re: cvs commit: src/lib/libc/posix1e cap_text.c)
Robert Watson <[EMAIL PROTECTED]> writes: > rwatson 2001/08/30 19:12:00 PDT > > Modified files: > lib/libc/posix1e cap_text.c > Log: > o Remove definition of CAP_MAX_BUF_LEN since it is defined in > sys/capability.h now. > > Submitted by: tmm > Obtained from: TrustedBSD Project > > Revision ChangesPath > 1.4 +5 -2 src/lib/libc/posix1e/cap_text.c This seems to break world on my Alpha. The error is: /usr/src/lib/libc/../libc/posix1e/cap_text.c:293: `CAP_MAX_BUF_LEN' undeclared CAP_MAX_BUF_LEN doesn't seem to be defined in rev 1.8 of capability.h. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unpleasant ps output and possible related problems.
Dave Cornejo <[EMAIL PROTECTED]> writes: > you wrote: > > > When you rebuild and install a new kernel, are you also doing a > > `make buildworld` and a `make installworld` in /usr/src before you > > reboot? > > My usual method is to build a kernel, reboot, build world, reboot, > build a kernel using the new world, reboot again, do a mergemaster, > one final build world, reboot, then test. > > If I'm bored I'll do it all over again after combing for stale binaries > > Fortunately, I have a very fast system. :-) I think it can safely be said that you're rebooting too much. The process can be simplified to: make world make kernel mergemaster reboot Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: corrupted 'w' output
[Moved to -current, BCC'd to -hackers] Eugene L. Vorokov <[EMAIL PROTECTED]> writes: > Hello, > > I updated from -current yesterday, ran "make world; make kernel KERNCONF=X" > and went to bed. When I rebooted with fresh kernel this morning, I noticed > something strange: > > vel@bugz:/usr/src # w > 3:47PM up 5:38, 4 users, load averages: 0.00, 0.11, 0.08 > USER TTY FROM LOGIN@ IDLE WHAT > vel p0 kg.infotecs.ru 10:11AM 2 ssh -l vel bsx.ru > vel p1 kg.infotecs.ru 10:22AM - w > vel p2 kg.infotecs.ru 12:13PM 1:55 \M-[\M-!\^D\b (tcsh) > vel p3 kg.infotecs.ru 12:53PM 2 \M-[\M-!\^D\b (tcsh) > > This only happens for terminals that are in a shell, when something else > is running, output isn't corrupted. I think someone reported similar problem > with 'ps' output. > > Regards, > Eugene Those shell argv[0]'s are generated by login(1). I wonder if it was a recent commit to src/usr.bin/login/login.c that is causing it. Can you try locally backing out Rev. 1.68 (and Rev 1.36 of Makefile)? You will ofcourse have to relogin to see whether the w(1) output has changed. BTW, I can't reproduce this problem locally. Is there any special about your local configuration, particularly regarding PAM? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp in INSTALLTMP?
Christian Weisgerber <[EMAIL PROTECTED]> writes: > Bruce Evans <[EMAIL PROTECTED]> wrote: > > > > I don't know why nobody else seems to be seeing this, but cp is > > > > This might be caused by having the sources and objects on different > > machines with inconsistent clocks. > > No, it's all local on a single machine. > FWIW, I'm on alpha. I'm seeing this on my alpha as well. I believe it started about a week or two ago. As a temporary solution I've been adding cp to /usr/obj/usr/src/alpha/usr/bin and using chflags to set the schg flag. This has to be done once a make world has started. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Alpha kernel breakage
I'm seeing the following error building a kernel on my Alpha. The sources are updated as of a few minutes ago. [Output of 'make kernel KERNCONF=GENERIC NO_MODULES=true'] -- >>> Kernel build for GENERIC started on Wed Sep 12 21:31:24 EDT 2001 -- ===> GENERIC mkdir -p /usr/obj/usr/src/sys cd /usr/src/sys/alpha/conf; PATH=/usr/obj/usr/src/alpha/usr/sbin:/usr/obj/usr/src/alpha/usr/bin:/usr/obj/usr/src/alpha/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/GENERIC /usr/src/sys/alpha/conf/GENERIC FYI: static unit limits for pci are set: NPCI=1 FYI: static unit limits for faith are set: NFAITH=1 FYI: static unit limits for ppp are set: NPPP=1 FYI: static unit limits for atkbdc are set: NATKBDC=1 FYI: static unit limits for sc are set: NSC=1 Kernel build directory is /usr/obj/usr/src/sys/GENERIC Don't forget to do a ``make depend'' cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/alpha/usr/libexec:/usr/obj/usr/src/alpha/usr/bin LIBRARY_PATH=/usr/obj/usr/src/alpha/usr/lib:/usr/obj/usr/src/alpha/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/alpha/usr/libexec CFLAGS="-nostdinc -O -pipe -mcpu=ev4" PERL5LIB=/usr/obj/usr/src/alpha/usr/libdata/perl/5.6.0 GROFF_BIN_PATH=/usr/obj/usr/src/alpha/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/alpha/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/alpha/usr/share/tmac DESTDIR=/usr/obj/usr/src/alpha INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/alpha/usr/sbin:/usr/obj/usr/src/alpha/usr/bin:/usr/obj/usr/src/alpha/usr/games:/sbin:/bin:/usr/sbin:/usr/bin OBJFORMAT_PATH=/usr/obj/usr/src/alpha/usr/libexec:/usr/libexec MACHINE=alpha make KERNEL=kernel clean rm -f *.o *.so *.So *.ko *.s eddep errs kernel.debug kernel linterrs makelinks setdef[01].c setdefs.h tags vers.c vnode_if.c vnode_if.h device_if.c bus_if.c linker_if.c miibus_if.c pci_if.c pcib_if.c ppbus_if.c usb_if.c isa_if.c clock_if.c alphapci_if.c mcclock_if.c device_if.h bus_if.h linker_if.h miibus_if.h pci_if.h pcib_if.h ppbus_if.h usb_if.h isa_if.h clock_if.h alphapci_if.h mcclock_if.h aicasm aicasm_gram.c aicasm_scan.c y.tab.h aic7xxx_seq.h aic7xxx_reg.h __divqu.S __divq.S __divlu.S __divl.S __remqu.S __remq.S __remlu.S __reml.S cd /usr/obj/usr/src/sys/GENERIC; MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make -f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/usr/src/sys/GENERIC yacc -d /usr/src/sys/dev/aic7xxx/aicasm/aicasm_gram.y mv y.tab.c aicasm_gram.c cc -O -pipe -mcpu=ev4 -I/usr/include -I.-c aicasm_gram.c lex -t /usr/src/sys/dev/aic7xxx/aicasm/aicasm_scan.l > aicasm_scan.c cc -O -pipe -mcpu=ev4 -I/usr/include -I.-c aicasm_scan.c cc -O -pipe -mcpu=ev4 -I/usr/include -I.-c /usr/src/sys/dev/aic7xxx/aicasm/aicasm.c cc -O -pipe -mcpu=ev4 -I/usr/include -I.-c /usr/src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c cc -O -pipe -mcpu=ev4 -I/usr/include -I. -o aicasm aicasm_gram.o aicasm_scan.o aicasm.o aicasm_symbol.o -ll cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/alpha/usr/libexec:/usr/obj/usr/src/alpha/usr/bin LIBRARY_PATH=/usr/obj/usr/src/alpha/usr/lib:/usr/obj/usr/src/alpha/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/alpha/usr/libexec CFLAGS="-nostdinc -O -pipe -mcpu=ev4" PERL5LIB=/usr/obj/usr/src/alpha/usr/libdata/perl/5.6.0 GROFF_BIN_PATH=/usr/obj/usr/src/alpha/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/alpha/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/alpha/usr/share/tmac DESTDIR=/usr/obj/usr/src/alpha INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/alpha/usr/sbin:/usr/obj/usr/src/alpha/usr/bin:/usr/obj/usr/src/alpha/usr/games:/sbin:/bin:/usr/sbin:/usr/bin OBJFORMAT_PATH=/usr/obj/usr/src/alpha/usr/libexec:/usr/libexec MACHINE=alpha make KERNEL=kernel depend rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi make _kernel-depend cc -c -O -pipe -mcpu=ev4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -include opt_global.h -elf -mno-fp-regs -ffixed-8 -Wa,-mev56 -elf /usr/src/sys/alpha/alpha/genassym.c In file included from /usr/src/sys/alpha/alpha/genassym.c:43: /usr/src/sys/sys/proc.h: In function `sigonstack': /usr/src/sys/sys/proc.h:339: dereferencing pointer to incomplete type In file included from /usr/src/sys/alpha/alpha/genassym.c:45: /usr/src/sys/sys/buf.h: In function `BUF_KERNPROC': /usr/src/sys/sys/buf.h:338: dereferencing pointer to incomplete type /usr/src/sys/sys/buf.h:339: dereferencing pointer to incomplete type /usr/src/sys/alpha/alpha/genassym.c: At top level: /usr/src/sys/a
Re: Alpha kernel breakage
Marcel Moolenaar <[EMAIL PROTECTED]> writes: > On Wed, Sep 12, 2001 at 09:55:31PM -0400, Mike Barcroft wrote: > > I'm seeing the following error building a kernel on my Alpha. The > > sources are updated as of a few minutes ago. > > I had the same problem. Try using a different CVSup server. > I had a kernel compiling shortly after the KSE stuff was > checked, but had to go directly to freefall to get the > lastest bits. After syncing again with one of the CVSup > mirrors I had the breakage again... > > BTW: I used cvsup9.freebsd.org. > > That reminds me, I have to let somebody know... It appears this was the problem. Switching to cvsup2.FreeBSD.org seems to have have solved it. I assume this is a result of the S1G bug in cvsup. FYI: I was using cvsup.ca.FreeBSD.org. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CVSup mirrors (was Re: Alpha kernel breakage)
[Moved to -hubs, BCC'd to -current] John Polstra <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, > Mike Barcroft <[EMAIL PROTECTED]> wrote: > > It appears this was the problem. Switching to cvsup2.FreeBSD.org > > seems to have have solved it. I assume this is a result of the S1G > > bug in cvsup. FYI: I was using cvsup.ca.FreeBSD.org. > > Not intending to single out you folks in particular, but ... > > Just a reminder, people: Please, if you think something is wrong > with a CVSup mirror, write to the maintainer of that mirror and tell > him. All of the maintainers' e-mail addresses are listed in the > Handbook: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-MIRRORS > > It doesn't do any good to tell the -current list; you have to tell > the maintainer or the problem won't get fixed. I was actually intending to contact the maintainer, but it looks like the problem has already been fixed. Would it be possible for us to be more proactive and check to make sure all the offical CVSup mirrors are running the corrected version? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: broken installworld?
Matthew Jacob <[EMAIL PROTECTED]> writes: > Seems like this has been broken for some time? I might just go off and 'fix' > unless somebody fixes it first. > > install -c -o root -g wheel -m 555 rcs-to-cvs > /usr/share/examples/cvs/contrib/rcs-to-cvs > cp /usr/src/gnu/usr.bin/cvs/contrib/../../../../contrib/cvs/contrib/rcs2log.sh > rcs2log > cp:No such file or directory > *** Error code 1 The problem was a timing issue related to the kernel. Building a new kernel before installing your world should fix it. This is an Alpha only issue. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: broken installworld?
Matthew Jacob <[EMAIL PROTECTED]> writes: > ROFL. That's hilarious. By timing issue, I mean where the Makefiles think the files are out-of-date and try to regenerate them, not a kernel race. :) > This is a pretty much brand new kernel- same tree, buildkernel/installkernel. > Okay, it's from last night's cvsup. But still. The problem was solved for me and the other person experiencing the problem about a week ago. JHB speculated that the problem's disappearence was the result of a commit from dfr to pmap.c. [See thread 'cp in INSTALLTMP?' posted to -current on Sept 9.] Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in ipfw code
Daniel Rock <[EMAIL PROTECTED]> writes: > I wondered nobody noticed this bug so far. > The kernel panics if you feed him with unnumbered firewall rules > (like "ipfw add allow all from any to any") This was reported by DES, and fixed moments before you sent out your e-mail (with a delta identical to your patch). Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Revert awk to one that works
Doug Barton <[EMAIL PROTECTED]> writes: > On Wed, 31 Oct 2001, David O'Brien wrote: > > I *DID* test it with a full `make world'. By chance is this your second > > `make world' after the change? It seems we are using the host awk > > instead of the one we built. Requiring someone to do two back-to-back > > `make world's before a commit has never been a requirement. Some things > > we just find out after a commit. > > "Required" isn't really the question. It seems like common sense > to me when discussing such a frequently used build tool. I'm sure there's better things you could be doing besides lecturing David about testing his changes before committing. Not every bug can be found before committing, which is why we have a little thing called -CURRENT. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "make release" breakage: src/sbin/ifconfig
Makoto Matsushita <[EMAIL PROTECTED]> writes: > With 5-current as of Dec/04/2001 15:00:00 GMT. > > It seems that this is because 'WARNS=0' line is inside of > !defined(RELEASE_CRUNCH) clause. IMO, if an application's code > requires to set 'WARNS=0" for build, it should also be set when > building as a part of a crunched binary. Should be fixed now. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird dump(8) messages
Maxim Sobolev <[EMAIL PROTECTED]> writes: > DUMP: 75.00% done, finished in 0:11 > DUMP: 79.58% done, finished in 0:10 > DUMP: 86.22% done, finished in 0:07 > DUMP: 93.22% done, finished in 0:03 > DUMP: 105.07% done, finished in 0:-2 > DUMP: 111.89% done, finished in 0:-6 > DUMP: 122.01% done, finished in 0:-11 > DUMP: 134.91% done, finished in 0:-18 > ^^^ ^^^!!! > DUMP: DUMP: 1299650 tape blocks > DUMP: finished in 4454 seconds, throughput 291 KBytes/sec > > This is a 3GB partition with a standard 5-CURRENT, several packages and my > development /usr/src and /usr/ports trees. > > Any ideas? What, you've never heard of giving a 110%? :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld broken on _FBSDID in xinstall.c ??
Michel Oosterhof <[EMAIL PROTECTED]> writes: > I might be doing something wrong here, this is my first try at > -CURRENT. Anyway, buildworld fails right at the start after yacc: It looks like Mark Murray broke xinstall.c in revision 1.45 by adding __FBSDID() to a build tool. FreeBSD localisms should not be used in build tools. Perhaps he would be so kind as to back out the offending code. > Any suggestions? I would recommend removing the __FBSD() line locally until this has been resolved. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 2>&1 in /bin/sh
KT Sin <[EMAIL PROTECTED]> writes: > Just ran make world this morning and 2>&1 fd redirection stopped working > for /bin/sh. > > $ ls /bad/file > /dev/null 2>&1 > ls: /bad/file: No such file or directory > > 2>&1 is used extensively in the /etc/rc* bootup scripts. Now, the bootup > screen is cluttered with unwanted messages. > > Any idea? AFAIK, this was fixed. Check the commit logs for sh(1). Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup vs inttypes.h,v
Julian Elischer <[EMAIL PROTECTED]> writes: > Well it's a pitty whoever moved it didn't grep for > it.. my builds fail because of it. I did indeed grep for occurences of it and fixed them. The only remaining instance appears in sys/dev/bktr/bktr_core.c which is in a `#if defined(__NetBSD__) || defined(__OpenBSD__)' section. If you are interested in the types that used to be defined there, they are now in . Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
LINT broken
LINT appears to be broken: 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/work/src/sys -I/work/src/sys/dev -I/work/src/sys/contrib/dev/acpica -I/work/src/sys/contrib/ipfilter -I/work/src/sys/../include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue /work/src/sys/dev/usb/uhci.c /work/src/sys/dev/usb/uhci.c: In function `uhci_dump_all': /work/src/sys/dev/usb/uhci.c:694: structure has no member named `hlink' /work/src/sys/dev/usb/uhci.c: At top level: /work/src/sys/dev/usb/uhci.c:1270: warning: `uhci_reset' defined but not used /work/src/sys/dev/usb/uhci.c:261: warning: `uhci_dump_ii' used but never defined *** Error code 1 Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 5.x
[-hackers removed from CC. One list is enough.] Alp Atici <[EMAIL PROTECTED]> writes: > Is gcc 3.x going to be the default compiler starting from > FBSD 5.x series? Is the development on current branch > compiled using gcc 3.0 (or up)? Yes. Not yet. > Is 5.x series going to be based on a preemptible kernel? That's the plan. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 5.x
Dan Nelson <[EMAIL PROTECTED]> writes:
> In the last episode (Jan 19), Terry Lambert said:
> > Alp Atici wrote:
> > > Is gcc 3.x going to be the default compiler starting from FBSD 5.x
> > > series? Is the development on current branch compiled using gcc 3.0
> > > (or up)?
> >
> > I think that the cut over will happen after the compiler
> > no longer core dumps on:
> >
> > main()
> > {
> > int i;
> >
> > i = foo();
> >
> > switch( i) {
> > default:
> > printf( "hello, stupid compiler!\n");
> > break;
> > }
> > }
> >
> > int
> > foo()
> > {
> > return( 6);
> > }
>
> Doesn't core on me (gcc30+bounds-checking port, FreeBSD-current). In
> fact, I've got USE_GCC30 in my make.conf and build all my ports with it
> (at least the ports that aren't broken and hardcode cc or gcc).
Interesting. The sparc64 toolchain suffers from this problem, so a
number of files on the sparc64 p4 branch have custom versions.
Anyway, I'm told this problem has been fixed in 3.1, which is the
planned version of GCC for 5.0-RELEASE.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
LINT Broken
With up-to-date sources: sh /work/src/sys/conf/newvers.sh LINT -DGPROF -DGPROF4 -DGUPROF 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/work/src/sys -I/work/src/sys/dev -I/work/src/sys/contrib/dev/acpica -I/work/src/sys/contrib/ipfilter -I/work/src/sys/../include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue vers.c linking kernel uhci.o: In function `uhci_idone': uhci.o(.text+0x1330): undefined reference to `uhci_dump_ii' uhci.o: In function `uhci_device_isoc_done': uhci.o(.text+0x2fab): undefined reference to `uhci_dump_ii' *** Error code 1 Stop in /usr/obj/work/src/sys/LINT. *** Error code 1 Stop in /work/src. *** Error code 1 Stop in /work/src. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pam_ssh world breakage (was: Re: cvs commit: src/lib/libpam Makefile.inc)
David O'Brien <[EMAIL PROTECTED]> writes: > Not to mention there is ZERO way this code will pass WARNS=4 for GCC 3. > Please Committers, do not try to WARNS code right now -- there just is no > use. It will only get in the way later. > > Well, of course feel free to make the code changes, but PLEASE do not > commit any stronger WARNS levels to Makefiles. Alternatively, developers working on WARNS could use a newer GCC from the ports collection. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
Wilko Bulte <[EMAIL PROTECTED]> writes: > C'mon guys: it is not so long ago (days..) that the Alpha started > buildworlding -current again. Alpha builds tend to take much > longer (on most people's hardware that is) so a bit of patience > would be nice. > > FWIW: I'm trying to get 2 of my Alphas to go to -current again. Running most things compiled with the new binutils on Alpha causes segfaults. Be very careful not to install anything compiled with it. To test KSE on Alpha I recommend locally backing out the new binutils until David or another developer resolves the issues with it. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.x issues
Peter Wemm <[EMAIL PROTECTED]> writes: > 2: We need to get a *basic* compiler up and running first. Give David > a break, ok? There are far bigger problems to deal with first before > futzing around on obscure languages that we have no critical need for > in the base system. We ***NEED*** the ability to compile basic C code > for the sparc64, ia64 and x86-64 platforms. Until that is dealt with, > the rest is a luxury. Yes, absolutely. Every minute David spends replying to these idiotic suggestions wastes valuable project time. How many FreeBSD users need to compile Java to machine code? 2, 3, 4 people? How hard is it to use `pkg_add -r' and rearrange your PATH to make a stock GCC work? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.x issues
Nat Lanza <[EMAIL PROTECTED]> writes: > You know, people might be less persistent about these "idiotic" > suggestions if they got treated with some civility and respect. >From what I read, the participants in this thread were very civil and respectful. I don't think the original poster had given his suggestion much thought before bringing it up though. :( > It's a lot more meaningful and useful to receive an explanation, even a > brief one, about why your suggestion isn't good than it is to receive > personal abuse. If you simply abuse someone, they're just going to think > you're a jerk, not that their ideas are bad. I completely agree. I found David's explanations quite helpful in determining the legitimacy of the original suggestion. > More flies with honey, and all that. > > I've noticed a lot of nastiness in this thread, and it's really pretty > disappointing. Yes, you're all busy people. Yes, this is a volunteer > project. Yes, people are never satisfied with what others do for them > for free. That sucks, sure. But it doesn't make it okay to treat people > like crap for daring to disagree with you. I didn't notice much "nastiness", but I guess I wasn't really looking for it. I did notice that some people were wasting a developer's time when the project as a whole needs it much more. I'm talking, ofcourse, about the imminent GCC upgrade that David is working on. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
Terry Lambert <[EMAIL PROTECTED]> writes: > Other people's code has dropped by the wayside completely, and > been lost; the SACK/TSACK work Luigi did never got integrated > and accepted by the project, and LRP code that Peter Druschel > and Gaurav Banga did at Rice University, which was originally > done against FreeBSD 2.2. For that matter, we've also lost > out on integration of the IO-Lite code, also from Rice (both > were a result of the ScalaServer project). Likewise, the CMU > work on TCP Rate Halving (admittedly, it's based on NetBSD 1.3.2, > but that's not that significantly different from FreeBSD to matter), > as well as their FACK/SACK implementation. I'm getting sick of reading this. Terry, if you want this code integrated into FreeBSD, here's what you do: 1) Find yourself a mentor, 2) Get a commit bit, 3) Update worthy patchsets to -current sources, 4) Have them reviewed, 5) Commit them. If you aren't interested in doing this, you are the sole person to be blamed for them not being integrated into FreeBSD. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Forking" FreeBSD: CVS vs. P4
Terry Lambert <[EMAIL PROTECTED]> writes: > Mike Barcroft wrote: > > I'm getting sick of reading this. Terry, if you want this code > > integrated into FreeBSD, here's what you do: 1) Find yourself a > > mentor, 2) Get a commit bit, 3) Update worthy patchsets to -current > > sources, 4) Have them reviewed, 5) Commit them. > > > > If you aren't interested in doing this, you are the sole person to be > > blamed for them not being integrated into FreeBSD. > > And I'm getting sick of being dragged down into details in what > should be a meta-discussion, thus effectively glossing over the > major point in order to pick on one or two "objectionable" > paragraphs out of an entire posting. [Discussion related to the root of the thread, rather than my message, removed.] I see you are not interested in doing this. -CURRENT READERS TAKE NOTE: No longer can Terry blame CVS, P4, Gnats, our two seperate branches of development, FreeBSD developers, or the color of the sky; Terry can be attributed to be the sole reason why these outside projects have never been integrated into FreeBSD. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sa_handler and sigaction...
Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> writes: > I don't have the spec, but a perusal of secondary sources has > P1003.1-1990 specifying sa_handler and P1003.1-1993 adding sa_sigaction. > > I should add that sigaction() without sa_handler is almost entirely > useless for portable programming, so it would be downright bizarre for > POSIX to specify sigaction() and yet omit sa_handler. This looks like my bug. I'll fix it. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Dec 27 16:12:52 GMT 2002 -- ===> ipfilter /tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c: In function `ffs_load_inode': /tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c:114: argument `mtype' doesn't match prototype /tinderbox/sparc64/src/sys/ufs/ffs/ffs_extern.h:73: prototype declaration /tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c:114: argument `fs' doesn't match prototype /tinderbox/sparc64/src/sys/ufs/ffs/ffs_extern.h:73: prototype declaration /tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c:114: number of arguments doesn't match prototype /tinderbox/sparc64/src/sys/ufs/ffs/ffs_extern.h:73: prototype declaration *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ia64 tinderbox failure
Peter Wemm <[EMAIL PROTECTED]> writes:
> ===> sbin/swapon
> cc1: warnings being treated as errors
> /home/tinderbox/ia64/src/sbin/swapon/swapon.c: In function `swaplist':
> /home/tinderbox/ia64/src/sbin/swapon/swapon.c:246: warning: field width is not type
>int (arg 3)
> /home/tinderbox/ia64/src/sbin/swapon/swapon.c:246: warning: field width is not type
>int (arg 5)
> /home/tinderbox/ia64/src/sbin/swapon/swapon.c:265: warning: field width is not type
>int (arg 3)
> /home/tinderbox/ia64/src/sbin/swapon/swapon.c:265: warning: field width is not type
>int (arg 5)
> /home/tinderbox/ia64/src/sbin/swapon/swapon.c:274: warning: field width is not type
>int (arg 2)
> /home/tinderbox/ia64/src/sbin/swapon/swapon.c:274: warning: field width is not type
>int (arg 4)
> *** Error code 1
Proposed fix:
%%%
Index: swapon.c
===
RCS file: /work/repo/src/sbin/swapon/swapon.c,v
retrieving revision 1.14
diff -u -r1.14 swapon.c
--- swapon.c28 Dec 2002 23:39:47 - 1.14
+++ swapon.c29 Dec 2002 05:53:17 -
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -210,8 +211,8 @@
{
size_t mibsize, size;
struct xswdev xsw;
- int mib[16], n, pagesize;
- size_t hlen;
+ int hlen, mib[16], n, pagesize;
+ size_t hsize;
long blocksize;
long long total = 0;
long long used = 0;
@@ -229,7 +230,8 @@
hlen = 10;
break;
default:
- getbsize(&hlen, &blocksize);
+ getbsize(&hsize, &blocksize);
+ hlen = MIN(INT_MAX, hsize);
break;
}
%%%
BTW, the tabbing in this area of the source file is messed up.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> sbin/swapon cc1: warnings being treated as errors /tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist': /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 2) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 4) *** Error code 1 Stop in /tinderbox/sparc64/src/sbin/swapon. *** Error code 1 Stop in /tinderbox/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> sbin/swapon cc1: warnings being treated as errors /tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist': /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 2) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 4) *** Error code 1 Stop in /tinderbox/sparc64/src/sbin/swapon. *** Error code 1 Stop in /tinderbox/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ia64 tinderbox failure
Bruce Evans <[EMAIL PROTECTED]> writes: > The correct fix is to unbreak getbsize() so that it takes an `int *' as its > first arg like it used to. The interface change and the above change > just give a header length that is not directly usably by any of its users. > The header length is what must be passed to printf in %*s formats; it > should have type int since that is what printf takes; any bounds checking > of it belongs in getbsize() (but in practice it is a small positive > number since anything else would give preposterous formatting, so there > is never a problem with its bounds). Other users of getbsize() in the > src tree but perhaps not ones in ports have been broken to match the > interface breakage. The usual breakage is to cast the size_t to int > without checking bounds. Agreed. Not a single consumer actually wants a size_t and not all base system uses have been "fixed" for the new interface (ls(1) for instance). I'd like to see the interface restored and merged into RELENG_5_0 before we introduce this mistake on the world. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> sbin/swapon cc1: warnings being treated as errors /tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist': /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 2) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 4) *** Error code 1 Stop in /tinderbox/sparc64/src/sbin/swapon. *** Error code 1 Stop in /tinderbox/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> sbin/swapon cc1: warnings being treated as errors /tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist': /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 2) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 4) *** Error code 1 Stop in /tinderbox/sparc64/src/sbin/swapon. *** Error code 1 Stop in /tinderbox/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> sbin/swapon cc1: warnings being treated as errors /tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist': /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 3) /tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int (arg 5) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 2) /tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int (arg 4) *** Error code 1 Stop in /tinderbox/sparc64/src/sbin/swapon. *** Error code 1 Stop in /tinderbox/sparc64/src/sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- ===> usr.sbin/fwcontrol cd: can't cd to /tinderbox/sparc64/src/usr.sbin/fwcontrol *** Error code 2 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> bin/df cc1: warnings being treated as errors /tinderbox/sparc64/src/bin/df/df.c: In function `prtstat': /tinderbox/sparc64/src/bin/df/df.c:395: warning: passing arg 1 of `getbsize' from incompatible pointer type /tinderbox/sparc64/src/bin/df/df.c: In function `update_maxwidths': /tinderbox/sparc64/src/bin/df/df.c:448: warning: passing arg 1 of `getbsize' from incompatible pointer type *** Error code 1 Stop in /tinderbox/sparc64/src/bin/df. *** Error code 1 Stop in /tinderbox/sparc64/src/bin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> usr.bin/gcore In file included from /tinderbox/sparc64/src/usr.bin/gcore/elfcore.c:38: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include/vm/vm_map.h:167: field `system_mtx' has incomplete type *** Error code 1 Stop in /tinderbox/sparc64/src/usr.bin/gcore. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.bin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> ===> vinum
> "Makefile", line 4453: warning: duplicate script for target "geom_bsd.o" ignored
> cc1: warnings being treated as errors
> /h/des/src/sys/dev/isp/isp_pci.c: In function `tdma_mkfc':
> /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: unsigned int format, different type
>arg (arg 5)
> /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: int format, different type arg (arg
>6)
> /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type
>arg (arg 6)
> /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type
>arg (arg 7)
> *** Error code 1
Proposed fix:
%%%
Index: isp_pci.c
===
RCS file: /work/repo/src/sys/dev/isp/isp_pci.c,v
retrieving revision 1.89
diff -u -r1.89 isp_pci.c
--- isp_pci.c 11 Oct 2002 17:28:01 - 1.89
+++ isp_pci.c 1 Jan 2003 14:56:25 -
@@ -1538,9 +1538,10 @@
cto->rsp.m0.ct_dataseg[cto->ct_seg_count].ds_count =
dm_segs[segcnt].ds_len;
cto->rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
- isp_prt(isp, ISP_LOGTDEBUG1, "isp_send_ctio2: ent0[%d]0x%x:%d",
- cto->ct_seg_count, dm_segs[segcnt].ds_addr,
- dm_segs[segcnt].ds_len);
+ isp_prt(isp, ISP_LOGTDEBUG1,
+ "isp_send_ctio2: ent0[%d]0x%lx:%lu",
+ cto->ct_seg_count, (unsigned long)dm_segs[segcnt].ds_addr,
+ (unsigned long)dm_segs[segcnt].ds_len);
}
while (segcnt < nseg) {
@@ -1567,9 +1568,10 @@
crq->req_dataseg[seg].ds_base = dm_segs[segcnt].ds_addr;
crq->req_dataseg[seg].ds_count = dm_segs[segcnt].ds_len;
isp_prt(isp, ISP_LOGTDEBUG1,
- "isp_send_ctio2: ent%d[%d]%x:%u",
+ "isp_send_ctio2: ent%d[%d]%lx:%lu",
cto->ct_header.rqs_entry_count-1, seg,
- dm_segs[segcnt].ds_addr, dm_segs[segcnt].ds_len);
+ (unsigned long)dm_segs[segcnt].ds_addr,
+ (unsigned long)dm_segs[segcnt].ds_len);
cto->rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
cto->ct_seg_count++;
}
%%%
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> --
> >>> Kernel build for LINT started on Mon Jan 6 03:35:12 PST 2003
> --
> ===> vinum
> "Makefile", line 4445: warning: duplicate script for target "geom_bsd.o" [...]
> /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver i [...]
> /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
> /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...]
> /h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver i [...]
> /h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is b [...]
> cc1: warnings being treated as errors
> /h/des/src/sys/security/mac_lomac/mac_lomac.c: In function `mac_lomac_ass [...]
> /h/des/src/sys/security/mac_lomac/mac_lomac.c:1070: warning: passing arg [...]
> /h/des/src/sys/security/mac_lomac/mac_lomac.c:1081: warning: int format, [...]
> *** Error code 1
These new truncated lines only make problems harder to solve.
Anyway, the problem is the 5th argument to vn_extattr_get() should be
an int *, but it's passing a size_t *. It looks like most consumers
of vn_extattr_get() would prefer a size_t *, so maybe the interface
should be changed.
This patch should resolve the problem without changing
vn_extattr_get()'s interface:
%%%
Index: mac_lomac.c
===
RCS file: /work/repo/src/sys/security/mac_lomac/mac_lomac.c,v
retrieving revision 1.6
diff -u -r1.6 mac_lomac.c
--- mac_lomac.c 10 Dec 2002 16:20:33 - 1.6
+++ mac_lomac.c 6 Jan 2003 15:53:02 -
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1067,7 +1068,7 @@
bzero(&temp, buflen);
error = vn_extattr_get(vp, IO_NODELOCKED, MAC_LOMAC_EXTATTR_NAMESPACE,
- MAC_LOMAC_EXTATTR_NAME, &buflen, (char *)&temp, curthread);
+ MAC_LOMAC_EXTATTR_NAME, (int *)&buflen, (char *)&temp, curthread);
if (error == ENOATTR || error == EOPNOTSUPP) {
/* Fall back to the fslabel. */
mac_lomac_copy_single(source, dest);
@@ -1077,8 +1078,9 @@
if (buflen != sizeof(temp)) {
if (buflen != sizeof(temp) - sizeof(temp.ml_auxsingle)) {
- printf("mac_lomac_associate_vnode_extattr: bad size %d\n",
- buflen);
+ printf(
+ "mac_lomac_associate_vnode_extattr: bad size %ju\n",
+ (uintmax_t)buflen);
return (EPERM);
}
bzero(&temp.ml_auxsingle, sizeof(temp.ml_auxsingle));
%%%
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
Mike Barcroft <[EMAIL PROTECTED]> writes:
> @@ -1077,8 +1078,9 @@
>
> if (buflen != sizeof(temp)) {
> if (buflen != sizeof(temp) - sizeof(temp.ml_auxsingle)) {
> - printf("mac_lomac_associate_vnode_extattr: bad size %d\n",
> - buflen);
> + printf(
> + "mac_lomac_associate_vnode_extattr: bad size %ju\n",
> + (uintmax_t)buflen);
> return (EPERM);
> }
> bzero(&temp.ml_auxsingle, sizeof(temp.ml_auxsingle));
Oops, I forgot we have %z in printf(9) now. That would obviously be
better.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Tue Jan 7 04:15:50 GMT 2003 -- ===> ipfilter touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ipfilter/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Tue Jan 7 16:18:02 GMT 2003 -- ===> unionfs touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/unionfs/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/unionfs. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Tue Jan 7 22:18:05 GMT 2003 -- ===> ums touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ums/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/ums. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Jan 8 10:16:18 GMT 2003 -- ===> ipfilter touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ipfilter/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Jan 8 16:16:05 GMT 2003 -- ===> ipfilter touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ipfilter/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Jan 8 22:16:49 GMT 2003 -- ===> vx touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/vx. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
Jake Burkholder <[EMAIL PROTECTED]> writes: > Apparently, On Wed, Jan 08, 2003 at 11:25:12PM +, > Mike Barcroft said words to the effect of; > > -- > > >>> Kernel build for GENERIC started on Wed Jan 8 22:16:49 GMT 2003 > > -- > > ===> vx > > touch: >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms: > No such file or directory > > *** Error code 1 > > FWIW, I can't reproduce this locally, it must be a problem with the > tinderbox. I haven't seen Mike around lately, hopefully he can see > what's going on soon. > > Sorry for the spam. Hmm, I'll try clearing the obj directory and see if that helps. I did have some trouble with the filesystem the tinderbox runs on. fsck may have deleted some files that left things in an unexpected state. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Jan 10 04:16:49 GMT 2003 -- ===> vx touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/vx. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Jan 10 10:17:39 GMT 2003 -- ===> usb ld: cannot open output file usb.kld: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/usb. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Fix man pages with iovec
Craig Rodrigues <[EMAIL PROTECTED]> writes: > Hi, > > This patch fixes the read(2) and write(2) man pages > to accurately reflect the iovec structure defined > in and . Committed, thanks. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RELENG_5 branch ?
Joao Pedras <[EMAIL PROTECTED]> writes: > > Hi all > > Will there be a RELENG_5 where we would get 5.0-STABLE ? Pretty much in the same > way it has been up until now... > > Is this code currently tagged with RELENG_5_0 ? This won't happen until after 5.1 or 5.2. For now we have 5.1-CURRENT or something like that. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > -- > >>> Kernel build for LINT started on Sun Jan 19 03:36:18 PST 2003 > -- > ===> vinum > "Makefile", line 4437: warning: duplicate script for target "geom_bsd.o" ignored > /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken >and is not compiled with LINT" > /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': > /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer >target type > /h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken >and is not compiled with LINT" > /h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is broken and >is not compiled with LINT" > cc1: warnings being treated as errors > /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': > /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit constant >conversion > *** Error code 1 Fixed. Peter fixed the same problem elsewhere, but must have missed this one. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: adduser(8) in 5.0-R
Mike Makonnen <[EMAIL PROTECTED]> writes: > Committed. > Thanks! Should this be an errata item? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sun Jan 26 14:16:30 EST 2003 -- ===> hme cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/sparc64/sparc64/tick.c: In function `tick_process': /tinderbox/sparc64/src/sys/sparc64/sparc64/tick.c:75: warning: passing arg 1 of `statclock_process' from incompatible pointer type *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sun Jan 26 20:16:54 EST 2003 -- ===> hme cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/sparc64/sparc64/tick.c: In function `tick_process': /tinderbox/sparc64/src/sys/sparc64/sparc64/tick.c:75: warning: passing arg 1 of `statclock_process' from incompatible pointer type *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to teach config(8) about "platforms".
Benno Rice <[EMAIL PROTECTED]> writes: > On Wed, 2003-01-29 at 11:18, Juli Mallett wrote: > > * De: Juli Mallett <[EMAIL PROTECTED]> [ Data: 2003-01-28 ] > > [ Subjecte: Re: Patch to teach config(8) about "platforms". ] > > > > In short, platform provides machinery for a single port of FreeBSD > > which represents exactly one MACHINE_ARCH to support a numbe of > > different hardware platforms - MACHINE - under a unified system, > > without interfering with how anything works, and without doing it in > > a convoluted/imho-backwards way. There is not a way to mix MACHINE > > and MACHINE_ARCH within a single port, as it is now. You have to > > duplicate things like pc98 does. > > I'd also like to point out that PowerPC will benefit greatly from this. > PowerPC platforms vary wildly in how they do various things (incl. > endianness in some cases) and so this provides a much cleaner mechanism > to select a set of platform "quirks" than trying to do what i386/pc98 > do. Perhaps if we could see PC98 converted to this design the advantages would become obvious. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- ===> lib/libpam/modules/pam_ssh In file included from /tinderbox/sparc64/src/lib/libpam/modules/pam_ssh/pam_ssh.c:59: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include/openssl/evp.h:111:26: openssl/idea.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules/pam_ssh. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Jan 29 14:27:54 EST 2003 -- ===> hme In file included from /tinderbox/sparc64/src/sys/dev/aic7xxx/aic7xxx_osm.h:64, from /tinderbox/sparc64/src/sys/dev/aic7xxx/ahc_pci.c:36: machine/bus.h: In function `sparc64_dmamem_alloc_size': machine/bus.h:1096: structure has no member named `dmamem_alloc' machine/bus.h:1096: structure has no member named `parent' machine/bus.h:1098: structure has no member named `dmamem_alloc_size' machine/bus.h: In function `sparc64_dmamem_free_size': machine/bus.h:1122: structure has no member named `dmamem_free' machine/bus.h:1122: structure has no member named `parent' machine/bus.h:1124: structure has no member named `dmamem_free_size' *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removed?
Kris Kennaway <[EMAIL PROTECTED]> writes: > A number of ports have started to complain about a missing stropts.h > header..was this recently removed, and if so then what is the fix? I don't think we've ever supported STREAMS. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: State of the Union Report (backout request department)
Mark Linimon <[EMAIL PROTECTED]> writes: > (This is just a view from the sidelines; I generally do ports hacking > and not kernel hacking, and thus my views might not carry much > weight, but here goes anyways). > > One of the more interesting features of the FreeBSD development > model seems to me to be the ability for people to request controversial > CVS commits to be backed out pending further technical discussion. > IMHO this seems like a wise (albeit nonintuitive) plan to avoid > meta-discussions about what should and should not have been > committed by whom and reviewed by whom (and so on and so forth). > > But recently (especially since the 5.0 release) the backout request > mechanism seems to have fallen on hard times. Without too much > difficulty, I was able to find 5 separate backout requests in this > year's archive of cvs-all alone which were not quickly honored. > (I'm not counting an ignored request for which the underlying > change was apparently security-related). I'm not sure, but there > may have been others, possibly on freebsd-current. The archives might not be telling the whole story. A lot of times these things get handled behind closed doors, whether private e-mail or developer-only lists. Thankfully though, most conflicts *do* get resolved. :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: split out patch
Brad Knowles <[EMAIL PROTECTED]> writes: > At 6:27 PM -0800 2003/02/01, Matthew Dillon wrote: > > > Well, it is an active conversation/thread. Either people care enough > > to stay involved or they don't. > > But don't people have to sleep sometime? Shouldn't we allow for that? Real hackers don't sleep. :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interested in helping the C99 integration project
[Please wrap lines at 72 characters or less.] David Leimbach <[EMAIL PROTECTED]> writes: > Hi, > > I am a software developer who has benefitted greatly from using FreeBSD the past few >years as well as other software like KDE. I have been doing what I can here and >there to make sure big projects like KDE will build and run on FreeBSD as well as >other operating systems. > > I came to the realization that we [FreeBSD users/developers] are missing some thread >safe functions like getpwnam_r. I was wondering if I could somehow help ease the >burden either by testing or implementing some of these functions. > > Who do I want to organize with to help with this stuff? See http://www.freebsd.org/projects/c99/ Wes Peters has been assigned this task for a while. Perhaps you could co-ordinate with him. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tmpfile breakage on setuid executables
Mike Makonnen <[EMAIL PROTECTED]> writes:
> The original poster was right.
> The following patch should fix it. I'll check it in as soon as my test cycle is
> over.
>
> Cheers.
> --
> Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
> [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
>
> Index: lib/libc/stdio/tmpfile.c
> ===
> RCS file: /home/ncvs/src/lib/libc/stdio/tmpfile.c,v
> retrieving revision 1.8
> diff -u -r1.8 tmpfile.c
> --- lib/libc/stdio/tmpfile.c 13 Oct 2002 11:22:16 - 1.8
> +++ lib/libc/stdio/tmpfile.c 5 Feb 2003 23:37:28 -
> @@ -61,6 +61,7 @@
> char *buf;
> const char *tmpdir;
>
> + tmpdir = NULL;
> if (issetugid() == 0)
> tmpdir = getenv("TMPDIR");
> if (tmpdir == NULL)
Looks like kris broke it. Shame on us for not having a WARNS level on
libc big enough to catch simple regressions like this.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: C conformance.
Marcin Dalecki <[EMAIL PROTECTED]> writes: > Trying to use a compiler different from GCC I have found the folowing error > > "/usr/include/sys/syslimits.h", line 42: Error: >[ISO 6.8]: Unknown preprocessing directive, '#warning'. > > I think that somthing like to above should not appear in system > headers. This is a bug in TenDRA. It looks in conditionals that don't apply for syntax errors. I use the attached workaround on my system to support TenDRA. Best regards, Mike Barcroft Index: cdefs.h === RCS file: /work/repo/src/sys/sys/cdefs.h,v retrieving revision 1.68 diff -u -r1.68 cdefs.h --- cdefs.h 21 Oct 2002 20:50:30 - 1.68 +++ cdefs.h 14 Dec 2002 16:46:57 - @@ -113,27 +113,27 @@ * in a different (wrong) way). If we do not provide an implementation * for a given compiler, let the compile fail if it is told to use * a feature that we cannot live without. + * + * XXX the check for lint here is incorrect, since either your lint supports + * GNUC or it doesn't. Some kernel source code is very GNUC-centric, so we + * need this hack here until those GNUCisms are fixed. In reality, having + * hacks like this usually extend the life of bugs. */ -#ifdef lint +#if defined(lint) #define__dead2 #define__pure2 #define__unused #define__packed #define__aligned(x) #define__section(x) -#else -#if __GNUC__ < 2 || __GNUC__ == 2 && __GNUC_MINOR__ < 5 -#define__dead2 -#define__pure2 -#define__unused -#endif -#if __GNUC__ == 2 && __GNUC_MINOR__ >= 5 && __GNUC_MINOR__ < 7 +/* Older GCC versions default to NOP for everything. */ +#elif __GNUC__ == 2 && __GNUC_MINOR__ >= 5 && __GNUC_MINOR__ < 7 #define__dead2 __attribute__((__noreturn__)) #define__pure2 __attribute__((__const__)) -#define__unused +/* XXX __aligned() is too critical to working code to safely be defined away. */ +#define__aligned(x) /* XXX Find out what to do for __packed, __aligned and __section */ -#endif -#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7 || __GNUC__ == 3 +#elif __GNUC__ == 2 && __GNUC_MINOR__ >= 7 || __GNUC__ == 3 #define__dead2 __attribute__((__noreturn__)) #define__pure2 __attribute__((__const__)) #define__unused__attribute__((__unused__)) @@ -141,6 +141,25 @@ #define__aligned(x)__attribute__((__aligned__(x))) #define__section(x)__attribute__((__section__(x))) #endif + +/* + * Default to NOP for compiler-dependent extentions. + * XXX missing __aligned(), since we can't safely define it away. + */ +#ifndef __dead2 +#define__dead2 +#endif +#ifndef __packed +#define__packed +#endif +#ifndef __pure2 +#define__pure2 +#endif +#ifndef __section +#define__section(x) +#endif +#ifndef __unused +#define__unused #endif /* XXX: should use `#if __STDC_VERSION__ < 199901'. */ @@ -226,6 +245,14 @@ * The alternative is: #define __IDSTRING(name,string) [nothing] */ #define__IDSTRING(name,string) static const char name[] __unused = string +#endif + +/* + * TenDRA looks inside conditionals that don't apply (ie. #if __GNUC__). + * #warning is the most likely cause of syntax errors, so work around this. + */ +#ifdef __TenDRA__ +#pragmaTenDRA directive warning (ignore) allow #endif /*
Re: Best method to produce patches?
David Leimbach <[EMAIL PROTECTED]> writes: > I am about to try to make some changes to FreeBSD current... > > Should I begin to use read-only CVS instead of CVSup for this work or > is it possible to generate diffs based on CVSup'd sources? > > What is the recommend method to use for playing with the source? > > I already found a small change in libc that should probably get > committed but I want to generate the patch properly for everyone's > approval. Most developers use CVSup to download the repo. I use the following supfile: *default host=cvsup10.freebsd.org *default base=/usr *default prefix=/work/repo *default release=cvs *default delete use-rel-suffix *default compress doc-all ports-all src-all www Then setup an alias for local operations: alias lcvscvs -d/work/repo -R Then: lcvs checkout src cd src [make changes to files] lcvs diff >~/my.diff Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Feb 13 14:30:47 EST 2003 -- ===> agp /tinderbox/sparc64/src/sys/pci/agp_i810.c: In function `agp_i810_match': /tinderbox/sparc64/src/sys/pci/agp_i810.c:112: `AGP_I85X_CAPID' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:112: (Each undeclared identifier is reported only once /tinderbox/sparc64/src/sys/pci/agp_i810.c:112: for each function it appears in.) /tinderbox/sparc64/src/sys/pci/agp_i810.c:113: `AGP_I855_GME' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:116: `AGP_I855_GM' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:119: `AGP_I852_GME' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:122: `AGP_I852_GM' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c: In function `agp_i810_attach': /tinderbox/sparc64/src/sys/pci/agp_i810.c:342: `AGP_I855_GCC1' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:343: `AGP_I855_GCC1_GMS' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:344: `AGP_I855_GCC1_GMS_STOLEN_1M' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:347: `AGP_I855_GCC1_GMS_STOLEN_4M' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:350: `AGP_I855_GCC1_GMS_STOLEN_8M' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:353: `AGP_I855_GCC1_GMS_STOLEN_16M' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:356: `AGP_I855_GCC1_GMS_STOLEN_32M' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/agp. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Feb 13 20:28:04 EST 2003 -- ===> agp /tinderbox/sparc64/src/sys/pci/agp_i810.c: In function `agp_i810_match': /tinderbox/sparc64/src/sys/pci/agp_i810.c:112: `AGP_I85X_CAPID' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:112: (Each undeclared identifier is reported only once /tinderbox/sparc64/src/sys/pci/agp_i810.c:112: for each function it appears in.) /tinderbox/sparc64/src/sys/pci/agp_i810.c:113: `AGP_I855_GME' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:116: `AGP_I855_GM' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:119: `AGP_I852_GME' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:122: `AGP_I852_GM' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c: In function `agp_i810_attach': /tinderbox/sparc64/src/sys/pci/agp_i810.c:342: `AGP_I855_GCC1' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:343: `AGP_I855_GCC1_GMS' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:344: `AGP_I855_GCC1_GMS_STOLEN_1M' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:347: `AGP_I855_GCC1_GMS_STOLEN_4M' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:350: `AGP_I855_GCC1_GMS_STOLEN_8M' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:353: `AGP_I855_GCC1_GMS_STOLEN_16M' undeclared (first use in this function) /tinderbox/sparc64/src/sys/pci/agp_i810.c:356: `AGP_I855_GCC1_GMS_STOLEN_32M' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/agp. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS2 regression tests?
John De Boskey <[EMAIL PROTECTED]> writes: > Hi Folks, > >I've just put together a 1.7TB filesystem and was looking for some > regression tests to run against it. Looking through the mailing lists > doesn't turn up anything, nor does a websearch (at least for the keywords > I tried). > >So, does anyone have any comments/ideas on a good way to test the > new system? src/tools/regression/fsx Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Feb 20 03:10:07 EST 2003 -- ===> unionfs touch: /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/unionfs/export_syms: No such file or directory *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/unionfs. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config files and includes.
Julian Elischer <[EMAIL PROTECTED]> writes: > I have just gone through the process of upgrading or installing several > hundred machines, and Thst includes altering or editing many config > files in /etc. I like the way that rc.conf > is handled, in that defaults/rc.comf can be updated and only the > local changes live in r.conf. I wish that more files had this > capability. > For example syslogd.conf or newsyslog.conf are updated between releases > but they are also prime candidates for local additions. > What would be really cool is if more config files could > do 'includes' so that you could have a syslogd.local.conf > wher eall your local entries could be. In addition you could make it > look in /usr/local/etc/syslogd.conf for loging requirments for > packages. Why not making it simple on yourself and use CPP. /etc/defaults/syslog.global.conf: #ifndef SECURITY security.* /nfs/log/security #endif #ifndef MAIL mail.info /nfs/log/maillog #endif /etc/syslog.local.conf: #define SECURITY security.* /var/log/security #include "/etc/defaults/syslog.global.conf" /etc/rc.d/syslogd (or similar): +# Preprocess syslog.conf +cpp /etc/syslog.local.conf -o /etc/syslog.conf + Unix has *so* many text processing tools, I don't see why we need to bloat daemons with this stuff. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html Sun Feb 23 03:38:01 EST 2003 cvs [update aborted]: /work/repo/CVSROOT: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html Sun Feb 23 11:38:00 EST 2003 cvs [update aborted]: /work/repo/CVSROOT: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Tue Feb 25 08:17:29 EST 2003 -- ===> hme /tinderbox/sparc64/src/sys/kern/vfs_bio.c: In function `bdwrite': /tinderbox/sparc64/src/sys/kern/vfs_bio.c:1040: too few arguments to function `BUF_LOCK' *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: build busted in xlint: stat.h related?
Andrew Gallatin <[EMAIL PROTECTED]> writes: > > I just tried to buildworld, and xlint crapped out like this: > > ===> usr.bin/xlint/llib > lint -cghapbx -Cposix /usr/src/usr.bin/xlint/llib/llib-lposix > lint -cghapbx -Cstdc /usr/src/usr.bin/xlint/llib/llib-lstdc > llib-lposix: > llib-lstdc: > stdio.h(79): warning: struct __sFILEX never defined [233] > Lint pass2: > stat.h(132): syntax error [249] > stdio.h(79): warning: struct __sFILEX never defined [233] > signal.h(207): warning: struct __siginfo never defined [233] > *** Error code 1 > > I'm rebuilding now with your latest stat.h change reverted.. I committed a fix. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> usr.bin/xlint/llib llib-lposix: stat.h(132): syntax error [249] stdio.h(79): warning: struct __sFILEX never defined [233] signal.h(207): warning: struct __siginfo never defined [233] *** Error code 1 Stop in /tinderbox/sparc64/src/usr.bin/xlint/llib. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.bin/xlint. *** Error code 1 Stop in /tinderbox/sparc64/src/usr.bin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL question for id_function()
John Polstra <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, > Craig Rodrigues <[EMAIL PROTECTED]> wrote: > > > > pthread_self() returns something of type pthread_t. > > This code works under Linux, because pthread_t is mapped to an integer value. > > > > However, on FreeBSD, pthread_t is a pointer to struct pthread, so this > > code does not compile: > > FreeBSD violates POSIX in this respect. The 1003.1 standard > (section 2.5) requires pthread_t to be an arithmetic type. We are > non-compliant in the same way for almost all of the primary > thread-related types: > > pthread_attr_t > pthread_mutex_t > pthread_mutexattr_t > pthread_cond_t > pthread_condattr_t > pthread_once_t > > We got it right for pthread_key_t, though. :-) It looks like this requirement was removed in POSIX.1-2001. A problem with our implementation is that struct pthread* is in the implementation namespace, so we can't define these types in as required. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenSSL question for id_function()
John Polstra <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, > Mike Barcroft <[EMAIL PROTECTED]> wrote: > > John Polstra <[EMAIL PROTECTED]> writes: > > > FreeBSD violates POSIX in this respect. The 1003.1 standard > > > (section 2.5) requires pthread_t to be an arithmetic type. > > > > It looks like this requirement was removed in POSIX.1-2001. > > Interesting. I don't have that standard and wasn't aware of the > change. Are you sure the requirement was removed? It was hidden > away in an obscure place in the 1996 edition of the standard. > There's a table of "Primitive System Data Types" containing the > usual suspects (dev_t, gid_t, uid_t, ...) and including the thread > types I mentioned. Then there's a sentence in the nearby text that > says, "All of the types listed in Table 2-1 shall be arithmetic > types ..." Here's the text: : 12974 All of the types shall be defined as arithmetic types of an appropriate length, with the following : 12975 exceptions: : 12976 XSI key_t : 12977 THR pthread_attr_t : 12978 BAR pthread_barrier_t : 12979 pthread_barrierattr_t : 12980 THR pthread_cond_t : 12981 pthread_condattr_t : 12982 pthread_key_t : 12983 pthread_mutex_t : 12984 pthread_mutexattr_t : 12985 pthread_once_t : 12986 pthread_rwlock_t : 12987 pthread_rwlockattr_t : 12988 SPI pthread_spinlock_t : 12989 TRC trace_attr_t : 12990 trace_event_id_t : 12991 TRC TEF trace_event_set_t : 12992 TRC trace_id_t So it looks like pthread_t must be an arithmetic type, but not the others. My mistake. It goes on to say: : 13010 There are no defined comparison or assignment operators for the following types: : 13011 THR pthread_attr_t : 13012 BAR pthread_barrier_t : 13013 pthread_barrierattr_t : 13014 THR pthread_cond_t : 13015 pthread_condattr_t : 13016 pthread_mutex_t : 13017 pthread_mutexattr_t : 13018 pthread_rwlock_t : 13019 pthread_rwlockattr_t : 13020 SPI pthread_spinlock_t : 13021 TRC trace_attr_t Again pthread_t isn't listed. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Volunteer with genuine i386 cpu & lots of time wanted.
John Baldwin <[EMAIL PROTECTED]> writes: > Fixed. Apparently people don't compile kernels for 80386's very often. Maybe LINT should be building I386 instead of more modern processors. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Feb 27 16:19:26 EST 2003 -- ===> hme linking kernel.debug kern_conf.o: In function `make_dev': kern_conf.o(.text+0x55c): undefined reference to `reserved_majors' kern_conf.o(.text+0x560): undefined reference to `reserved_majors' kern_conf.o(.text+0x5c4): undefined reference to `reserved_majors' kern_conf.o(.text+0x5c8): undefined reference to `reserved_majors' *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 64 bit endian routines
Nate Lawson <[EMAIL PROTECTED]> writes: > First, the simple question: what's the simplest cross-platform way of > implementing scsi_ulto4b and scsi_4btoul (/sys/cam/scsi/scsi_all.h) for > 64 bit values. GEOM (/sys/geom/geom_enc.c) implements it via a 64 bit > cast in g_enc_le8. Is this the best current way? Maybe the byteorder(9) macrofunctions with a union? > Second, anyone done work on unifying our various byte ordering macros? > Besides htonl and ntohl, there are scsi_*ul*, g_enc_*, openssl/aes_locl.h, > machine/endian.h, arpa/nameser.h, and I'm sure there are others. Perhaps > the best thing is to add macros similar to geom_enc_* to machine/endian.h. > Any ideas? Most of these could probably be implemented in terms of the __bswap*() functions in , except for vendor sources like openssl, and htonl and ntohl which already are. I'm not sure if there would be an advantage to moving the geom byte ordering functions to (I guess phk didn't either). Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 64 bit endian routines
Nate Lawson <[EMAIL PROTECTED]> writes: > Both scsi and geom implement unaligned access functions that perform byte > ordering. I never intended to supplant them with __bswap*(). What I want > is for machine/endian.h to have functions that provide 16-64 bit endian > conversions in both aligned and unaligned access forms. After these functions > are there, I'd like us to unify use of them and remove driver-private > versions. Sounds good, though would be more appropriate unless they're MD. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Mon Mar 3 00:15:48 EST 2003 -- ===> hme make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Mon Mar 3 08:17:05 EST 2003 -- ===> hme make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't sshd into box
Wayne <[EMAIL PROTECTED]> writes: > Dear Jason, > >[Not too many people jumping onto this thread to help me.] > >The first two non-bold lines on rebooting, are: > hw.bus.devctl_disable: 0 -> 1 > Entropy harvesting: interrupts ethernet point_to_point. > > So I try: > [EMAIL PROTECTED]:/home/wayne>sysctl hw.bus.devctl_disable: 1 -> 0 >[but the result is:] > sysctl: unknown oid 'hw.bus.devctl_disable:' > > So what the heck is "Entropy harvesting" ? Could this > be blocking my incoming contact attempts? I missed most of this thread, but to set the sysctl you want to: `sysctl hw.bus.devctl_disable=0'. See random(4) for details on entropy harvesting. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
Terry Lambert <[EMAIL PROTECTED]> writes: > Tim Robbins wrote: > > Is there a compelling reason why I shouldn't remove netns? That is, does > > it serve a purpose now that it could not serve if it was moved to the > > Attic? > > Might as well move /sys/i386/conf/GENERIC to the attic while > you are at it. It can serve it's purpose from there, too. This comment is not helpful. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert <[EMAIL PROTECTED]> writes: > Mike Barcroft wrote: > > Terry Lambert <[EMAIL PROTECTED]> writes: > > > Tim Robbins wrote: > > > > Is there a compelling reason why I shouldn't remove netns? That is, does > > > > it serve a purpose now that it could not serve if it was moved to the > > > > Attic? > > > > > > Might as well move /sys/i386/conf/GENERIC to the attic while > > > you are at it. It can serve it's purpose from there, too. > > > > This comment is not helpful. > > Then let me politically correct it. This is much more useful, since you document your assertions which turn out to be incorrect (see below). > I am cynical about the ability of any code to serve the same purpose > from the Attic which it serves in the main source tree. > > What of the rest of my comment, which you removed? I'll > rephrase that, too: > > > Is there a compelling reason for removing this working code to > the Attic? Yes, the compelling reason is that it is broken and no one has stepped forward to fix it. Tim is trying to ascertain whether there are infact real users of this. Real users would either have big patchsets or very old versions of FreeBSD. > I am cynical that any purpose is served by making this change; > my cynicism leads me to believe that the intention of it is to > make it easier for someone to hack up other code which uses > related API's, without having to hack up the netns code as > well. The LINT option for Xerox NS protocols has been commented out since at least 1996. It's very unlikely there are actual FreeBSD users of said protocol. > In other words, it is being done to avoid maintenance, so that > code changes may be hurried into the source tree. No, Tim's goal is to clean up the tree and remove unused code, or find maintainers for broken code that indeed has users. [other comments based on false assertions removed.] > Practically, and historically, it seems that there are a lot > of instances, recently, of code being diked out, not because > it is not currently working, but because someone wished to > avoid maintaining it in the face of some sweeping change or > new idea they want to push into the project. I think most people just don't want to have to maintain code that no one uses. The only way we can figure out if anyone's using the code is to ask. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- ===> lib/libpam/modules/pam_opieaccess cc1: warnings being treated as errors /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c: In function `pam_sm_authenticate': /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c:70: warning: passing arg 2 of `opielookup' discards qualifiers from pointer target type /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c:80: warning: passing arg 1 of `opieaccessfile' discards qualifiers from pointer target type *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- ===> lib/libpam/modules/pam_opieaccess cc1: warnings being treated as errors /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c: In function `pam_sm_authenticate': /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c:70: warning: passing arg 2 of `opielookup' discards qualifiers from pointer target type /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c:80: warning: passing arg 1 of `opieaccessfile' discards qualifiers from pointer target type *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
Andrey A. Chernov <[EMAIL PROTECTED]> writes: > Many programs (from ports too) defines _ISOC99_SOURCE to get C99 > functions, but we don't sense this define currently. Here is the fix for > review: Cool. I didn't realize there was an existing precedence, or I would have used it. > --- cdefs.h.bak Wed Oct 23 05:04:06 2002 > +++ cdefs.h Mon Mar 10 09:11:01 2003 > @@ -360,6 +360,9 @@ > #define __POSIX_VISIBLE 198808 > #define __ISO_C_VISIBLE 0 > #endif /* _POSIX_C_SOURCE */ > +#ifdef _ISOC99_SOURCE > +#define __ISO_C_VISIBLE 1999 > +#endif This part isn't needed... > #else > /*- > * Deal with _ANSI_SOURCE: > @@ -378,7 +381,7 @@ > #define __XSI_VISIBLE 0 > #define __BSD_VISIBLE 0 > #define __ISO_C_VISIBLE 1990 > -#elif defined(_C99_SOURCE) /* Localism to specify strict C99 env. */ > +#elif defined(_ISOC99_SOURCE)/* Strict C99 env. */ > #define __POSIX_VISIBLE 0 > #define __XSI_VISIBLE 0 > #define __BSD_VISIBLE 0 ...since the next line here is: #define __ISO_C_VISIBLE 1999 Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
Andrey A. Chernov <[EMAIL PROTECTED]> writes: > Hm, I don't quite understand, which one part you mean? My patch handles > 2 following cases: > > 1) Any _POSIX_C_SOURCE with _ISOC99_SOURCE. It is from real life example > (ImageMagick). It wants lower POSIX level, *but* wants _ISOC99_SOURCE in > the same time. I don't like this at all. The meaning of _ANSI_SOURCE is that the source is exclusively written in C89 with no BSD, POSIX, or XSI extentions. Similarly, I was intending _C99_SOURCE to be used without any POSIX. Programs looking for C99+POSIX functions should specify POSIX.1-2001, which incorporates both of these. > 2) _ISOC99_SOURCE without any _POSIX_C_SOURCE. In that case it overrides > _ANSI_SOURCE like old _C99_SOURCE does. Yes, _ANSI_SOURCE and any other standard constant are mutually exclusive. Defining _C99_SOURCE or _ANSI_SOURCE with some other standard constant results in unspecified behaviour. I'd like to keep things this way if you're going to rename _C99_SOURCE. Best regards, Mike BArcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
Andrey A. Chernov <[EMAIL PROTECTED]> writes: > On Tue, Mar 11, 2003 at 10:49:43 -0500, Mike Barcroft wrote: > > > 1) Any _POSIX_C_SOURCE with _ISOC99_SOURCE. It is from real life example > > > (ImageMagick). It wants lower POSIX level, *but* wants _ISOC99_SOURCE in > > > the same time. > > > > I don't like this at all. The meaning of _ANSI_SOURCE is that the > > source is exclusively written in C89 with no BSD, POSIX, or XSI > > extentions. Similarly, I was intending _C99_SOURCE to be used without > > any POSIX. Programs looking for C99+POSIX functions should specify > > POSIX.1-2001, which incorporates both of these. > > What to do, if, say, C99 program want to use some POSIX functions from > lower (and not from higher) POSIX standard? I think this is pretty rare. POSIX provides application writers with lots of time to transition away from deprecated interfaces. What functions are missing if you change _POSIX_C_SOURCE to 200112L and remove _ISOC99_SOURCE from the code you posted? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MB_LEN_MAX undeclared (scan.c)
Francisco Solsona <[EMAIL PROTECTED]> writes: > Hi all, > > I just cvsup updated my tree (this is FreeBSD CURRENT, 5.0), and make > buildworld breaks with: It doesn't sound like your tree is completely in-sync. > shouldn't MB_LEN_MAX be defined in /limits.h? It's in revision 1.15 of . Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Mar 12 00:10:07 EST 2003 -- ===> hifn /tinderbox/sparc64/src/sys/dev/hifn/hifn7751.c:47:22: opt_hifn.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/hifn. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html Thu Mar 13 11:38:00 EST 2003 cvs [update aborted]: /work/repo/CVSROOT: Interrupted system call To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Mar 14 00:08:59 EST 2003 -- ===> hme cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/sparc64/sparc64/bus_machdep.c: In function `nexus_dmamem_alloc_size': /tinderbox/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:633: warning: implicit declaration of function `mtx_lock' /tinderbox/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:633: `Giant' undeclared (first use in this function) /tinderbox/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:633: (Each undeclared identifier is reported only once /tinderbox/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:633: for each function it appears in.) /tinderbox/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:639: warning: implicit declaration of function `mtx_unlock' /tinderbox/sparc64/src/sys/sparc64/sparc64/bus_machdep.c: In function `nexus_dmamem_free_size': /tinderbox/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:669: `Giant' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ports broken due to -current change (Re: Ports broken on ia64)
Kris Kennaway <[EMAIL PROTECTED]> writes: > On Fri, Mar 14, 2003 at 02:35:43AM -0800, Kris Kennaway wrote: > > A number of ports have become broken on ia64 for what appears to be a > > similar reason: > > > > In file included from nid3.c:50: > > /usr/include/sys/stat.h:127: syntax error before "u_int" > > /usr/include/sys/stat.h:158: syntax error before "u_int" > > *** Error code 1 > > This appears to also be affecting sparc64 ports (i386 and alpha 5.0 > packages have not been built in a few weeks because of the 4.8 release > cycle), so it may be a general current problem. I'm cross-posting to > [EMAIL PROTECTED] > > > http://bento.freebsd.org/errorlogs/ia64-5-latest/ImageMagick-5.5.5.log > > http://bento.freebsd.org/errorlogs/ia64-5-latest/aide-0.9.log > > http://bento.freebsd.org/errorlogs/ia64-5-latest/gcc-3.2.2_20030205.log > > http://bento.freebsd.org/errorlogs/ia64-5-latest/gnu-finger-1.37.log > > http://bento.freebsd.org/errorlogs/ia64-5-latest/icecast-1.3.12_1.log > > http://bento.freebsd.org/errorlogs/ia64-5-latest/ncbi-toolkit-2002.04.26.log > > http://bento.freebsd.org/errorlogs/ia64-5-latest/normalize-0.7.5_1.log > > http://bento.freebsd.org/errorlogs/ia64-5-latest/osh-020214.log > > http://bento.freebsd.org/errorlogs/ia64-5-latest/pg-010103.log > > > > Can someone please investigate? This was fixed in rev 1.33 of . Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ports broken due to -current change (Re: Ports broken on ia64)
Kris Kennaway <[EMAIL PROTECTED]> writes: > On Fri, Mar 14, 2003 at 09:06:45AM -0800, Kris Kennaway wrote: > > On Fri, Mar 14, 2003 at 11:41:23AM -0500, Mike Barcroft wrote: > > > > > > > Can someone please investigate? > > > > > > This was fixed in rev 1.33 of . > > > > Great, thanks..I'll update the bindists. > > It still appears to be broken: > > http://bento.freebsd.org/errorlogs/i386-5-latest/pg-010103.log > > http://bento.freebsd.org/errorlogs/i386-5-latest/icecast-1.3.12_1.log > > The bindists have the following revision: > > stat.h: > $FreeBSD: src/sys/sys/stat.h,v 1.34 2003/03/14 16:09:48 mike Exp $ I think I see the problem. I'll try to get a fix committed by tonight. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ports broken due to -current change (Re: Ports broken on ia64)
Mike Barcroft <[EMAIL PROTECTED]> writes: > Kris Kennaway <[EMAIL PROTECTED]> writes: > > On Fri, Mar 14, 2003 at 09:06:45AM -0800, Kris Kennaway wrote: > > > On Fri, Mar 14, 2003 at 11:41:23AM -0500, Mike Barcroft wrote: > > > > > > > > > Can someone please investigate? > > > > > > > > This was fixed in rev 1.33 of . > > > > > > Great, thanks..I'll update the bindists. > > > > It still appears to be broken: > > > > http://bento.freebsd.org/errorlogs/i386-5-latest/pg-010103.log > > > > http://bento.freebsd.org/errorlogs/i386-5-latest/icecast-1.3.12_1.log > > > > The bindists have the following revision: > > > > stat.h: > > $FreeBSD: src/sys/sys/stat.h,v 1.34 2003/03/14 16:09:48 mike Exp $ > > I think I see the problem. I'll try to get a fix committed by > tonight. Okay, try revision 1.35. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- ===> usr.sbin/gstat make: don't know how to make subr_sbuf.c. Stop *** Error code 2 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
