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
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
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
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
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
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.
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.
___
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
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
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
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
> 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.
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
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
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
(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
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
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
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
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
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
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.
_
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
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
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
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.
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
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
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
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
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
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
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
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
34 matches
Mail list logo