Re: mips32 + gcc9 -- still broken

I'm just testing the build out before I put up some patches. jhb mentioned we don't install the libatomic gcc bits right now? So we should likely poke at that somewhat too after this. I'll put up some patches to fix gcc builds and this c++ contention thing soon. -adrian On Sun, 4 Oct 2020 at

Re: mips32 + gcc9 -- still broken

Sorry, i hadn't picked up on this thread at all. What is the concrete patch you are proposing? Is is in Phabricator somewhere? (Note that when building with gcc, we should really just automatically add -latomic, to get rid of these errors.) -Dimitry > On 5 Oct 2020, at 05:40, Adrian Chadd wro

Re: mips32 + gcc9 -- still broken

ping! I've got the world building on gcc + mips32 just patching cxx_contention_t to be 32 bits, but it looks like an ABI change. Would the better thing be to just make it 32 bits on FreeBSD + MIPS for now? I don't think anyone is going to mind that changing at this point. -adrian On Sat, 3 O

Re: mips32 + gcc9 -- still broken

On Mon, 21 Sep 2020 at 00:43, Alexander Richardson wrote: > > On Mon, 21 Sep 2020, 07:38 Adrian Chadd, wrote: > >> So, the big list of unknown symbols was my fault! Whoops. >> >> i've gotten further using gcc-6.4 by fixing some of the warnings/issues >> that have crept up. >> >> Here's a review

Re: mips32 + gcc9 -- still broken

On Mon, 21 Sep 2020, 07:38 Adrian Chadd, wrote: > So, the big list of unknown symbols was my fault! Whoops. > > i've gotten further using gcc-6.4 by fixing some of the warnings/issues > that have crept up. > > Here's a review for one of them: > > https://reviews.freebsd.org/D26504 > > However, no

Re: mips32 + gcc9 -- still broken

So, the big list of unknown symbols was my fault! Whoops. i've gotten further using gcc-6.4 by fixing some of the warnings/issues that have crept up. Here's a review for one of them: https://reviews.freebsd.org/D26504 However, now I've hit: /usr/local/bin/mips-unknown-freebsd13.0-ld: /usr/home

mips32 + gcc9 -- still broken

hi! So mips32 and gcc9 is broken, and things have been broken with mips32+gcc for months now. I've been poking slowly at the various build failures and they're getting slowly fixed, but this one deep in linker fun is stumping me: === /usr/local/bin/mips-unknown-freebsd13.0-gcc9 --sysroot=/usr/h

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

On 13/08/2019 16:31, Hans Petter Selasky wrote: > 1) AcpiUtAcquireMutex() doesn't support recursion, but also fails to > report an error when such a condition is occurring. Here is the > backtrace of the illegal mutex recursion. I have an old patch that replaces hand-rolled ACPI platform primitive

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

Hi, After tearing ACPI apart, there appears to be an issue like following: 1) AcpiUtAcquireMutex() doesn't support recursion, but also fails to report an error when such a condition is occurring. Here is the backtrace of the illegal mutex recursion. > AcpiUtAcquireMutex() at AcpiUtAcquireMut

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

I’m 99% sure that the boot breakage is due to this commit: Author: jkim Date: Tue Jul 9 18:02:36 2019 New Revision: 349863 URL: https://svnweb.freebsd.org/changeset/base/349863 Log: MFV: r349861 Import ACPICA 20190703. I have two systems now that are affected, and both of them are “fixed”

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

Sorry boot is broken from harddrive or iso(as cdrom) for some users(at least 3) since somewhere in the revisions listed above and that still stands as of the Head snapshot of 072519. Sorry for lack of clarity. There was a thread under Problem with USB after r349133 but I decided to rename it to try

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

Rodney, you are right that the .iso "should work", and a lot of other projects, from Microsoft Windows 10 to Trident BSD only a furnish an iso, and no img file. FreeBSD is one of the few that give you both choices. The problem goes deeper than any one operating system. If you've ever used the Rufus

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

> The .iso files are for a dvd install. If you want to use a usb, download > the .img files. > > FreeBSD-13.0-CURRENT-amd64-20190725-r350322-memstick.img > The FreeBSD

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

The .iso files are for a dvd install. If you want to use a usb, download the .img files. FreeBSD-13.0-CURRENT-amd64-20190725-r350322-memstick.img ( or get the .xz vers

Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

I just tested the snapshot from 20190725 and still am getting the root mount rating for "boot on boot. I think something deeper broke between r349133 and r349160 because even when I turn off wait for Root Mount on usb root via a loader variable boot just get's stuck later on in the process. This i

Re: svn commit: r336002 - in head: usr.bin/netstat usr.sbin/tcpdrop [ as-of -r336013: still broken: ci.freebsd.org FreeBSD-head-{mips,powerpc,powerpcspe}-build

> Author: brooks > Date: Thu Jul 5 17:02:10 2018 > New Revision: 336002 > URL: > https://svnweb.freebsd.org/changeset/base/336002 > > > Log: > Work around lame warnings in ancient gcc on 32-bit platforms. > > Fixes r335979. [The below are the gcc 4.2.1 based 32-bit architectures.] htt

ci.freebsd.org's FreeBSD-head-amd64-gcc broken by -r335338 and/or -r335339 (-r335389 still broken)

>From https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6190/consoleText and https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6213/ as examples: --- ixl_pf_qmgr.o --- In file included from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.h:36:0, from /workspace/src/sys/dev/ixl/ixl_pf_qmgr.

Re: head -r333905 broke the builds [ -r333906 changed the details but they are still broken]

On 2018-May-19, at 7:56 PM, Mark Millard wrote: > https://ci.freebsd.org shows all the builds being broken and > going through the list -r333903 was working but -r333905 and > later are not. (I ignore riscv64 here.) > > Using powerpc64 as an -r333905 example: > > --- sourcefilter.o --- > In fil

Re: Ports still broken by ino64?

I'm sure stas can figure it out! -a On 25 June 2017 at 22:44, Thomas Mueller wrote: > from Adrian Chadd: > >> valgrind broke as part of the ino64 work :( > > Valgrind was not on my mind! Your post sent me to > > ls -d /usr/ports/*/val* > > to find valgrind, and then read the pkg-descr. > > On

Re: Ports still broken by ino64?

from Adrian Chadd: > valgrind broke as part of the ino64 work :( Valgrind was not on my mind! Your post sent me to ls -d /usr/ports/*/val* to find valgrind, and then read the pkg-descr. One less tool for getting debugging information when something crashes? Tom

Re: Ports still broken by ino64?

Hi, valgrind broke as part of the ino64 work :( -a ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Ports still broken by ino64?

> Maybe not, but I think so. synth(8) requires the ada compiler which means > lang/gcc6-aux or lang/gcc5-aux and those DID require work to install on > ino64. I believe that this is now resolved, but I would seriously consider > simply installing synth from the package. It has no run or lib depends

Re: Ports still broken by ino64?

On Fri, Jun 23, 2017 at 8:19 PM, Thomas Mueller wrote: > On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller > wrote: > > > > I remember some ports on FreeBSD-current were rendered nonbuildable by > the > > > introduction of 64-bit inodes (ino64). > > > > What is the progress on resolving those snag

Re: Ports still broken by ino64?

On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller wrote: > > I remember some ports on FreeBSD-current were rendered nonbuildable by the > > introduction of 64-bit inodes (ino64). > > What is the progress on resolving those snags? > > I haven't heard anything recently and was unable to find anythi

Re: Ports still broken by ino64?

On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller wrote: > I remember some ports on FreeBSD-current were rendered nonbuildable by the > introduction of 64-bit inodes (ino64). > > What is the progress on resolving those snags? > > I haven't heard anything recently and was unable to find anything on

Ports still broken by ino64?

I remember some ports on FreeBSD-current were rendered nonbuildable by the introduction of 64-bit inodes (ino64). What is the progress on resolving those snags? I haven't heard anything recently and was unable to find anything on wiki.freebsd.org. So how do I know the current status? I am par

Re: m4 still broken on gcc platforms

wrote: > > > > Hi, > > > > > > > > I am still seeing this with arm/power/sparc/mips. Can somene please > > > > fix it? > > > > > > Did this get fixed because I still see it on -current while trying to > > > build armeb for the AVILA and

Re: m4 still broken on gcc platforms

r/sparc/mips. Can somene please fix > > > it? > > > > Did this get fixed because I still see it on -current while trying to > > build armeb for the AVILA and CAMBRIA boards. > > > It has ben fixed last week The build is still broken. I did not looked too cl

Re: m4 still broken on gcc platforms

r/sparc/mips. Can somene please fix > > > it? > > > > Did this get fixed because I still see it on -current while trying to > > build armeb for the AVILA and CAMBRIA boards. > > > It has ben fixed last week It is still broken for me. Maybe it is my environment. Th

Re: m4 still broken on gcc platforms

On Thu, Aug 07, 2014 at 10:15:51AM +0200, John Hay wrote: > On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote: > > Hi, > > > > I am still seeing this with arm/power/sparc/mips. Can somene please fix it? > > Did this get fixed because I still see it on -current while trying to > buil

Re: m4 still broken on gcc platforms

On Thu, Jul 31, 2014 at 08:15:32AM +, Bjoern A. Zeeb wrote: > Hi, > > I am still seeing this with arm/power/sparc/mips. Can somene please fix it? Did this get fixed because I still see it on -current while trying to build armeb for the AVILA and CAMBRIA boards. Regards John -- John Hay --

m4 still broken on gcc platforms

Hi, I am still seeing this with arm/power/sparc/mips. Can somene please fix it? ===> usr.bin/m4/tests (all) cc1: warnings being treated as errors /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c: In function 'm4errx': /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c:268: warning: declaration of 'eval' sh

dc(1) -e "6 2 / p" is still broken as of r207919

Hello! Just to remind that still: ~> dc -e "6 2 / p" Segmentation fault (core dumped) This was already mentioned on this list: http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016560.html and there is a patch proposed in the same thread: http://lists.freebsd.org/pipermail/freebsd-cu

Re: CF cards / ATAng / interrupt code still broken

I've also had problems with CF cards and ATAng :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"

CF cards / ATAng / interrupt code still broken

Hello, as reproducable seen on my IBM Thinkpad, current as of some days ago has problems to boot with my 128MB noname CF card inserted. The panic output is very similar the problem Alex Dupre reported in mid of september, but Sorens patch which should be tried to get this stuff fixed but the patch

cardbus code still broken in current

cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstric t-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fforma t-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contri b/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/

Re: yep, umass still broken

What motherboards are you using with the OHCI controller? John-Mark Gurney (jmg@) and I kicked this around at bsdcon but couldn't reproduce it. If its a common board or chipset we can probably get it and work on the issue. The zeroed block showed up in 8KB boundaries in the instance we saw, whic

Re: yep, umass still broken

-- Your message was: (from "Wesley Morgan") On Fri, 26 Sep 2003, Brian Fundakowski Feldman wrote: > I can get fdisk to read the MBR, but when I try mdir, I get this trace back > (of course, no crash dump because those haven't worked for me in a year): > trap 0xc > memcpy() > ohci_softintr() > us

Re: yep, umass still broken

On Fri, 26 Sep 2003, Brian Fundakowski Feldman wrote: > I can get fdisk to read the MBR, but when I try mdir, I get this trace back > (of course, no crash dump because those haven't worked for me in a year): > trap 0xc > memcpy() > ohci_softintr() > usb_schedsoftintr() > ohci_intr1() > ohci_intr()

Re: yep, umass still broken

On Friday 26 September 2003 09:18, Brian Fundakowski Feldman wrote: > ohci_intr() > ithread_loop() > > Anyone have any clued? I'll include my dmesg, of course. Yes, the same bad thing with umass on my sony vaio pcg-v505bx laptop. This is the only reason I have to keep slackware linux within to

yep, umass still broken

I can get fdisk to read the MBR, but when I try mdir, I get this trace back (of course, no crash dump because those haven't worked for me in a year): trap 0xc memcpy() ohci_softintr() usb_schedsoftintr() ohci_intr1() ohci_intr() ithread_loop() Anyone have any clued? I'll include my dmesg, of cou

Re: Recent sound change still broken?

> >David Xu wrote: >| >| I tried to backout ac97.c revision 1.43, now my sound card works again, >| If someone wants more information, please tell me. > >David > >Could you revert to head and check that the mixer "ogain" is non-zero >(say 100 :-)? On some codecs "ogain" provides the traditional >

Re: Recent sound change still broken?

On Thursday 28 August 2003 10:33 pm, Orion Hodson wrote: > Could you revert to head and check that the mixer "ogain" is non-zero > (say 100 :-)? On some codecs "ogain" provides the traditional > functionality of "vol". I appreciate this is not ideal. OTOH, "OGain" makes *SLIGHTLY* more sense for

Re: Recent sound change still broken?

David Xu wrote: | | I tried to backout ac97.c revision 1.43, now my sound card works again, | If someone wants more information, please tell me. David Could you revert to head and check that the mixer "ogain" is non-zero (say 100 :-)? On some codecs "ogain" provides the traditional functionalit

Re: Recent sound change still broken?

On Thursday 28 August 2003 07:37, David Xu wrote: > My patch http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/54810 ever worked > well for my old Creative sound card, the device is probed, but now no sound > at all. :-( > > I tried to backout ac97.c revision 1.43, now my sound card works again, If

Re: Recent sound change still broken?

I use es137x module: [EMAIL PROTECTED]:/home/davidxu> kldstat Id Refs AddressSize Name 15 0xc010 37fc28 kernel 21 0xc048 6964 snd_es137x.ko 32 0xc0487000 1e554snd_pcm.ko 41 0xc5f0e000 16000radeon.ko David Xu On Thursday 28 August 2003 07:37, Da

Recent sound change still broken?

My patch http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/54810 ever worked well for my old Creative sound card, the device is probed, but now no sound at all. :-( dmesg: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994

Re: ufs2 snapshots in 5.1 still broken

>I'm not use what you mean. The suspension of I/O during creation of a >snapshot is the intended behaviour, but it doesn't take long. For example, df -h /dev/x 813G 7.1G 741G 1%/export df -i /dev/853004856 7422014 777342454 1% 328978 1480728120% /export ~330

Re: ufs2 snapshots in 5.1 still broken

On Sat, 19 Jul 2003, [iso-8859-2] Branko F. Gra?nar wrote: > This only accours if there is alot (several 100 thousand) of small files > on a filesystem. > > During snapshot creation all userland I/O hangs until snapshot is made. > Machine doesn't respond even on ping!. After snapshot is created, >

ufs2 snapshots in 5.1 still broken

Hi. I upgraded my home server to 5.1-release today with hope, that ufs2 filesystem snapshot issues will be fixed and working ... but they are not. this is a serious issue, becouse background fsck is on by default, which reflects in creating filesystem snapshot on mounting not cleanly umoun

Re: World is still broken. Please fix.

Martin Blapp said: > > > In file included from /usr/obj/usr/src/i386/usr/include/sys/types.h:45, > from /usr/src/usr.bin/xlint/llib/llib-lposix:39: > /usr/obj/usr/src/i386/usr/include/sys/cdefs.h:148:2: #error FreeBSD alloca > support needed for this compiler > *** Error code 1 D

World is still broken. Please fix.

Is anybody testing his changes before he commits them ? In file included from /usr/obj/usr/src/i386/usr/include/sys/types.h:45, from /usr/src/usr.bin/xlint/llib/llib-lposix:39: /usr/obj/usr/src/i386/usr/include/sys/cdefs.h:148:2: #error FreeBSD alloca support needed for this comp

Re: PC98 still broken

On Sat, Mar 29, 2003 at 05:01:27AM -0500, Matthew N. Dodd wrote: > On Sat, 29 Mar 2003, Takahashi Yoshihiro wrote: > > > ===> pcspeaker > > > @ -> /usr/src/sys > > > machine -> /usr/src/sys/i386/include > > > make: don't know how to make spkr.c. Stop > > > *** Error code 2 > > Sorry about that. F

Re: PC98 still broken

On Sat, 29 Mar 2003, Takahashi Yoshihiro wrote: > > ===> pcspeaker > > @ -> /usr/src/sys > > machine -> /usr/src/sys/i386/include > > make: don't know how to make spkr.c. Stop > > *** Error code 2 Sorry about that. Fixed. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD

PC98 still broken

> ===> pcspeaker > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > make: don't know how to make spkr.c. Stop > *** Error code 2 --- TAKAHASHI Yoshihiro <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/li

Re: TCP is still broken

In article you write: >This program, based on one from the Apache 2 configure script, still causes >-current to lock up solid despite the recent bug fixes to the tcptw code. >Explicitly closing connected_s before returning from main() seems to avoid >the problem. Thanks for the test case. I've j

Re: signals still broken ?

On Thu, Feb 27, 2003 at 01:10:03AM +1100, Tim Robbins wrote: > On Wed, Feb 26, 2003 at 06:25:39AM -0500, Mike Makonnen wrote: > > > The following program is stuck in pause(3) forever. I have reproduced the bug in > > 5.0-RELEASE, but 4.7-STABLE behaves as expected: the child resumes upon > > recei

Re: signals still broken ?

On Wed, Feb 26, 2003 at 06:25:39AM -0500, Mike Makonnen wrote: > The following program is stuck in pause(3) forever. I have reproduced the bug in > 5.0-RELEASE, but 4.7-STABLE behaves as expected: the child resumes upon > receiving SIGCONT. I spent a while trying to decipher the 5.x signal code a

signals still broken ?

# uname -a FreeBSD kokeb.ambesa.net 5.0-CURRENT FreeBSD 5.0-CURRENT #8: Tue Feb 25 16:45:54 EST 2003 [EMAIL PROTECTED]:/daemon/build/current/obj/daemon/build/current/src/sys/QUARK i386 The following program is stuck in pause(3) forever. I have reproduced the bug in 5.0-RELEASE, but 4.7-STABLE be

TCP is still broken

This program, based on one from the Apache 2 configure script, still causes -current to lock up solid despite the recent bug fixes to the tcptw code. Explicitly closing connected_s before returning from main() seems to avoid the problem. #include #include #include #include #include #include

Re: make release still broken

* De: Ruslan Ermilov <[EMAIL PROTECTED]> [ Data: 2003-01-26 ] [ Subjecte: make release still broken ] > Hi Juli! > > This is just a FYI that your patch for newfs(8) that makes > it use libufs _does_ make it fit onto the MFSROOT floppy > again! Okay, cool. I hav

make release still broken

Hi Juli! This is just a FYI that your patch for newfs(8) that makes it use libufs _does_ make it fit onto the MFSROOT floppy again! The bad thing is that the kern.flp is now overflowed again, due to the wlan(4) thing, I think. I'm currently testing with this patch: %%% Index: release/i386/drive

Re: Cardbus/dc(4) still broken

In message: <[EMAIL PROTECTED]> Mark Murray <[EMAIL PROTECTED]> writes: : > Fix the dc driver to not suck so much in this reguard. :-) : > : > I think that some flags aren't being properly set in the probe : > routine, but haven't had a chance to look at it in detail. I'm sorry : > I

Re: Cardbus/dc(4) still broken

> Fix the dc driver to not suck so much in this reguard. :-) > > I think that some flags aren't being properly set in the probe > routine, but haven't had a chance to look at it in detail. I'm sorry > I don't have a more complete answer... What is my prognosis for the future? Is my best chance

Re: Cardbus/dc(4) still broken

In message: <[EMAIL PROTECTED]> Mark Murray <[EMAIL PROTECTED]> writes: : > Yup. Known problem with some cards. : : How do I fix? Fix the dc driver to not suck so much in this reguard. :-) I think that some flags aren't being properly set in the probe routine, but haven't had a chan

Re: Cardbus/dc(4) still broken

> Yup. Known problem with some cards. How do I fix? M -- Mark Murray Beware! I'm umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: Cardbus/dc(4) still broken

Yup. Known problem with some cards. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Cardbus/dc(4) still broken

Hi My Netgear FA510 card is still not working. If I boot with the card in a cardbus slot, I get the below: Product version: 5.0 Product name: NETGEAR | FA510 | Fast Ethernet CardBus Card | 1.00 | Manufacturer ID: 13958100 Functions: Network Adaptor, Multi-Functioned Function Extension: 0102 Funct

Re: rc_ng: amd invocation is still broken

In article <[EMAIL PROTECTED]>, Mike Makonnen <[EMAIL PROTECTED]> wrote: > On Mon, 24 Jun 2002 10:54:06 -0700 (PDT) > John Polstra <[EMAIL PROTECTED]> wrote: > > > I updated my -current system yesterday, and AMD still isn't being > > started quite right by rc_ng. The messages at boot time say:

Re: rc_ng: amd invocation is still broken

On Mon, 24 Jun 2002 10:54:06 -0700 (PDT) John Polstra <[EMAIL PROTECTED]> wrote: > I updated my -current system yesterday, and AMD still isn't being > started quite right by rc_ng. The messages at boot time say: > does the following patch fix it? If so, please commit it. Cheers, Mike Makonnen

rc_ng: amd invocation is still broken

I updated my -current system yesterday, and AMD still isn't being started quite right by rc_ng. The messages at boot time say: Starting amd. Amd configuration file (/etc/amd.conf): No such file or directory Here is my rc.conf file: rc_ng="YES" hostname="blake.polstra.com"

Re: binutils doc still broken

On Sat, 22 Jun 2002, David O'Brien wrote: > On Sat, Jun 22, 2002 at 09:59:44AM -0700, Steve Kargl wrote: > > make: don't know how to make remote.texi. Stop > > remote.texi does not exist in /usr/src. > > > > The obvious fix of removing remote.texi from the Makefile > > doesn't work because of > >

Re: binutils doc still broken

On Sat, Jun 22, 2002 at 10:05:38AM -0700, David O'Brien wrote: > On Sat, Jun 22, 2002 at 09:59:44AM -0700, Steve Kargl wrote: > > make: don't know how to make remote.texi. Stop > > remote.texi does not exist in /usr/src. > > > > The obvious fix of removing remote.texi from the Makefile > > doesn'

Re: binutils doc still broken

On Sat, Jun 22, 2002 at 09:59:44AM -0700, Steve Kargl wrote: > make: don't know how to make remote.texi. Stop > remote.texi does not exist in /usr/src. > > The obvious fix of removing remote.texi from the Makefile > doesn't work because of I just took a larger hammer and just turned off docs. T

binutils doc still broken

sp.info > gasp.info.gz ln -sf /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/\ all-cfg.texi gdb-cfg.texi make: don't know how to make remote.texi. Stop remote.texi does not exist in /usr/src. The obvious fix of removing remote.texi from the Makefile doesn't work because of /u

fwiw: nfs loopback still broken in -current

NFS loopback mounts still periodically gets hung with: ypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include -D_KERNEL -ffreestanding -incl

Re: buildworld is still broken in libpam/libpam

> The patch is attached. Thanks! Committed. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

buildworld is still broken in libpam/libpam

Hi! Alpha buildworld is still broken due to the WARNS=4 change: : cc -O -pipe -nostdinc :-I/CURRENT/usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam/include :-I/CURRENT/usr/src/lib/libpam/libpam/../../../contrib/libpam/libpam_misc/include :-I/CURRENT/usr/src/lib/libpam/libpam

Re: help! su(1) is still broken

There is a recen-ish fix that may sort this out. Re-sup and build again... M > I cvsupped earlier in the week (august 9th) for the first time in > about 3 weeks. The pam changes seem to have broken su on my machine. > I'm using the default pam.conf (via mergemaster), so I would assume > that i

help! su(1) is still broken

I cvsupped earlier in the week (august 9th) for the first time in about 3 weeks. The pam changes seem to have broken su on my machine. I'm using the default pam.conf (via mergemaster), so I would assume that it should work. I can't seem to tweak it into behaving. I searched the list, but moving l

Re: PAMmed su still broken for passwordless accounts

> > Feature, not bug. PAM has been told to use "unix" authentication. > > The bug turns out to be that PAM shouldn't have been told this. The > non-PAM case uses the following check to avoid checking for passwords > on passwordless accounts: > --- > /* if target requires a password

Re: PAMmed su still broken for passwordless accounts

On Sat, 28 Apr 2001, Mark Murray wrote: > > > 1) su on passwordless accounts. > > >(a) `su ' now bogusly prompts for a password. It lets > > >you in if you type an empty password. (a1) It also lets you in if you type garbage followed by a newline. > > >(b) `echo somec

Re: PAMmed su still broken for passwordless accounts

> > 1) su on passwordless accounts. > >(a) `su ' now bogusly prompts for a password. It lets > >you in if you type an empty password. > >(b) `echo somecommand | su ' now bogusly prompts for > >a password. su doesn't find a password, and exits without printing > >a

PAMmed su still broken for passwordless accounts

On Wed, 28 Mar 2001, Bruce Evans wrote: > > markm 2001/03/27 11:40:51 PST > > > > Modified files: > > etc pam.conf > > libexec/rshd Makefile rshd.8 rshd.c > > libexec/ftpd Makefile ftpd.c > > usr.bin/loginMakefile login.1 login.

Re: make release still broken...

> > ===> rpcsvc > > rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > > rpcgen: cannot find any C preprocessor (cpp) > > *** Error code 1 > > > Let me start a release. This means rpcgen has been using > /usr/libexec/cpp which is *only* for the compiler's use. rpcgen s

Re: make release still broken...

On Tue, Jan 09, 2001 at 09:11:20AM +0100, Poul-Henning Kamp wrote: > ===> rpcsvc > rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > rpcgen: cannot find any C preprocessor (cpp) > *** Error code 1 Let me start a release. This means rpcgen has been using /usr/libexec/cp

make release still broken...

-- >>> stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/us

Re: -current still broken as of today, just in case anyone's interested. :)

> ===> usr.bin > ===> usr.bin/apply > cc -O -pipe -Wall -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/appl > y/apply.c > In file included from /usr/obj/usr/src/i386/usr/include/sys/wait.h:93, > from /usr/src/usr.bin/apply/apply.c:45: > /usr/obj/usr/src/i386/usr/include

-current still broken as of today, just in case anyone's interested. :)

===> usr.bin ===> usr.bin/apply cc -O -pipe -Wall -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/appl y/apply.c In file included from /usr/obj/usr/src/i386/usr/include/sys/wait.h:93, from /usr/src/usr.bin/apply/apply.c:45: /usr/obj/usr/src/i386/usr/include/machine/endia

make release still broken

bsd.ports.mk don't have the version of new perl (5.006). So, make release still broken. chflags -R noschg /R/stage/trees touch release.2 Making docs... ===> Extracting for docproj-1.1 >> No MD5 checksum file. ===> Patching for docproj-1.1 ===> Configuring for docproj-1.1

Re: Release still broken with new Perl

> > On 29-Jun-00 Mark Murray wrote: > > Hi > > > > I just committed a fix for this. > > Thank you!! Please give me feedback on this when releases work again for you... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "uns

Re: Release still broken with new Perl

On 29-Jun-00 Mark Murray wrote: > Hi > > I just committed a fix for this. Thank you!! > M -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscr

Re: Release still broken with new Perl

Hi I just committed a fix for this. M > Mark, > > A test release I built today died while installing Perl the second > time around into the trees directory where the install distributions > are rolled from as follows: > > ===> gnu/usr.bin/perl/library/re > cd /usr/obj/usr/src/gnu/usr.bin/perl

Re: Release still broken with new Perl

On 28-Jun-00 Mark Murray wrote: >> ===> gnu/usr.bin/perl/library/B >> make: don't know how to make distribute. Stop > > OK - I know how to fix this. > > Thanks for the report! Thanks. :) > M > -- > Mark Murray > Join the anti-SPAM movement: http://www.cauce.org -- John Baldwin <[EMAIL PROT

Re: Release still broken with new Perl

> ===> gnu/usr.bin/perl/library/B > make: don't know how to make distribute. Stop OK - I know how to fix this. Thanks for the report! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the bod

Re: Release still broken with new Perl

> On Tue, Jun 27, 2000 at 03:55:59PM -0700, John Baldwin wrote: > > Mark, > > > > A test release I built today died while installing Perl the second > > time around into the trees directory where the install distributions > > are rolled from as follows: > > I just successfully upgraded from a ap

Re: Release still broken with new Perl

On Tue, Jun 27, 2000 at 03:55:59PM -0700, John Baldwin wrote: > Mark, > > A test release I built today died while installing Perl the second > time around into the trees directory where the install distributions > are rolled from as follows: I just successfully upgraded from a approx 3-4 week ol

Release still broken with new Perl

Mark, A test release I built today died while installing Perl the second time around into the trees directory where the install distributions are rolled from as follows: ===> gnu/usr.bin/perl/library/re cd /usr/obj/usr/src/gnu/usr.bin/perl/library/re/ext/re ; make -B install INSTALLPRIVLIB=/R/

make release still broken...

===> bin/csh install -c -s -o root -g wheel -m 555 csh /syv/release/bin /syv/release/bin/tcsh -> /syv/release/bin/csh ===> bin/csh/nls ===> bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /syv/release/../usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat install: /syv/release/../usr/shar

Re: -current is still broken as of 2000/01/27

On Thu, 27 Jan 2000 18:35:33 PST, Jason Evans wrote: > This is the same kind of breakage I caused when moving some definitions > into unistd.h. I would call it bootstrapping breakage, but others who know > the build system better claim it's avoidable. I think it _is_ avoidable. One way to av

  1   2   >