Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Simon J. Gerraty]

Peter Jeremy  wrote:
> In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was
> using "make buildworld" - which failed.  The upgrade worked cleanly
> when I manually deleted all the .meta files.  If I get a round tuit,

sys.mk is setup such that missing .meta file makes the target
out-of-date.

FWIW I just did a buildworld -DWITH_META_MODE followed by the same with
-DNO_CLEAN - but no change to the tree.
That at least worked fine (and quickly) tree was last updated to r318755

Wonder if it is safe to update...
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Peter Jeremy]

On 2017-May-24 20:21:54 +0300, Konstantin Belousov  wrote:
>No SIGSEGV etc, so I think that the effects seen are due to build system.
>rm -rf obj/* is the safest trick, I believe.

But the behaviour does indicate that meta mode is not doing the right thing
under all circumstances.  It's blatently breaking in this scenario but could
be causing more subtle (and unnoticed) breakage in other cases.  This makes
me feel that this is worth investigating further.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Peter Jeremy]

On 2017-May-24 18:01:42 -0700, "Simon J. Gerraty"  wrote:
>Peter Jeremy  wrote:
>> as follows.  My suspicion is that meta mode isn't seeing enough of the
>> differences between the bootstrap and main build steps and so causing make
>> to incorrectly skip steps.
>
>I see a number of places in src/Makefile* where BUILD_TOOLS_META=.NOMETA
>is added to env of things like CROSSENV, CD2MAKE, LIBCOMPATWMAKEENV
>
>Use of .NOMETA could be leading to problems - but I'm not familiar with
>where BUILD_TOOLS_META is used.

I've not looked at the guts of how meta mode works or is inhibited either.

In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was
using "make buildworld" - which failed.  The upgrade worked cleanly
when I manually deleted all the .meta files.  If I get a round tuit,
I'll try to revert to before the update and have a closer look at what
broke with the "normal" build, if no-one else beats me to it.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Bug in make setting wrong MAKESYSPATH

[Simon J. Gerraty]

Thomas Mueller  wrote:

> I go into /BETA1/usr/ports/ports-mgmt/synth , run
> env MAKESYSPATH make all-depends-list

I assume you mean MAKESYSPATH=something? otherwise env itself should
vomit

> and then it seems to work correctly with no syntax error in
> /BETA1/usr/share/mk/bsd.compiler.mk
> 
> Maybe I need to file a bug.

For what?
 
> What happens if src, ports and doc trees are installed on an NFS
> share, where there would be no FreeBSD installation?

Not sure what you mean. make doesn't care what the filesystem is
if there is a share/mk found in . or somewhere above it, the default
MAKESYSPATH will find it.
___
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: 64-bit inodes (ino64) Status Update and Call for Testing

[Conrad Meyer]

Hi Jilles,

Thanks for bringing this up.  And of course, thanks to kib@ for
including the d_namlen size bump and for his work in driving the rest
of this change through to completion.

On Sun, May 21, 2017 at 5:14 AM, Jilles Tjoelker  wrote:
> We have another type in this area which is too small in some situations:
> uint8_t for struct dirent.d_namlen. For filesystems that store filenames
> as upto 255 UTF-16 code units, the name to be stored in d_name may be
> upto 765 bytes long in UTF-8. This was reported in PR 204643. The code
> currently handles this by returning the short (8.3) name, but this name
> may not be present or usable, leaving the file inaccessible.

We've been working to add such support to our FreeBSD-derivative
product.  A big piece of it is expanding d_namlen out to 16 bits.
We've also been trying to divorce system-wide constants like MAXNAMLEN
/ NAME_MAX and MAXPATHLEN / PATH_MAX from filesystem-specific
limitations (UFS' limit of 255 bytes).  And push that upstream when
possible, e.g., r313475, r316509.

Bumping d_namlen in FreeBSD reduces the amount of ABI breakage we have
to introduce in our product relative to FreeBSD, and leaves open the
possibility of supporting 255-unicode-character filesystems natively
in FreeBSD down the road.

> Actually allowing longer names seems too complicated to add to the ino64
> change, but changing d_namlen to uint16_t (using d_pad0 space) and
> skipping entries with d_namlen > 255 in libc may be helpful.
>
> Note that applications using the deprecated readdir_r() will not be able
> to read such long names, since the API does not allow specifying that a
> larger buffer has been provided. (This could be avoided by making struct
> dirent.d_name 766 bytes long instead of 256.)

We're looking at 255 Unicode code points, which can be 4 bytes a piece
in UTF8, or 1020 bytes potentially.

> Unfortunately, the existence of readdir_r() also prevents changing
> struct dirent.d_name to the more correct flexible array.

Best,
Conrad
___
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: Bug in make setting wrong MAKESYSPATH

[Thomas Mueller]

>From Simon J. Gerraty:

> > Thomas Mueller  wrote:
> > For building the system, MAKESYSPATH should be $SRCDIR/share/mk , to be in 
> > sync.

> > I tried "make -V MAKESYSPATH" from several SRCDIRs, and that's what 
> > happened.

> Yes.  If you look at share/mk/src.sys.env.mk
> it detects that it was found via a .../ path, and replaces it in
> MAKESYSPATH with the actual location - otherwise some makefiles break.

> > So maybe I have to set MAKESYSPATH every time I am in ports, don't
> > know if this would work from /etc/make.conf (need to experiment).

> Probably not, because sys.mk will have already been found before that
> ie. the damage may already have been done

> > I wonder what would happen if there is no FreeBSD installation at all
> > on partition where ports tree is located.

> An error like:

> make: no system rules (sys.mk).

I go into /BETA1/usr/ports/ports-mgmt/synth , run
env MAKESYSPATH make all-depends-list
and then it seems to work correctly with no syntax error in
/BETA1/usr/share/mk/bsd.compiler.mk

Maybe I need to file a bug.

What happens if src, ports and doc trees are installed on an NFS share, where 
there would be no FreeBSD installation?

Tom

___
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: svn commit: r318757 - head

[Jeffrey Bouquet]

On Wed, 24 May 2017 20:10:00 +0200, "O. Hartmann"  
wrote:

> Am Wed, 24 May 2017 13:04:30 -0500
> Larry Rosenman  schrieb:
> 
> > On 5/24/17, 1:01 PM, "O. Hartmann"  wrote:
> > 
> > Am Wed, 24 May 2017 19:40:46 +0200
> > "O. Hartmann"  schrieb:
> > 
> > > Am Wed, 24 May 2017 12:28:51 -0500
> > > Larry Rosenman  schrieb:
> > >   
> > > > I fixed my issues by force-rebuilding perl and all installed p5-* 
> > ports. 
> > > > 
> > > > 
> > > 
> > > 
> > > This isn't possible in my case :-(
> > > 
> > > lang/perl rebuilds all right, but every p5-* ports fails with
> > > 
> > > [...]
> > > Checking if your kit is complete...
> > > ListUtil.c: loadable library and perl binaries are mismatched (got 
> > handshake key
> > > 0xd200080, needed 0xdf00080) 
> > > *** Error code 1
> > > 
> > > I tried to rebuild also via portmaster -f, no success. Now, I growing 
> > bunch of
> > > ports showing up with this mysterious error.
> > > 
> > > To which port "ListUtil.c" might belong to?
> > > 
> > > Rebuilding autotools (which I suspected first) also fails ...
> > > 
> > >   
> > 
> > ... it seems, as K. belousov mentioned prior regarding different ABI, 
> > all p5-*
> > ports need to be deleted by force ... They rebuild properly afterwards.
> > 
> > Which is essentially what I did re: Poudriere (poudriere bulk –C –j  
> > -p
> >  -f )
> 
> I use the traditional "make" way (via portmaster)
> 
> -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


Would it be worthwhile to have say weeks 1-3 of each month usual, then the 
fourth week a
'fix poudriere run of current totally [ or synth ] so that snapshots can be had 
monthly of
the CURRENT with ALL ports working as packages?  And a freeze on CURRENT during 
that
time? so poudriere and/or synth takes precedence over CURRENT?  For the sake of 
persons using CURRENT as their principal desktop/dev box?
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Simon J. Gerraty]

Peter Jeremy  wrote:
> as follows.  My suspicion is that meta mode isn't seeing enough of the
> differences between the bootstrap and main build steps and so causing make
> to incorrectly skip steps.

I see a number of places in src/Makefile* where BUILD_TOOLS_META=.NOMETA
is added to env of things like CROSSENV, CD2MAKE, LIBCOMPATWMAKEENV

Use of .NOMETA could be leading to problems - but I'm not familiar with
where BUILD_TOOLS_META is used.


> 
> --
> >>> stage 2.3: build tools
> --
> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj  INSTALL="sh 
> /usr/src/tools/install.sh"  TOOLS_PREFIX=/usr/obj/usr/src/tmp  
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
>   WORLDTMP=/usr/obj/usr/src/tmp  MAKEFLAGS="-m /usr/src/tools/build/mk  -m 
> /usr/src/share/mk" /usr/obj/usr/src/make.amd64/bmake  -f Makefile.inc1  
> TARGET=amd64 TARGET_ARCH=amd64  DESTDIR=  BOOTSTRAPPING=1200031  SSP_CFLAGS=  
> -DNO_LINT  -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no  MK_CLANG_EXTRAS=no 
> MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no build-tools
> ...
> ===> usr.bin/mkesdb_static (obj,build-tools)
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_bcs.o
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_factory.o
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_hash.o
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_lookup_factory.o
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.c
> Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.o
> /usr/src/usr.bin/mkesdb/lex.l:44:10: fatal error: 'yacc.h' file not found
> #include "yacc.h"
>  ^~~~
>1 error generated.
>*** Error code 1
___
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: ino64 package fallout

[Don Lewis]

On 24 May, Konstantin Belousov wrote:
> On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote:
>> I just upgraded by package build box and its poudriere jail to r318776
>> and ran into some significant package build fallout.
> 
> There are several reviews that fix ports with most significant fallouts,
>lang/llvm39D10796
>lang/llvm40D10797
>lang/ghc   D10798
>multimedia/webcamd D10800
>devel/libgtop  D10795
>sysutils/py-psutil D1081
>lang/rust  D10799
> 
> I intend to commit this tomorrow, after the ino64 get some probation time,
> long enough to ensure that it does not get immediate revert.  You may
> see the discussions and use the patches locally, meantime.

devel/libgtop is also broken:

procopenfiles.c:325:39: error: no member named 'kf_sa_local' in 'struct 
kinfo_file'
sun = (struct sockaddr_un *)>kf_sa_local;
 ~~~  ^
procopenfiles.c:330:37: error: no member named 'kf_sa_local' in 'struct 
kinfo_file'
addrstr = 
addr_to_string(>kf_sa_local);
  ~~~  ^
procopenfiles.c:338:37: error: no member named 'kf_sa_peer' in 'struct 
kinfo_file'
addrstr = 
addr_to_string(>kf_sa_peer);
  ~~~  ^
procopenfiles.c:352:36: error: no member named 'kf_sa_peer' in 'struct 
kinfo_file'
addrstr = addr_to_string(>kf_sa_peer);
  ~~~  ^
procopenfiles.c:357:52: error: no member named 'kf_sa_peer' in 'struct 
kinfo_file'
entry.info.sock.dest_port = 
addr_to_port(>kf_sa_peer);
procwd.c:155:16: warning: comparison of integers of different signs: 'int' and 
'unsigned long' [-Wsign-compare]
for (i = 0; i < len / sizeof(*kif); i++, kif++) {
~ ^ ~~
  ~~~  ^
procopenfiles.c:388:9: warning: cast from 'gchar *' (aka 'char *') to 
'glibtop_open_files_entry *' (aka 'struct _glibtop_open_files_entry *') 
increases required alignment from 1 to 4 [-Wcast-align]
return (glibtop_open_files_entry*)g_array_free(entries, FALSE);
   ^~~
procopenfiles.c:305:16: warning: comparison of integers of different signs: 
'ssize_t' (aka 'long') and 'unsigned long' [-Wsign-compare]
for (i = 0; i < len / sizeof(*kif); i++, kif++) {
~ ^ ~~
2 warnings and 5 errors generated.

___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Peter Jeremy]

On 2017-May-24 08:47:41 -0700, Ngie Cooper  wrote:
>There was another report on the list about a stale MAKEOBJDIRPREFIX 
> causing someone grief. I think it's safe to say that meta mode and -DNO_CLEAN 
> might not work across this transition--in particular meta mode tends to err 
> on the side of not to rebuilding things.

I ran into a very similar problem trying to update from r318744 to r318781.
In my case, even two "make clean" wasn't enough and "make buildworld" died
as follows.  My suspicion is that meta mode isn't seeing enough of the
differences between the bootstrap and main build steps and so causing make
to incorrectly skip steps.

--
>>> stage 2.3: build tools
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj  INSTALL="sh /usr/src/tools/install.sh"  
TOOLS_PREFIX=/usr/obj/usr/src/tmp  
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
  WORLDTMP=/usr/obj/usr/src/tmp  MAKEFLAGS="-m /usr/src/tools/build/mk  -m 
/usr/src/share/mk" /usr/obj/usr/src/make.amd64/bmake  -f Makefile.inc1  
TARGET=amd64 TARGET_ARCH=amd64  DESTDIR=  BOOTSTRAPPING=1200031  SSP_CFLAGS=  
-DNO_LINT  -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no  MK_CLANG_EXTRAS=no 
MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no build-tools
...
===> usr.bin/mkesdb_static (obj,build-tools)
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_bcs.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_factory.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_hash.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_lookup_factory.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.c
Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.o
/usr/src/usr.bin/mkesdb/lex.l:44:10: fatal error: 'yacc.h' file not found
#include "yacc.h"
 ^~~~
 1 error generated.
 *** Error code 1

Stop.
bmake[3]: stopped in /usr/src/usr.bin/mkesdb_static
.ERROR_TARGET='lex.o'
.ERROR_META_FILE='/usr/obj/usr/src/usr.bin/mkesdb_static/lex.o.meta'
.MAKE.LEVEL='3'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/usr.bin/mkesdb_static'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/usr.bin/mkesdb_static'
.TARGETS='build-tools'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20161212'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
/usr/src/usr.bin/mkesdb_static/Makefile /usr/src/usr.bin/mkesdb/Makefile.inc 
/usr/src/tools/build/mk/bsd.prog.mk /usr/src/share/mk/bsd.prog.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/usr.bin/mkesdb_static/../Makefile.inc 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk 
/usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk /usr/src/tools/build/mk/Makefile.boot'
.PATH='. /usr/src/usr.bin/mkesdb_static /usr/src/lib/libc/iconv 
/usr/src/usr.bin/mkesdb'
*** Error code 1

I've done a "find /usr/obj -name \*.meta -print0 | xargs -0 rm" and am still
waiting for that to complete, though it has passed the above failure point.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: NFS client performance degradation when SMP enabled

[Ryan Stone]

What type of network interface do you have?  The Intel 1G (em and igb) were
switched over to the "iflib" framework a few months ago and that could be
the cause.
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[David Wolfskill]

On Wed, May 24, 2017 at 01:42:39PM -0700, Simon J. Gerraty wrote:
> David Wolfskill  wrote:
> > As far as I can tell, the "ld" command was:
> 
> Since you have the .meta file, it should tell you exactly what the
> command was and what path was actually exec'd

And now that I'm not running around like a headless chicken, and
had time to look to see where the single-character codes in the
meta file are documented (filemon(4)), the correct answeer is:
/usr/obj/usr/src/tmp/usr/bin/ld

(Note that I provided the entire meta file, as well :-})

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Simon J. Gerraty]

Ngie Cooper  wrote:

> There was another report on the list about a stale
> MAKEOBJDIRPREFIX causing someone grief.

Pointer?
What does stale MAKEOBJDIRPREFIX mean?

>I think it's safe to say that
> meta mode and -DNO_CLEAN might not work across this transition--in
> particular meta mode tends to err on the side of not to rebuilding
> things.

I would have expected the opposite.
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Simon J. Gerraty]

David Wolfskill  wrote:
> As far as I can tell, the "ld" command was:

Since you have the .meta file, it should tell you exactly what the
command was and what path was actually exec'd

___
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"

NFS client performance degradation when SMP enabled

[Rick Macklem]

Without boring you with too much detail, I have been doing development/testing
of pNFS stuff (mostly server side) on a 1 year old kernel (Apr. 12, 2016).
When I recently carried the code across to a recent kernel, everything seemed 
to work,
but performance was much slower.
After some fiddling around, it appears to be on the NFS client side and nothing 
in the
NFS client code seemed to be causing it. (RPC counts were almost exactly the 
same,
for example. I tried reverting r316532 and disabling vfs.nfs.use_buf_pager. 
Neither
made a significant difference.)

I made most of the performance degradation go away by disabling SMP on the 
client.
Here's some elapsed times for kernel builds with everything the same except for
which kernel and SMP enabled/disabled (amd64 client machine).
1 year old kernel, SMP enabled  - 100minutes
recent kernel, SMP disabled- 113minutes
recent kernel, SMP enabled-  148minutes
(The builds were all of the same kernel sources. When I say "1 year old" vs 
"recent"
 I am referring to which kernel was booted for the test run.)

All I can think of is that some change in the last year has resulted in an 
increase in
something like interrupt latency or context switch latency that has caused this?

Anyone have an idea what this might be caused by or any tunables to fool with
beyond disabling SMP (which I suspect won't be a popular answer to "how to fix
slow NFS";-).

I haven't yet tried fiddling with interrupt moderation on the net interface, but
the tests all used the same settings.

rick
___
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: svn commit: r318757 - head

[Bryan Drewery]

On 5/24/17 1:17 PM, Cy Schubert wrote:
> In message <1c1ab22c-60bf-4707-f635-8069aa1e0...@freebsd.org>, Bryan 
> Drewery wr
> ites:
>> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
>> --sIw1a8MPU8obGIEqPMSjxuV84b026de6m
>> Content-Type: multipart/mixed; boundary="8b3Tlc1Bt9VfscoFw6tX1N8B8aTeGubhr";
>>  protected-headers="v1"
>> From: Bryan Drewery 
>> To: Larry Rosenman , Ed Maste ,
>>  src-committ...@freebsd.org, svn-src-...@freebsd.org,
>>  svn-src-h...@freebsd.org,
>>  "freebsd-current@freebsd.org" 
>> Message-ID: <1c1ab22c-60bf-4707-f635-8069aa1e0...@freebsd.org>
>> Subject: Re: svn commit: r318757 - head
>> References: <201705232025.v4nkpnrh001...@repo.freebsd.org>
>>  
>>  
>>  <145539de-59b4-4f21-b699-877ded6a2...@lerctr.org>
>>  <4fe6fbf4-03e4-804d-784a-67283ed9e...@freebsd.org>
>> In-Reply-To: <4fe6fbf4-03e4-804d-784a-67283ed9e...@freebsd.org>
>>
>> --8b3Tlc1Bt9VfscoFw6tX1N8B8aTeGubhr
>> Content-Type: text/plain; charset=utf-8
>> Content-Language: en-US
>> Content-Transfer-Encoding: quoted-printable
>>
>> On 5/23/2017 4:29 PM, Bryan Drewery wrote:
>>> On 5/23/2017 4:24 PM, Larry Rosenman wrote:
 borg.lerctr.org /home/ler $ sudo poudriere jail -l
 JAILNAME   VERSION  ARCH  METHOD   TIMESTAMP  =
>>  PATH
 p103amd64  10.3-RELEASE-p18 amd64 http 2017-04-23 08:3=
>> 9:24 /usr/local/poudriere/jails/p103amd64
 p103i386   10.3-RELEASE-p18 i386  http 2017-04-23 08:4=
>> 0:44 /usr/local/poudriere/jails/p103i386
 p110amd64  11.0-RELEASE-p10 amd64 http 2017-05-15 14:5=
>> 4:58 /usr/local/poudriere/jails/p110amd64
 p110i386   11.0-RELEASE-p9  i386  http 2017-04-23 08:4=
>> 1:48 /usr/local/poudriere/jails/p110i386
 live   12.0-CURRENT amd64 src=3D/usr/src 2017-05-23 13=
>> :39:40 /usr/local/poudriere/jails/live
 pHEADamd64 12.0-CURRENT amd64 src=3D/usr/src 2017-04-24 17=
>> :15:13 /usr/local/poudriere/jails/pHEADamd64
 p120armv6  12.0-CURRENT r317340 arm.armv6 svn+https2017-04-23 10:0=
>> 7:40 /usr/local/poudriere/jails/p110borg.lerctr.org /usr/local/etc/poudri=
>> ere.d/jails/live $ cat version
 12.0-CURRENT
 borg.lerctr.org /usr/local/etc/poudriere.d/jails/live $armv6
 borg.lerctr.org /home/ler $


 borg.lerctr.org /usr/local/poudriere/data/packages/live-host-ports $ c=
>> at .jailversion
 12.0-CURRENT
 borg.lerctr.org /usr/local/poudriere/data/packages/live-host-ports $



>>> =20
>>> That looks like a bug in Poudriere with -m src. It is using 12.0-CURREN=
>> T
>>> rather than __FreeBSD_version of 1200031. I'm working on a fix.
>>> =20
>>
>> Usually Poudriere, for head, will rebuild if the SVN revision changes.
>> It is very liberal with rebuilds on head and does not usually consider
>> __FreeBSD_version since it can be forgotten, and historically was not
>> always bumped on SA/EN either so we used the uname -r output.  So this
>> bug is limited to -m src|null|tar.
> 
> Hi Bryan,
> 
> If do you choose to fix this, please provide a facility to override the 
> liberal rebuilds. I for one know when I need to blow away all my package 
> repos and start from scratch, which BTW I commenced with -c this morning 
> after upgrading my poudriere jails. I may update a poudriere jail to 
> address occasional port build failures under 12.0 which are fixed by more 
> recent commits to -CURRENT that don't affect the ABI.
> 
> Rebuilding packages from scratch is painful.
> 
> 

Agreed, it is painful. I came up with an idea to reduce the massive
rebuild needs on arch@ a few years ago. I just haven't had a chance to
implement it.

https://lists.freebsd.org/pipermail/freebsd-arch/2015-April/017025.html


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r318757 - head

[Cy Schubert]

In message <1c1ab22c-60bf-4707-f635-8069aa1e0...@freebsd.org>, Bryan 
Drewery wr
ites:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --sIw1a8MPU8obGIEqPMSjxuV84b026de6m
> Content-Type: multipart/mixed; boundary="8b3Tlc1Bt9VfscoFw6tX1N8B8aTeGubhr";
>  protected-headers="v1"
> From: Bryan Drewery 
> To: Larry Rosenman , Ed Maste ,
>  src-committ...@freebsd.org, svn-src-...@freebsd.org,
>  svn-src-h...@freebsd.org,
>  "freebsd-current@freebsd.org" 
> Message-ID: <1c1ab22c-60bf-4707-f635-8069aa1e0...@freebsd.org>
> Subject: Re: svn commit: r318757 - head
> References: <201705232025.v4nkpnrh001...@repo.freebsd.org>
>  
>  
>  <145539de-59b4-4f21-b699-877ded6a2...@lerctr.org>
>  <4fe6fbf4-03e4-804d-784a-67283ed9e...@freebsd.org>
> In-Reply-To: <4fe6fbf4-03e4-804d-784a-67283ed9e...@freebsd.org>
> 
> --8b3Tlc1Bt9VfscoFw6tX1N8B8aTeGubhr
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
> 
> On 5/23/2017 4:29 PM, Bryan Drewery wrote:
> > On 5/23/2017 4:24 PM, Larry Rosenman wrote:
> >> borg.lerctr.org /home/ler $ sudo poudriere jail -l
> >> JAILNAME   VERSION  ARCH  METHOD   TIMESTAMP  =
>  PATH
> >> p103amd64  10.3-RELEASE-p18 amd64 http 2017-04-23 08:3=
> 9:24 /usr/local/poudriere/jails/p103amd64
> >> p103i386   10.3-RELEASE-p18 i386  http 2017-04-23 08:4=
> 0:44 /usr/local/poudriere/jails/p103i386
> >> p110amd64  11.0-RELEASE-p10 amd64 http 2017-05-15 14:5=
> 4:58 /usr/local/poudriere/jails/p110amd64
> >> p110i386   11.0-RELEASE-p9  i386  http 2017-04-23 08:4=
> 1:48 /usr/local/poudriere/jails/p110i386
> >> live   12.0-CURRENT amd64 src=3D/usr/src 2017-05-23 13=
> :39:40 /usr/local/poudriere/jails/live
> >> pHEADamd64 12.0-CURRENT amd64 src=3D/usr/src 2017-04-24 17=
> :15:13 /usr/local/poudriere/jails/pHEADamd64
> >> p120armv6  12.0-CURRENT r317340 arm.armv6 svn+https2017-04-23 10:0=
> 7:40 /usr/local/poudriere/jails/p110borg.lerctr.org /usr/local/etc/poudri=
> ere.d/jails/live $ cat version
> >> 12.0-CURRENT
> >> borg.lerctr.org /usr/local/etc/poudriere.d/jails/live $armv6
> >> borg.lerctr.org /home/ler $
> >>
> >>
> >> borg.lerctr.org /usr/local/poudriere/data/packages/live-host-ports $ c=
> at .jailversion
> >> 12.0-CURRENT
> >> borg.lerctr.org /usr/local/poudriere/data/packages/live-host-ports $
> >>
> >>
> >>
> >=20
> > That looks like a bug in Poudriere with -m src. It is using 12.0-CURREN=
> T
> > rather than __FreeBSD_version of 1200031. I'm working on a fix.
> >=20
> 
> Usually Poudriere, for head, will rebuild if the SVN revision changes.
> It is very liberal with rebuilds on head and does not usually consider
> __FreeBSD_version since it can be forgotten, and historically was not
> always bumped on SA/EN either so we used the uname -r output.  So this
> bug is limited to -m src|null|tar.

Hi Bryan,

If do you choose to fix this, please provide a facility to override the 
liberal rebuilds. I for one know when I need to blow away all my package 
repos and start from scratch, which BTW I commenced with -c this morning 
after upgrading my poudriere jails. I may update a poudriere jail to 
address occasional port build failures under 12.0 which are fixed by more 
recent commits to -CURRENT that don't affect the ABI.

Rebuilding packages from scratch is painful.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.




___
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: ino64: desastrous update - recommendations not working!!!

[Cy Schubert]

In message <20170524192734.67a84...@thor.intern.walstatt.dynvpn.de>, "O. 
Hartma
nn" writes:
> --Sig_/4+3DjX6aWzM+U5.TkY0/Z6W
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> Am Wed, 24 May 2017 14:15:07 +0200
> "Hartmann, O."  schrieb:
> 
> > On Wed, 24 May 2017 14:31:08 +0300
> > Konstantin Belousov  wrote:
> >=20
> > > On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote: =20
> > > > On almost every CURRENT that has been updated according to UPDATING
> > > > entry 2017-05-23 regarding ino64, the recommended update process
> > > > ends up in a desaster or, if the old environemnt/kernel is intact,
> > > > itr doesn't work.
> > > >=20
> > > > Procedure:
> > > >=20
> > > > make -jX buildworld buildkernel [successful]
> > > > make installkernel [successful]
> > > > reboot
> > > > Booting single user mode as recommended withnthe newly installed
> > > > kernel BUMMER!
> > > > When it comes to the point to type in the full path
> > > > of /bin/sh, /bin/sh immediately fails with SIGNAL 12   =20
> > > Signal 12 is SIGSYS, which strongly suggest that your 'new' kernel is
> > > not new, it does not implement some of the syscalls called by new
> > > binaries. =20
> >=20
> > It is(!) new as it has been installed from sources checked out
> > recently, rebuilt world and rebuilt world after I completely
> > DELETED(!) /usr/obj.
> > The most striking evidence would be the revision number right now, but
> > I don't have the luxury of time at the moment to play with the harhsly
> > failing wreckeges.
> >=20
> > >  =20
> > > >=20
> > > > In this case, I can boot without problems the old kernel and the
> > > > system works again.
> > > >=20
> > > > But, depending on the entry revision from which I started the 22nd,
> > > > or 23rd of May ino64-deal, there is a more harsh failure!   =20
> > > I do not understand what are you trying to say there. =20
> >=20
> > Well, that is easy. On our development and testing facilities, I do
> > in most cases daily updates. Some notebooks or systems I/we have to
> > rely a bit more on, I do this after two or more days after a successful
> > update of the others.
> >=20
> > What I want to say - and did say - is: boxes which I have updated
> > recently, 22nd, 23rd May the last time, do break on installworld after
> > they booted successfully the new kernel and gave me a single-user
> > console, while the notebooks, for instance, which has been updated
> > CURRENT the last time on Thursday last week, only fail in getting a
> > login due to the /bin/sh SIGSYS issue.
> >=20
> > I think David Wolfskill made a point about this in a recent commit to
> > the list.
> >=20
> > >  =20
> > > >=20
> > > > According to the above recommendation of updating, BUMMER! doesn't
> > > > occur at that point and the shell /bin/sh starts as expected.
> > > > Performing=20
> > > >=20
> > > > mergemaster -Fp
> > > >=20
> > > > also performs well without any questions or installations so far,
> > > > but then
> > > >=20
> > > > make installworld
> > > >=20
> > > > BUMMER! again and this time with fatal consequences! The
> > > > installation fails in libexec/rtld-elf or something like that in the
> > > > source/object tree after copying libexec/ld-elf.so.1. I
> > > > see /libexec/ld-elf.so.1 successfully copied with the security copy
> > > > marked with appendix .old being of a conclusive date and time.
> > > > The installworld bails out, leaves the tree in a mixture of old and
> > > > new binaries and now, thanks, the whole system ist wrecked.
> > > > When trying to reboot such a half-ready installation in single user
> > > > mode, I can't even get an shell enymore.
> > > >=20
> > > > How can I fix this emergency case with the tools aboard?
> > > >=20
> > > > Since there is no compiler or build infrastructure any more on the
> > > > USB bootimage, I can not simply installworld and installkernel -
> > > > the boot image is useless - on this list I had such a discussion in
> > > > March. For short: I have the intact and complete /usr/obj tree and
> > > > I think it would be a great deal to be able to simply boot via USB
> > > > memstick and perform installworld with propper settings of DESTDIR=3D
> > > > and sibblings.
> > > >=20
> > > > Yes, now what is to do ... :-(
> > > >=20
> > > > Help appreciated and thanks in advance for those reading so far.   =20
> > >=20
> > > I put a statically built stat(1) binary there:
> > > https://www.kib.kiev.ua/kib/stat-ino64-static
> > >=20
> > > You might use it as a test for the right kernel: after you boot with
> > > supposedly new kernel but old world, try to run the binary.  If
> > > running results in SIGSYS (12), you have configuration issue to solve. =
> =20
> >=20
> > I'll try. And report. But I'm out of the lab until Monday :-( I have
> > boxes at home I'd like to update, last update of those was the day
> > before yesterday, but I do not dare until the issue is identified
> > 

Re: svn commit: r318757 - head

[O. Hartmann]

Am Wed, 24 May 2017 12:11:06 -0700
"Ngie Cooper (yaneurabeya)"  schrieb:

> > On May 24, 2017, at 11:10, O. Hartmann  wrote:
> > 
> > Am Wed, 24 May 2017 13:04:30 -0500
> > Larry Rosenman  schrieb:  
> 
> …
> 
> > I use the traditional "make" way (via portmaster)  
> 
>   There were some reports about needing to do “make clean” before “make 
> install”.
> Memory serves me correctly there are ways in portmaster to bypass “make 
> clean” before
> running “make install”. Could you please provide your portmasterrc file? 
> Thanks, -Ngie


attached, but there is nothing unusual from my point of view. make clean is 
also done
prior to the make all.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


portmaster.rc
Description: Binary data


pgprbOnzQD9h0.pgp
Description: OpenPGP digital signature

Re: ino64: desastrous update - recommendations not working!!!

[O. Hartmann]

Am Wed, 24 May 2017 14:15:07 +0200
"Hartmann, O."  schrieb:

> On Wed, 24 May 2017 14:31:08 +0300
> Konstantin Belousov  wrote:
> 
> > On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote:  
> > > On almost every CURRENT that has been updated according to UPDATING
> > > entry 2017-05-23 regarding ino64, the recommended update process
> > > ends up in a desaster or, if the old environemnt/kernel is intact,
> > > itr doesn't work.
> > > 
> > > Procedure:
> > > 
> > > make -jX buildworld buildkernel [successful]
> > > make installkernel [successful]
> > > reboot
> > > Booting single user mode as recommended withnthe newly installed
> > > kernel BUMMER!
> > > When it comes to the point to type in the full path
> > > of /bin/sh, /bin/sh immediately fails with SIGNAL 12
> > Signal 12 is SIGSYS, which strongly suggest that your 'new' kernel is
> > not new, it does not implement some of the syscalls called by new
> > binaries.  
> 
> It is(!) new as it has been installed from sources checked out
> recently, rebuilt world and rebuilt world after I completely
> DELETED(!) /usr/obj.
> The most striking evidence would be the revision number right now, but
> I don't have the luxury of time at the moment to play with the harhsly
> failing wreckeges.
> 
> >   
> > > 
> > > In this case, I can boot without problems the old kernel and the
> > > system works again.
> > > 
> > > But, depending on the entry revision from which I started the 22nd,
> > > or 23rd of May ino64-deal, there is a more harsh failure!
> > I do not understand what are you trying to say there.  
> 
> Well, that is easy. On our development and testing facilities, I do
> in most cases daily updates. Some notebooks or systems I/we have to
> rely a bit more on, I do this after two or more days after a successful
> update of the others.
> 
> What I want to say - and did say - is: boxes which I have updated
> recently, 22nd, 23rd May the last time, do break on installworld after
> they booted successfully the new kernel and gave me a single-user
> console, while the notebooks, for instance, which has been updated
> CURRENT the last time on Thursday last week, only fail in getting a
> login due to the /bin/sh SIGSYS issue.
> 
> I think David Wolfskill made a point about this in a recent commit to
> the list.
> 
> >   
> > > 
> > > According to the above recommendation of updating, BUMMER! doesn't
> > > occur at that point and the shell /bin/sh starts as expected.
> > > Performing 
> > > 
> > > mergemaster -Fp
> > > 
> > > also performs well without any questions or installations so far,
> > > but then
> > > 
> > > make installworld
> > > 
> > > BUMMER! again and this time with fatal consequences! The
> > > installation fails in libexec/rtld-elf or something like that in the
> > > source/object tree after copying libexec/ld-elf.so.1. I
> > > see /libexec/ld-elf.so.1 successfully copied with the security copy
> > > marked with appendix .old being of a conclusive date and time.
> > > The installworld bails out, leaves the tree in a mixture of old and
> > > new binaries and now, thanks, the whole system ist wrecked.
> > > When trying to reboot such a half-ready installation in single user
> > > mode, I can't even get an shell enymore.
> > > 
> > > How can I fix this emergency case with the tools aboard?
> > > 
> > > Since there is no compiler or build infrastructure any more on the
> > > USB bootimage, I can not simply installworld and installkernel -
> > > the boot image is useless - on this list I had such a discussion in
> > > March. For short: I have the intact and complete /usr/obj tree and
> > > I think it would be a great deal to be able to simply boot via USB
> > > memstick and perform installworld with propper settings of DESTDIR=
> > > and sibblings.
> > > 
> > > Yes, now what is to do ... :-(
> > > 
> > > Help appreciated and thanks in advance for those reading so far.
> > 
> > I put a statically built stat(1) binary there:
> > https://www.kib.kiev.ua/kib/stat-ino64-static
> > 
> > You might use it as a test for the right kernel: after you boot with
> > supposedly new kernel but old world, try to run the binary.  If
> > running results in SIGSYS (12), you have configuration issue to solve.  
> 
> I'll try. And report. But I'm out of the lab until Monday :-( I have
> boxes at home I'd like to update, last update of those was the day
> before yesterday, but I do not dare until the issue is identified
> correctly. As David Wolfskill stated in his headline, it is probably
> not ino64 messing up - as I interprete his question mark.
> 
> > ___
> > 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"  
> 

Stefan Esser was so kind and pushed me towards COMPAT_FREEBSD11 options 
requisite in the
kernel. It was missing in 

Re: svn commit: r318757 - head

[Ngie Cooper (yaneurabeya)]

> On May 24, 2017, at 11:10, O. Hartmann  wrote:
> 
> Am Wed, 24 May 2017 13:04:30 -0500
> Larry Rosenman  schrieb:

…

> I use the traditional "make" way (via portmaster)

There were some reports about needing to do “make clean” before “make 
install”. Memory serves me correctly there are ways in portmaster to bypass 
“make clean” before running “make install”. Could you please provide your 
portmasterrc file?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r318757 - head

[O. Hartmann]

Am Wed, 24 May 2017 13:04:30 -0500
Larry Rosenman  schrieb:

> On 5/24/17, 1:01 PM, "O. Hartmann"  wrote:
> 
> Am Wed, 24 May 2017 19:40:46 +0200
> "O. Hartmann"  schrieb:
> 
> > Am Wed, 24 May 2017 12:28:51 -0500
> > Larry Rosenman  schrieb:
> >   
> > > I fixed my issues by force-rebuilding perl and all installed p5-* 
> ports. 
> > > 
> > > 
> > 
> > 
> > This isn't possible in my case :-(
> > 
> > lang/perl rebuilds all right, but every p5-* ports fails with
> > 
> > [...]
> > Checking if your kit is complete...
> > ListUtil.c: loadable library and perl binaries are mismatched (got 
> handshake key
> > 0xd200080, needed 0xdf00080) 
> > *** Error code 1
> > 
> > I tried to rebuild also via portmaster -f, no success. Now, I growing 
> bunch of
> > ports showing up with this mysterious error.
> > 
> > To which port "ListUtil.c" might belong to?
> > 
> > Rebuilding autotools (which I suspected first) also fails ...
> > 
> >   
> 
> ... it seems, as K. belousov mentioned prior regarding different ABI, all 
> p5-*
> ports need to be deleted by force ... They rebuild properly afterwards.
> 
> Which is essentially what I did re: Poudriere (poudriere bulk –C –j  -p
>  -f )

I use the traditional "make" way (via portmaster)

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpUCOFNoPBfl.pgp
Description: OpenPGP digital signature

Re: svn commit: r318757 - head

[Larry Rosenman]

On 5/24/17, 1:01 PM, "O. Hartmann"  wrote:

Am Wed, 24 May 2017 19:40:46 +0200
"O. Hartmann"  schrieb:

> Am Wed, 24 May 2017 12:28:51 -0500
> Larry Rosenman  schrieb:
> 
> > I fixed my issues by force-rebuilding perl and all installed p5-* 
ports. 
> > 
> >   
> 
> 
> This isn't possible in my case :-(
> 
> lang/perl rebuilds all right, but every p5-* ports fails with
> 
> [...]
> Checking if your kit is complete...
> ListUtil.c: loadable library and perl binaries are mismatched (got 
handshake key
> 0xd200080, needed 0xdf00080) 
> *** Error code 1
> 
> I tried to rebuild also via portmaster -f, no success. Now, I growing 
bunch of ports
> showing up with this mysterious error.
> 
> To which port "ListUtil.c" might belong to?
> 
> Rebuilding autotools (which I suspected first) also fails ...
> 
> 

... it seems, as K. belousov mentioned prior regarding different ABI, all 
p5-* ports need
to be deleted by force ... They rebuild properly afterwards.

Which is essentially what I did re: Poudriere (poudriere bulk –C –j  -p 
 -f )

 


___
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: svn commit: r318757 - head

[O. Hartmann]

Am Wed, 24 May 2017 19:40:46 +0200
"O. Hartmann"  schrieb:

> Am Wed, 24 May 2017 12:28:51 -0500
> Larry Rosenman  schrieb:
> 
> > I fixed my issues by force-rebuilding perl and all installed p5-* ports. 
> > 
> >   
> 
> 
> This isn't possible in my case :-(
> 
> lang/perl rebuilds all right, but every p5-* ports fails with
> 
> [...]
> Checking if your kit is complete...
> ListUtil.c: loadable library and perl binaries are mismatched (got handshake 
> key
> 0xd200080, needed 0xdf00080) 
> *** Error code 1
> 
> I tried to rebuild also via portmaster -f, no success. Now, I growing bunch 
> of ports
> showing up with this mysterious error.
> 
> To which port "ListUtil.c" might belong to?
> 
> Rebuilding autotools (which I suspected first) also fails ...
> 
> 

... it seems, as K. belousov mentioned prior regarding different ABI, all p5-* 
ports need
to be deleted by force ... They rebuild properly afterwards.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp_4yfOQzuN5.pgp
Description: OpenPGP digital signature

Re: svn commit: r318757 - head

[Larry Rosenman]

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/24/17, 12:40 PM, "O. Hartmann"  wrote:

Am Wed, 24 May 2017 12:28:51 -0500
Larry Rosenman  schrieb:

> I fixed my issues by force-rebuilding perl and all installed p5-* ports. 
> 
> 


This isn't possible in my case :-(

lang/perl rebuilds all right, but every p5-* ports fails with

[...]
Checking if your kit is complete...
ListUtil.c: loadable library and perl binaries are mismatched (got 
handshake key
0xd200080, needed 0xdf00080) 
*** Error code 1

I tried to rebuild also via portmaster -f, no success. Now, I growing bunch 
of ports
showing up with this mysterious error.

To which port "ListUtil.c" might belong to?

Rebuilding autotools (which I suspected first) also fails ...


I rebuilt all in Poudriere and it was fine.




___
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: svn commit: r318757 - head

[O. Hartmann]

Am Wed, 24 May 2017 12:28:51 -0500
Larry Rosenman  schrieb:

> I fixed my issues by force-rebuilding perl and all installed p5-* ports. 
> 
> 


This isn't possible in my case :-(

lang/perl rebuilds all right, but every p5-* ports fails with

[...]
Checking if your kit is complete...
ListUtil.c: loadable library and perl binaries are mismatched (got handshake key
0xd200080, needed 0xdf00080) 
*** Error code 1

I tried to rebuild also via portmaster -f, no success. Now, I growing bunch of 
ports
showing up with this mysterious error.

To which port "ListUtil.c" might belong to?

Rebuilding autotools (which I suspected first) also fails ...


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpGNbzhBpg6T.pgp
Description: OpenPGP digital signature

Re: svn commit: r318757 - head

[Larry Rosenman]

I fixed my issues by force-rebuilding perl and all installed p5-* ports. 


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 


___
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: svn commit: r318757 - head

[O. Hartmann]

Am Wed, 24 May 2017 08:06:34 -0500
Larry Rosenman  schrieb:

> The initial failure:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42
> 
> I then recompiled perl, and got:
> borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest
> && ./run_branches.pl --run-all --config=/home/pgbuildfarm/conf/build-farm.conf
> Socket.c: loadable library and perl binaries are mismatched (got handshake key
> 0xd200080, needed 0xdf00080) borg.lerctr.org /home/pgbuildfarm/bin/latest $
> 
> force rebuilding and installing perl and all p5-* ports fixed that. 
> 
> 
> 

I ran into a similar problem, several ports do not build due to a mysterious 
error from
perl:

ListUtil.c: loadable library and perl binaries are mismatched (got handshake key
0xd200080, needed 0xdf00080)

lang/perl5.24 can be rebuild, but almost every p5* port bails out with that 
error shown
above. Rebuilding p5-* ports is impossible.

Running   FreeBSD 12.0-CURRENT #3 r318789: Wed May 24 18:03:48 CEST 2017 amd64 
with
WITH_LLD_IS_LD=yes.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpSiy2dQIjYR.pgp
Description: OpenPGP digital signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Konstantin Belousov]

On Wed, May 24, 2017 at 08:15:09AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote:
> > ...
> > > > I have updated /usr/src back to 318781, then started a new build.
> > > So are you building stock 318781, or did you reverted r318750 ?
> > 
> > Stock 318781 [*].  I revert as a (nearly) last resort. :-)
> > 
> > > > While it has not yet completed ">>> stage 4.2: building libraries", it
> > > > is well beyond the provious point of failure (again, building parts of
> > > > clang/libllvm).
> > > > 
> > > > I'm reporting now, as I'll need to head in to work fairly soon.  I
> > > > should be able to report definitively a bit later.
> > 
> > It's completed the ">>> stage 4.2: building libraries" part, and well
> > into ">>> stage 4.3: building everything".
> > 
> > * Save for my (usual) hacking of conf/newvers.sh a bit.
> > 
> > And now I really do need to head in to work.
> > ...
> 
> It completed successfully and a reboot shows:
> 
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354  
> r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64
> 

I performed a local experiment, first building sources from r318784
on a system where I did pre-commit test for ino64, updating the machine
to the result of it, then building sources of r318789 and again updating.

No SIGSEGV etc, so I think that the effects seen are due to build system.
rm -rf obj/* is the safest trick, I believe.
___
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: ino64 package fallout

[Konstantin Belousov]

On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote:
> I just upgraded by package build box and its poudriere jail to r318776
> and ran into some significant package build fallout.

There are several reviews that fix ports with most significant fallouts,
   lang/llvm39  D10796
   lang/llvm40  D10797
   lang/ghc D10798
   multimedia/webcamd   D10800
   devel/libgtopD10795
   sysutils/py-psutil   D1081
   lang/rustD10799

I intend to commit this tomorrow, after the ino64 get some probation time,
long enough to ensure that it does not get immediate revert.  You may
see the discussions and use the patches locally, meantime.
___
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: ino64 package fallout

[Shawn Webb]

On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote:
> I just upgraded by package build box and its poudriere jail to r318776
> and ran into some significant package build fallout.
> 
> devel/llvm40:build:
> 
> 
> /usr/bin/c++  -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0  -O2 -pipe 
> -fstack-protector -isystem /usr/local/include -fno-strict-aliasing  -isystem 
> /usr/local/include -Wall -std=c++11 -Wno-unused-parameter -O2 -pipe 
> -fstack-protector -isystem /usr/local/include -fno-strict-aliasing  -isystem 
> /usr/local/include-O2 -pipe -fstack-protector -isystem /usr/local/include 
> -fno-strict-aliasing  -isystem /usr/local/include -Wall -std=c++11 
> -Wno-unused-parameter -m64 -fPIC -fno-builtin -fno-exceptions 
> -fomit-frame-pointer -funwind-tables -fno-stack-protector 
> -fno-sanitize=safe-stack -fvisibility=hidden -fvisibility-inlines-hidden 
> -fno-function-sections -fno-lto -O3 -gline-tables-only -Wno-gnu 
> -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti 
> -Wframe-larger-than=570 -Wglobal-constructors -MD -MT 
> lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.x86_64.dir/sanitizer_platform_limits_posix.cc.o
>  -MF lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTer!
>  mination.x86_64.dir/sanitizer_platform_limits_posix.cc.o.d -o 
> lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.x86_64.dir/sanitizer_platform_limits_posix.cc.o
>  -c 
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> In file included from 
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:59:
> /usr/include/sys/timeb.h:42:2: warning: "this file includes  
> which is deprecated" [-W#warnings]
> #warning "this file includes  which is deprecated"
>  ^
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:1037:1:
>  error: 'assertion_failed__1037' declared as an array with a negative size
> CHECK_SIZE_AND_OFFSET(dirent, d_ino);
> ^~~~
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.h:1470:3:
>  note: expanded from macro 'CHECK_SIZE_AND_OFFSET'
>   COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) == \
>   ^~
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_internal_defs.h:257:30:
>  note: expanded from macro 'COMPILER_CHECK'
> #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
>  ^~~~
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_internal_defs.h:263:57:
>  note: expanded from macro 'IMPL_COMPILER_ASSERT'
> typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
> ^~~
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:1045:1:
>  error: 'assertion_failed__1045' declared as an array with a negative size
> CHECK_SIZE_AND_OFFSET(dirent, d_reclen);
> ^~~
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.h:1472:3:
>  note: expanded from macro 'CHECK_SIZE_AND_OFFSET'
>   COMPILER_CHECK(offsetof(__sanitizer_##CLASS, MEMBER) ==  \
>   ^~
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_internal_defs.h:257:30:
>  note: expanded from macro 'COMPILER_CHECK'
> #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
>  ^~~~
> /wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_internal_defs.h:263:57:
>  note: expanded from macro 'IMPL_COMPILER_ASSERT'
> typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
> ^~~
> 1 warning and 2 errors generated.
> 
> 
> lang/ghc:configure:
> 
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking Setup ...
> Setup: No cabal file found.
> Please create a package description file .cabal
> *** Error code 1
> 
> 
> lang/rust:build:
> 
>   extracting 
> cargo-nightly-x86_64-unknown-freebsd/cargo/etc/bash_completion.d/ca
> rgo
>Compiling rustc-serialize v0.3.22
>Compiling libc v0.2.21
>Compiling gcc v0.3.43
>Compiling getopts v0.2.14
>Compiling num_cpus v0.2.13
>Compiling filetime v0.1.10
>Compiling build_helper v0.1.0 
> (file:///wrkdirs/usr/ports/lang/rust/work/rustc
> -1.17.0-src/src/build_helper)
> 

Re: Bug in make setting wrong MAKESYSPATH

[Simon J. Gerraty]

Thomas Mueller  wrote:
> For building the system, MAKESYSPATH should be $SRCDIR/share/mk , to be in 
> sync.
> 
> I tried "make -V MAKESYSPATH" from several SRCDIRs, and that's what happened.

Yes.  If you look at share/mk/src.sys.env.mk
it detects that it was found via a .../ path, and replaces it in
MAKESYSPATH with the actual location - otherwise some makefiles break.

> So maybe I have to set MAKESYSPATH every time I am in ports, don't
> know if this would work from /etc/make.conf (need to experiment).

Probably not, because sys.mk will have already been found before that
ie. the damage may already have been done
 
> I wonder what would happen if there is no FreeBSD installation at all
> on partition where ports tree is located.

An error like:

make: no system rules (sys.mk).

> 
> > Yes, but requires you to keep /usr/share/mk in sync with whatever you a
> > building, tricky if you build head, stable/10 and stable/11 on the
> > same box.
> 
> I don't think you have to do that, since I find that MAKESYSPATH
> becomes $SRCDIR/share/mk .

Per above; that's due to the default .../share/mk
I was speaking about alternatives to that magic value.

Thanks
--sjg
___
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"

ino64 package fallout

[Don Lewis]

I just upgraded by package build box and its poudriere jail to r318776
and ran into some significant package build fallout.

devel/llvm40:build:


/usr/bin/c++  -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0  -O2 -pipe 
-fstack-protector -isystem /usr/local/include -fno-strict-aliasing  -isystem 
/usr/local/include -Wall -std=c++11 -Wno-unused-parameter -O2 -pipe 
-fstack-protector -isystem /usr/local/include -fno-strict-aliasing  -isystem 
/usr/local/include-O2 -pipe -fstack-protector -isystem /usr/local/include 
-fno-strict-aliasing  -isystem /usr/local/include -Wall -std=c++11 
-Wno-unused-parameter -m64 -fPIC -fno-builtin -fno-exceptions 
-fomit-frame-pointer -funwind-tables -fno-stack-protector 
-fno-sanitize=safe-stack -fvisibility=hidden -fvisibility-inlines-hidden 
-fno-function-sections -fno-lto -O3 -gline-tables-only -Wno-gnu 
-Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti 
-Wframe-larger-than=570 -Wglobal-constructors -MD -MT 
lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.x86_64.dir/sanitizer_platform_limits_posix.cc.o
 -MF lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTer!
 mination.x86_64.dir/sanitizer_platform_limits_posix.cc.o.d -o 
lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.x86_64.dir/sanitizer_platform_limits_posix.cc.o
 -c 
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc
In file included from 
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:59:
/usr/include/sys/timeb.h:42:2: warning: "this file includes  which 
is deprecated" [-W#warnings]
#warning "this file includes  which is deprecated"
 ^
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:1037:1:
 error: 'assertion_failed__1037' declared as an array with a negative size
CHECK_SIZE_AND_OFFSET(dirent, d_ino);
^~~~
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.h:1470:3:
 note: expanded from macro 'CHECK_SIZE_AND_OFFSET'
  COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) == \
  ^~
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_internal_defs.h:257:30:
 note: expanded from macro 'COMPILER_CHECK'
#define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
 ^~~~
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_internal_defs.h:263:57:
 note: expanded from macro 'IMPL_COMPILER_ASSERT'
typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^~~
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:1045:1:
 error: 'assertion_failed__1045' declared as an array with a negative size
CHECK_SIZE_AND_OFFSET(dirent, d_reclen);
^~~
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.h:1472:3:
 note: expanded from macro 'CHECK_SIZE_AND_OFFSET'
  COMPILER_CHECK(offsetof(__sanitizer_##CLASS, MEMBER) ==  \
  ^~
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_internal_defs.h:257:30:
 note: expanded from macro 'COMPILER_CHECK'
#define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
 ^~~~
/wrkdirs/usr/ports/devel/llvm40/work/compiler-rt-4.0.1rc1.src/lib/sanitizer_common/sanitizer_internal_defs.h:263:57:
 note: expanded from macro 'IMPL_COMPILER_ASSERT'
typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^~~
1 warning and 2 errors generated.


lang/ghc:configure:

[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
Setup: No cabal file found.
Please create a package description file .cabal
*** Error code 1


lang/rust:build:

  extracting cargo-nightly-x86_64-unknown-freebsd/cargo/etc/bash_completion.d/ca
rgo
   Compiling rustc-serialize v0.3.22
   Compiling libc v0.2.21
   Compiling gcc v0.3.43
   Compiling getopts v0.2.14
   Compiling num_cpus v0.2.13
   Compiling filetime v0.1.10
   Compiling build_helper v0.1.0 (file:///wrkdirs/usr/ports/lang/rust/work/rustc
-1.17.0-src/src/build_helper)
   Compiling cmake v0.1.21
   Compiling toml v0.1.30
   Compiling bootstrap v0.0.0 (file:///wrkdirs/usr/ports/lang/rust/work/rustc-1.
17.0-src/src/bootstrap)
Finished dev [unoptimized] target(s) in 31.38 secs
Build completed 

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Ngie Cooper]

> On May 24, 2017, at 08:15, David Wolfskill  wrote:

...

> It completed successfully and a reboot shows:
> 
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354  
> r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

Hi David!
There was another report on the list about a stale MAKEOBJDIRPREFIX causing 
someone grief. I think it's safe to say that meta mode and -DNO_CLEAN might not 
work across this transition--in particular meta mode tends to err on the side 
of not to rebuilding things.
Cheers,
-Ngie
___
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: ERROR: ctfconvert: [...] has too many members: 1911 > 1023 _and_ ERROR: rc = -1 No entry found [dwarf_next_cu_header_c(61)]

[Boris Samorodov]

24.05.2017 18:09, Dimitry Andric пишет:
> On 24 May 2017, at 14:58, Boris Samorodov  wrote:
>>
>> JFYI: Today I've got a bunch (as much as 63) of cftconvert errors
>> while make buildkernel. There were no such errors tomorrow. The building
>> machine is FreeBSD-amd64-r317665.
>>
>> Errors are not fatal, so the kernel has build successfully. I didn't
>> dare to try to install it yet.
> 
> These messages have been occurring for a long time now (years?), and
> can be safely ignored.

Hi Dimitry,

I suspected something like this. I have WITH_META_MODE defined so it may
be why I do see those messages rarely.

Thank you.
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve



signature.asc
Description: OpenPGP digital signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[David Wolfskill]

On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote:
> ...
> > > I have updated /usr/src back to 318781, then started a new build.
> > So are you building stock 318781, or did you reverted r318750 ?
> 
> Stock 318781 [*].  I revert as a (nearly) last resort. :-)
> 
> > > While it has not yet completed ">>> stage 4.2: building libraries", it
> > > is well beyond the provious point of failure (again, building parts of
> > > clang/libllvm).
> > > 
> > > I'm reporting now, as I'll need to head in to work fairly soon.  I
> > > should be able to report definitively a bit later.
> 
> It's completed the ">>> stage 4.2: building libraries" part, and well
> into ">>> stage 4.3: building everything".
> 
> * Save for my (usual) hacking of conf/newvers.sh a bit.
> 
> And now I really do need to head in to work.
> ...

It completed successfully and a reboot shows:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354  
r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

Peace,
david   (typing from shuttle en route to work)
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ERROR: ctfconvert: [...] has too many members: 1911 > 1023 _and_ ERROR: rc = -1 No entry found [dwarf_next_cu_header_c(61)]

[Dimitry Andric]

On 24 May 2017, at 14:58, Boris Samorodov  wrote:
> 
> JFYI: Today I've got a bunch (as much as 63) of cftconvert errors
> while make buildkernel. There were no such errors tomorrow. The building
> machine is FreeBSD-amd64-r317665.
> 
> Errors are not fatal, so the kernel has build successfully. I didn't
> dare to try to install it yet.

Hi Boris,

These messages have been occurring for a long time now (years?), and
can be safely ignored.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: ino64: desastrous update - recommendations not working!!!

[Alan Somers]

On Wed, May 24, 2017 at 4:42 AM, Hartmann, O.  wrote:
> On almost every CURRENT that has been updated according to UPDATING
> entry 2017-05-23 regarding ino64, the recommended update process ends
> up in a desaster or, if the old environemnt/kernel is intact, itr
> doesn't work.
>
> Procedure:
>
> make -jX buildworld buildkernel [successful]
> make installkernel [successful]
> reboot
> Booting single user mode as recommended withnthe newly installed kernel
> BUMMER!
> When it comes to the point to type in the full path of /bin/sh, /bin/sh
> immediately fails with SIGNAL 12

Did you use a custom kernel config file without COMPAT_FREEBSD11?
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[David Wolfskill]

On Wed, May 24, 2017 at 05:16:38PM +0300, Konstantin Belousov wrote:
> On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote:
> > On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote:
> > > If build of r318739 succed, can you try, please, to rebuild the current
> > > latest sources, but now with reverted r318750 ?
> > 
> > It did complete successfully.
> > 
> > I have updated /usr/src back to 318781, then started a new build.
> So are you building stock 318781, or did you reverted r318750 ?

Stock 318781 [*].  I revert as a (nearly) last resort. :-)

> > While it has not yet completed ">>> stage 4.2: building libraries", it
> > is well beyond the provious point of failure (again, building parts of
> > clang/libllvm).
> > 
> > I'm reporting now, as I'll need to head in to work fairly soon.  I
> > should be able to report definitively a bit later.

It's completed the ">>> stage 4.2: building libraries" part, and well
into ">>> stage 4.3: building everything".

* Save for my (usual) hacking of conf/newvers.sh a bit.

And now I really do need to head in to work.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Konstantin Belousov]

On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote:
> > If build of r318739 succed, can you try, please, to rebuild the current
> > latest sources, but now with reverted r318750 ?
> 
> It did complete successfully.
> 
> I have updated /usr/src back to 318781, then started a new build.
So are you building stock 318781, or did you reverted r318750 ?

> 
> While it has not yet completed ">>> stage 4.2: building libraries", it
> is well beyond the provious point of failure (again, building parts of
> clang/libllvm).
> 
> I'm reporting now, as I'll need to head in to work fairly soon.  I
> should be able to report definitively a bit later.
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[David Wolfskill]

On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote:
> ...
> > (lldb) bt
> > * thread #1, name = 'ld', stop reason = signal SIGSEGV
> >   * frame #0: 0x
> > (lldb) 
> > 
> > which isn't entirely unexpected, I suppose, given the nature of SIGSEGV.
> Useful gdb is in ports, devel/gdb.

OK; thanks.

> There is nothing in the nature of SIGSEGV which makes lack of the
> backtrace a reasonable outcome.

Oh; OK.

> ...
> If build of r318739 succed, can you try, please, to rebuild the current
> latest sources, but now with reverted r318750 ?

It did complete successfully.

I have updated /usr/src back to 318781, then started a new build.

While it has not yet completed ">>> stage 4.2: building libraries", it
is well beyond the provious point of failure (again, building parts of
clang/libllvm).

I'm reporting now, as I'll need to head in to work fairly soon.  I
should be able to report definitively a bit later.

Thank you for your help!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: svn commit: r318757 - head

[Larry Rosenman]

The initial failure was NOT, except that the PostgreSQL build builds a PL/Perl 
interpreter that MIGHT
Be considered that.

It was unexpected.


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/24/17, 8:33 AM, "Konstantin Belousov"  wrote:

On Wed, May 24, 2017 at 08:06:34AM -0500, Larry Rosenman wrote:
> The initial failure:
> 
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42
> 
> I then recompiled perl, and got:
> borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest && 
./run_branches.pl --run-all --config=/home/pgbuildfarm/conf/build-farm.conf
> Socket.c: loadable library and perl binaries are mismatched (got 
handshake key 0xd200080, needed 0xdf00080)
> borg.lerctr.org /home/pgbuildfarm/bin/latest $
> 
> force rebuilding and installing perl and all p5-* ports fixed that. 
From what I understand in reading some perl bugs and perl source, perl
performs some validation of the structures shared between the perl
interpreter and XS libraries loaded into it. So I am almost sure that
you have perl itself and some module built against different src/ bases.

Is it true ?  If yes, then this is user error.  You are trying to mix
two binaries built against incompatible ABI.

> 
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>  
>  
> 
> On 5/24/17, 4:05 AM, "Konstantin Belousov"  wrote:
> 
> On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote:
> > My PostgreSQL buildfarm animal BROKE with this change until I force 
rebuilt
> > lang/perl5.24
> > and all my p5-* ports. 
> So what was the symptoms and the error, exactly ?
> 
> A lot of efforts were spent to ensure that _consistent_ set of old 
binaries
> and libraries would run without issues on the new system.  I mean that
> if you have binaries and libraries built on pre-ino64 system, which do
> not reference any libraries built on post ino64, except system 
libraries
> (like libc/libthr etc), everything should work.  This feature was the
> main cause of long delay finishing ino64.
> 
> > 
> > emulators/qemu-user-static also won???t compile (sbruno@ is on this 
one).
> This is a separate issue.
> 
> > 
> > Poudriere did *NOT* force a fuill rebuild even though 
freebsd-version *WAS* bumped. 
> > 
> > Is there a hazard for others here?
> > 
> > Or more info needed in /usr/{src,ports}/UPDATING?
> > 
> > 
> > -- 
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
> >   
> > 
> > 
> > 
> 
> 



___
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: ino64: desastrous update - recommendations not working!!!

[Hartmann, O.]

On Wed, 24 May 2017 14:31:08 +0300
Konstantin Belousov  wrote:

> On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote:
> > On almost every CURRENT that has been updated according to UPDATING
> > entry 2017-05-23 regarding ino64, the recommended update process
> > ends up in a desaster or, if the old environemnt/kernel is intact,
> > itr doesn't work.
> > 
> > Procedure:
> > 
> > make -jX buildworld buildkernel [successful]
> > make installkernel [successful]
> > reboot
> > Booting single user mode as recommended withnthe newly installed
> > kernel BUMMER!
> > When it comes to the point to type in the full path
> > of /bin/sh, /bin/sh immediately fails with SIGNAL 12  
> Signal 12 is SIGSYS, which strongly suggest that your 'new' kernel is
> not new, it does not implement some of the syscalls called by new
> binaries.

It is(!) new as it has been installed from sources checked out
recently, rebuilt world and rebuilt world after I completely
DELETED(!) /usr/obj.
The most striking evidence would be the revision number right now, but
I don't have the luxury of time at the moment to play with the harhsly
failing wreckeges.

> 
> > 
> > In this case, I can boot without problems the old kernel and the
> > system works again.
> > 
> > But, depending on the entry revision from which I started the 22nd,
> > or 23rd of May ino64-deal, there is a more harsh failure!  
> I do not understand what are you trying to say there.

Well, that is easy. On our development and testing facilities, I do
in most cases daily updates. Some notebooks or systems I/we have to
rely a bit more on, I do this after two or more days after a successful
update of the others.

What I want to say - and did say - is: boxes which I have updated
recently, 22nd, 23rd May the last time, do break on installworld after
they booted successfully the new kernel and gave me a single-user
console, while the notebooks, for instance, which has been updated
CURRENT the last time on Thursday last week, only fail in getting a
login due to the /bin/sh SIGSYS issue.

I think David Wolfskill made a point about this in a recent commit to
the list.

> 
> > 
> > According to the above recommendation of updating, BUMMER! doesn't
> > occur at that point and the shell /bin/sh starts as expected.
> > Performing 
> > 
> > mergemaster -Fp
> > 
> > also performs well without any questions or installations so far,
> > but then
> > 
> > make installworld
> > 
> > BUMMER! again and this time with fatal consequences! The
> > installation fails in libexec/rtld-elf or something like that in the
> > source/object tree after copying libexec/ld-elf.so.1. I
> > see /libexec/ld-elf.so.1 successfully copied with the security copy
> > marked with appendix .old being of a conclusive date and time.
> > The installworld bails out, leaves the tree in a mixture of old and
> > new binaries and now, thanks, the whole system ist wrecked.
> > When trying to reboot such a half-ready installation in single user
> > mode, I can't even get an shell enymore.
> > 
> > How can I fix this emergency case with the tools aboard?
> > 
> > Since there is no compiler or build infrastructure any more on the
> > USB bootimage, I can not simply installworld and installkernel -
> > the boot image is useless - on this list I had such a discussion in
> > March. For short: I have the intact and complete /usr/obj tree and
> > I think it would be a great deal to be able to simply boot via USB
> > memstick and perform installworld with propper settings of DESTDIR=
> > and sibblings.
> > 
> > Yes, now what is to do ... :-(
> > 
> > Help appreciated and thanks in advance for those reading so far.  
> 
> I put a statically built stat(1) binary there:
> https://www.kib.kiev.ua/kib/stat-ino64-static
> 
> You might use it as a test for the right kernel: after you boot with
> supposedly new kernel but old world, try to run the binary.  If
> running results in SIGSYS (12), you have configuration issue to solve.

I'll try. And report. But I'm out of the lab until Monday :-( I have
boxes at home I'd like to update, last update of those was the day
before yesterday, but I do not dare until the issue is identified
correctly. As David Wolfskill stated in his headline, it is probably
not ino64 messing up - as I interprete his question mark.

> ___
> 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"

___
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: svn commit: r318757 - head

[Konstantin Belousov]

On Wed, May 24, 2017 at 08:06:34AM -0500, Larry Rosenman wrote:
> The initial failure:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42
> 
> I then recompiled perl, and got:
> borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest && 
> ./run_branches.pl --run-all --config=/home/pgbuildfarm/conf/build-farm.conf
> Socket.c: loadable library and perl binaries are mismatched (got handshake 
> key 0xd200080, needed 0xdf00080)
> borg.lerctr.org /home/pgbuildfarm/bin/latest $
> 
> force rebuilding and installing perl and all p5-* ports fixed that. 
>From what I understand in reading some perl bugs and perl source, perl
performs some validation of the structures shared between the perl
interpreter and XS libraries loaded into it. So I am almost sure that
you have perl itself and some module built against different src/ bases.

Is it true ?  If yes, then this is user error.  You are trying to mix
two binaries built against incompatible ABI.

> 
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>  
>  
> 
> On 5/24/17, 4:05 AM, "Konstantin Belousov"  wrote:
> 
> On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote:
> > My PostgreSQL buildfarm animal BROKE with this change until I force 
> rebuilt
> > lang/perl5.24
> > and all my p5-* ports. 
> So what was the symptoms and the error, exactly ?
> 
> A lot of efforts were spent to ensure that _consistent_ set of old 
> binaries
> and libraries would run without issues on the new system.  I mean that
> if you have binaries and libraries built on pre-ino64 system, which do
> not reference any libraries built on post ino64, except system libraries
> (like libc/libthr etc), everything should work.  This feature was the
> main cause of long delay finishing ino64.
> 
> > 
> > emulators/qemu-user-static also won???t compile (sbruno@ is on this 
> one).
> This is a separate issue.
> 
> > 
> > Poudriere did *NOT* force a fuill rebuild even though freebsd-version 
> *WAS* bumped. 
> > 
> > Is there a hazard for others here?
> > 
> > Or more info needed in /usr/{src,ports}/UPDATING?
> > 
> > 
> > -- 
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
> >   
> > 
> > 
> > 
> 
> 
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Konstantin Belousov]

On Wed, May 24, 2017 at 06:01:43AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote:
> > ...
> > > building special pic c library
> > > --- libc.so.7 ---
> > > cc: error: unable to execute command: Segmentation fault (core dumped)
> > > cc: error: linker command failed due to signal (use -v to see invocation)
> > > *** [libc.so.7] Error code 254
> > 
> > Looks like your linker is crashing.  Can you figure out:
> > 1) The exact linker command being run
> > 2) The path to the linker executable that crashes
> > 3) Backtrace of the crash
> > 
> > -Dimitry
> > 
> 
> On Wed, May 24, 2017 at 03:10:33PM +0300, Konstantin Belousov wrote:
> > ...
> > 
> > If you perform build of r318739 on r318739 (i.e. build of the same sources
> > as installed on your machine), does the SIGSEGV occur ?
> > 
> > Anyway, get the core file loaded into gdb and get the backtrace, at least.
> 
> Sorry for the delay; I'm way out of practice with using a debugger...
> and I see that gdb isn't in head now.  lldb tells me:
> 
> (lldb) bt
> * thread #1, name = 'ld', stop reason = signal SIGSEGV
>   * frame #0: 0x
> (lldb) 
> 
> which isn't entirely unexpected, I suppose, given the nature of SIGSEGV.
Useful gdb is in ports, devel/gdb.

There is nothing in the nature of SIGSEGV which makes lack of the
backtrace a reasonable outcome.

> 
> On the build machine, I "cloned" slice 4 to slice 3, then rebooted it
> from slice 3, "updated" /usr/src to r318739 and told it to go build
> itself (while I continued poking at my laptop).  The build machine has
> not yet completed the ">>> stage 4.2: building libraries" step -- recall
> that I had performed a "make clean" before cloning... -- but it has got
> quite a bit beyond the previous point of failure (still building clang).
> 
> I have copied the ld.core and libc.so.7.meta files from the build
> machine to  (and
> made gzipped copies, as well).
> 
> As far as I can tell, the "ld" command was:
> freebeast(12.0-C)[10] ls -lT `which ld`
> -r-xr-xr-x  2 root  wheel  1706336 May 23 05:29:59 2017 /usr/bin/ld
> 
> This, from:
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #352  
> r318739M/318739:1200031: Tue May 23 05:16:24 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 
> Late note: ">>> stage 4.2: building libraries" has completed on the
> build machine (building r318739 while running r318739).
> 
> I apologize for not getting all the information you (both) requested, but
> thought it best to provisde what I can (sooner).

If build of r318739 succed, can you try, please, to rebuild the current
latest sources, but now with reverted r318750 ?
___
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: The futur of the roff toolchain

[Steffen Nurpmeso]

Mr. McKusick,

Kirk McKusick  wrote:
 |Thanks for all your work on this project. As I still use roff for
 |our book and for many of my presentations, it is a topic of interest
 |to me. That said, I am fine with roff dropping out of base as I can
 |easily enough bring it in from ports. And I am curious to try using
 |heirloom doctools on our book to see if it works. We do some pretty
 |evil things with diversions, so I can easily believe that it will
 |not work. But it would be great if it does work, because the groff
 |in base has some bugs that are annoying to work around.

i would be interested to hear about all bugs for future references.
I will continue to work on the GPLv2 clone of GNU roff -- that
i will maintain -- again in the nearer future, and have brought
that almost in sync with v1.22.3 years before.  (In sync, but
having left off some things which touch code, and that is GPLv3.
Etc.)
I have not seen annoying bugs in my daily, very unscientific
though, use of the FreeBSD version of groff for what can be called
many years.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
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: base packages, ino64 and upgrade

[Boris Samorodov]

24.05.2017 16:00, Glen Barber пишет:
> On Wed, May 24, 2017 at 03:47:47PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> Does anyone know the procedure to upgrade for those using base packages?
> 
> 'pkg install FreeBSD-kernel-generic' (or whatever your kernel package is
> called), reboot, 'pkg upgrade'.

OK, thanks. I'll try in the evening.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r318757 - head

[Larry Rosenman]

The initial failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42

I then recompiled perl, and got:
borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest && 
./run_branches.pl --run-all --config=/home/pgbuildfarm/conf/build-farm.conf
Socket.c: loadable library and perl binaries are mismatched (got handshake key 
0xd200080, needed 0xdf00080)
borg.lerctr.org /home/pgbuildfarm/bin/latest $

force rebuilding and installing perl and all p5-* ports fixed that. 



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/24/17, 4:05 AM, "Konstantin Belousov"  wrote:

On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote:
> My PostgreSQL buildfarm animal BROKE with this change until I force 
rebuilt
> lang/perl5.24
> and all my p5-* ports. 
So what was the symptoms and the error, exactly ?

A lot of efforts were spent to ensure that _consistent_ set of old binaries
and libraries would run without issues on the new system.  I mean that
if you have binaries and libraries built on pre-ino64 system, which do
not reference any libraries built on post ino64, except system libraries
(like libc/libthr etc), everything should work.  This feature was the
main cause of long delay finishing ino64.

> 
> emulators/qemu-user-static also won???t compile (sbruno@ is on this one).
This is a separate issue.

> 
> Poudriere did *NOT* force a fuill rebuild even though freebsd-version 
*WAS* bumped. 
> 
> Is there a hazard for others here?
> 
> Or more info needed in /usr/{src,ports}/UPDATING?
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>   
> 
> 
> 



___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[David Wolfskill]

On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote:
> ...
> > building special pic c library
> > --- libc.so.7 ---
> > cc: error: unable to execute command: Segmentation fault (core dumped)
> > cc: error: linker command failed due to signal (use -v to see invocation)
> > *** [libc.so.7] Error code 254
> 
> Looks like your linker is crashing.  Can you figure out:
> 1) The exact linker command being run
> 2) The path to the linker executable that crashes
> 3) Backtrace of the crash
> 
> -Dimitry
> 

On Wed, May 24, 2017 at 03:10:33PM +0300, Konstantin Belousov wrote:
> ...
> 
> If you perform build of r318739 on r318739 (i.e. build of the same sources
> as installed on your machine), does the SIGSEGV occur ?
> 
> Anyway, get the core file loaded into gdb and get the backtrace, at least.

Sorry for the delay; I'm way out of practice with using a debugger...
and I see that gdb isn't in head now.  lldb tells me:

(lldb) bt
* thread #1, name = 'ld', stop reason = signal SIGSEGV
  * frame #0: 0x
(lldb) 

which isn't entirely unexpected, I suppose, given the nature of SIGSEGV.

On the build machine, I "cloned" slice 4 to slice 3, then rebooted it
from slice 3, "updated" /usr/src to r318739 and told it to go build
itself (while I continued poking at my laptop).  The build machine has
not yet completed the ">>> stage 4.2: building libraries" step -- recall
that I had performed a "make clean" before cloning... -- but it has got
quite a bit beyond the previous point of failure (still building clang).

I have copied the ld.core and libc.so.7.meta files from the build
machine to  (and
made gzipped copies, as well).

As far as I can tell, the "ld" command was:
freebeast(12.0-C)[10] ls -lT `which ld`
-r-xr-xr-x  2 root  wheel  1706336 May 23 05:29:59 2017 /usr/bin/ld

This, from:
FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #352  
r318739M/318739:1200031: Tue May 23 05:16:24 PDT 2017 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

Late note: ">>> stage 4.2: building libraries" has completed on the
build machine (building r318739 while running r318739).

I apologize for not getting all the information you (both) requested, but
thought it best to provisde what I can (sooner).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: base packages, ino64 and upgrade

[Glen Barber]

On Wed, May 24, 2017 at 03:47:47PM +0300, Boris Samorodov wrote:
> Hi All,
> 
> Does anyone know the procedure to upgrade for those using base packages?
> 

'pkg install FreeBSD-kernel-generic' (or whatever your kernel package is
called), reboot, 'pkg upgrade'.

Glen



signature.asc
Description: PGP signature

ERROR: ctfconvert: [...] has too many members: 1911 > 1023 _and_ ERROR: rc = -1 No entry found [dwarf_next_cu_header_c(61)]

[Boris Samorodov]

Hi All,

JFYI: Today I've got a bunch (as much as 63) of cftconvert errors
while make buildkernel. There were no such errors tomorrow. The building
machine is FreeBSD-amd64-r317665.

Errors are not fatal, so the kernel has build successfully. I didn't
dare to try to install it yet.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

base packages, ino64 and upgrade

[Boris Samorodov]

Hi All,

Does anyone know the procedure to upgrade for those using base packages?

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Konstantin Belousov]

On Wed, May 24, 2017 at 04:59:31AM -0700, David Wolfskill wrote:
> Yesterday's in-place src update (r318606 -> r318739) was a bit more
> "interesting" than usual; as has been noted elsewhere, it really is
> necessary to boot the new kernel before the "make installworld"
> completes successfully.  That said, it ("make installworld") did
> complete successfully, and a followup reboot/smoke test worked without
> incident.
> 
> For today's update, sources are now at r318781; both laptop and build
> machine fail identically during ">>> stage 4.2: building libraries":
> 
> ...
> Building /common/S4/obj/usr/src/lib/libc/strsignal.pico
> Building /common/S4/obj/usr/src/lib/libc/libc.a
> --- libc.a ---
> building static c library
> Building /common/S4/obj/usr/src/lib/libc/libc.so.7
> Building /common/S4/obj/usr/src/lib/libc/libc_pic.a
> --- libc.so.7 ---
> building shared library libc.so.7
> --- libc_pic.a ---
> building special pic c library
> --- libc.so.7 ---
> cc: error: unable to execute command: Segmentation fault (core dumped)
> cc: error: linker command failed due to signal (use -v to see invocation)
> *** [libc.so.7] Error code 254
> 
> bmake[4]: stopped in /usr/src/lib/libc
> .ERROR_TARGET='libc.so.7'
> .ERROR_META_FILE='/common/S4/obj/usr/src/lib/libc/libc.so.7.meta'
> .MAKE.LEVEL='4'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> .CURDIR='/usr/src/lib/libc'
> .MAKE='/usr/obj/usr/src/make.amd64/bmake'
> .OBJDIR='/usr/obj/usr/src/lib/libc'
> .TARGETS='all'
> DESTDIR='/usr/obj/usr/src/tmp'
> LD_LIBRARY_PATH=''
> MACHINE='amd64'
> MACHINE_ARCH='amd64'
> MAKEOBJDIRPREFIX='/usr/obj'
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20160604'
> PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
> SRCTOP='/usr/src'
> OBJTOP='/usr/obj/usr/src'
> .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
> /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
> /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk 
> /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
> /etc/src.conf /usr/src/lib/libc/Makefile /usr/src/share/mk/src.opts.mk 
> /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk 
> /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk 
> /usr/src/share/mk/bsd.compiler.mk /usr/src/lib/libc/amd64/Makefile.inc 
> /usr/src/lib/libc/db/Makefile.inc /usr/src/lib/libc/db/btree/Makefile.inc 
> /usr/src/lib/libc/db/db/Makefile.inc /usr/src/lib/libc/db/hash/Makefile.inc 
> /usr/src/lib/libc/db/man/Makefile.inc /usr/src/lib/libc/db/mpool/Makefile.inc 
> /usr/src/lib/libc/db/recno/Makefile.inc 
> /usr/src/lib/libc/compat-43/Makefile.inc /usr/src/lib/libc/gdtoa/Makefile.inc 
> /usr/src/lib/libc/gen/Makefile.inc /usr/src/lib/libc/amd64/gen/Makefile.inc 
> /usr/src/lib/libc/gmon/Makefile.inc /usr/s
 rc/lib/libc/iconv/Makefile.inc /usr/src/lib/libc_nonshared/Makefile.iconv 
/usr/src/lib/libc/inet/Makefile.inc /usr/src/lib/libc/isc/Makefile.inc 
/usr/src/lib/libc/locale/Makefile.inc /usr/src/lib/libc/md/Makefile.inc 
/usr/src/lib/libc/nameser/Makefile.inc /usr/src/lib/libc/net/Makefile.inc 
/usr/src/lib/libc/nls/Makefile.inc /usr/src/lib/libc/posix1e/Makefile.inc 
/usr/src/lib/libc/regex/Makefile.inc /usr/src/lib/libc/resolv/Makefile.inc 
/usr/src/lib/libc/stdio/Makefile.inc /usr/src/lib/libc/stdlib/Makefile.inc 
/usr/src/lib/libc/amd64/stdlib/Makefile.inc 
/usr/src/lib/libc/stdlib/jemalloc/Makefile.inc 
/usr/src/lib/libc/stdtime/Makefile.inc /usr/src/lib/libc/string/Makefile.inc 
/usr/src/lib/libc/amd64/string/Makefile.inc /usr/src/lib/libc/sys/Makefile.inc 
/usr/src/sys/sys/syscall.mk /usr/src/lib/libc/amd64/sys/Makefile.inc 
/usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makefile.inc 
/usr/src/lib/libc/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc 
/usr/src/lib/libc/x86/
 sys/Makefile.inc /usr/src/lib/libc/yp/Makefile.inc /
> .PATH='. /usr/src/lib/libc /usr/src/lib/libc/db/btree /usr/src/lib/libc/db/db 
> /usr/src/lib/libc/db/hash /usr/src/lib/libc/db/man /usr/src/lib/libc/db/mpool 
> /usr/src/lib/libc/db/recno /usr/src/lib/libc/compat-43 
> /usr/src/lib/libc/gdtoa /usr/src/lib/libc/amd64/gen /usr/src/lib/libc/gen 
> /usr/src/contrib/libc-pwcache /usr/src/contrib/libc-vis 
> /usr/src/lib/libc/gmon /usr/src/lib/libc/iconv /usr/src/lib/libc/inet 
> /usr/src/lib/libc/isc /usr/src/lib/libc/locale /usr/src/lib/libmd 
> /usr/src/lib/libc/nameser /usr/src/lib/libc/net /usr/src/lib/libc/nls 
> /usr/src/lib/libc/posix1e /usr/src/lib/libc/regex /usr/src/lib/libc/resolv 
> /usr/src/lib/libc/stdio /usr/src/lib/libc/amd64/stdlib 
> /usr/src/lib/libc/stdlib /usr/src/lib/libc/stdlib/jemalloc 
> /usr/src/lib/libc/stdtime /usr/src/contrib/tzcode/stdtime 
> /usr/src/lib/libc/amd64/string /usr/src/lib/libc/string /usr/src/sys/libkern 
> 

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Dimitry Andric]

On 24 May 2017, at 13:59, David Wolfskill  wrote:
> 
> Yesterday's in-place src update (r318606 -> r318739) was a bit more
> "interesting" than usual; as has been noted elsewhere, it really is
> necessary to boot the new kernel before the "make installworld"
> completes successfully.  That said, it ("make installworld") did
> complete successfully, and a followup reboot/smoke test worked without
> incident.
> 
> For today's update, sources are now at r318781; both laptop and build
> machine fail identically during ">>> stage 4.2: building libraries":
> 
> ...
> Building /common/S4/obj/usr/src/lib/libc/strsignal.pico
> Building /common/S4/obj/usr/src/lib/libc/libc.a
> --- libc.a ---
> building static c library
> Building /common/S4/obj/usr/src/lib/libc/libc.so.7
> Building /common/S4/obj/usr/src/lib/libc/libc_pic.a
> --- libc.so.7 ---
> building shared library libc.so.7
> --- libc_pic.a ---
> building special pic c library
> --- libc.so.7 ---
> cc: error: unable to execute command: Segmentation fault (core dumped)
> cc: error: linker command failed due to signal (use -v to see invocation)
> *** [libc.so.7] Error code 254

Looks like your linker is crashing.  Can you figure out:
1) The exact linker command being run
2) The path to the linker executable that crashes
3) Backtrace of the crash

-Dimitry



signature.asc
Description: Message signed with OpenPGP

ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[David Wolfskill]

Yesterday's in-place src update (r318606 -> r318739) was a bit more
"interesting" than usual; as has been noted elsewhere, it really is
necessary to boot the new kernel before the "make installworld"
completes successfully.  That said, it ("make installworld") did
complete successfully, and a followup reboot/smoke test worked without
incident.

For today's update, sources are now at r318781; both laptop and build
machine fail identically during ">>> stage 4.2: building libraries":

...
Building /common/S4/obj/usr/src/lib/libc/strsignal.pico
Building /common/S4/obj/usr/src/lib/libc/libc.a
--- libc.a ---
building static c library
Building /common/S4/obj/usr/src/lib/libc/libc.so.7
Building /common/S4/obj/usr/src/lib/libc/libc_pic.a
--- libc.so.7 ---
building shared library libc.so.7
--- libc_pic.a ---
building special pic c library
--- libc.so.7 ---
cc: error: unable to execute command: Segmentation fault (core dumped)
cc: error: linker command failed due to signal (use -v to see invocation)
*** [libc.so.7] Error code 254

bmake[4]: stopped in /usr/src/lib/libc
.ERROR_TARGET='libc.so.7'
.ERROR_META_FILE='/common/S4/obj/usr/src/lib/libc/libc.so.7.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/lib/libc'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/lib/libc'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/lib/libc/Makefile /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/lib/libc/amd64/Makefile.inc 
/usr/src/lib/libc/db/Makefile.inc /usr/src/lib/libc/db/btree/Makefile.inc 
/usr/src/lib/libc/db/db/Makefile.inc /usr/src/lib/libc/db/hash/Makefile.inc 
/usr/src/lib/libc/db/man/Makefile.inc /usr/src/lib/libc/db/mpool/Makefile.inc 
/usr/src/lib/libc/db/recno/Makefile.inc 
/usr/src/lib/libc/compat-43/Makefile.inc /usr/src/lib/libc/gdtoa/Makefile.inc 
/usr/src/lib/libc/gen/Makefile.inc /usr/src/lib/libc/amd64/gen/Makefile.inc 
/usr/src/lib/libc/gmon/Makefile.inc /usr/src/lib/libc/iconv/Makefile.inc 
/usr/src/lib/libc_nonshared/Makefile.iconv /usr/src/lib/libc/inet/Makefile.inc 
/usr/src/lib/libc/isc/Makefile.inc /usr/src/lib/libc/locale/Makefile.inc 
/usr/src/lib/libc/md/Makefile.inc /usr/src/lib/libc/nameser/Makefile.inc 
/usr/src/lib/libc/net/Makefile.inc /usr/src/lib/libc/nls/Makefile.inc 
/usr/src/lib/libc/posix1e/Makefile.inc /usr/src/lib/libc/regex/Makefile.inc 
/usr/src/lib/libc/resolv/Makefile.inc /usr/src/lib/libc/stdio/Makefile.inc 
/usr/src/lib/libc/stdlib/Makefile.inc 
/usr/src/lib/libc/amd64/stdlib/Makefile.inc 
/usr/src/lib/libc/stdlib/jemalloc/Makefile.inc 
/usr/src/lib/libc/stdtime/Makefile.inc /usr/src/lib/libc/string/Makefile.inc 
/usr/src/lib/libc/amd64/string/Makefile.inc /usr/src/lib/libc/sys/Makefile.inc 
/usr/src/sys/sys/syscall.mk /usr/src/lib/libc/amd64/sys/Makefile.inc 
/usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makefile.inc 
/usr/src/lib/libc/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc 
/usr/src/lib/libc/x86/sys/Makefile.inc /usr/src/lib/libc/yp/Makefile.inc 
/usr/src/lib/libc/capability/Makefile.inc /usr/src/share/mk/bsd.lib.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/lib/libc/../Makefile.inc 
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/lib/libc /usr/src/lib/libc/db/btree /usr/src/lib/libc/db/db 
/usr/src/lib/libc/db/hash /usr/src/lib/libc/db/man /usr/src/lib/libc/db/mpool 
/usr/src/lib/libc/db/recno /usr/src/lib/libc/compat-43 /usr/src/lib/libc/gdtoa 
/usr/src/lib/libc/amd64/gen /usr/src/lib/libc/gen /usr/src/contrib/libc-pwcache 
/usr/src/contrib/libc-vis /usr/src/lib/libc/gmon /usr/src/lib/libc/iconv 
/usr/src/lib/libc/inet /usr/src/lib/libc/isc /usr/src/lib/libc/locale 
/usr/src/lib/libmd 

Re: ino64: desastrous update - recommendations not working!!!

[Konstantin Belousov]

On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote:
> On almost every CURRENT that has been updated according to UPDATING
> entry 2017-05-23 regarding ino64, the recommended update process ends
> up in a desaster or, if the old environemnt/kernel is intact, itr
> doesn't work.
> 
> Procedure:
> 
> make -jX buildworld buildkernel [successful]
> make installkernel [successful]
> reboot
> Booting single user mode as recommended withnthe newly installed kernel
> BUMMER!
> When it comes to the point to type in the full path of /bin/sh, /bin/sh
> immediately fails with SIGNAL 12
Signal 12 is SIGSYS, which strongly suggest that your 'new' kernel is not
new, it does not implement some of the syscalls called by new binaries.

> 
> In this case, I can boot without problems the old kernel and the system
> works again.
> 
> But, depending on the entry revision from which I started the 22nd, or
> 23rd of May ino64-deal, there is a more harsh failure!
I do not understand what are you trying to say there.

> 
> According to the above recommendation of updating, BUMMER! doesn't
> occur at that point and the shell /bin/sh starts as expected.
> Performing 
> 
> mergemaster -Fp
> 
> also performs well without any questions or installations so far,
> but then
> 
> make installworld
> 
> BUMMER! again and this time with fatal consequences! The installation
> fails in libexec/rtld-elf or something like that in the
> source/object tree after copying libexec/ld-elf.so.1. I
> see /libexec/ld-elf.so.1 successfully copied with the security copy
> marked with appendix .old being of a conclusive date and time.
> The installworld bails out, leaves the tree in a mixture of old and new
> binaries and now, thanks, the whole system ist wrecked.
> When trying to reboot such a half-ready installation in single user
> mode, I can't even get an shell enymore.
> 
> How can I fix this emergency case with the tools aboard?
> 
> Since there is no compiler or build infrastructure any more on the USB
> bootimage, I can not simply installworld and installkernel - the boot
> image is useless - on this list I had such a discussion in March. For
> short: I have the intact and complete /usr/obj tree and I think it
> would be a great deal to be able to simply boot via USB memstick and
> perform installworld with propper settings of DESTDIR= and sibblings.
> 
> Yes, now what is to do ... :-(
> 
> Help appreciated and thanks in advance for those reading so far.

I put a statically built stat(1) binary there:
https://www.kib.kiev.ua/kib/stat-ino64-static

You might use it as a test for the right kernel: after you boot with
supposedly new kernel but old world, try to run the binary.  If running
results in SIGSYS (12), you have configuration issue to solve.
___
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"

ino64: desastrous update - recommendations not working!!!

[Hartmann, O.]

On almost every CURRENT that has been updated according to UPDATING
entry 2017-05-23 regarding ino64, the recommended update process ends
up in a desaster or, if the old environemnt/kernel is intact, itr
doesn't work.

Procedure:

make -jX buildworld buildkernel [successful]
make installkernel [successful]
reboot
Booting single user mode as recommended withnthe newly installed kernel
BUMMER!
When it comes to the point to type in the full path of /bin/sh, /bin/sh
immediately fails with SIGNAL 12

In this case, I can boot without problems the old kernel and the system
works again.

But, depending on the entry revision from which I started the 22nd, or
23rd of May ino64-deal, there is a more harsh failure!

According to the above recommendation of updating, BUMMER! doesn't
occur at that point and the shell /bin/sh starts as expected.
Performing 

mergemaster -Fp

also performs well without any questions or installations so far,
but then

make installworld

BUMMER! again and this time with fatal consequences! The installation
fails in libexec/rtld-elf or something like that in the
source/object tree after copying libexec/ld-elf.so.1. I
see /libexec/ld-elf.so.1 successfully copied with the security copy
marked with appendix .old being of a conclusive date and time.
The installworld bails out, leaves the tree in a mixture of old and new
binaries and now, thanks, the whole system ist wrecked.
When trying to reboot such a half-ready installation in single user
mode, I can't even get an shell enymore.

How can I fix this emergency case with the tools aboard?

Since there is no compiler or build infrastructure any more on the USB
bootimage, I can not simply installworld and installkernel - the boot
image is useless - on this list I had such a discussion in March. For
short: I have the intact and complete /usr/obj tree and I think it
would be a great deal to be able to simply boot via USB memstick and
perform installworld with propper settings of DESTDIR= and sibblings.

Yes, now what is to do ... :-(

Help appreciated and thanks in advance for those reading so far.

O
___
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: svn commit: r318757 - head

[Konstantin Belousov]

On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote:
> My PostgreSQL buildfarm animal BROKE with this change until I force rebuilt
> lang/perl5.24
> and all my p5-* ports. 
So what was the symptoms and the error, exactly ?

A lot of efforts were spent to ensure that _consistent_ set of old binaries
and libraries would run without issues on the new system.  I mean that
if you have binaries and libraries built on pre-ino64 system, which do
not reference any libraries built on post ino64, except system libraries
(like libc/libthr etc), everything should work.  This feature was the
main cause of long delay finishing ino64.

> 
> emulators/qemu-user-static also won???t compile (sbruno@ is on this one).
This is a separate issue.

> 
> Poudriere did *NOT* force a fuill rebuild even though freebsd-version *WAS* 
> bumped. 
> 
> Is there a hazard for others here?
> 
> Or more info needed in /usr/{src,ports}/UPDATING?
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>   
> 
> 
> 
___
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: Bug in make setting wrong MAKESYSPATH

[Thomas Mueller]

>From Simon J. Gerraty:

> Thomas Mueller  wrote:
> > It seems to me that MAKESYSPATH should match the host building system
> > FreeBSD version.

> Which would only be correct if building the same version of FreeBSD as
> is running on the host.
> Many folk work on multiple branches on the same machine.

I have even built FreeBSD i386 from FreeBSD amd64, and vice versa.

Even when the user tracks only one branch, such as HEAD, one or more 
/usr/share/mk files may have been updated since the last build, and therefore 
not in sync with the build host's /usr/share/mk .

For building the system, MAKESYSPATH should be $SRCDIR/share/mk , to be in sync.

I tried "make -V MAKESYSPATH" from several SRCDIRs, and that's what happened.

Like this:

$ make -C /usr/src -V MAKESYSPATH
/usr/src/share/mk
$ make -C /freebsd-base-graphics -V MAKESYSPATH
/freebsd-base-graphics/share/mk

> Thus for anyone working on src/ there is no guarantee that /usr/share/mk
> is even remotely correct.

> So you either buy into the idea of using a wrapper script and canned
> .env file for each tree (that's what I do;
> http://www.crufty.net/sjg/docs/sb-tools.htm) to ensure correct
> settings per tree (whether FreeBSD, NetBSD, ...), or you compromise and
> have 'make' itself try to find the "correct" share/mk for whereever it is.
> This is why the default MAKESYSPATH starts with .../share/mk

> > Now I believe the correct syntax for setting MAKESYSPATH in .cshrc and 
> > .profile would be
> > export MAKESYSPATH=/usr/share/mk  # for .profile, or
> > setenv MAKESYSPATH /usr/share/mk  # for .cshrc

Something like that might be appropriate for ports but not for building the 
system.

So maybe I have to set MAKESYSPATH every time I am in ports, don't know if this 
would work from /etc/make.conf (need to experiment).

I wonder what would happen if there is no FreeBSD installation at all on 
partition where ports tree is located.

> Yes, but requires you to keep /usr/share/mk in sync with whatever you a
> building, tricky if you build head, stable/10 and stable/11 on the
> same box.

I don't think you have to do that, since I find that MAKESYSPATH becomes 
$SRCDIR/share/mk .

> sjg


Tom

___
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"