On Wed, Jan 15, 2020 at 07:25:10AM +0100, Matthias Petermann wrote:
> Hello Maya,
>
> many thanks for your response. I used the patch in my NetBSD 9.0 (RC1)
> kernel and rebuilt it. However, it does not seem to be the solution to the
> problem. If i want to send the system to sleep, the message st
m...@petermann-it.de (Matthias Petermann) writes:
>Hello Maya,
>many thanks for your response. I used the patch in my NetBSD 9.0 (RC1)=20
>kernel and rebuilt it. However, it does not seem to be the solution to=20
>the problem. If i want to send the system to sleep, the message still=20
>appears:
Hello Maya,
many thanks for your response. I used the patch in my NetBSD 9.0 (RC1)
kernel and rebuilt it. However, it does not seem to be the solution to
the problem. If i want to send the system to sleep, the message still
appears:
[92,499360] Devices without power management suppo
Updating src tree:
P src/doc/CHANGES
P src/external/bsd/libarchive/dist/libarchive/archive_write_disk_posix.c
P src/lib/libc/thread-stub/thread-stub.c
P src/sbin/rndctl/Makefile
P src/share/man/man4/piixpm.4
P src/share/man/man4/wd.4
P src/share/mk/bsd.own.mk
P src/sys/arch/arm/imx/if_enet.c
P sr
*--- dependall-exec_elf32
---/c/usr/src/obj/tooldir.NetBSD-9.99.17-evbarm/bin/nbctfconvert -L VERSION
exec_elf32.o--- core_elf32.o ---# compile
exec_elf32/core_elf32.o/c/usr/src/obj/tooldir.NetBSD-9.99.17-evbarm/bin/armv7--netbsdelf-eabihf-gcc
-O2 -g -std=gnu99-Wall -Wstrict-prototypes -W
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2020.01.14.22.55.27 msaitoh src/sys/dev/pci/piixpmreg.h,v 1.12
2020.01.14.23.13.36 christos src/sbin/rndctl/Makefile,v 1.5
Log files can be found at:
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.01.14.16.48.18.
An extract from the build.sh output follows:
/tmp/bracket/build/2020.01.14.16.48.18-i386/tools/
Riccardo Mottola wrote:
>I confirm the peristent build failure, even if starting totally from
>scratch (clean obj dir) and no -u flag.
>Built tools first, then distribution. Same error, on amd64
>
>could it be that the combination
>MKLLVM = no
>HAVE_LLVM=no
>MKLLVMRT = no
>
>is not supported?
Hi all!
I confirm the peristent build failure, even if starting totally from
scratch (clean obj dir) and no -u flag.
Built tools first, then distribution. Same error, on amd64
could it be that the combination
MKLLVM = no
HAVE_LLVM=no
MKLLVMRT = no
is not supported?
the error is:
# compile
On Tue, 14 Jan 2020 at 18:28, Greg Troxel wrote:
>
> This appears to be a broken tar issue surounding hardlinks and Christos
> has backed it out. So perhaps update and rebuild and try again.
I vaguely remember similar discussion sometimes ago.
>
> I can see why you refer to 9.33.37 as a version
This appears to be a broken tar issue surounding hardlinks and Christos
has backed it out. So perhaps update and rebuild and try again.
I can see why you refer to 9.33.37 as a version of NetBSD, but really it
is not a name for a specific version. That last number is increased
when there is an in
On Tue, 14 Jan 2020 at 15:43, Patrick Welche wrote:
>
> On Tue, Jan 14, 2020 at 03:20:46PM +, Chavdar Ivanov wrote:
> > To complete the analysis, I tried to upgrade a 9.99.36 system to
> > 9.99.37 by booting off the ISO file I previously used for the clean
> > installation described above.
> >
On Tue, 14 Jan 2020 at 15:43, Patrick Welche wrote:
>
> On Tue, Jan 14, 2020 at 03:20:46PM +, Chavdar Ivanov wrote:
> > To complete the analysis, I tried to upgrade a 9.99.36 system to
> > 9.99.37 by booting off the ISO file I previously used for the clean
> > installation described above.
> >
On Tue, Jan 14, 2020 at 03:20:46PM +, Chavdar Ivanov wrote:
> To complete the analysis, I tried to upgrade a 9.99.36 system to
> 9.99.37 by booting off the ISO file I previously used for the clean
> installation described above.
>
> It failed in a similar was as with sysupgrade :
>
> ls -l /s
On Tue, 14 Jan 2020 at 14:20, Chavdar Ivanov wrote:
>
> On Tue, 14 Jan 2020 at 13:41, Patrick Welche wrote:
> >
> > On Tue, Jan 14, 2020 at 01:28:15PM +, Chavdar Ivanov wrote:
> > > Clean installation from the same ISO file is fine, so it probably was
> > > sysupgrade failure induced by the d
On Tue, 14 Jan 2020 at 13:41, Patrick Welche wrote:
>
> On Tue, Jan 14, 2020 at 01:28:15PM +, Chavdar Ivanov wrote:
> > Clean installation from the same ISO file is fine, so it probably was
> > sysupgrade failure induced by the different tar.
>
> You did quite some detective work! (Yes, I don'
On Tue, 14 Jan 2020 at 12:45, Chavdar Ivanov wrote:
>
> I was able to downgrade to 9.99.36 using sysupgrade after linking
> /usr/bin/tar to /usr/pkg/bin/bsdtar, as /bin/tar /bin/pax and
> /bin/cpio were also of length 0 on my 9.99.37...
>
> Unintended consequences.
>
> On Tue, 14 Jan 2020 at 12:40
I was able to downgrade to 9.99.36 using sysupgrade after linking
/usr/bin/tar to /usr/pkg/bin/bsdtar, as /bin/tar /bin/pax and
/bin/cpio were also of length 0 on my 9.99.37...
Unintended consequences.
On Tue, 14 Jan 2020 at 12:40, Chavdar Ivanov wrote:
>
> On Tue, 14 Jan 2020 at 12:29, Patrick
On Tue, 14 Jan 2020 at 12:29, Patrick Welche wrote:
>
> On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote:
> > There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130
> > lines...
>
> FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me:
> $ ls -l `w
On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote:
> There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130
> lines...
FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me:
$ ls -l `which gcc`
-r-xr-xr-x 2 root wheel 1045384 Jan 13 17:43 /usr/bin
On Tue, 14 Jan 2020 at 12:22, Rares Aioanei wrote:
>
> Meanwhile, I found that at least /usr/bin/gcc and /sbin/reboot are
> empty files. I upgraded to 9.99.37 via "sysupgrade auto $URL".
I do essentially the same, but with self-built versions. In my case
/sbin/reboot appears OK, but /usr/bin/lex
On Tue, 14 Jan 2020 at 12:18, Chavdar Ivanov wrote:
>
> On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote:
> >
> > Unsure if related or not, but I updated pkgsrc, then ran
> > "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to
> > py-setuptools, and gcc3 needs binutils, which fails a
Meanwhile, I found that at least /usr/bin/gcc and /sbin/reboot are
empty files. I upgraded to 9.99.37 via "sysupgrade auto $URL".
On Tue, Jan 14, 2020 at 2:18 PM Chavdar Ivanov wrote:
>
> On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote:
> >
> > Unsure if related or not, but I updated pkgsrc, t
On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote:
>
> Unsure if related or not, but I updated pkgsrc, then ran
> "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to
> py-setuptools, and gcc3 needs binutils, which fails at the configure
> step with "C compiler cannot create executables
Unsure if related or not, but I updated pkgsrc, then ran
"pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to
py-setuptools, and gcc3 needs binutils, which fails at the configure
step with "C compiler cannot create executables". I switched to
another terminal, wrote a short hello world i
On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote:
>
> Hi,
>
> I bumped up my development machine to 9.99.37; after that I usually
> rebuild pkgtools/osabi and all that depend on it; this usually does
> not cause problems (with the exception of lsof, which I had installed
> some times ago and whi
Hi,
I bumped up my development machine to 9.99.37; after that I usually
rebuild pkgtools/osabi and all that depend on it; this usually does
not cause problems (with the exception of lsof, which I had installed
some times ago and which does not build any more at all, as it is
using apparently inter
Hi List!
Yesterday, I did a new CVS update. I did rebuild tools and userland.
I ad mit, to save some time, I used the "-u" update flag. The issue came
up again however.
I will try today again, without an update build.
Riccardo
Riccardo Mottola wrote:
# compile libgomp/oacc-init.o
/usr/sr
28 matches
Mail list logo
