Re: gitup issues [was Re: No update for a day on ports?]

2021-04-14 Thread Ed Maste
On Sat, 10 Apr 2021 at 21:34, Peter Jeremy via freebsd-ports wrote: > > gitup walks the destination tree (ie /usr/ports), hashing every file > it finds (by reading the complete file into memory). Whilst the > default gitup configuration ignores /usr/ports/packages and > /usr/ports/distfiles, it r

Portsnap restoration after Git migration

2021-04-12 Thread Ed Maste
Colin (cperciva) and I are making good progress on the portsnap build infrastructure Git migration. I'll follow up when it is back in operation. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubsc

Proposed ports git transition schedule

2021-03-25 Thread Ed Maste
The doc and src tree git migrations are complete, and the git working group is preparing the ports tree transition in advance of the 2021Q2 quarterly branch. The proposed schedule is available at https://wiki.freebsd.org/git and the status will be updated throughout the process, and important mile

Re: the state of amd64 ports on -CURRENT as of 20200827

2020-08-27 Thread Ed Maste
On Thu, 27 Aug 2020 at 10:03, David Wolfskill wrote: > > It's https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248859, in case you > wanted to see for yourself. > > As I'm not a committer, it's not clear to me what (else) I can do to > help fix this. Hopefully your email will help raise the visi

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 w

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: Retiring GNU objdump 2.17.50

2020-01-13 Thread Ed Maste
On Sun, 12 Jan 2020 at 20:40, Slawa Olhovchenkov wrote: > > As long as pmcannotate relies on objdump(1) and pmcstat(8) to > work, it > will fail if one of them is not available. Ah, we could have pmcannotate check for both llvm-objdump and objdump in $PATH. ___

Retiring GNU objdump 2.17.50

2020-01-09 Thread Ed Maste
We currently install and use at most three tools from GNU binutils 2.17.50, depending on target architecture: 1. as - assembler 2. ld - linker 3. objdump - diagnostic / information tool I hope to retire all use of these obsolete binutils before FreeBSD 13. Here I'd like to discuss objdump. It is

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

2019-02-22 Thread Ed Maste
On Thu, 21 Feb 2019 at 16:47, Steve Kargl wrote: > > The missing symbols are > > % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort Thank you for collecting these. > It looks like we may be able to grab some of these from libc/softfloat: > getf2.c, gttf2.c, letf2.c, lttf2

HEADS-UP: switching i386 to lld as system linker

2019-01-11 Thread Ed Maste
As you may know I've been working on migrating to LLVM's lld as our system linker, to replace the outdated GNU binutils ld 2.17.50. lld is currently the system linker (i.e., is /usr/bin/ld) on amd64, arm64, and armv7. i386 was not switched over at the same time as the other architectures because ma

Re: error: undefined symbol: main in poudriere jail

2018-09-25 Thread Ed Maste
On 25 September 2018 at 09:29, blubee blubeeme wrote: > On Tue, Sep 25, 2018 at 5:27 PM Lorenzo Salvadore via freebsd-ports < > freebsd-ports@freebsd.org> wrote: > >> > > That's the problem, the same code works for earlier version of FreeBSD. >> > >> > You can try switching back to the old GNU ld

Re: error: undefined symbol: main in poudriere jail

2018-09-24 Thread Ed Maste
> That's the problem, the same code works for earlier version of FreeBSD. You can try switching back to the old GNU ld via something like "ln -fs ld.bfd /usr/bin/ld" and building the port on 12. (Or, set WITHOUT_LLD_IS_LD in src.conf.) If that works I'll try to suggest some further steps.

Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-05-10 Thread Ed Maste
On 26 March 2018 at 22:14, Ed Maste wrote: > Some changes related to the amd64 linker are nearly ready to be > committed (within a week or three), so I'm sending this notice to > request any final comments or concerns before these changes are made. It took somewhat longer than a

Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-04-04 Thread Ed Maste
On 29 March 2018 at 13:14, Ed Maste wrote: > > There are now 14 PRs open for failures when lld is /usr/bin/ld. Now down to 5: PR 221800 - www/mod_jk Appears to be an issue with libtool passing through linker flags. 0 dependent ports skipped. PR 224673 - misc/seabios Port maintainer has

Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-03-29 Thread Ed Maste
On 27 March 2018 at 18:21, Ed Maste wrote: > (Moved from -current to -ports) > > On 27 March 2018 at 13:15, Ed Maste wrote: >> >> Fair enough - this was the reason I sent the email. I've now gone >> through and submitted a PR for for each failure that did not alre

Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-03-27 Thread Ed Maste
(Moved from -current to -ports) On 27 March 2018 at 13:15, Ed Maste wrote: > > Fair enough - this was the reason I sent the email. I've now gone > through and submitted a PR for for each failure that did not already > have one. I've also added LLD_UNSAFE to a few po

Re: Ports and LLVM's lld linker

2017-12-22 Thread Ed Maste
On 18 December 2017 at 22:10, Ed Maste wrote: > > With a couple of recent changes in src head (r326831 and r326897) lld > is now suitable for use as the base system /usr/bin/ld on amd64 and > i386. We're working through ports failures, starting with those > responsible for t

Re: Ports and LLVM's lld linker

2017-12-18 Thread Ed Maste
On 27 November 2017 at 15:39, Ed Maste wrote: > We're making good progress on using LLVM's lld linker as FreeBSD's > /usr/bin/ld, so I'd like to raise awareness of the new linker within > the ports community. With a couple of recent changes in src head (r326831 and

Ports and LLVM's lld linker

2017-11-27 Thread Ed Maste
We're making good progress on using LLVM's lld linker as FreeBSD's /usr/bin/ld, so I'd like to raise awareness of the new linker within the ports community. Why do we need a new linker? Compared to GNU ld 2.17.50 currently in the FreeBSD base system, lld brings: * AArch64 (arm64) support * Link T

Linking ports with LLD: no default library search paths

2017-09-01 Thread Ed Maste
As mentioned recently on this list I've been investigating building the ports tree with LLVM's lld installed as /usr/bin/ld (via the exp-run in PR 214864). One of the common failure causes is that LLD does not include default library search paths (e.g., /usr/lib). Paths must be explicitly specifie

linking ports with lld: some ports pass $LDFLAGS to $LD instead of the compiler driver

2017-08-25 Thread Ed Maste
I've been investigating building the ports tree with LLVM's lld installed as /usr/bin/ld (via the exp-run in PR 214864). Through this I've found a few common issues, some of which are due to limitations of lld or choices made by its authors, and some of which are problems in the ports themselves. O

Re: The future of portmaster [and of ports-mgmt/synth]

2017-05-30 Thread Ed Maste
On 30 May 2017 at 15:00, Mark Millard wrote: > > ports-mgmt/synth depends on lang/gcc6-aux For reference, I've created PR 219667 to track the lang/gcc6-aux issue. The pre-built bootstrap compilers need to be recreated I believe, with a trick similar to the one used for lang/ghc. _

ino64 status update and upgrade caution

2017-05-29 Thread Ed Maste
The ino64 project was committed to src last week[1][2] with UPDATING notes added shortly thereafter [3][4][5]. As some people have been tripped up by the ino64 change I want to emphasize again that the upgrade procedure described in UPDATING should be followed exactly. The reboot after installing

Re: FYI: amd64 built with WITH_LLD_IS_LD= vs. devel/libunwind : cannot preempt symbol (for various symbols)

2017-04-16 Thread Ed Maste
On 16 April 2017 at 04:10, Mark Millard wrote: > Context: amd64 FreeBSD -r316952 as a VirtualBox guest > that was built using WITH_LLD_IS_LD= . ports -r438577. > > x11/xorg-minimal indirectly gets to devel/libunwind and > devel/libunwind fails to build from source: > > > --- Lperf-simple --- > lib

Re: os of system fetching port source

2017-04-04 Thread Ed Maste
On 3 April 2017 at 17:04, qjail1 wrote: > Ed Maste wrote: > > Is "Libfetch" whats used in the current port system to download the port > source? Libfetch is the library used by fetch(1) and pkg(8). The ports infrastructure will invoke the fetch binary. It looks like Mk/Scri

Re: os of system fetching port source

2017-04-03 Thread Ed Maste
On 19 February 2017 at 10:06, qjail1 wrote: > > Is there some fetch/ftp option to tag the ports system download request with > the operating system the request is coming from? Libfetch uses the HTTP_USER_AGENT environment variable if set, and it can also be set via a fetch command-line argument.

Re: Some reproducible builds notes

2016-06-17 Thread Ed Maste
On 17 June 2016 at 04:47, Maxim Sobolev wrote: > Hi Ed, I have not got time to look at diffoscope myself yet, but it's > definitely in my short-term TODO list. Quick question for you though. Would > it work given two tar.bz2 packages or does it need two directories? It does in fact process two pa

Some reproducible builds notes

2016-06-16 Thread Ed Maste
I recently presented on "Reproducible Builds in FreeBSD" at BSDCan. For anyone unfamiliar with the topic, from https://reproducible-builds.org/ "Reproducible builds are a set of software development practices which create a verifiable path from human readable source code to the binary code used by

Recording TIMESTAMPs in distinfo for reproducible builds work

2016-05-12 Thread Ed Maste
Baptiste and I have been looking at reproducible builds in the FreeBSD ports tree, and one thing we'll need is a consistent timestamp that doesn't change when a port is rebuilt without changes. We considered a few different ideas, and have settled on experimenting with the time 'make makesum' is r

Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)

2014-10-03 Thread Ed Maste
On 3 October 2014 10:00, wrote: > > Does 10.1 with vt in text mode support _all_ the following in rc.conf? > > scrnmap="koi8-u2cp866u" > font8x16="cp866u-8x16" > allscreens_flags="80x30" > keymap="ru.koi8-r" No, in text mode vt currently has support for cp437 only. vt(4) uses UTF-8 only right n

Re: [FreeBSD-Announce] FreeBSD bug tracking moves from GNATS to Bugzilla

2014-06-04 Thread Ed Maste
On 4 June 2014 06:34, Darren Pilgrim wrote: > > Requiring oauth will literally guarantee me and a whole bunch of other > people will never have bugzilla accounts. I don't think anyone's suggesting oauth would be required. It would just be available as an alternate method for those who don't want

sysutils/aaccli to be deprecated

2008-04-01 Thread Ed Maste
The sysutils/aaccli port is a precompiled binary for managing Adaptec aac(4) RAID cards. Unfortunately it's incompatible with some changes in Adaptec's latest drivers, needed for supporting their recent cards. It is also unmaintained and no longer being supported by Adaptec, and also is a Linux bi

Re: databases/unixODBC installs empty config files

2007-04-19 Thread Ed Maste
On Thu, Apr 19, 2007 at 03:12:53PM -0500, Scot Hetzel wrote: > You can't simply remove them from the plist, as those files (odbc.ini, > odbcinst.ini) are created by work/unixODBC-2.2.12/Makefile in the > install-data-am target. It's a shame that the target just touches the files to create empty o

databases/unixODBC installs empty config files

2007-04-19 Thread Ed Maste
The unixODBC port installs an etc/odbc.ini file which wipes out an existing config on install of a new package. (It's not even a sample config from the distribution; it's just an empty file created by virtue of existing in the plist it seems.) Can it just be removed from the plist: Index: pkg-pl