Re: Plans for git

2020-09-19 Thread Ed Maste
On Sat, 19 Sep 2020 at 12:06, Bakul Shah wrote: > > The cgit-beta.FreeBSD.org and github trees are not identical the last > time I looked (mainly in meta data). Any reason for not keeping them > identical? I switched from the github tree to the cgit-beta tree. The current GitHub mirror is

Re: on moving freebsd from svn to git; would this be of any help?

2020-09-18 Thread Ed Maste
On Fri, 18 Sep 2020 at 15:07, Chris wrote: > > While contemplating a massive re-tooling job ahead to accommodate > any/all changes when freebsd fully lands in git. I ran across this[1][2] > and wondered if it may be of any assistance for the task of those > involved in the migration process

Re: Deprecating ftpd in the FreeBSD base system?

2020-09-16 Thread Ed Maste
On Wed, 16 Sep 2020 at 16:51, Allan Jude wrote: > > Is the [ftpd] version we have in base unique? That is to say, does it need > to be preserved somehow. I'm not sure if we have functionality that doesn't exist elsewhere, although we definitely have some changes that do not exist in other BSDs.

Deprecating ftpd in the FreeBSD base system?

2020-09-16 Thread Ed Maste
FTP is (becoming?) a legacy protocol, and I think it may be time to remove the ftp server from the FreeBSD base system - with the recent security advisory for ftpd serving as a reminder. I've proposed adding a deprecation notice to the man page in https://reviews.freebsd.org/D26447 to start this

Re: tracking -current, using poudriere-devel and the switch to git

2020-09-10 Thread Ed Maste
On Thu, 10 Sep 2020 at 07:02, tech-lists wrote: > > On Wed, Sep 09, 2020 at 04:34:20PM -0400, Ed Maste wrote: > > [...lots of stuff explaining...] > > thank you Oh, I see I left a word out of my first reply and it could be confusing - added text in brackets below: > At the

Re: tracking -current, using poudriere-devel and the switch to git

2020-09-09 Thread Ed Maste
On Wed, 9 Sep 2020 at 15:00, tech-lists wrote: > > Hi, > > What's the repo to use now in order to track -current with a poudriere jail > via git ? i.e. in poudriere.conf, what is GIT_BASEURL ? svn is still the canonical repo. If you want to help test the Git migration work in progress, the

Re: vfs.zfs.min_auto_ashift and OpenZFS

2020-09-06 Thread Ed Maste
On Sun, 6 Sep 2020 at 22:26, Matthew Macy wrote: > > This long since been fixed. Note that Ryan built working installer images > during the CFT. Yep, thanks for the note and sorry for the false alarm; it was a local issue and I've closed the PR. ___

Re: vfs.zfs.min_auto_ashift and OpenZFS

2020-09-06 Thread Ed Maste
On Fri, 1 May 2020 at 20:20, Matthew Macy wrote: > > OpenZFS doesn't have the same ashift optimization logic that FreeBSD > has. It's something that needs to be resolved before the code can be > integrated downstream. Note that our installer tries to set the min_auto_ashift when ZFS is selected

Re: Please check the current beta git conversions

2020-09-02 Thread Ed Maste
On Tue, 1 Sep 2020 at 22:38, Thomas Mueller wrote: > > from Ed Maste: > > > > Any guidance on amount of diskspace and how long it takes to clone the > > > repo ? > > > I see just over 3GB in my clone, including about 2.5GB in the .git > > directory.

Re: Plans for git (was: Please check the current beta git conversions)

2020-09-02 Thread Ed Maste
On Wed, 2 Sep 2020 at 02:31, Steve Kargl wrote: > > > A short intro on git for svn users: > > https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view > > > > ROTFL. From the "short intro", 2nd sentence. > > New committers are assumed to already be familiar with the basic > operation of Git. If not, start

Re: Plans for git (was: Please check the current beta git conversions)

2020-09-02 Thread Ed Maste
On Wed, 2 Sep 2020 at 07:51, Mathieu Arnold wrote: > > > Git also supports sha-256 soon now, adoption should > > be researched from various online article series and > > work product before committing plans... > > https://lwn.net/Articles/823352/ > >

Re: Please check the current beta git conversions

2020-09-01 Thread Ed Maste
On Tue, 1 Sep 2020 at 13:37, Poul-Henning Kamp wrote: > > > Goran Mekić writes: > > > While I can clone src nicely, it is very slow in Serbia/Europe. The best > > speed I got is 1.45MB/s but it's mostly around 700kB/s (still cloning). > > I was about to ask about that: > > Any guidance

Re: Please check the current beta git conversions

2020-09-01 Thread Ed Maste
On Tue, 1 Sep 2020 at 13:23, Goran Mekić wrote: > > Hello, > > While I can clone src nicely, it is very slow in Serbia/Europe. Thanks for the report - I wouldn't be surprised if the host is a bit bogged down from folks trying this just after my message went out. Once your clone finishes please

Please check the current beta git conversions

2020-09-01 Thread Ed Maste
We've been updating the svn-git converter and pushing out a new converted repo every two weeks, and are now approaching the time where we'd like to commit to the tree generated by the exporter, and guarantee that hashes will remain consistent from this point. At this point the Git Working Group

Re: kldref: too many segments on kernel build

2020-08-19 Thread Ed Maste
On Wed, 19 Aug 2020 at 00:19, Dustin Marquess wrote: > > On Tue, Aug 18, 2020 at 3:19 PM Michael Butler > wrote: > > > > Any thoughts as to why this is happening when I build a (custom) kernel? > > > > kldxref: /boot/kernel/kernel: too many segments > > I'm seeing this too. I haven't tried

Re: DRM Project report (week of August 10)

2020-08-17 Thread Ed Maste
On Mon, 17 Aug 2020 at 04:46, Emmanuel Vadot wrote: > > - Remove the remaining GPLv2 code to start thinking of import into > base. How much GPLv2 code do we have left now? ___ freebsd-current@freebsd.org mailing list

Re: KiCad is horrible on CURRENT

2020-07-29 Thread Ed Maste
On Wed, 29 Jul 2020 at 15:18, Poul-Henning Kamp wrote: > > > Michael Gmelin writes: > > > Which driver are you using? > > drm-devel-kmod-5.3.g20200724 I'm using drm-kmod built from https://github.com/freebsd/drm-kmod at 6aeae91adbebae15bb77ccdc87f4e0a1d9fcb184

Re: KiCad is horrible on CURRENT

2020-07-29 Thread Ed Maste
On Wed, 29 Jul 2020 at 06:20, Poul-Henning Kamp wrote: > > I just noticed that KiCad's scroll-bars flash a lot whenever the mouse > pointer is moved, that sounds like it could be the focus-event-flooding. For me KiCad's scroll bars are hidden, and flash briefly on and off while the pointer's

Heads-up: removing outdated OpenSSH ciphers

2020-07-27 Thread Ed Maste
A base system OpenSSH update in 2016 or so removed a number of ciphers from the default lists offered by the server/client (due to known weaknesses). This prompted FreeBSD PR207679, and they were restored in r296634. It's time to retire this local change against upstream OpenSSH; the ciphers

HEADS-UP: obsolete GNU as 2.17.50 retirement for FreeBSD 13, expected 2020-05-31

2020-05-10 Thread Ed Maste
All architectures supported by FreeBSD now using Clang and lld, and tools from obsolete GNU binutils 2.17.50 have been retired one by one - most recently objdump, in r360698. There is one binutil tool left: GNU as. I plan to disable it at the end of the month, and then remove all of binutils some

HEADS-UP: /usr/bin/objdump to be removed

2020-05-05 Thread Ed Maste
I plan to remove the obsolete GNU binutils 2.17.50 objdump from the base system in the next few days. If you currently use objdump from the base system you can give llvm-objdump a try instead - it is mostly compatible, but has a few missing options and the output format may be slightly different.

Re: Ordering of files in zoneinfo

2020-04-24 Thread Ed Maste
On Fri, 24 Apr 2020 at 07:23, Fabian Keil wrote: > > > I wonder if we could drop the sort and replace ${TZS} in line 100 with > > ${TZS:O} instead? > > Makes sense to me. Agreed, that seems sensible. > > By the way, looking at > > https://github.com/freebsd/pkg/blob/master/libpkg/metalog.c , I

Re: .debug files, skip?

2020-04-05 Thread Ed Maste
On Sun, 5 Apr 2020 at 08:32, Jeffrey Bouquet wrote: > > A recent build[k,w] [ ** stable 12.1] and many .debug files I'd like to > skip if poss. A knob? Yes, from src.conf(5): WITHOUT_DEBUG_FILES Set to avoid building or installing standalone debug files for

Re: Is sc(4) no longer supported in GENERIC?

2020-04-03 Thread Ed Maste
On Fri, 3 Apr 2020 at 04:25, Chris wrote: > > On Thu, 2 Apr 2020 19:31:53 -0400 Ed Maste ema...@freebsd.org said > > > On Thu, 2 Apr 2020 at 17:13, Chris wrote: > > > > > > Ahem... I used the wrong syntax. > > > changing the entry to > > > >

Re: Is sc(4) no longer supported in GENERIC?

2020-04-02 Thread Ed Maste
On Thu, 2 Apr 2020 at 17:13, Chris wrote: > > Ahem... I used the wrong syntax. > changing the entry to > > kern.vty=sc > > solved it! :) I'm glad it's working for you, but note that sc(4) is deprecated and has no ongoing effort behind it, so it would be best if we can identify and resolve the

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

2020-03-30 Thread Ed Maste
On Mon, 30 Mar 2020 at 11:33, Brooks Davis wrote: > > FWIW, we don't generally rely on +x and invoke the interperter directly > (to enable storing src on a noexec filesystm). I fixed the bug that > caused direct invocation of the script in r359426. Good point, we should probably add a CI run to

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

2020-03-27 Thread Ed Maste
On Fri, 27 Mar 2020 at 21:11, Enji Cooper wrote:> > > Hi Julian, > I just worked around the issue by bypassing the manpage generation as part of > buildworld: https://svnweb.freebsd.org/base?view=revision=359385 . > While the approach you took makes wonderful sense, I thought it was best to >

Re: src/usr.bin/kyua breaks on manbuild.sh: Permission denied

2020-03-27 Thread Ed Maste
On Fri, 27 Mar 2020 at 20:48, Julian H. Stacey wrote: > > l /usr/src/contrib/kyua/doc/manbuild.sh > -rw-r--r-- 1 jhs staff 5187 Mar 25 12:34 > /usr/src/contrib/kyua/doc/manbuild.sh Indeed, this is the problem. manbuild.sh is +x in svn and in the git mirror, so it appears something's

Re: Build failed compiling ittnotify_static.pico

2020-03-14 Thread Ed Maste
. the obj-lib32 subpath). > > Ed Maste tried to fix that up in r358909, but maybe it does not work in > all situations, for example with custom MAKEOBJDIRPREFIX settings? My change in r358909 will definitely not be effective if you already had a failed build bet

Re: Any a.out users?

2020-03-13 Thread Ed Maste
On Fri, 13 Mar 2020 at 13:22, Ian Lepore wrote: > > Could a.out support be a kernel config option that's off by default? Probably. That seems reasonable to me. > And could its presence be indicated via sysctl in some way, so that > ldconfig could do a.out hints only if support for them is

Any a.out users?

2020-03-13 Thread Ed Maste
While looking at other things we came across ldconfig's a.out support, which hasn't been used by anything in the FreeBSD base system in ~2 decades. I know there are (or at least recently were) folks using a.out binaries on contemporary FreeBSD. Most likely statically linked proprietary software.

Re: Is amd automount still supported in 13.0 or not?

2020-03-09 Thread Ed Maste
On Sun, 8 Mar 2020 at 13:23, Bob Willcox wrote: > > Thanks for the tip! That worked for me. I guess from reading the documentation > I didn't pick up on staying with the symlinks and simply changing host to net. Glad it's working for you! Is there anything else that you found tricky or

Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

2020-02-21 Thread Ed Maste
On Sat, 15 Feb 2020 at 05:03, Bjoern A. Zeeb wrote: > > I am also worried that the change will make a lot of machines > unprotected upon updating to 13 if there is no big red warning flag > before the install. At least having sshd emit a warning is a prerequisite, certainly. I don't yet know if

Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

2020-02-14 Thread Ed Maste
On Fri, 14 Feb 2020 at 15:27, Joey Kelly wrote: > > On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote: > > Upstream OpenSSH-portable removed libwrap support in version 6.7, > > released in October 2014. We've maintained a patch in our tree to > > restore it, but it

Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

2020-02-14 Thread Ed Maste
Upstream OpenSSH-portable removed libwrap support in version 6.7, released in October 2014. We've maintained a patch in our tree to restore it, but it causes friction on each OpenSSH update and may introduce security vulnerabilities not present upstream. It's (past) time to remove it. Although

Re: Turn off PROFILE option and remove WITH_PROFILE after FreeBSD 13?

2020-01-17 Thread Ed Maste
On Fri, 17 Jan 2020 at 12:19, Steve Kargl wrote: > > Why? Because adding -pg to the gfortran command line is sufficient > to getting profiling information for long running numerically > intensive codes. 'gfortran -pg', of course, loosk for libc_p.a > and libm_p.a. Have you tried sampling-based

Turn off PROFILE option and remove WITH_PROFILE after FreeBSD 13?

2020-01-17 Thread Ed Maste
As far as I can tell most/all developers have used sampling-based profiling for years (e.g. hwpmc on FreeBSD) and have not been using gprof-based profiling. Prompted by followup to a pkgbase tweak I committed relating to profiling libraries[1] I propose following Brooks' suggestion: * turn off

Re: AT_EXECPATH aux_info vector contains path of interpreter when directly exec'ing rtld

2019-12-20 Thread Ed Maste
On Fri, 20 Dec 2019 at 16:26, Ryan Stone wrote: > > I've noticed that on head, if I directly execute rtld to run an > executable, AT_EXECPATH contains the path to rtld on head (on > 12.0-RELEASE it will contain nothing). This is causing me a problem > because clang uses AT_EXECPATH to

Re: kernel module code coverage

2019-12-05 Thread Ed Maste
> > Have you looked into /dev/kcov. This is used by SYZKALLER for getting > > coverage information from the kernel. > > > That's part of Matt Macy's gcov project, right?. No, /dev/kcov is independent of, and predates, Matt Macy's work. It provides broadly the same sort of information, but not

Re: breakage at usr.sbin/jail/Makefile

2019-11-21 Thread Ed Maste
On Wed, 20 Nov 2019 at 23:19, Pete Wright wrote: > > the issue seems to be on my amd64 system ${LINKER_TYPE} is not defined. > i was contemplating suggesting updating the .if clause in the Makefile > like so: > > .if defined($LINKER_TYPE}) && ${LINKER_TYPE} == "bfd" && ${MACHINE} == > "riscv"

Re: CURRENT October images do not create a bootable install

2019-11-08 Thread Ed Maste
On Thu, 7 Nov 2019 at 03:38, Chris wrote: > > I'm wondering what happened between RELENG-12, and 13 that made the change? What is the latest 12.x you tried that worked in this configuration? ___ freebsd-current@freebsd.org mailing list

Re: sweeping change over all NIC drivers

2019-10-17 Thread Ed Maste
On Mon, 14 Oct 2019 at 17:07, Gleb Smirnoff wrote: > > Hi, > > I'd like to commit a sweeping change over all NIC drivers, > details can be found here: > > https://reviews.freebsd.org/D21943 Note that the default view of this review is the as-committed changes, which excludes all of the

HEADS UP - users of hpt27xx, hptmv, hptnr, hptrr drivers

2019-10-03 Thread Ed Maste
These drivers have been removed from GENERIC. If you use them on -CURRENT please add the appropriate foo_load="YES" entry to /boot/loader.conf, or create a kernel config with the required driver(s) added. -- Forwarded message - Author: emaste Date: Thu Oct 3 12:51:57 2019 New

Re: FreeBSD Quarterly Status Report - Second Quarter 2019

2019-08-26 Thread Ed Maste
talked about methods for making for more training material available. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. In Q2, Ed M

Re: /usr/lib/libomp.so that was added in 13-CURRENT causes port failures and might conflict with libomp.so provided by devel/openmp

2019-05-20 Thread Ed Maste
On Sat, 18 May 2019 at 22:23, Yuri wrote: > > Why was /usr/lib/libomp.so added to the base? It was added to the base because it's a runtime library required to support a feature provided by the base system compiler. Do you have an example of a failing port?

Re: SVN r346700 breaks build

2019-04-26 Thread Ed Maste
On Fri, 26 Apr 2019 at 00:11, Enji Cooper wrote: > > We don’t have a CI infrastructure that proactively tests phabricator reviews > yet. Hopefully (soon) we can make that a reality (or via Travis). Travis-CI support has been on several wishlists for a long time, and it doesn't seem like

Re: SVN r346316 breaks build

2019-04-17 Thread Ed Maste
On Wed, 17 Apr 2019 at 17:31, Michael Butler wrote: > > There seems to be a missing include here? > > ===> usr.bin/strings (obj,all,install) > Building > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/strings/strings.o > /usr/src/contrib/elftoolchain/strings/strings.c:198:55: error: use of >

Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd

2019-03-01 Thread Ed Maste
On Thu, 28 Feb 2019 at 14:13, Ian Lepore wrote: > > I have been of the opinion that armv[67] has met all the bullet points > to be a tier-1 arch for several years, but nobody seemed interested in > declaring it so. Now it'll never happen, because there seems to be > growing momentum to throw

Re: uname -a output without svn revision number

2019-01-07 Thread Ed Maste
On Sat, 5 Jan 2019 at 04:44, Julian H. Stacey wrote: > > > WITHOUT_REPRODUCIBLE_BUILD. You probably want to add it to > > /etc/src.conf. > > Thanks Ed, Added, Rebuilding. > > I suggest the default should be the opposite, or has that already > been discussed & I missed it ? I don't know that

Re: uname -a output without svn revision number

2019-01-04 Thread Ed Maste
On Fri, 4 Jan 2019 at 10:36, Matthias Apitz wrote: > > To save space on the netbook > I excluded /usr/src/.svn which is causing now the absence of the > revision number. Yes, newvers.sh relies on the metadata in .svn to determine the revision number so this is as expected.

Re: uname -a output without svn revision number

2019-01-04 Thread Ed Maste
On Fri, 4 Jan 2019 at 08:42, Julian H. Stacey wrote: > > Matthias Apitz wrote: > > $ sh /usr/src/sys/conf/newvers.sh > > Me too. Mine also returns nothing. Ditto uname. Ditto dmesg. Annoying. Please read the UPDATING entry and the src.conf description for WITHOUT_REPRODUCIBLE_BUILD. You

Re: uname -a output without svn revision number

2019-01-04 Thread Ed Maste
On Fri, 4 Jan 2019 at 00:53, Matthias Apitz wrote: > > Why is this? I've read in UPDATING that: > > ... > 20180913: > Reproducible build mode is now on by default, in preparation for > FreeBSD 12.0. This eliminates build metadata such as the user, > ... > > But this does not

Re: buildworld falure: truncated or malformed archive

2018-12-27 Thread Ed Maste
On Thu, 27 Dec 2018 at 19:16, Warner Losh wrote: > > On Thu, Dec 27, 2018, 5:29 PM Ed Maste > >> On Thu, 27 Dec 2018 at 14:35, Ryan Stone wrote: >> > >> > I seem to recall something about libarchive or ar having a bug >> > creating archives >

Re: buildworld falure: truncated or malformed archive

2018-12-27 Thread Ed Maste
On Thu, 27 Dec 2018 at 14:35, Ryan Stone wrote: > > I seem to recall something about libarchive or ar having a bug > creating archives > 4GB, Indeed, FreeBSD's bespoke ar does not support the /SYM64/ format needed for offsets >4GB. imp@ also ran into this; I'm not sure what's causing libclang.a

Re: r111 build error

2018-12-12 Thread Ed Maste
On Wed, 12 Dec 2018 at 10:19, Ed Maste wrote: > > While we could take this to > root cause I think the most expedient fix is probably just to check > for evidence of clang 6 in the object tree, and rm the .depend files > and objects if found. A patch implementing this is avail

Re: r111 build error

2018-12-12 Thread Ed Maste
On Wed, 12 Dec 2018 at 07:35, Lev Serebryakov wrote: > > On 12.12.2018 14:59, Dimitry Andric wrote: > > ld: error: undefined symbol: clang::CallExpr::getLocStart() const > >>> referenced by MacOSXAPIChecker.cpp:86 > >>>

Re: GNU binutils 2.17.50 retirement planning

2018-11-26 Thread Ed Maste
On Mon, 26 Nov 2018 at 10:52, Ed Maste wrote: > > The most significant issue is > sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use > of GNU macro extensions. I have looked at nasm and yasm but believe > the macro extension support in those is less developed

Re: GNU binutils 2.17.50 retirement planning

2018-11-26 Thread Ed Maste
On Sat, 24 Nov 2018 at 17:24, Charlie Li wrote: > > some Makefile logic in stand/i386/btx specify a > hard-coded /usr/bin/as without bootstrapped binutils, necessitating a > symlink. Which logic specifically? I can't seem to find it. > If it is true that the only assembly files that clang IAS

Re: GNU binutils 2.17.50 retirement planning

2018-11-26 Thread Ed Maste
On Sun, 25 Nov 2018 at 07:52, David Chisnall wrote: > > We probably need to kill ld.bfd before 12.0. It predates ifunc and so > interprets anything with an ifunc as requiring a copy relocation. I posted https://reviews.freebsd.org/D18340 to stop installing ld.bfd when LLD_IS_LD is enabled.

GNU binutils 2.17.50 retirement planning

2018-11-23 Thread Ed Maste
For some time we have been incrementally working to retire the use of obsolete GNU Binutils 2.17.50 tools. At present we still install three binutils by default: as ld.bfd objdump The intent is to retire all of these by FreeBSD 13. Depending on tool and architecture we will just remove it,

ctm(1) deprecation in the FreeBSD base system?

2018-10-22 Thread Ed Maste
The ctm(1) client remains in the FreeBSD base system, although FreeBSD-hosted ctm infrastructure was shut down some time ago. I suspect it is time to remove it from the base system (perhaps making a port). How much use does ctm have these days? ___

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread Ed Maste
On Wed, 10 Oct 2018 at 18:11, O. Hartmann wrote: > > security/libssh This one is open as PR 228895. If there are other ports that you're trying to build and are failing with OpenSSL 1.1.1 please check PR 228865 and 231931 to see if it is already listed as a dependency. You can see all of the

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread Ed Maste
On Tue, 9 Oct 2018 at 23:15, Michael Butler wrote: > > On 10/9/18 5:34 PM, Glen Barber wrote: > > OpenSSL has been updated to version 1.1.1 as of r339270. > > > > It is important to rebuild third-party packages before running: > > > > # make -C /usr/src delete-old && make -C /usr/src

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-27 Thread Ed Maste
On 27 September 2018 at 06:46, tech-lists wrote: > > So, I want to know where and when each system was compiled. > Why lose this information by default? This comes down to the simple fact that our build / release process does not currently distinguish between building a world or kernel that's

Re: change in uname -a behaviour between 12-ALPHA5 and 12-ALPHA7

2018-09-26 Thread Ed Maste
On 26 September 2018 at 12:20, tech-lists wrote: > On 26/09/2018 14:34, Andrey Fesenko wrote: >> >> See WITH_REPRODUCIBLE_BUILD >> >> https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071125.html > > > Thanks, I was unaware of the change till now. Somehow missed that thread.

Re: Buildowrld tries to use old ld, and fails

2018-09-25 Thread Ed Maste
On 25 September 2018 at 02:55, wrote: > >> The normal procedure shouldn't need any LD= overrides; is there >> something unique in your build? Any src.conf settings? > > Indeed, I had "WITHOUT_LLD_BOOTSTRAP=yes" in src.conf. Not sure how > that line made it into this file on a number of my

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

2018-09-24 Thread Ed Maste
On 23 September 2018 at 07:31, Michael Tuexen wrote: > Using this patch I was able to build/install world and kernel on an i386 > system. > However, after removing it, I can't build world then. When trying to compile a > kernel "the old way" I end up with: > > tuexen@head:~/head/sys/i386/conf %

Re: Buildowrld tries to use old ld, and fails

2018-09-24 Thread Ed Maste
On 23 September 2018 at 21:18, wrote: > > Howdy! > > Since a couple months ago, the world on -CURRENT cannot be built using > the normal procedure: >time env LD=ld.lld make -j6 buildworld buildkernel The normal procedure shouldn't need any LD= overrides; is there something unique in your

Re: r338902 error buildworld on i386

2018-09-24 Thread Ed Maste
On 24 September 2018 at 06:43, Alex V. Petrov wrote: > ===> lib/libc (cleandir) > make[4]: "/usr/src/lib/libc/Makefile" line 26: i386 libc requires linker > ifunc support > *** Error code 1 Please try r338903. ___ freebsd-current@freebsd.org mailing

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

2018-09-21 Thread Ed Maste
On 21 September 2018 at 15:31, Mark Johnston wrote: > > Perhaps the following? It's not quite right since it'll still use > -zifunc-noplt with an external LLVM toolchain, but I can't seem to > figure out how to define a linker feature for only non-cross toolchains. > In any case, we're going to

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

2018-09-21 Thread Ed Maste
On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain wrote: > In looking into another report about using devel/amd64-gcc to buld > head I tried a build of -r338675 ( with WERROR= ). It got: > ... > > Question: > > Is ignoring "-z ifunc-noplt" a problem for using what > is built?

Re: FreeBSD EFI projects

2018-09-19 Thread Ed Maste
On 19 September 2018 at 10:34, Rodney W. Grimes wrote: > > You would be hard pressed to find a system with a 64 bit CPU that > could run 64 bit FreeBSD that had a 32 bit EFI implementation. The Minnowboard Turbot has an Atom E3826, and has four precompiled Tianocore UEFI firmware releases

Re: just a FYI

2018-09-19 Thread Ed Maste
On 19 September 2018 at 09:28, Jeffrey Bouquet wrote: > /usr/ports/security/lockdown [ sorry if this is a PR or for ports- ] Unfortunately this port has no maintainer, so fixing this is going to need someone to take an interest in the port. I had a quick look at the script and it looks like it

Re: FreeBSD EFI projects

2018-09-17 Thread Ed Maste
On 17 September 2018 at 14:17, Warner Losh wrote: > Items on my list are: > > (1) Retiring boot1.efi entirely before 13.0. It was originally designed to > be a small, never changing blob we'd toss into an ESP and have all the > smarts in loader.efi. I'd go further than this: it was originally

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-11 Thread Ed Maste
On 11 September 2018 at 07:35, Tomoaki AOKI wrote: > I prefer releng, rather than stable, to make it default. > Binary releases requiring reproducible builds are built from > release and releng branches. This might be the reasonable long-term strategy, but we don't yet have experience running

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
On 10 September 2018 at 14:52, Ed Maste wrote: > > I brought this up on -arch in 2015... That said, the kgdb -n issue was brought up in the old thread and it seems I did forget about it. I don't think we should cater too much to the needs of the deprecated in-tree kgdb, but we should mak

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
On 10 September 2018 at 13:57, Rodney W. Grimes wrote: >> >> I know a number of developers want to keep the metadata for their own >> builds at least. > > And we do not really know what the users position is on this... If users are building FreeBSD from source they can set the knob however they

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
On 10 September 2018 at 12:51, Rodney W. Grimes wrote: > > Why not just turn this on and leave it on? I know a number of developers want to keep the metadata for their own builds at least. We have essentially three different levels of metadata that are arguably sensible: 1. Major/minor

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
On 10 September 2018 at 11:11, Jonathan Anderson wrote: > Hi Ed, > > I think that sounds great. In the future, could we go even further and, by > default, only emit date/user/path if the source tree is “dirty” with respect > to SVN? If the build really is reproducible, that data should only be >

Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
The FreeBSD base system is a reproducible build[1] with a minor exception: the build metadata (timestamps, user, hostname, etc.) included in the kernel and loader. With the default, non-reproducible build the kernel ident looks like: FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018

Re: github freebsd and svn freebsd

2018-09-06 Thread Ed Maste
On 6 September 2018 at 20:11, Warner Losh wrote: > >> Assuming we're confident the issue in the svn mirroring process is >> fixed and will not recur we can redo the conversion, with a one-time >> change to all hashes from the offending commit on, and they would not >> change again in the future.

Re: github freebsd and svn freebsd

2018-09-06 Thread Ed Maste
On 4 September 2018 at 06:53, Kurt Jaeger wrote: > > The github repo isn't official, because there are still some > consistency issues. The consistency problem is: If an repo-copy > from svn to git is done, how can that repo-copy be done a second > time and still keep the same commit ids (in the

Re: kldref: unhandled relocation type 2

2018-08-17 Thread Ed Maste
On 8 August 2018 at 13:27, Warner Losh wrote: > >> % /usr/obj/usr/src/i386.i386/usr.sbin/kldxref/kldxref /boot/kernel >> kldxref: unhandled relocation type 2 >> (40+ messages...) > > > Oh, wait: relocation type, not module info That's not me, that's ed and > the new linker I think, or Dimitry

i386 top reporting nan% or inf% WCPU

2018-07-24 Thread Ed Maste
I recently merged my work in progress tree up to r336665 and built a i386 VM image. Running the image in QEMU (qemu-system-x86_64) and executing 'top' I see the WCPU column reported as either nan% or inf% for all processes. Prior to today I hadn't built or tested i386 in a while, so I am not sure

Re: Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-21 Thread Ed Maste
On 21 June 2018 at 09:09, Ed Maste wrote: > > We'll also need a man page. I took a quick look at this, and in doing so found that the output from "llvm-objdump --help" appears to be missing a large number of single-letter options, so one more thing to sort out. As it happens the

Re: Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-21 Thread Ed Maste
On 20 June 2018 at 17:26, Alexander Richardson wrote: > > When I made the change to use llvm-objdump in CheriBSD I had to change the > objdump flags from -xrsSd to -r -s -p -S -d -h -l -t. Ah yes, I recall discussing this now. Per GNU objdump's man page, -x is equivalent to -a -f -h -p -r -t.

Re: Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-20 Thread Ed Maste
On 20 June 2018 at 18:25, Shawn Webb wrote: > > Would you like me to quantify the compilation breakages due to the > full llvm toolchain switch? If so, I can do that after July 12th. Thanks Shawn, right now I'm interested specifically in llvm-objdump, with the goal of sorting it out in advance

Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-20 Thread Ed Maste
Work is in progress to migrate fully to modern and permissively licensed components for the tool chain. This includes moving away from the three obsolete binutils components that are still in the base system (as, ld, objdump). objdump is a tool to report information about binary objects (such as

Re: A head buildworld race visible in the ci.freebsd.org build history

2018-06-18 Thread Ed Maste
On 18 June 2018 at 19:29, Bryan Drewery wrote: > > The error is coming from libarchive which had a change between those > revisions: > >> >> r328332 | mm | 2018-01-24 06:24:17 -0800 (Wed, 24 Jan 2018) | 14 lines Li-Wen

Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)

2018-05-30 Thread Ed Maste
On 30 May 2018 at 18:08, Philip Homburg wrote: >>Strange. Can you try an updated test image of mine >>(https://people.freebsd.org/~emaste/mini-image-2018-05-28.xz) Oops - that should have been https://people.freebsd.org/~emaste/mini-image-2018-05-28-amd64.xz But the most recent snapshot images

Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)

2018-05-30 Thread Ed Maste
On 25 May 2018 at 04:51, Philip Homburg wrote: > > I have bad news and some good news. > > The bad news is that with this image the USB stick doesn't get recognized as > a boot device. Same as with the 11.2-BETA2 images. At least it's not a regression. > The good news is that if I completely

Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)

2018-05-24 Thread Ed Maste
On 23 May 2018 at 17:51, Philip Homburg wrote: > I tried both FreeBSD-11.2-BETA2-amd64-bootonly.iso.xz and > FreeBSD-11.2-BETA2-amd64-mini-memstick.img.xz on a Dell PowerEdge 2950 > BIOS version 2.7.0. With both images, the USB stick is not recognized. Can you download

Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-23 Thread Ed Maste
On 23 May 2018 at 05:48, Philip Homburg wrote: > > Turns out, you can't install FreeBSD using a USB stick image because the > BIOS only support MBR. No idea why MBR support was dropped for the USB images. We haven't "dropped" MBR support, and our amd64 memstick images

Re: HEADS-UP: Linker issues building amd64 kernels with config & make

2018-05-14 Thread Ed Maste
On 14 May 2018 at 18:05, Julian H. Stacey wrote: > > I guess this explains : > Date: Sun, 13 May 2018 20:26:38 +0200 > Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend > .svn_revision 333575 > linking kernel.full >

HEADS-UP: Linker issues building amd64 kernels with config & make

2018-05-14 Thread Ed Maste
As of r333461 the amd64 kernel makes use of ifuncs, and requires support in the linker. A safety belt added in r333470 enforces this, and will produce an explicit error if the linker does not support ifuncs. lld is the default bootstrap linker for amd64 and has ifunc support. The typical 'make

Deprecating the lmc(4) driver

2018-04-24 Thread Ed Maste
The lmc(4) driver supports hardware for a number of legacy interfaces, including EIA612/613, T1/E1, T3, etc. The driver's license is ambiguous and attempts to contact the author failed. I would like to remove this driver from 12.0, and have a deprecation notice in review D15182 [1]; I would

HEADS-UP: Deprecation of legacy (v3) password database support

2018-04-20 Thread Ed Maste
FreeBSD password databases (/etc/pwd.db, /etc/spwd.db) can contain records in one or both of two versions: * v3, a legacy architecture-dependent format * v4, the current architecture- and endian-independent format When v4 support was added in 2003 (r113596) pwd_mkdb emitted both v3 and v4

Re: snapshot of april 12th wont boot at all

2018-04-17 Thread Ed Maste
On 17 April 2018 at 11:17, Shawn Webb wrote: > > HardenedBSD enables PTI regardless of underlying CPU by default. We've > found that some older AMD CPUs have issues with PTI as currently > implemented. The oldest AMD CPU I have is a FX-6100, and FreeBSD-CURRENT works

Re: clang manual page?

2018-04-07 Thread Ed Maste
On 6 April 2018 at 07:25, Dimitry Andric wrote: > > With lld there wasn't even *any* form of command line documentation > yet, which is why Ed slapped together a man page (that could probably > still use more details). It should really be upstreamed, in Sphinx's > RST format,

Re: Can't load linux64.ko module

2018-04-04 Thread Ed Maste
On 3 April 2018 at 12:26, Steve Kargl wrote: > Booting a kernel from > % uname -a > FreeBSD sleepdirt 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331370: \ > Thu Mar 22 13:41:30 AKDT 2018 \ > kargl@sleepdirt:/usr/obj/usr/src/amd64.amd64/sys/SLEEPDIRT amd64 > >

  1   2   3   >