Re: Problems building 11-stable/i386 with readonly /usr/src
On 2/18/18 1:12 AM, Peter Jeremy wrote: > Sometime between r329122 and r329157, my 11-stable i386 box stopped > being able to buildworld with a readonly /usr/src. I've been updating > regularly but the problem still remains at r329450. I don't have any > problems building the same tree on amd64 or building head on i386 or > amd64. Does anyone have any ideas? > > Starting from an empty /usr/obj, the failure is: > ... >>>> stage 4.3: building everything > ... > ===> stand/zfs (all) > Building /usr/obj/usr/src/stand/zfs/machine > machine -> /usr/src/sys/i386/include > Building /usr/obj/usr/src/stand/zfs/x86 > x86 -> /usr/src/sys/x86/include > Building /usr/obj/usr/src/stand/zfs/zfs.o > Building /usr/obj/usr/src/stand/zfs/skein.o > Building /usr/obj/usr/src/stand/zfs/skein_block.o > Building /usr/obj/usr/src/stand/zfs/libzfsboot.a > building static zfsboot library > ===> stand/efi (all) > machine -> /usr/src/sys/i386/include > ln: machine: Read-only file system > *** Error code 1 > > Stop. > make[4]: stopped in /usr/src/stand/efi > .ERROR_TARGET='machine' > .ERROR_META_FILE='' > .MAKE.LEVEL='4' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='.PHONY' > .CURDIR='/usr/src/stand/efi' > .MAKE='make' > .OBJDIR='/usr/src/stand/efi' It's wanting to use .OBJDIR=.CURDIR. I'm thinking this is due to the bsd.init.mk abuse in stand/. I say "abuse" because bsd.init.mk has this comment and I've only been writing my logic with the assumption that the comment is valid, which I know Warner disagrees with. > # The include file includes , > # ../Makefile.inc and ; this is used at the > # top of all <bsd.*.mk> files that actually "build something" I'll try to get a fix in later today or tomorrow. > .TARGETS='all' > DESTDIR='/usr/obj/usr/src/tmp' > LD_LIBRARY_PATH='' > MACHINE='i386' > MACHINE_ARCH='i386' > MAKEOBJDIRPREFIX='/usr/obj' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20170720' > 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/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 /etc/make.conf /usr/src/share/mk/local.sys.mk > /usr/src/share/mk/src.sys.mk Makefile /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/stand/efi/../Makefile.inc /usr/src/stand/efi/../defs.mk > /usr/src/share/mk/src.opts.mk /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.subdir.mk' > .PATH='. /usr/src/stand/efi' > *** Error code 1 > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
FYI about native-xtools / Poudriere jail -x change in head
The latest FreeBSD head's native-xtools support (jail -x) requires poudriere-devel-3.1.99.20171028 or poudriere-3.1.22 after r325082. Otherwise it will build but not install. Also with the new Poudriere and latest head native-xtools no longer requires a /usr/src checkout but uses the jails own source after r325001. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Use of env SRC_ENV_CONF=. . . for buildworld does not override/avoid use of /etc/src.conf : Intentional?
On 11/3/2016 5:28 PM, Mark Millard wrote: > I just had a case of "odd" command text in a buildworld that was based on (in > part) env SRC_ENV_CONF=. . . > > env __MAKE_CONF=. . . does not get the kind of behavior reported below for > /etc/src.conf . > > Overall this means that even with an explicit env SRC_ENV_CONF=. . . one must > separately prevent /etc/src.conf from contributing if the SRC_ENV_CONF file > is intended to cover everything. SRC_ENV_CONF is kind of a special hack to allow setting some specific values that feasibly can't be set later. Just stick to src.conf unless you need to set one of the options that requires src-env.conf. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: libmap32.conf on stable/11
On 9/1/2016 3:51 AM, Slawa Olhovchenkov wrote: > libmap32.conf missing on 11.0-STABLE. It's no longer needed in the default install after r282420, it was removed in r282421. > still present in `man libmap.conf` It's still a valid file. > etcupdate remove existing libmap32.conf This should not happen if the file has user modifications in it. If it is just this then it is fine to remove: > # $FreeBSD: head/etc/libmap32.conf 255413 2013-09-09 06:02:30Z des $ > /usr/lib/private/usr/lib32/private Did you have modifications in it? -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: 11.0-RELEASE status update
On 9/1/2016 2:13 PM, Slawa Olhovchenkov wrote: > On Thu, Sep 01, 2016 at 09:10:00PM +, Glen Barber wrote: > >> As some of you may be aware, a few last-minute showstoppers appeared >> since 11.0-RC1 (and before RC1). >> >> One of the showstoppers has been fixed in 12-CURRENT, and merged to >> stable/11 and releng/11.0 that affected booting from large volumes: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212139 >> >> There is one issue that is still being investigated, which we are >> classifying as an EN candidate, given the manifestations of the issue >> and reproducibility: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212168 >> >> There is one blocker before 11.0-RELEASE, that affects libarchive, which >> we are waiting for feedback. Once feedback is received, the schedule >> for 11.0-RELEASE will be updated on the website to reflect reality. >> >> There are a few post-release EN items on our watch list as well, so if >> something was not mentioned here, that does not mean it will not be >> fixed in 11.0-RELEASE. >> >> Apologies for the delay, and as always, thank you for your patience. >> >> Glen >> On behalf of:re@ >> > > > Do you planed to fix issuse with missied and delete libmap32.conf? > This was done intentionally quite a while ago: https://svnweb.freebsd.org/base?view=revision=282421 Though it was later removed from ObsoleteFiles so 'make delete-old' would not remove it from users' systems in r282423. etcupdate removing it is the problem really being reported here. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Error compiling stable/11 from stable/10
On 8/26/2016 6:38 AM, Matt Smith wrote: > Hi, I'm attempting to compile the latest stable/11 from a 12 day old > stable/10 system and I'm getting the following error. I've tried > completely deleting /usr/obj. I've tried without make -j. And I've tried > commenting out options from src.conf and make.conf and nothing seems to > make any difference. Any ideas? I haven't tried it yet but I'm wondering > if I should do RC2 before stable/11. > > In file included from > /usr/src/lib/liblzma/../../contrib/xz/src/liblzma/lz/lz_encoder.c: > 23: > /usr/src/lib/liblzma/../../contrib/xz/src/liblzma/common/memcmplen.h:19:11: > fatal error: > > 'immintrin.h' file not found > # include > ^ > 1 error generated. > *** Error code 1 > > Stop. > bmake[4]: stopped in /usr/src/lib/liblzma > > > Can you provide a full log of buildworld somewhere for me to look at? What's in your make.conf and src.conf? -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: NanoBSD install phase failing for releng/11
On 8/24/2016 10:46 AM, Bryan Drewery wrote: > On 8/24/16 7:55 AM, Bryan Drewery wrote: >> On 8/22/2016 4:08 AM, Guido Falsi wrote: >>> Hi, >>> >>> While building a NanoBSD image using releng/11 sources I got this error >>> message: >>> >>> ===> lib/libc++ (install) >>> install -C -o root -g wheel -m 444 libc++.a >>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/ >>> install -s -o root -g wheel -m 444 libc++.so.1 >>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/ >>> install -S -C -o root -g wheel -m 444 libc++.ld >>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libc++.so >>> ===> lib/libcxxrt (install) >>> install -C -o root -g wheel -m 444 libcxxrt.a >>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/ >>> install -s -o root -g wheel -m 444 libcxxrt.so.1 >>> /usr/local/nanobsd/rr-trunk/obj/_.w/lib/ >>> install -l rs /usr/local/nanobsd/rr-trunk/obj/_.w/lib/libcxxrt.so.1 >>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libcxxrt.so >>> install: symlink ../../lib/libcxxrt.so.1 -> >>> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib: File exists >>> *** Error code 71 >>> >>> Stop. >>> >>> I'm not sure what's happening, I already tried reverting locally >>> r301880, thinking it could be related, but this changed nothing. >>> >>> Anyone has some insight? It was working fine up to August 4th. >>> >>> Thanks in advance to anyone giving me some hint! >>> >> >> Is this still reproducible for anyone? I have theories but need it in >> its broken state to debug it further. >> > > I've created a trivial reproducibility on it and am working on a fix. > So far it appears to be purely an issue in head with dirname(3) compat. > This is fixed in head r304860 by ed@. It requires updating the host. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: NanoBSD install phase failing for releng/11
On 8/24/16 7:55 AM, Bryan Drewery wrote: > On 8/22/2016 4:08 AM, Guido Falsi wrote: >> Hi, >> >> While building a NanoBSD image using releng/11 sources I got this error >> message: >> >> ===> lib/libc++ (install) >> install -C -o root -g wheel -m 444 libc++.a >> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/ >> install -s -o root -g wheel -m 444 libc++.so.1 >> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/ >> install -S -C -o root -g wheel -m 444 libc++.ld >> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libc++.so >> ===> lib/libcxxrt (install) >> install -C -o root -g wheel -m 444 libcxxrt.a >> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/ >> install -s -o root -g wheel -m 444 libcxxrt.so.1 >> /usr/local/nanobsd/rr-trunk/obj/_.w/lib/ >> install -l rs /usr/local/nanobsd/rr-trunk/obj/_.w/lib/libcxxrt.so.1 >> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libcxxrt.so >> install: symlink ../../lib/libcxxrt.so.1 -> >> /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib: File exists >> *** Error code 71 >> >> Stop. >> >> I'm not sure what's happening, I already tried reverting locally >> r301880, thinking it could be related, but this changed nothing. >> >> Anyone has some insight? It was working fine up to August 4th. >> >> Thanks in advance to anyone giving me some hint! >> > > Is this still reproducible for anyone? I have theories but need it in > its broken state to debug it further. > I've created a trivial reproducibility on it and am working on a fix. So far it appears to be purely an issue in head with dirname(3) compat. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: NanoBSD install phase failing for releng/11
On 8/22/2016 4:08 AM, Guido Falsi wrote: > Hi, > > While building a NanoBSD image using releng/11 sources I got this error > message: > > ===> lib/libc++ (install) > install -C -o root -g wheel -m 444 libc++.a > /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/ > install -s -o root -g wheel -m 444 libc++.so.1 > /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/ > install -S -C -o root -g wheel -m 444 libc++.ld > /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libc++.so > ===> lib/libcxxrt (install) > install -C -o root -g wheel -m 444 libcxxrt.a > /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/ > install -s -o root -g wheel -m 444 libcxxrt.so.1 > /usr/local/nanobsd/rr-trunk/obj/_.w/lib/ > install -l rs /usr/local/nanobsd/rr-trunk/obj/_.w/lib/libcxxrt.so.1 > /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib/libcxxrt.so > install: symlink ../../lib/libcxxrt.so.1 -> > /usr/local/nanobsd/rr-trunk/obj/_.w/usr/lib: File exists > *** Error code 71 > > Stop. > > I'm not sure what's happening, I already tried reverting locally > r301880, thinking it could be related, but this changed nothing. > > Anyone has some insight? It was working fine up to August 4th. > > Thanks in advance to anyone giving me some hint! > Is this still reproducible for anyone? I have theories but need it in its broken state to debug it further. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode
+*/ > + if ((ifp->if_flags & IFF_UP) == 0 && > + !IEEE80211_ADDR_EQ(vap->iv_myaddr, > IF_LLADDR(ifp))) > + IEEE80211_ADDR_COPY(vap->iv_myaddr, > + IF_LLADDR(ifp)); > + } > break; > case SIOCADDMULTI: > case SIOCDELMULTI: > #9 0x80b9811c in ifioctl (so=, > cmd=, data=, > td=) at /usr/src/sys/net/if.c:2447 > #10 0x80afc914 in kern_ioctl (td=, > fd=, com=2149607696, data=0xfe060bc958e0 "wlan0") > at file.h:327 > #11 0x80afc5d1 in sys_ioctl (td=, > uap=0xfe060bc95a40) at /usr/src/sys/kern/sys_generic.c:743 > #12 0x80eeb6c9 in amd64_syscall (td=, > traced=) at subr_syscall.c:135 > #13 0x80ece3bb in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:396 > #14 0x0008015c448a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > This was on my laptop, which I'm actively using at work as I type > -- though it's now connected via wired NIC (em0). I had experienced > no trouble with wlan0 at home (before coming in to work) or on the > bus (en route to work). (I didn't attempt it while cycling to the > bus stop. :-}) > > Also, I had no issues running stable/11 (amd64) @303870 -- either > at home or at work -- yesterday. On the other hand, this is (so > far) a one-off, so alleging a "pattern" at this point is not something > I'm willing to do. > > Peace, > david > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: make buildworld Failure on 10-STABLE and WITHOUT_OPENSSL=TRUE
On 2/6/2016 6:21 AM, Jim Ohlstein wrote: > Hello, > > First noticed: > > root@rubicon:/usr/src # svn info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 295341 > Node Kind: directory > Schedule: normal > Last Changed Author: marius > Last Changed Rev: 295289 > Last Changed Date: 2016-02-04 19:14:24 -0500 (Thu, 04 Feb 2016) > > > Still present: > > root@rubicon:/usr/src # svn info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 295351 > Node Kind: directory > Schedule: normal > Last Changed Author: wblock > Last Changed Rev: 295350 > Last Changed Date: 2016-02-06 09:03:31 -0500 (Sat, 06 Feb 2016) > > > root@rubicon:/usr/src # make clean && make buildworld > > > [snip] > > > > cc -O2 -pipe -I. -DINET6 -DFTP_COMBINE_CWDS -std=iso9899:1999 > -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c > /usr/src/lib/libfetch/common.c -o common.o > /usr/src/lib/libfetch/common.c:811:43: error: unused parameter 'URL' > [-Werror,-Wunused-parameter] > fetch_ssl(conn_t *conn, const struct url *URL, int verbose) > ^ Try this patch please: https://people.freebsd.org/~bdrewery/patches/libfetch-unused-ssl.patch -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: 10.3-BETA2 Buildworld issue
On 2/19/2016 10:42 AM, dweimer wrote:
>
> In my testing of 10.3-BETA2, I have discovered that the buildworld is
> failing on libc/posix1e/acl_support_nfs4.c on my mail server jail.
> Anyone have any ideas as to what's causing the issue?
>
> /jails/devel/ROOT/usr/src/lib/libc/posix1e/acl_support_nfs4.c:51:8:
> error: use of undeclared identifier 'ACL_ENTRY_INHERITED'
> { ACL_ENTRY_INHERITED, "inherited", 'I' },
>^
That is defined in sys/sys/acl.h. It all seems fine to me.
Check in your OBJDIR for a tmp/usr/include/sys/acl.h file and see if it
has ACL_ENTRY_INHERITED defined.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: FYI: "make -DNO_CLEAN buildworld" failed (stable/10 @r294657 -> r294721)
o-pointer-sign -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter > -Wno-parentheses -L/usr/obj/usr/src/tmp/usr/lib/private -rpath > /usr/lib/private -o scp scp.o roaming_dummy.o -lssh -lcrypt > -lcrypto -lz --- usr.bin.all__D --- --- all_subdir_xz --- --- > secure.all__D --- --- all_subdir_libexec --- --- > all_subdir_sftp-server --- > /usr/obj/usr/src/tmp/usr/lib/private/libssh.so: undefined reference > to `crypto_scalarmult_curve25519' Should be fixed once I MFC r294370. - -- Regards, Bryan Drewery -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWplvuAAoJEDXXcbtuRpfP8TUIANCQORwUNnoIqDgbry8x8HVB XyvFe7rgEQ7nLZVgKQBrjKvMGOM/u4PUoO+DLY3e6isIy2Dyvm+yDLRlkaE1I5bG eRGTSzVxm/si59Ff3ziR2tZ6MVINI/Bas5E6Ix0xflT5K9LU1raIwrfxOtw47t0v 3LZJmLFr+5X+KvZ163TJ9294Oax5AhAXcTu2y6ZOzqwqmG4ocz4LziCzfmiT2H76 enR1rgktn9T3KkwlwRUQlf+/RT8V/rQGgJmX3OOWPKfUSZ30DL53DJXthVQr3p5w hRBAi9DBtX9FTFhT+JY+4B/Fg6nO7ZRPqRkkhAfkwf8OoHa/MBXfbZlZR9FR7K4= =I8gW -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bmake[1]: don't know how to make _bootstrap-tools-usr.bin/m4. Stop
On 1/15/16 9:04 AM, Slawa Olhovchenkov wrote:
> On Fri, Jan 08, 2016 at 01:01:45PM -0800, Bryan Drewery wrote:
>
>> On 1/8/2016 12:58 PM, Bryan Drewery wrote:
>>> On 12/23/2015 11:52 PM, Slawa Olhovchenkov wrote:
>>>> I am try to upgrade very old 10-CURRENT to latest 10-STABLE and got
>>>> next error:
>>>>
>>>> ===> usr.bin/yacc (obj,depend,all,install)
>>>> bmake[1]: don't know how to make _bootstrap-tools-usr.bin/m4. Stop
>>>>
>>>> bmake[1]: stopped in /usr/src
>>>> *** Error code 2
>>>>
>>>> Stop.
>>>> bmake: stopped in /usr/src
>>>> *** [buildworld] Error code 1
>>>>
>>>> Stop in /usr/src.
>>>
>>> It's a bug in the build for sure.
>>>
>>> .if ${BOOTSTRAPPING} < 102
>>> _m4=usr.bin/m4
>>> .endif
>>>
>>> .if ${BOOTSTRAPPING} < 133
>>> _lex= usr.bin/lex
>>>
>>> ${_bt}-usr.bin/lex: ${_bt}-usr.bin/m4
>>> .endif
>>>
>>> Upgrading from 102-132 to latest will not build usr.bin/m4 even
>>> though usr.bin/lex is claiming to need it.
>>>
>>> https://people.freebsd.org/~bdrewery/patches/stable-10-lex-m4.diff
>>> should fix it. It's not necessarily the final fix though but it should
>>> let you build for now.
>>>
>>
>> Actually that patch won't suffice according to the change that added the
>> bug:
>>
>> r288829 | ian | 2015-10-05 10:45:13 -0700 (Mon, 05 Oct 2015) | 13 lines
>>
>> The latest version of lex requires the latest m4 to build, add a dependency
>> when running the build-tools stage.
>>
>> The requirement is due to the -P flag used when running m4 from usr.bin/lex
>
> STABLE now in build process, thanks!
> Because this is VIA C3 with 192MB PC133 RAM after day build only
> install includes passed :)
>
FYI, I committed a patch to stable/10 recently. No custom patch is
needed now.
--
Regards,
Bryan Drewery
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: A recent 10.2-STABLE no longer builds on a no-exec /usr/src file system
Where / What is the error? The only example here was fixed in November. On 1/14/2016 7:42 AM, Mark Martinec wrote: > Prompted by recent security advisories I did a 'make buildworld' > on a fresh svn checkout, only to find out that it seems the 'exec' > mount flag on /usr/src is still required for a successful build. > > This wasn't so for 10.2, and I hope it won't become a requirement > in 10.3 - or at least it should be clearly documented in release notes. > > Mark > > > On 2015-12-07 16:35, Mark Martinec wrote: >> So, is this a new state of affairs that /usr/src file system >> needs to be mounted exec in order for buildworld to succeed, >> or is this an unintended change and I should file a bug report? >> >> Mark >> >> >> On 2015-11-26 19:44, Miroslav Lachman wrote: >>> Mark Martinec wrote on 11/26/2015 19:31: >>>> Up to about a week ago building world on FreeBSD 10.2-STABLE went >>>> just fine. Today after svn update the build fails: >>>> >>>> >>>> # make buildworld >>>> [...] >>>> >>>> CC='cc ' mkdep -f .depend.getprotoent_test -a >>>> -I/usr/src/lib/libc/tests/net -I/usr/src/lib/libnetbsd >>>> -I/usr/src/contrib/netbsd-tests -std=gnu99 >>>> /usr/src/contrib/netbsd-tests/lib/libc/net/t_getprotoent.c >>>> echo getprotoent_test: /usr/obj/usr/src/tmp/usr/lib/libc.a >>>> /usr/obj/usr/src/tmp/usr/lib/private/libatf-c.a >> >>>> .depend.getprotoent_test >>>> (cd /usr/src/lib/libc/tests/net && make -f >>>> /usr/src/lib/libc/tests/net/Makefile _RECURSING_PROGS= SUBDIR= >>>> PROG=ether_aton_test DEPENDFILE=.depend.ether_aton_test >>>> .MAKE.DEPENDFILE=.depend.ether_aton_test depend) >>>> /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr >>>> /usr/src/sys/net/if_ethersubr.c aton_ether_subr.c >>>> make[7]: >>>> exec(/usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr) >>>> failed (Permission denied) >>>> *** Error code 1 >>>> >>>> Stop. >>>> make[7]: stopped in /usr/src/lib/libc/tests/net >>>> *** Error code 1 >>>> >>>> >>>> It turns out that our file system /usr/src had an "exec" flag >>>> turned off, so now running a command: >>>>/usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr >>>> fails with "Permission denied". >>>> >>>> It would be valuable if building a system on an exec-protected >>>> src file system would continue to be possible. >>>> >>>> Not sure if the >>>> /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr >>>> is the only such new command breaking the build. Anyway, a simple >>>> workaround is to run shell from a command line instead of as a >>>> shebang, i.e.: >>>> >>>> # /bin/sh /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr >>>> >>>> instead of: >>>> >>>># /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr >>> >>> I was puzzled by similar thing years ago. I was using /var/db and /tmp >>> mounted with noexec. And then there was some changes. Ports need >>> /var/db with exec because of some script in /var/db/pkg and /tmp must >>> have exec too for buildworld or installworld (I don't remember it >>> well, now I always do mount -u -o current,exec /tmp before build + >>> install world and kernel) >>> >>> Anyway - it would be better to not have these partitions mounted with >>> exec. >>> -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: bmake[1]: don't know how to make _bootstrap-tools-usr.bin/m4. Stop
On 12/23/2015 11:52 PM, Slawa Olhovchenkov wrote:
> I am try to upgrade very old 10-CURRENT to latest 10-STABLE and got
> next error:
>
> ===> usr.bin/yacc (obj,depend,all,install)
> bmake[1]: don't know how to make _bootstrap-tools-usr.bin/m4. Stop
>
> bmake[1]: stopped in /usr/src
> *** Error code 2
>
> Stop.
> bmake: stopped in /usr/src
> *** [buildworld] Error code 1
>
> Stop in /usr/src.
It's a bug in the build for sure.
.if ${BOOTSTRAPPING} < 102
_m4=usr.bin/m4
.endif
.if ${BOOTSTRAPPING} < 133
_lex= usr.bin/lex
${_bt}-usr.bin/lex: ${_bt}-usr.bin/m4
.endif
Upgrading from 102-132 to latest will not build usr.bin/m4 even
though usr.bin/lex is claiming to need it.
https://people.freebsd.org/~bdrewery/patches/stable-10-lex-m4.diff
should fix it. It's not necessarily the final fix though but it should
let you build for now.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: bmake[1]: don't know how to make _bootstrap-tools-usr.bin/m4. Stop
On 1/8/2016 12:58 PM, Bryan Drewery wrote:
> On 12/23/2015 11:52 PM, Slawa Olhovchenkov wrote:
>> I am try to upgrade very old 10-CURRENT to latest 10-STABLE and got
>> next error:
>>
>> ===> usr.bin/yacc (obj,depend,all,install)
>> bmake[1]: don't know how to make _bootstrap-tools-usr.bin/m4. Stop
>>
>> bmake[1]: stopped in /usr/src
>> *** Error code 2
>>
>> Stop.
>> bmake: stopped in /usr/src
>> *** [buildworld] Error code 1
>>
>> Stop in /usr/src.
>
> It's a bug in the build for sure.
>
> .if ${BOOTSTRAPPING} < 102
> _m4=usr.bin/m4
> .endif
>
> .if ${BOOTSTRAPPING} < 133
> _lex= usr.bin/lex
>
> ${_bt}-usr.bin/lex: ${_bt}-usr.bin/m4
> .endif
>
> Upgrading from 102-132 to latest will not build usr.bin/m4 even
> though usr.bin/lex is claiming to need it.
>
> https://people.freebsd.org/~bdrewery/patches/stable-10-lex-m4.diff
> should fix it. It's not necessarily the final fix though but it should
> let you build for now.
>
Actually that patch won't suffice according to the change that added the
bug:
r288829 | ian | 2015-10-05 10:45:13 -0700 (Mon, 05 Oct 2015) | 13 lines
The latest version of lex requires the latest m4 to build, add a dependency
when running the build-tools stage.
The requirement is due to the -P flag used when running m4 from usr.bin/lex
---
This one should work:
https://people.freebsd.org/~bdrewery/patches/stable-10-lex-m4-2.diff
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: 10.2-RELEASE-p2 lost ability to bootstrap pkg with signature_type="pubkey"
On 9/9/15 12:14 AM, Marko Cupać wrote: > On Tue, 8 Sep 2015 23:28:59 +0200 > Baptiste Daroussin <b...@freebsd.org> wrote: > >> On Tue, Sep 08, 2015 at 12:38:38PM +0200, Marko Cupać wrote: >>> Hi, >>> >>> I just found out that 10.2-RELEASE-p2 lost ability to bootstrap pkg >>> with signature_type="pubkey". >>> >>> Quick search returns: >>> https://github.com/freebsd/pkg/issues/1309 >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202622 >>> >>> I guess it is not hard to switch repo to fingerprints, however I >>> would not expect to lose this functionality by updating to >>> patchlevel. >>> >> Implemented in head: r287579 I will MFC it asap. And see if it cannot >> be added asap to a next patchlevel update. >> >> Best regards, >> Bapt > > Thanx! > > Just a few quick not-completely-related questions: poudriere has the > ability to sign repos with PKG_REPO_SIGNING_KEY, but not with external > command, right? Poudriere already has SIGNING_COMMAND support for external command. It is used for the fingerprints signing on pkg.FreeBSD.org. What is lacking is signing pkg with the new format added in r287579 when using pubkey. I am adding it in now for the next release. > Is there a plan to support it? Can I build packages in > poudriere without PKG_REPO_SIGNING_KEY, and sign repo later on with > external command? > > Regards, > -- Regards, Bryan Drewery ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 10.2-RELEASE-p2 lost ability to bootstrap pkg with signature_type="pubkey"
On 9/9/15 6:21 AM, Shawn Webb wrote:
> Is the signing_command option to `pkg repo` really only used in generating
> pkg.txz.sig? Is there any formal documentation about the cryptography design
> and architecture in relation to pkg's repositories?
No. It is used for all signing needs. Both the repo and pkg.txz.sig.
pkg repo:
JNETNAME="n" injail ${PKG_BIN} repo \
-o /tmp/packages ${PKG_META} /packages \
${SIGNING_COMMAND:+signing_command: ${SIGNING_COMMAND}}
pkg.txz.sig:
rm -f "${pkgfile}.sig"
sha256 -q "${pkgfile}" | ${SIGNING_COMMAND} > "${pkgfile}.sig"
--
Regards,
Bryan Drewery
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic: pmap active 0xfffff8001b7154b8
On 5/7/2015 7:08 AM, Johan Schuijt-Li wrote: Hi, We’ve been seeing (seemingly) random reboots on 10.1-RELEASE virtual machines (KVM virtualisation) on our production servers. In an attempt to determine what was causing this we’ve switched to running a kernel with INVARIANTS enabled. This resulted for us in the following panic: Unread portion of the kernel message buffer: panic: pmap active 0xf8001b7154b8 cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe03dd1493a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe03dd149450 vpanic() at vpanic+0x126/frame 0xfe03dd149490 kassert_panic() at kassert_panic+0x139/frame 0xfe03dd149500 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe03dd1495f0 exec_new_vmspace() at exec_new_vmspace+0x16a/frame 0xfe03dd149650 exec_elf64_imgact() at exec_elf64_imgact+0x658/frame 0xfe03dd149720 kern_execve() at kern_execve+0x5e4/frame 0xfe03dd149a80 sys_execve() at sys_execve+0x37/frame 0xfe03dd149ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe03dd149bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe03dd149bf0 --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x80158af1a, rsp = 0x7fffac38, rbp = 0x7fffad40 --- I’ve only come across one other report here (without result unfortunate): https://lists.freebsd.org/pipermail/freebsd-current/2014-June/050827.html https://lists.freebsd.org/pipermail/freebsd-current/2014-June/050827.html I looked around for the conclusion of that thread but could not find it. I was reproducing so often I'm sure this case was fixed. I may have privately contacted one of the VM maintainers to fix it. However lacking evidence I think it just stopped happening for me and I never reported anything useful. Are other people aware of this issue or working on this? I can provide access to a VM with a kernel dump and the kernel build for extra information if needed. What we really need is a full core dump (minidump) and backtrace. This will let us inspect the pmap state. https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: panic: pmap active 0xfffff8001b7154b8
On 5/7/2015 10:06 AM, Bryan Drewery wrote: On 5/7/2015 7:08 AM, Johan Schuijt-Li wrote: Hi, We’ve been seeing (seemingly) random reboots on 10.1-RELEASE virtual machines (KVM virtualisation) on our production servers. In an attempt to determine what was causing this we’ve switched to running a kernel with INVARIANTS enabled. This resulted for us in the following panic: Unread portion of the kernel message buffer: panic: pmap active 0xf8001b7154b8 cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe03dd1493a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe03dd149450 vpanic() at vpanic+0x126/frame 0xfe03dd149490 kassert_panic() at kassert_panic+0x139/frame 0xfe03dd149500 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe03dd1495f0 exec_new_vmspace() at exec_new_vmspace+0x16a/frame 0xfe03dd149650 exec_elf64_imgact() at exec_elf64_imgact+0x658/frame 0xfe03dd149720 kern_execve() at kern_execve+0x5e4/frame 0xfe03dd149a80 sys_execve() at sys_execve+0x37/frame 0xfe03dd149ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe03dd149bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe03dd149bf0 --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x80158af1a, rsp = 0x7fffac38, rbp = 0x7fffad40 --- I’ve only come across one other report here (without result unfortunate): https://lists.freebsd.org/pipermail/freebsd-current/2014-June/050827.html https://lists.freebsd.org/pipermail/freebsd-current/2014-June/050827.html I looked around for the conclusion of that thread but could not find it. Found it. https://svnweb.freebsd.org/base?view=revisionrevision=271000 This fix is in 10.1-RELEASE, so yours must be a little different. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Problem using mergemaster for 10-alpha
On Fri, Sep 20, 2013 at 03:38:17PM +0930, Shane Ambler wrote:
I have setup a few machines in the past from CD installer and my current
machine started with CD install and was then updated from source.
Currently my machine runs 9.1-RELEASE-p3
Yesterday I started to setup a clean 10.0 install onto a new drive that
I can boot from to test ports building with, but had trouble running
mergemaster to get the config files into place. I manually copied the
/etc files from /var/tmp/temproot to get the system running.
The steps I used are based on the handbook upgrade steps but I don't
see any variations to do a clean install from source (I created empty
src.conf and make.conf to prevent using my current files) -
setenv TOPDIR ~/Projects/f10-test
setenv TMPTESTROOT /mnt
setenv MAKEOBJDIRPREFIX ${TOPDIR}/obj
cd ${TOPDIR}
svn co svn://svn0.us-west.FreeBSD.org/base/head src
touch make.conf
touch src.conf
setenv __MAKE_CONF ${TOPDIR}/make.conf
setenv SRCCONF ${TOPDIR}/src.conf
cd ${TOPDIR}/src
make -j4 buildworld
make -j4 buildkernel
mount /dev/da4p3 ${TMPTESTROOT}
make installkernel DESTDIR=${TMPTESTROOT}
mergemaster -p -a -m ${TOPDIR}/src -D ${TMPTESTROOT}
make installworld DESTDIR=${TMPTESTROOT}
mergemaster -a -m ${TOPDIR}/src -D ${TMPTESTROOT}
When using mergemaster with -a I get the following error
*** Creating the temporary root environment in /var/tmp/temproot
*** /var/tmp/temproot ready for use
*** Creating and populating directory structure in /var/tmp/temproot
install: illegal option -- l
usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 file2
install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 ... fileN directory
install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** FATAL ERROR: Cannot 'cd' to /home/shane/Projects/f10-test/src and
install files to
the temproot environment
See /usr/src/UPDATING entry 20130425
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
pgpIPRopjCqsN.pgp
Description: PGP signature
Failure to build stable/9 (r253683) from head - WCHAR_MIN redefined
Anyone else seeing this? cc -O2 -pipe -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/include -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/../../include -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/../../contrib/gdtoa -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/stdtime -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /zpoudriere/jails/exp-bdrewery/usr /src/lib/libc/gen/fnmatch.c -o fnmatch.o In file included from /zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/gen/fnmatch.c:66: In file included from /zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/locale/collate.h:41: In file included from /zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/locale/xlocale_private.h:38: /usr/include/stdint.h:75:9: error: 'WCHAR_MIN' macro redefined [-Werror] #define WCHAR_MIN __WCHAR_MIN ^ /zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/../../include/wchar.h:92:9: note: previous definition is here #define WCHAR_MIN __INT_MIN ^ In file included from /zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/gen/fnmatch.c:66: In file included from /zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/locale/collate.h:41: In file included from /zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/locale/xlocale_private.h:38: /usr/include/stdint.h:76:9: error: 'WCHAR_MAX' macro redefined [-Werror] #define WCHAR_MAX __WCHAR_MAX ^ /zpoudriere/jails/exp-bdrewery/usr/src/lib/libc/../../include/wchar.h:93:9: note: previous definition is here #define WCHAR_MAX __INT_MAX ^ 2 errors generated. *** [fnmatch.o] Error code 1 1 error *** [lib/libc__L] Error code 2 1 error *** [libraries] Error code 2 1 error *** [_libraries] Error code 2 1 error *** [buildworld] Error code 2 1 error -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: [HEADSUP] New pkg-devel 1.1.0 beta1
On 6/11/2013 11:51 AM, Slawa Olhovchenkov wrote: On Mon, Jun 03, 2013 at 08:40:31PM +0200, Baptiste Daroussin wrote: On Mon, Jun 03, 2013 at 07:39:03PM +0400, Slawa Olhovchenkov wrote: On Mon, Jun 03, 2013 at 05:34:19PM +0200, Baptiste Daroussin wrote: On Mon, Jun 03, 2013 at 07:17:24PM +0400, Slawa Olhovchenkov wrote: On Thu, May 30, 2013 at 05:20:54PM +0200, Baptiste Daroussin wrote: The pkg developement team is proud to announce the new 1.1.0 beta1 release of pkg. - new experimental pkg convert (can convert from and to legacy pkg database) pkg2ng now uses pkg convert (still recommanded to use pkg2ng) Converting packages from /var/db/pkg Converting pkg-1.1.0.b3_1... pkg: unknown keyword display, ignoring @display Installing pkg-1.1.0.b3_1...Segmentation fault (core dumped) ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Have you run pkg2ng? Yes, this is run pkg2ng. Ok I'll have a look and fix asap. And for graphics/evince don't recorded dependencies from archivers/unzip (as RUN_DEPENDS in Makefile). This is possibly expected because unzip is in base. The archivers/unzip package is not installed. The port is not depending on LOCALBAES/bin/unzip so it doesn't pull in the archivers/unzip port, it just uses the base version. It's not a pkg problem. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: [HEADSUP] New pkg-devel 1.1.0 beta1
On 6/11/2013 12:17 PM, Slawa Olhovchenkov wrote:
On Tue, Jun 11, 2013 at 11:52:59AM -0500, Bryan Drewery wrote:
On 6/11/2013 11:51 AM, Slawa Olhovchenkov wrote:
On Mon, Jun 03, 2013 at 08:40:31PM +0200, Baptiste Daroussin wrote:
On Mon, Jun 03, 2013 at 07:39:03PM +0400, Slawa Olhovchenkov wrote:
On Mon, Jun 03, 2013 at 05:34:19PM +0200, Baptiste Daroussin wrote:
On Mon, Jun 03, 2013 at 07:17:24PM +0400, Slawa Olhovchenkov wrote:
On Thu, May 30, 2013 at 05:20:54PM +0200, Baptiste Daroussin wrote:
The pkg developement team is proud to announce the new 1.1.0 beta1
release of
pkg.
- new experimental pkg convert (can convert from and to legacy pkg
database)
pkg2ng now uses pkg convert (still recommanded to use pkg2ng)
Converting packages from /var/db/pkg
Converting pkg-1.1.0.b3_1...
pkg: unknown keyword display, ignoring @display
Installing pkg-1.1.0.b3_1...Segmentation fault (core dumped)
___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
Have you run pkg2ng?
Yes, this is run pkg2ng.
Ok I'll have a look and fix asap.
And for graphics/evince don't recorded dependencies from
archivers/unzip (as RUN_DEPENDS in Makefile).
This is possibly expected because unzip is in base. The archivers/unzip
package is not installed. The port is not depending on
LOCALBAES/bin/unzip so it doesn't pull in the archivers/unzip port, it
just uses the base version.
It's not a pkg problem.
Whose problem is it? Where addressed PR?
In ports Makefile for graphics/evince
.if ${PORT_OPTIONS:MCOMICS}
RUN_DEPENDS+= unzip:${PORTSDIR}/archivers/unzip
CONFIGURE_ARGS+=--enable-comics
GCONF_SCHEMAS+= evince-thumbnailer-comics.schemas
PLIST_SUB+= COMICS=
.else
CONFIGURE_ARGS+=--disable-comics
PLIST_SUB+= COMICS=@comment
.endif
poudriere check dependencies changing by comparing 'make
run-depends-list' and recorded dependices from existing package. In
run-depends-list archivers/unzip prsent, in package -- absent.
As result on every run 'poudriere bulk' package graphics/evince
removed (new dependency: archivers/unzip) and rebuilding. And
depended from evince packages too.
This is a known poudriere bug. Documented in the 3.0 release notes:
- Add CHECK_CHANGED_DEPS (default yes) to automatically detect
direct dependency changes and rebuild packages if needed. This
allow automatically detecting default postgresql/mysql/perl
changes requiring rebuild of ports. Note this has a bug with
ports that depend on libraries that are in base, but have a
port fallback. This will be addressed in 3.1.
...
This is problem of evince port or port infrastructure?
It's a evince port problem, or not. Up to maintainer to decide if it
really needs archives/unzip port, or not. Apparently it does not need
it, or should be changed to LOCALBASE/bin/unzip or USE_ZIP or removed.
Or may be we need 'soft' (optional) dependencies -- installed if some
files missing? (for example -- system build w/o bzip2, package
installed bzip2, for usual system -- do nothing).
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: [HEADSUP] New pkg-devel 1.1.0 beta1
On 5/30/2013 10:20 AM, Baptiste Daroussin wrote: Ports users (or in building factories: poudriere/tinderbox): Add WITH_PKGNG=devel to your make.conf pkg set -o ports-mgmt/pkg:ports-mgmt/pkg-devel FYI this will not currently work with portupgrade. I plan to address it soon. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
[HEADS UP] New pkgng git location
Pkg has moved from http://github.com/pkgng/pkgng to http://github.com/freebsd/pkg Please update any links or git checkouts you have. You can update your git checkout with: git remote set-url origin git://github.com/freebsd/pkg.git pkgng/pkgng -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
[HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1
This only affects binary-packages-only users. pkg 1.0.9 had a regression with 'pkg update' that will prevent updating your repository. Please skip this version and use 1.0.9_1. This version was only in ports for 7 hours. Due to the security incident, there are still no official FreeBSD packages. If you are using an unofficial mirror, it is unlikely it would have upgraded to 1.0.9 in the time it was in the tree. If you are building your own packages and managed to get onto 1.0.9 you can upgrade to 1.0.9_1 as follows: # cp /usr/local/sbin/pkgs-static . # pkg delete -f pkg # ./pkg-static add URL-TO-YOUR-PACKAGESITE/All/pkg-1.0.9_1.txz #optional # rm pkg-static As for how this managed to get released. We did do a functional test of this before releasing, but due to the nature of 'pkg update' using a cache, it was not immediately obvious that it was broken. We do need your help with adding more automated tests. http://lists.freebsd.org/pipermail/freebsd-pkg/2013-March/16.html has our call for help on this front and more information. Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: MFC openssh fix versionaddendum?
On 2/11/2013 6:05 AM, Ruben de Groot wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=163843 The fix was committed to -current, but in 9.1 it's still not working. cheersRuben I plan to also add this back into the security/openssh-portable port soon. -- Regards, Bryan Drewery bdrewery@freenode/EFNet signature.asc Description: OpenPGP digital signature
Re: MFC: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) (fwd)
On 12/18/2012 9:18 AM, Robert Watson wrote: Dear all: Just an FYI that the new distributed audit daemon has been MFC'd to 9-STABLE. As noted in UPDATING, you will need to run mergemaster -p before using installkernel or installworld targets in order to add the new auditdistd system user. This should be part of the regular update cycle anyway, but after the experience of adding auditdistd in 10-CURRENT, we've discovered that many people are skipping that step in the update cycle, so I figured it best to point out here. (Technically, only installworld requires the user, but the user-check guards in the system Makefiles are enforced for both targets.) Have you seen misc/174405? Apparently installkernel is requiring the user as well. The documented process in UPDATING does not mention running mergemaster -p before [install]kernel. More details on the daemon below. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:15:11 + (GMT) From: Robert Watson rwat...@freebsd.org To: curr...@freebsd.org Cc: secur...@freebsd.org Subject: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) Dear all: I've now committed the build glue required to install the recently merged Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and sponsored by the FreeBSD Foundation. This allows individual hosts generating audit trails to submit trails to a central audit server for review and safe keeping. Part of the goal is to ensure that a host submitting trail data can't later modify the trails. Pawel uses a variety of useful security- and resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the recent security incident in the FreeBSD.org cluster illustrated, having reliable and detailed audit trails makes a big difference in forensic work, and hopefully this will allow the FreeBSD Project (and our users) to do that better in the future. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:11:46 + (UTC) From: Robert Watson rwat...@freebsd.org To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Subject: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd Author: rwatson Date: Sat Dec 1 15:11:46 2012 New Revision: 243752 URL: http://svnweb.freebsd.org/changeset/base/243752 Log: Merge a number of changes required to hook up OpenBSM 1.2-alpha2's auditdistd (distributed audit daemon) to the build: - Manual cross references - Makefile for auditdistd - rc.d script, rc.conf entrie - New group and user for auditdistd; associated aliases, etc. The audit trail distribution daemon provides reliable, cryptographically protected (and sandboxed) delivery of audit tails from live clients to audit server hosts in order to both allow centralised analysis, and improve resilience in the event of client compromises: clients are not permitted to change trail contents after submission. Submitted by:pjd Sponsored by:The FreeBSD Foundation (auditdistd) Added: head/etc/rc.d/auditdistd (contents, props changed) head/usr.sbin/auditdistd/ head/usr.sbin/auditdistd/Makefile (contents, props changed) Modified: head/etc/defaults/rc.conf head/etc/ftpusers head/etc/mail/aliases head/etc/master.passwd head/etc/mtree/BSD.var.dist head/etc/rc.d/Makefile head/share/man/man4/audit.4 head/usr.sbin/Makefile Modified: head/etc/defaults/rc.conf == --- head/etc/defaults/rc.confSat Dec 1 13:46:37 2012(r243751) +++ head/etc/defaults/rc.confSat Dec 1 15:11:46 2012(r243752) @@ -590,6 +590,9 @@ sendmail_rebuild_aliases=NO# Run newa auditd_enable=NO# Run the audit daemon. auditd_program=/usr/sbin/auditd# Path to the audit daemon. auditd_flags=# Which options to pass to the audit daemon. +auditdistd_enable=NO# Run the audit daemon. +auditdistd_program=/usr/sbin/auditdistd# Path to the auditdistd daemon. +auditdistd_flags=# Which options to pass to the auditdistd daemon. cron_enable=YES# Run the periodic job daemon. cron_program=/usr/sbin/cron# Which cron executable to run (if enabled). cron_dst=YES# Handle DST transitions intelligently (YES/NO) Modified: head/etc/ftpusers == --- head/etc/ftpusersSat Dec 1 13:46:37 2012(r243751) +++ head/etc/ftpusersSat Dec 1 15:11:46 2012(r243752) @@ -19,6 +19,7 @@ _pflogd _dhcp uucp
Re: how to update ports while using pkgng?
On 9/14/2012 11:41 PM, Mike Manilone wrote: Hi, I'm using ports with pkgng enabled. But I found that portmaster won't work. Is there any way to update ports? Thanks! Sincerely, Mike Manilone ports-mgmt/portupgrade-devel will work with PKGNG out of the box. Bryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1-RC1 Available...
On 8/25/2012 4:33 AM, Harald Schmalzbauer wrote: But my real problem is that svn is not in the base system. And for example installing subversion package on my cvsup mirror failed because pkg-config-0-25_1 was installed and sqlite, a dependency of subversion, wants to install pkgconf-0.8.5. So I'm hit by the henn-egg problem. This is because pkg-config was removed and moved from devel/pkg-config to devel/pkgconf. To update or install any port, you'll need to deinstall pkg-config and install pkgconf. There is an associated UPDATING entry: 20120726: AFFECTS: users of devel/pkg-config AUTHOR: b...@freebsd.org devel/pkg-config has been replaced by devel/pkgconf # portmaster -o devel/pkgconf devel/pkg-config or # portupgrade -fo devel/pkgconf pkg-config-\* pkgng: # pkg set -o devel/pkg-config:devel/pkgconf # pkg install -f devel/pkgconf Bryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1-RC1 Available...
On 8/23/2012 9:28 AM, Ian Smith wrote: On Thu, 23 Aug 2012 09:47:54 -0400, Ken Smith wrote: On Thu, 2012-08-23 at 23:12 +1000, Ian Smith wrote: On Thu, 23 Aug 2012 00:50:46 -0400, Ken Smith wrote: With both the doc and ports repositories now moved to SVN it has been decided to not export the 9.1 release branch activity to CVS. So csup/cvsup update mechanisms are not available for updating to 9.1-RC1. If you would like to use SVN the branch to use is releng/9.1. Assuming the stupid question is the one you didn't ask, just to clarify: does this mean that c*sup won't work with these RCs in particular, or that CVS is dead and SVN becomes mandatory from 9.1-RELEASE? cheers, Ian The latter. If you are not using FreeBSD-Update to handle the updates of a machine you'll need to update your source tree using SVN for release branches (releng/*) from now on. Updates of the CVS repository will continue for the existing stable/* and head for now. I don't think anything has been decided on when that will stop. Thanks Ken. I'm a bit POLAxed; guess I don't read enough lists .. I'm a bit surprised too. Shouldn't this mean svn should be in base? If not, should csup come OUT of base? Bryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1-RC1 Available...
On 8/23/2012 10:36 AM, Bryan Drewery wrote: On 8/23/2012 9:28 AM, Ian Smith wrote: On Thu, 23 Aug 2012 09:47:54 -0400, Ken Smith wrote: On Thu, 2012-08-23 at 23:12 +1000, Ian Smith wrote: On Thu, 23 Aug 2012 00:50:46 -0400, Ken Smith wrote: With both the doc and ports repositories now moved to SVN it has been decided to not export the 9.1 release branch activity to CVS. So csup/cvsup update mechanisms are not available for updating to 9.1-RC1. If you would like to use SVN the branch to use is releng/9.1. Assuming the stupid question is the one you didn't ask, just to clarify: does this mean that c*sup won't work with these RCs in particular, or that CVS is dead and SVN becomes mandatory from 9.1-RELEASE? cheers, Ian The latter. If you are not using FreeBSD-Update to handle the updates of a machine you'll need to update your source tree using SVN for release branches (releng/*) from now on. Updates of the CVS repository will continue for the existing stable/* and head for now. I don't think anything has been decided on when that will stop. Thanks Ken. I'm a bit POLAxed; guess I don't read enough lists .. I'm a bit surprised too. Shouldn't this mean svn should be in base? If not, should csup come OUT of base? I rethought this. Ignore me. Bryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Solaris features in FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/31/2012 3:45 PM, Chris Nehren wrote: On Thu, May 31, 2012 at 17:20:04 +0200 , Oliver Fromme wrote: And speaking of Solaris features... On Thu, May 31, 2012 at 19:13:32 +0100 , Matthew Seaman wrote: This sort of operation is something that ZFS boot environment support (recently committed to HEAD, due for MFC within the month) makes much, much safer and easier to deal with. You don't need to do a separate reboot to test the kernel as you've still got an entire kernel+world in the previous BE to fall back on. This is *awesome*. /me removes yet another item from the reasons to use Solaris list. I cannot wait to try this out. ZFS Boot Environments are supported even without the HEAD changes. Some ports/scripts to assist: beadm Solaris-like script: sysutils/beadm (see http://forums.freebsd.org/showthread.php?t=31662) Another: manageBE (http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE) Regards, Bryan Drewery -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPy3r/AAoJEG54KsA8mwz5jK8QALz9udwIxQ2aEjdDoqgbOVZ6 87PwyX8GNVhFdnusajj7zgZM+pqXft93SG8lpNPzPDa+bqI/wQRQAAvrztpPKZJM 4VwmRNmH7bFjjGSo0luUaJ+A5lyKmNl6IR5OqGniw51UVHgbIwDRLG304AXeQc9n Eua6bBSKgKUeYtYV+vtBcIAqCeOpyW+QD94z04BcM+f5LzC86E/XZyKKNhLwzDwb XWum7sBWa+bf3T5qfKofuV0iOlbMj8CEbHUZg1MqyuQASBLYwkhmC9MRhL6Wsksy ccmCTDW7dGk3ng7Iqfbs4JJJ71osToP/k1UxPECG+sISXafFFBTVqPHVquvxOaVv 2SmYMBT9FbfmwXg8Ld6mVCd/kqDQx2NBuIiHkHroi38EX2W1398/O/57VRlw031+ +vxrSAhHj2v3YXPEmBu+8J5gDGJV2luSCftH8COua2dhtwqLPfkJpxooJbuPc+ll fqQfd0D9Cr1GIRBg4NKn5naesTCSaEZSmRFbRx5cqmlJ+6BqTgCV3e3cGSQypF1L cwSTwZU9U1uDYGJJ/62BYZz01CCS/h3EcrkYzmpKN+L7HLe6dkXaWlE47GyJ7NZk YT9nyP/tZt/xf5cEkSiTCTg3m1iNYar+3eT51rPofmzybC0uBSqZe8Fj/CCjQQfH jkBjdI4fhyWWrosHpjC0 =G/Tu -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You NOT Using FreeBSD ?
On 6/1/2012 1:57 PM, Thomas David Rivers wrote: One developer here uses Linux Debian for about the same reason, it's trivial to update (via the network) to new versions, etc... FWIW, there is freebsd-update(8) now for binary updating of base, and pkgng[1] will allow binary upgrading of packages/ports similar to apt-get. [1] http://wiki.freebsd.org/pkgng -- Regards, Bryan Drewery bdrewery@freenode, bryan@EFNet signature.asc Description: OpenPGP digital signature
Re: Make filesystem type configurable for periodic(8)?
On 05/04/2012 11:05 AM, Freddie Cash wrote:
A few of the periodic(8) scripts in FreeBSD have constructs similar to
the following to get which filesystems to scan for various things:
MP=`mount -t ufs,zfs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
For systems with large ZFS pools, and many ZFS filesystems, these
periodic scripts can grind it to its knees, and then some. For
backups servers where we don't really care about the
ownership/permissions of files from the FreeBSD perspective, we really
don't want the ZFS filesytems to be scanned; only the UFS ones for the
FreeBSD OS install. To that end, I have to manually edit these files
to remove the ,zfs:
MP=`mount -t ufs | awk '$0 !~ /no(suid|exec)/ { print $3 }'`
Would it be worthwhile to anyone else to make the filesystem type(s)
to scan via the periodic(8) scripts a variable that's set by default
in /etc/defaults/periodic.conf and that user's can override via
/etc/periodic.conf?
Or, am I the only one that's suffering here? :)
If there's interesting in this, I can look into coming up with some
patches. But wanted to check if anyone else would find it useful.
I would find this useful. But further, I have a ZFS root pool as well as
a ZFS backup pool. I don't want to exclude all of ZFS, just certain
pools, or even certain datasets.
Regards,
Bryan Drewery
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
