Re: 15.0-CURRENT build broken in lib/libmagic
Am 10.09.23 um 05:18 schrieb Dag-Erling Smørgrav: Rainer Hurling writes: Unfortunately, here it breaks with: [...] /usr/src/lib/libc/gdtoa/machdep_ldisx.c:40:10: fatal error: 'sys/cdefs.h' file not found That's because you wiped /usr/obj before starting. Try running 'make buildincludes' inside the buildenv before building libc. If that still fails, just run buildworld; it will fail in libmagic as before but it will have built libc before failing, and you can install libc and restart the build. DES Yes, that works! Now I have a working, most recent 15.0-CURRENT again :D I think now I understand how to use the buildenv to build individual parts. Many thanks for that and for your help and patience. Regards, Rainer
Re: sed in CURRENT fails in textproc/jq
Greetings,
I apologise for the inconvenience. The issue seems to boil down to
various places calling
memchr(buf, c, SIZE_MAX);
which causes an overflow when my newly written memchr() computes buf +
len to find the end of the buffer. A patch to alleviate this issue can
be found here:
http://fuz.su/~fuz/freebsd/0001-lib-libc-amd64-string-memchr.S-fix-behaviour-with-ov.patch
Please check if it does the trick for you. If yes, I'll go ahead and
push it tomorrow-ish.
Yours,
Robert Clausecker
Am Sat, Sep 09, 2023 at 07:12:29PM +0200 schrieb Dag-Erling Smørgrav:
> Antoine Brodin writes:
> > Yuri writes:
> > > Either something has changed in sed(1) in CURRENT, or sed just fails
> > > during the configure stage of textproc/jq:
> > >
> > > sed: No error: 0
> > > checking for sys/cygwin.h... eval: ${+...}: Bad substitution
> > This seems to be a recent issue (less than 5 days).
> > Hundreds of configure scripts now fail to run on 15-current due to
> > this sed failure: [...]
>
> Try adding ARCHLEVEL=scalar to CONFIGURE_ENV on one of these. If that
> helps, yell at fuz@ :)
>
> DES
> --
> Dag-Erling Smørgrav - d...@freebsd.org
>
--
() ascii ribbon campaign - for an 8-bit clean world
/\ - against html email - against proprietary attachments
Re: 15.0-CURRENT build broken in lib/libmagic
Rainer Hurling writes: > Unfortunately, here it breaks with: > [...] > /usr/src/lib/libc/gdtoa/machdep_ldisx.c:40:10: fatal error: 'sys/cdefs.h' > file not found That's because you wiped /usr/obj before starting. Try running 'make buildincludes' inside the buildenv before building libc. If that still fails, just run buildworld; it will fail in libmagic as before but it will have built libc before failing, and you can install libc and restart the build. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: FreeBSD 14.0-BETA1 Now Available
On Fri, 8 Sept 2023 at 19:33, Glen Barber wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > The first BETA build of the 14.0-RELEASE release cycle is now available. > ... > The freebsd-update(8) utility supports binary upgrades of amd64 and i386 > systems running earlier FreeBSD releases. Note, aarch64 binary updates > are expected to be available starting with BETA2, due to a configuration > error. Systems running earlier FreeBSD releases can upgrade as follows: > > # freebsd-update upgrade -r 14.0-BETA1 Upgrading with FreeBSD-update is failing with: # freebsd-update install src component not installed, skipped Creating snapshot of existing boot environment... done. Installing updates...install: ///usr/include/c++/v1/__string exists but is not a directory install: ///usr/include/c++/v1/__string/char_traits.h: Not a directory install: ///usr/include/c++/v1/__string/extern_template_lists.h: Not a directory Reported by Vedran Miletic in PR273661. We'll provide an update with additional information and possible workarounds, when available.
Re: user problems when upgrading to v15
Over the last week or so, stable/13, stable/14 and current have improved. Finally, I can make it through a build and install with a password on the root account and a user in the wheel group without having it fail. Brian On 9/9/2023 9:02 AM, John Baldwin wrote: On 9/2/23 7:11 AM, Dimitry Andric wrote: On 1 Sep 2023, at 03:42, brian whalen wrote: Repeating the entire process: I created a 13.2 vm with 6 cores and 8GB of ram. Ran freebsd-update fetch and install. Ran pkg install git bash ccache open-vm-tools-nox11 Used git clone to get current and ports source files. Edited /etc/make.conf to use ccache Ran make -j6 buildworld && make -j6 kernel I then rebooted in single user mode and did the next steps saving output to a file with > filename. etcupdate -p was pretty uneventful. It did show the below and did not prompt to edit. root@f15:~ # less etcupdatep C /etc/group C /etc/master.passwd This is a problem: the "C" characters mean there were conflicts, and it's indeed very unfortunate that etcupdate does not immediately force you to resolve them. Because now you basically have mangled group and master.passwd files, with conflict markers in them! No, the conflicted files are in /var/db/etcupdate/conflicts, the files in /etc are still the old ones at this point and won't be updated until you run 'etcupdate resolve' to fix them. I suspect what happened here is that Brian chose the 'tf' (theirs-full) option for 'etcupdate resolve' when he really wanted to do 'e' to edit the conflicted version. Immediately after this, you should run "etcupdate resolve", and fix any conflicts that it has found. Note that recently there was a lot of churn due to the removal of $FreeBSD$ keywords, and this almost always creates conflicts in the group and passwd files. For lots of other files in /etc, the conflicts are resolved automatically, but unfortunately not for the files that are essential to log in! make installworld seemed mostly error free though I did see a nonzero status for a man page failed inn the man4 directory. etcupdate -B only showed the below. This was my first build after install. root@f15:~ # less etcupdateB Conflicts remain from previous update, aborting. Yes, that is indeed the problem. You must first resolve conflicts from any previous etcupdate run, before doing anything else. As to why it does not immediately forces you to do so, and delegates this to a separate step, which can easily be forgotten, I have no idea. So that if you are doing scripted upgrades, you don't hang forever in a script. The intention is that after doing a bunch of scripted installworld + etcupdate's on various hosts you can use 'etcupdate status' to see if there are any remaining steps requiring manual intervention. There could be an option to request batched vs interactivate updates perhaps. If I type exit in single user mode to go multi user mode, the local user still works. After a reboot the local user still works. This local user can also sudo as expected. This wasn't the case for the previous build when I first reported this. However, if I run etcupdate resolve it is still presenting /etc/group and /etc/master/passwd as problems. If this is is expected behavior for current then no big deal. I just wasn't sure. The conflicts themselves are expected, alas. But you _must_ resolve them, otherwise you can end up with a mostly-bricked system. No, the conflict markers are not placed in the versions in /etc. However, etucpdate does refuse to do a "new" upgrade until you resolve all the conflicts from your previous upgrade to ensure that conflicted upgrades aren't missed.
Re: 15.0-CURRENT build broken in lib/libmagic
Am 09.09.23 um 20:28 schrieb Dag-Erling Smørgrav: Rainer Hurling writes: After removing /usr/obj and 'make cleanworld', That was unnecessary. I tried to build libc like the following, but it fails: [...] $ cd /usr/src $ make buildenv done inside the buildenv, run: $ make -C lib/libc -j$(nproc) Unfortunately, here it breaks with: make -C lib/libc cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DNO__SCCSID -DNO__RCSID -I/usr/src/lib/libc/include -I/usr/src/include -I/usr/src/lib/libc/amd64 -DNLS -ftls-model=initial-exec -DCRT_IRELOC_RELA -DINIT_IRELOCS="init_cpu_features()" -I/usr/src/lib/libc/csu/amd64 -D__DBINTERFACE_PRIVATE -I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6 -I/usr/obj/usr/src/amd64.amd64/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libmd -I/usr/src/contrib/jemalloc/include -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DWANT_HYPERV -DYP -DNS_CACHING -DSYMBOL_VERSIONING -g -gz=zlib -MD -MF.depend.machdep_ldisx.o -MTmachdep_ldisx.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c /usr/src/lib/libc/gdtoa/machdep_ldisx.c -o machdep_ldisx.o /usr/src/lib/libc/gdtoa/machdep_ldisx.c:40:10: fatal error: 'sys/cdefs.h' file not found #include ^ 1 error generated. *** Error code 1 Stop. make[2]: stopped in /usr/src/lib/libc then exit the buildenv and run $ sudo make -C lib/libc install then buildworld as usual. DES Thanks for this description. Seems, that something more is odd here?
Re: 15.0-CURRENT build broken in lib/libmagic
Rainer Hurling writes: > After removing /usr/obj and 'make cleanworld', That was unnecessary. > I tried to build libc like the following, but it fails: > [...] $ cd /usr/src $ make buildenv inside the buildenv, run: $ make -C lib/libc -j$(nproc) then exit the buildenv and run $ sudo make -C lib/libc install then buildworld as usual. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: 15.0-CURRENT build broken in lib/libmagic
Am 09.09.23 um 19:04 schrieb Dag-Erling Smørgrav: Rainer Hurling writes: If I try to build world from todays c1b26df2972d with 15.0-CURRENT (main-n265063-e0752f431b01), it aborts with an error. Either update your source tree or apply aca3bd160257, then build and install libc before attempting buildworld. DES Hi Dag-Erling, Many thanks for your answer and the tip with libc! Source tree was updated already to c1b26df2972d, so aca3bd160257 is already included. I checked for its contents. After removing /usr/obj and 'make cleanworld', I tried to build libc like the following, but it fails: cd /usr/src/lib/libc make [..] building shared library libc.so.7 cc -nodefaultlibs -Wl,-zrelro -Wl,--version-script=Version.map -Wl,-znoexecstack -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 machdep_ldisx.pico libc_start1.pico bt_close.pico bt_conv.pico bt_debug.pico bt_delete.pico bt_get.pico bt_open.pico bt_overflow.pico bt_page.pico bt_put.pico bt_search.pico bt_seq.pico bt_split.pico bt_utils.pico db.pico hash.pico hash_bigkey.pico hash_buf.pico hash_func.pico hash_log2.pico hash_page.pico ndbm.pico mpool.pico mpool-compat.pico rec_close.pico rec_delete.pico rec_get.pico rec_open.pico rec_put.pico rec_search.pico rec_seq.pico rec_utils.pico creat.pico gethostid.pico getwd.pico killpg.pico sethostid.pico setpgrp.pico setrgid.pico setruid.pico sigcompat.pico __getosreldate.pico __pthread_mutex_init_calloc_cb_stub.pico __xuname.pico _once_stub.pico _pthread_stubs.pico _rand48.pico _spinlock_stub.pico _thread_init.pico alarm.pico arc4random.pico arc4random-compat.pico arc4random_uniform.pico assert.pico auxv.pico basename.pico basename_compat.pico cap_sandboxed.pico check_utility_compat.pico clock.pico clock_getcpuclockid.pico closedir.pico confstr.pico cpuset_alloc.pico cpuset_free.pico crypt.pico ctermid.pico daemon.pico devname.pico devname-compat11.pico dirfd.pico dirname.pico dirname_compat.pico disklabel.pico dlfcn.pico drand48.pico dup3.pico elf_utils.pico erand48.pico err.pico errlst.pico errno.pico eventfd.pico exec.pico exect.pico fdevname.pico feature_present.pico fmtcheck.pico fmtmsg.pico fnmatch.pico fpclassify.pico frexp.pico fstab.pico ftok.pico fts.pico fts-compat.pico fts-compat11.pico ftw.pico ftw-compat11.pico getbootfile.pico getbsize.pico getcap.pico getcwd.pico getdomainname.pico getentropy.pico getgrent.pico getgrouplist.pico gethostname.pico getloadavg.pico getlogin.pico getmntinfo.pico getmntinfo-compat11.pico getnetgrent.pico getosreldate.pico getpagesize.pico getpagesizes.pico getpeereid.pico getprogname.pico getpwent.pico getttyent.pico getusershell.pico getutxent.pico getvfsbyname.pico glob.pico glob-compat11.pico initgroups.pico isatty.pico isinf.pico isnan.pico jrand48.pico kqueue1.pico lcong48.pico libc_dlopen.pico lockf.pico lrand48.pico memalign.pico mrand48.pico nftw.pico nftw-compat11.pico nice.pico nlist.pico nrand48.pico opendir.pico pause.pico pmadvise.pico popen.pico posix_spawn.pico psignal.pico pututxline.pico pw_scan.pico raise.pico readdir.pico readdir-compat11.pico readpassphrase.pico recvmmsg.pico rewinddir.pico scandir.pico scandir_b.pico scandir-compat11.pico sched_getaffinity.pico sched_setaffinity.pico seed48.pico seekdir.pico semctl.pico sendmmsg.pico setdomainname.pico sethostname.pico setjmperr.pico setmode.pico setproctitle.pico setprogname.pico siginterrupt.pico siglist.pico signal.pico sigsetops.pico sleep.pico srand48.pico statvfs.pico stringlist.pico strtofflags.pico sysconf.pico sysctl.pico sysctlbyname.pico sysctlnametomib.pico syslog.pico telldir.pico termios.pico time.pico times.pico timespec_get.pico timespec_getres.pico timezone.pico tls.pico ttyname.pico ttyslot.pico ualarm.pico ulimit.pico uname.pico unvis-compat.pico usleep.pico utime.pico utxdb.pico valloc.pico wait.pico wait3.pico waitpid.pico waitid.pico wordexp.pico pwcache.pico unvis.pico vis.pico cancelpoints_sem.pico cancelpoints_sem_new.pico _setjmp.pico rfork_thread.pico setjmp.pico sigsetjmp.pico fabs.pico infinity.pico ldexp.pico makecontext.pico signalcontext.pico flt_rounds.pico fpgetmask.pico fpsetmask.pico fpgetprec.pico fpsetprec.pico fpgetround.pico fpsetround.pico fpgetsticky.pico gmon.pico mcount.pico citrus_bcs.pico citrus_bcs_strtol.pico citrus_bcs_strtoul.pico citrus_csmapper.pico citrus_db.pico citrus_db_factory.pico citrus_db_hash.pico citrus_esdb.pico citrus_hash.pico citrus_iconv.pico citrus_lookup.pico citrus_lookup_factory.pico citrus_mapper.pico citrus_memstream.pico citrus_mmap.pico citrus_module.pico citrus_none.pico citrus_pivot_factory.pico citrus_prop.pico citrus_stdenc.pico bsd_iconv.pico iconv_compat.pico inet_addr.pico inet_cidr_ntop.pico inet_cidr_pton.pico inet_lnaof.pico inet_makeaddr.pico inet_net_ntop.pico inet_net_pton.pico inet_neta.pico inet_netof.pico inet_network.pico inet_ntoa.pico inet_ntop.pico inet_pton.pico
Re: sed in CURRENT fails in textproc/jq
Antoine Brodin writes:
> Yuri writes:
> > Either something has changed in sed(1) in CURRENT, or sed just fails
> > during the configure stage of textproc/jq:
> >
> > sed: No error: 0
> > checking for sys/cygwin.h... eval: ${+...}: Bad substitution
> This seems to be a recent issue (less than 5 days).
> Hundreds of configure scripts now fail to run on 15-current due to
> this sed failure: [...]
Try adding ARCHLEVEL=scalar to CONFIGURE_ENV on one of these. If that
helps, yell at fuz@ :)
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Re: 15.0-CURRENT build broken in lib/libmagic
Rainer Hurling writes: > If I try to build world from todays c1b26df2972d with 15.0-CURRENT > (main-n265063-e0752f431b01), it aborts with an error. Either update your source tree or apply aca3bd160257, then build and install libc before attempting buildworld. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics
On Sep 8, 2023, at 21:54, Mark Millard wrote: > On Sep 8, 2023, at 18:19, Mark Millard wrote: > >> On Sep 8, 2023, at 17:03, Mark Millard wrote: >> >>> On Sep 8, 2023, at 15:30, Martin Matuska wrote: >>> I can confirm that the patch fixes the panic caused by the provided script on my test systems. Mark, would it be possible to try poudriere on your system with a patched kernel? >>> >>> . . . >>> >>> On 9. 9. 2023 0:09, Alexander Motin wrote: On 08.09.2023 09:52, Martin Matuska wrote: > . . . Thank you, Martin. I was able to reproduce the issue with your script and found the cause. I first though the issue is triggered by the `cp`, but it appeared to be triggered by `cat`. It also got copy_file_range() support, but later than `cp`. That is probably why it slipped through testing. This patch fixes it for me: https://github.com/openzfs/zfs/pull/15251 . Mark, could you please try the patch? >>> >>> If all goes well, this will end up reporting that the >>> poudriere bulk -a is still running but has gotten past, >>> say, 320+ port->package builds finished (so: more than >>> double observed so far for the panic context). Later >>> would be a report with a larger figure. A normal run >>> I might let go for 6000+ ports and 10 hr or so. >>> >>> Notes as I go . . . >>> >>> Patch applied, built, and installed to the test media. >>> Also, booted: >>> >>> # uname -apKU >>> FreeBSD amd64-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT amd64 150 #75 >>> main-n265228-c9315099f69e-dirty: Thu Sep 7 13:28:47 PDT 2023 >>> root@amd64-ZFS:/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG >>> amd64 amd64 150 150 >>> >>> Note that this is with a debug kernel (-dbg- in path and -DBG in >>> the GENERIC* name). Also, the vintage of what it is based on has: >>> >>> git: 969071be938c - main - vfs: copy_file_range() between multiple >>> mountpoints of the same fs type >>> >>> The usual sort of sequencing previously reported to get to this >>> point. Media update starts with the rewind to the checkpoint in >>> hopes of avoiding oddities from the later failure. >>> >>> . . . : >>> >>> [main-amd64-bulk_a-default] [2023-09-08_16h31m51s] [parallel_build:] >>> Queued: 34588 Built: 414 Failed: 0 Skipped: 39Ignored: 335 >>> Fetched: 0 Tobuild: 33800 Time: 00:30:41 >>> >>> >>> So 414 and and still building. >>> >>> More later. (It may be a while.) >>> >> >> [main-amd64-bulk_a-default] [2023-09-08_16h31m51s] [parallel_build:] Queued: >> 34588 Built: 2013 Failed: 2 Skipped: 179 Ignored: 335 Fetched: 0 >> Tobuild: 32059 Time: 01:42:47 >> >> and still going. (FYI: The failures are expected.) >> >> After a while I might stop it and start over with a non-debug >> kernel installed instead. > > I did ^C after 2.5 hr (with 2447 built): > > ^C[02:30:05] Error: Signal SIGINT caught, cleaning up and exiting > [main-amd64-bulk_a-default] [2023-09-08_16h31m51s] [sigint:] Queued: 34588 > Built: 2447 Failed: 5 Skipped: 226 Ignored: 335 Fetched: 0 > Tobuild: 31575 Time: 02:29:59 > [02:30:05] Logs: > /usr/local/poudriere/data/logs/bulk/main-amd64-bulk_a-default/2023-09-08_16h31m51s > [02:30:05] Cleaning up > [02:38:04] Unmounting file systems > Exiting with status 1 > > I'll switch it over to a non-debug kernel and, probably, world > and setup/run another test. > > . . . (time goes by) . . . > > Hmm. This did not get sent when I wrote the above. FYI, non-debug > test status: > > [main-amd64-bulk_a-default] [2023-09-08_19h51m52s] [parallel_build:] Queued: > 34588 Built: 2547 Failed: 5 Skipped: 239 Ignored: 335 Fetched: 0 > Tobuild: 31462 Time: 01:59:58 > > I may let it run overnight. I finally stopped it at 7473 built (a little over 13 hrs elapsed): ^C[13:08:30] Error: Signal SIGINT caught, cleaning up and exiting [main-amd64-bulk_a-default] [2023-09-08_19h51m52s] [sigint:] Queued: 34588 Built: 7473 Failed: 23Skipped: 798 Ignored: 335 Fetched: 0 Tobuild: 25959 Time: 13:08:26 [13:08:30] Logs: /usr/local/poudriere/data/logs/bulk/main-amd64-bulk_a-default/2023-09-08_19h51m52s [13:08:31] Cleaning up [13:17:10] Unmounting file systems Exiting with status 1 In part that was more evidence for deadlocks at least being fairly rare as well. None of the failed ones looked odd. (A fair portion are because the bulk -a was mostly doing WITH_DEBUG= builds. Many upstreams change library names, some other file names, or paths used for debug builds and ports generally do not cover well building the debug builds for such. I've used these runs to extend my list of exceptions that avoid using WITH_DEBUG .) So no evidence of corruptions. (I do not normally do bulk -a builds. The rare bulk -a runs are normally to check that my configuration of a builder machine still works reasonably --beyond building just the few hundred ports that I
15/14 upgrades break old sudo, maybe bump PAM's shlib?
I upgraded my laptop from a late June current to current from yesterday today, and after installworld sudo stopped working (dies with a SIGBUS). After some debugging, the issue ended up being OpenSSL library version mismatches as sudo uses PAM and PAM is linked agianst OpenSSL 3, but sudo is linked against OpenSSL 1.1.1. Both shlibs get mapped into the the process and at some point sudo crosses the streams and the crash occurs inside OpenSSL 3's libcrypto. I realize that we do have a generate note about needing to update third party packages after an upgrade, but I tend to use sudo as part of my workflow for doing that sort of thing. I generally build all my own packages via poudriere and use sudo at various points in that process, but even if I were using FreeBSD.org packages I would be using sudo to try to run 'pkg upgrade'. su(8) in base works fine, so that's my workaround for now on my laptop, but I wonder if we want to make this particular bump on the upgrade path a little less bumpy? Either by being clear in our release notes that tools like sudo (and I suspect any other third-party su wrappers that also use PAM, xscreensaver's screen lock doesn't seem to be affected since it probably doesn't use OpenSSL directly thankfully) can break, or another route we could take would be to bump the DSO versions of things that depend on libcrypto/libssl in base. We did not do this latter approach for the OpenSSL 1.0.2 -> 1.1.1 upgrade FWIW. If we wanted to do the shlib bump approach, Enji had a good list from a while back (though Enji wanted to make them all private rather than bumping): - kerberos - libarchive - libbsnmp - libfetch - libgeli - libldns - libmp - libradius - libunbound From my research it seems that PAM (library and modules), gssapi libraries, and libzfs would also need to be on the list. libldns is already private as is libunbound, though bumping them might be safter anyway. There is on libgeli, instead there is geli_eli.so which has no version, but hopefully is not widely used in ports the same as PAM. Note also that if we did this, we would want to do it for 14.0 as 13.x -> 14 upgrades are affected in the same way. -- John Baldwin
Re: user problems when upgrading to v15
On 9/2/23 7:11 AM, Dimitry Andric wrote: On 1 Sep 2023, at 03:42, brian whalen wrote: Repeating the entire process: I created a 13.2 vm with 6 cores and 8GB of ram. Ran freebsd-update fetch and install. Ran pkg install git bash ccache open-vm-tools-nox11 Used git clone to get current and ports source files. Edited /etc/make.conf to use ccache Ran make -j6 buildworld && make -j6 kernel I then rebooted in single user mode and did the next steps saving output to a file with > filename. etcupdate -p was pretty uneventful. It did show the below and did not prompt to edit. root@f15:~ # less etcupdatep C /etc/group C /etc/master.passwd This is a problem: the "C" characters mean there were conflicts, and it's indeed very unfortunate that etcupdate does not immediately force you to resolve them. Because now you basically have mangled group and master.passwd files, with conflict markers in them! No, the conflicted files are in /var/db/etcupdate/conflicts, the files in /etc are still the old ones at this point and won't be updated until you run 'etcupdate resolve' to fix them. I suspect what happened here is that Brian chose the 'tf' (theirs-full) option for 'etcupdate resolve' when he really wanted to do 'e' to edit the conflicted version. Immediately after this, you should run "etcupdate resolve", and fix any conflicts that it has found. Note that recently there was a lot of churn due to the removal of $FreeBSD$ keywords, and this almost always creates conflicts in the group and passwd files. For lots of other files in /etc, the conflicts are resolved automatically, but unfortunately not for the files that are essential to log in! make installworld seemed mostly error free though I did see a nonzero status for a man page failed inn the man4 directory. etcupdate -B only showed the below. This was my first build after install. root@f15:~ # less etcupdateB Conflicts remain from previous update, aborting. Yes, that is indeed the problem. You must first resolve conflicts from any previous etcupdate run, before doing anything else. As to why it does not immediately forces you to do so, and delegates this to a separate step, which can easily be forgotten, I have no idea. So that if you are doing scripted upgrades, you don't hang forever in a script. The intention is that after doing a bunch of scripted installworld + etcupdate's on various hosts you can use 'etcupdate status' to see if there are any remaining steps requiring manual intervention. There could be an option to request batched vs interactivate updates perhaps. If I type exit in single user mode to go multi user mode, the local user still works. After a reboot the local user still works. This local user can also sudo as expected. This wasn't the case for the previous build when I first reported this. However, if I run etcupdate resolve it is still presenting /etc/group and /etc/master/passwd as problems. If this is is expected behavior for current then no big deal. I just wasn't sure. The conflicts themselves are expected, alas. But you _must_ resolve them, otherwise you can end up with a mostly-bricked system. No, the conflict markers are not placed in the versions in /etc. However, etucpdate does refuse to do a "new" upgrade until you resolve all the conflicts from your previous upgrade to ensure that conflicted upgrades aren't missed. -- John Baldwin
Re: 15.0-CURRENT build broken in lib/libmagic
Just an update. This also happens in Poudriere, when I try to update my jails for 13.2, 14.0 and 15.0-CURRENT. It seems, that my installed version of 15.0-CURRENT (main-n265063-e0752f431b01) is the culprit :( Am 09.09.23 um 13:52 schrieb Rainer Hurling: If I try to build world from todays c1b26df2972d with 15.0-CURRENT (main-n265063-e0752f431b01), it aborts with an error. Seems it is not able to handle line 4979 of the magic file (Microsoft Advanced Streaming Format ASF): ===> lib/libmagic (all) echo libmagic.so.4: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libz.a >> .depend cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.apprentice.o -MTapprentice.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments -c /usr/src/contrib/file/src/apprentice.c -o apprentice.o cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.apptype.o -MTapptype.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments -c /usr/src/contrib/file/src/apptype.c -o apptype.o cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.ascmagic.o -MTascmagic.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments -c /usr/src/contrib/file/src/ascmagic.c -o ascmagic.o cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.buffer.o -MTbuffer.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments -c /usr/src/contrib/file/src/buffer.c -o buffer.o cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.cdf.o -MTcdf.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
15.0-CURRENT build broken in lib/libmagic
If I try to build world from todays c1b26df2972d with 15.0-CURRENT (main-n265063-e0752f431b01), it aborts with an error. Seems it is not able to handle line 4979 of the magic file (Microsoft Advanced Streaming Format ASF): ===> lib/libmagic (all) echo libmagic.so.4: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libz.a >> .depend cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.apprentice.o -MTapprentice.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments-c /usr/src/contrib/file/src/apprentice.c -o apprentice.o cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.apptype.o -MTapptype.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments-c /usr/src/contrib/file/src/apptype.c -o apptype.o cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.ascmagic.o -MTascmagic.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments-c /usr/src/contrib/file/src/ascmagic.c -o ascmagic.o cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.buffer.o -MTbuffer.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments-c /usr/src/contrib/file/src/buffer.c -o buffer.o cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H -I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic -I/usr/src/contrib/file/src -MD -MF.depend.cdf.o -MTcdf.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments-c /usr/src/contrib/file/src/cdf.c -o cdf.o cc -target
Re: Acer C720 Chromebook Cypress Trackpad
Please don't use what I said in my yesterday posting (attached below only as reference). Loading the kmod chromebook_platform.ko makes the mouse pointer jumping without any reason back and for to other places when Xorg is running. I observed and do use now: - the cyapa EVDEV patches from December 2020, I've got from Vladimir at that time, are in head; - I use in ~/.xinitrc: device="Cypress APA I2C Trackpad" xinput set-prop "$device" "libinput Tapping Enabled" 1 xinput set-prop "$device" "libinput Natural Scrolling Enabled" 1 xinput set-prop "$device" "libinput Middle Emulation Enabled" 0 and in /etc/sysctl.conf # Cypress Trackpad: kern.evdev.rcpt_mask=3 debug.cyapa_enable_tapclick=3 debug.cyapa_tapclick_max_ticks=20 This gives the Trackpad working as described in cyapa(4), esp. with this layout for taps (not clicks!): Trackpad layout 2/3 1/3 +++ || Middle | || Button | | Left || | Button++ || Right| || Button | ++| | Thumb/Button Area | 15% +-+ In the past (December 2020) exactly this configuration gave another layout: ++ || | main area | || || ++ | button1 | button2 | button3 | ~10mm in high ++ which also was in sync with the freedesktop.org documentation: https://wayland.freedesktop.org/libinput/doc/latest/clickpad-softbuttons.html Why this has changed? And is there any chance to get the old layout back, as I'm used to it :-) Thanks matthias El día viernes, septiembre 08, 2023 a las 11:35:40a. m. +0200, Matthias Apitz escribió: > > It seems that something has changed in cyapa.ko how the (not existing) > three buttons of the trackpad are emulated. In FreeBSD 13.0-CURRENT r368166 > I used only the cyapa.ko module and some xinput commands in .xinitrc > to get button1, button2 and button3 as shown in the small "grafic" > below. This was not working anymore and it took me some hours of > testing, until I got it working again with loading the additional kmod > chromebook_platform.ko. Now the three buttons are there as expected. > > I add this here if someone runs into the same problem (or if someone has > comments on this): > > ... -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: sed in CURRENT fails in textproc/jq
On Sat, Sep 9, 2023 at 6:47 AM Yuri wrote:
>
> Either something has changed in sed(1) in CURRENT, or sed just fails
> during the configure stage of textproc/jq:
>
> sed: No error: 0
> checking for sys/cygwin.h... eval: ${+...}: Bad substitution
>
>
> See the log:
> https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/peb032111a352_s9c80d66ec1/logs/jq-1.7.log
This seems to be a recent issue (less than 5 days).
Hundreds of configure scripts now fail to run on 15-current due to
this sed failure:
https://pkg-status.freebsd.org/gohan03/data/main-amd64-default-baseline/peb032111a352_s9c80d66ec1/logs/errors/readline-8.2.1.log
https://pkg-status.freebsd.org/gohan03/data/main-amd64-default-baseline/peb032111a352_s9c80d66ec1/logs/errors/expat-2.5.0.log
https://pkg-status.freebsd.org/gohan03/data/main-amd64-default-baseline/peb032111a352_s9c80d66ec1/logs/errors/libedit-3.1.20221030,1.log
etc.
Antoine
sed in CURRENT fails in textproc/jq
Either something has changed in sed(1) in CURRENT, or sed just fails
during the configure stage of textproc/jq:
sed: No error: 0
checking for sys/cygwin.h... eval: ${+...}: Bad substitution
See the log:
https://pkg-status.freebsd.org/beefy18/data/main-amd64-default/peb032111a352_s9c80d66ec1/logs/jq-1.7.log
Yuri
Re: git: ed03cfc5d231 - main - textproc/jq: Add USES=bison; Use gsed to fix configuration failure on 15
On Sat, Sep 9, 2023 at 6:05 AM Yuri Victorovich wrote: > > The branch main has been updated by yuri: > > URL: > https://cgit.FreeBSD.org/ports/commit/?id=ed03cfc5d231cad6ad16febfb3c1c7da411908d1 > > commit ed03cfc5d231cad6ad16febfb3c1c7da411908d1 > Author: Yuri Victorovich > AuthorDate: 2023-09-09 06:04:00 + > Commit: Yuri Victorovich > CommitDate: 2023-09-09 06:05:11 + > > textproc/jq: Add USES=bison; Use gsed to fix configuration failure on 15 > --- Hello, This is not the correct fix. Please report this bug to the FreeBSD Current mailing list. Antoine
