Installing drm-current-kmod from ports

I've been reading the HEADSUP: drm-current-kmod thread, actually several times, and since my pkg install of plain vanilla drm-kmod was a dud after working for several weekly installs of 13.0-Current, it's clear I probably need to make install from the ports, which I have installed, as w

Re: head -r351102 amd64 rebuilding itself but via devel/xtoolchain-llvm90 ( rc2: ports head -r509054 ) fails for boot2.out: ld.lld: error: undefined symbol: __ashldi3

On Thu, Aug 15, 2019 at 7:09 PM Mark Millard wrote: > > My attempt to have -r351102 rebuild itself via devel/llvm90 (rc2) > got: > > --- all_subdir_stand --- > --- boot2.out --- > ld.lld: error: undefined symbol: __ashldi3 > >>> referenced by ufsread.c:234 (/usr/src/stand/libsa/ufsread.c:234) > >>

head -r351102 amd64 rebuilding itself but via devel/xtoolchain-llvm90 ( rc2: ports head -r509054 ) fails for boot2.out: ld.lld: error: undefined symbol: __ashldi3

My attempt to have -r351102 rebuild itself via devel/llvm90 (rc2) got: --- all_subdir_stand --- --- boot2.out --- ld.lld: error: undefined symbol: __ashldi3 >>> referenced by ufsread.c:234 (/usr/src/stand/libsa/ufsread.c:234) >>> boot2.o:(fsread) >>> referenced by ufsread.c:270 (/usr

Re: r343843 /usr/ports/ make install error: unable to create target: 'No available targets are compatible with this triple.'

On 08/02/2019 13:54, Mark Linimon wrote: On Fri, Feb 08, 2019 at 12:18:33PM +, Graham Perrin wrote: I still wonder whether these problems arose, somehow, from: 235215 – Bump LLVM_DEFAULT to 80 AFAIK that's still being tested (n

Re: r343843 /usr/ports/ make install error: unable to create target: 'No available targets are compatible with this triple.'

On Fri, Feb 08, 2019 at 12:18:33PM +, Graham Perrin wrote: > I still wonder whether these problems arose, somehow, from: > > 235215 – Bump LLVM_DEFAULT to 80 > AFAIK that's still being tested (not committed yet). mcl

Re: r343843 /usr/ports/ make install error: unable to create target: 'No available targets are compatible with this triple.'

27;s not possible to install from /usr/ports > … The lost ability to install from /usr/ports was quite show-stopping: 1) I could not build things such as gpu-firmware-kmod or    drm-legacy-kmod with the updated system; and 2) in the absence of properly built kernel modules, I could    not start

r343843 /usr/ports/ make install error: unable to create target: 'No available targets are compatible with this triple.'

Follow-up to <https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072768.html> > r343663 poudriere can not configure pkg It seems, the problems are not limited to my poudriere environment. Also, it's not possible to install from /usr/ports /usr/ports/graphic

Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"

>> FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . >>> This >>> was a rebuild based on going from perl5.26 to perl5.28 without updating the >>> ports >>> tree and from system clang 6 for the prior FreeBSD-head context used t

Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"

> details.] > > On 2018-Dec-19, at 12:20, Mark Millard wrote: > >> FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . >> This >> was a rebuild based on going from perl5.26 to perl5.28 without updating the >> ports >> tree and from system

Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"

[Looks like a race or some such for devel/qt5-testlib: retry of poudreire-devel did not hang. The other hang-up seems to be repeating and I give some details.] On 2018-Dec-19, at 12:20, Mark Millard wrote: > FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . >

FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"

FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . This was a rebuild based on going from perl5.26 to perl5.28 without updating the ports tree and from system clang 6 for the prior FreeBSD-head context used to clang 7 this time. (I'm not attributing causes here.) poud

Re: Ports build fails on 13-CURRENT r341690

From: Justin Hibbits Subject: Re: Ports build fails on 13-CURRENT r341690 Date: Wed, 12 Dec 2018 10:37:25 -0600 > I see the exact same problem on one of my powerpc64 machines (a > P5020-based machine). I see it intermittently on my POWER9, so thought > it was a race condition, but

Re: Ports build fails on 13-CURRENT r341690

: normal > Last Changed Author: kib > Last Changed Rev: 341690 > Last Changed Date: 2018-12-08 00:19:00 +0900 (Sat, 08 Dec 2018) > > yasu@rolling-vm-freebsd1[2020]% LANG=C svn info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn.free

Ports build fails on 13-CURRENT r341690

@rolling-vm-freebsd1[2020]% LANG=C svn info /usr/ports Path: /usr/ports Working Copy Root Path: /usr/ports URL: https://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 487116 Node Kind: directory

fetch: https://www.FreeBSD.org/ports/INDEX-13.bz2: Authentication error - portupgrade

Hi: Just upgraded a machine to 13-current: FreeBSD 13.0-CURRENT FreeBSD 13.0-CURRENT #18 r339556: Sun Oct 21 17:33:46 EDT 2018 root@sparc:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 130 I deleted /usr/ports and did a fresh svnlite co into /usr/ports. When trying to rebuild all

Re: poudriere extract failures with TAR=/usr/local/bin/gtar with gtar from ports

1_GH0.tar.gz. /bin/sh: /usr/local/bin/gtar: not found *** Error code 1 Stop. make: stopped in /usr/ports/devel/gflags =>> Cleaning up wrkdir ===>  Cleaning for gflags-2.2.1 build of devel/gflags | gflags-2.2.1 ended at Wed Oct 17 02:32:54 BST 2018 build time: 00:00:02 !!! build failure encounte

RE: poudriere extract failures with TAR=/usr/local/bin/gtar with gtarfrom ports

s the greed of the few. --- -Original Message- From: Graham Perrin Sent: 15/10/2018 22:19 To: freebsd-current@freebsd.org Subject: poudriere extract failures with TAR=/usr/local/bin/gtar with gtarfrom ports For example: > [00:01:10] [02] [00:00:19] Finished www/qt5-webkit | >

poudriere extract failures with TAR=/usr/local/bin/gtar with gtar from ports

/usr/local/etc/poudriere.d/make.conf     ICA_CERTS=/usr/ports/distfiles/QuoVadisRootCA2.crt DEFAULT_VERSIONS+= samba=4.8 # <https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071704.html> TAR=/usr/local/bin/gtar root@

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

00, Alex V. Petrov wrote: >>>>> Перенаправленное сообщение >>>>> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) >>>>> Дата: Tue, 21 Aug 2018 16:41:42 +0700 >>>>> От: Alex V. Petrov >>>>> Кому: Free

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

On 22/08/2018 16:29, Alan Cox wrote: All of kmem_alloc_attr(), kmem_alloc_contig(), and kmem_malloc() should have their first parameter, typically kernel_arena, but sometimes kmem_arena, removed in FreeBSD 12. There is still one more pending change to kmem_free() that has not hit HEAD yet. That

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

Перенаправленное сообщение ---- >>>> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) >>>> Дата: Tue, 21 Aug 2018 16:41:42 +0700 >>>> От: Alex V. Petrov >>>> Кому: FreeBSD Ports >>> Should be fixed as of r477761. >>

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

енаправленное сообщение >>>> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) >>>> Дата: Tue, 21 Aug 2018 16:41:42 +0700 >>>> От: Alex V. Petrov >>>> Кому: FreeBSD Ports >>> Should be fixed as of r477761. >>> >

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

On 22/08/2018 05:29, Manfred Antar wrote: On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev wrote: On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: Перенаправленное сообщение Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) Дата: Tue, 21 Aug 2018 16:41

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

On 08/21/2018 23:29, Manfred Antar wrote: > >> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev wrote: >> >> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: >>> Перенаправленное сообщение >>> Тема: nvidia-driver build error (

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev wrote: > > On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: >> >> Перенаправленное сообщение >> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) >> Дата: Tue, 21 Aug

Re: Fwd: nvidia-driver build error (last ports, FreeBSD-HEAD)

On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: > > Перенаправленное сообщение > Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) > Дата: Tue, 21 Aug 2018 16:41:42 +0700 > От: Alex V. Petrov > Кому: FreeBSD Ports Should be f

Fwd: nvidia-driver build error (last ports, FreeBSD-HEAD)

Перенаправленное сообщение Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) Дата: Tue, 21 Aug 2018 16:41:42 +0700 От: Alex V. Petrov Кому: FreeBSD Ports cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.77\" -D__KERNEL__ -DNVRM -Wno-unuse

Re: how to make ports not install xorg or dependencies

On Tue, Jul 31, 2018 at 01:13:31PM +0200, Miroslav Lachman wrote: > As Guido Falsi already said it is not guaranteed that you will not > have ports with some X libs, because some ports does not have option > to disable X11 dependencies. IMHO those ports have b

Re: how to make ports not install xorg or dependencies

using OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS for all of our packages (built with poudriere) As Guido Falsi already said it is not guaranteed that you will not have ports with some X libs, because some ports does not have option to disable X11 dependencies. Miroslav La

Re: how to make ports not install xorg or dependencies

On 7/31/18 12:49 PM, Guido Falsi wrote: > On 7/31/18 12:41 PM, tech-lists wrote: >> Hello, >> >> context: freebsd-12 r336215 arm64 >> >> I don't want xorg or X11 or any of its components installed on this >> system. I install ports in the traditional w

Re: how to make ports not install xorg or dependencies

On 7/31/18 12:41 PM, tech-lists wrote: > Hello, > > context: freebsd-12 r336215 arm64 > > I don't want xorg or X11 or any of its components installed on this > system. I install ports in the traditional way, in other words cd port > && make config &&

how to make ports not install xorg or dependencies

Hello, context: freebsd-12 r336215 arm64 I don't want xorg or X11 or any of its components installed on this system. I install ports in the traditional way, in other words cd port && make config && make install. Any ports that in a generic config want to install xorg li

Re: building ports (well, pkg) and make -j (even -j1 ) on a fast and64 machine: builds fail (head -r325997 context)

Mark Millard wrote: > [Plain "make" works (no -j ).] > > Is it expected that -j1 and the like get what I report below? A bug in the makefile (eg conflict b/w .ORDER and dependencies) will result in that sort of noise. -j1 is still jobs mode ___ freeb

building ports (well, pkg) and make -j (even -j1 ) on a fast and64 machine: builds fail (head -r325997 context)

[Plain "make" works (no -j ).] Is it expected that -j1 and the like get what I report below? (Other oddities with -j usage for port builds have been noted on an rpi2.) In /usr/ports/ports-mgmt/pkg : ( WRKDIRPREFIX?=/wrkdirs ) # make -j30 --- check-license --- ===> License BSD2CL

updating /usr/ports to HEAD in a jail r318593 (May 2017)

Hello, My poudriere oven runs as kernel: $ uname -a FreeBSD jet 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318593: Sun May 21 22:05:29 ... and I have a jail on it with exact this kernel r318593. Is it save to update ports in this jail to HEAD (as of today) or are there some incompatible changes in

Re: svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.freebsd.org/ports/head'

svnlite up > Updating '.': > svn: E170013: Unable to connect to a repository at URL > 'svn+ssh://svn.freebsd.org/ports/head' For ssh access, you probably are better off with repo.freebsd.org, per the committer's guide. -Ben

Re: svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.freebsd.org/ports/head'

>> Is it my personal problem/misconfig? >> >> --- >> % svnlite up >> Updating '.': >> svn: E170013: Unable to connect to a repository at URL >> 'svn+ssh://svn.freebsd.org/ports/head' > > For ssh access, you probably are better o

Re: svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.freebsd.org/ports/head'

26.10.2017 20:49, Kurt Jaeger пишет: > Hi! > >> Since a few days I can't update repository (info and cleanup works, >> but not update and commit) both at local and remote systems. >> >> Is it my personal problem/misconfig? > > At least it works here (.de). > > Maybe this *is* a SSH issue ? > >>

Re: svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.freebsd.org/ports/head'

Hi! > Since a few days I can't update repository (info and cleanup works, > but not update and commit) both at local and remote systems. > > Is it my personal problem/misconfig? At least it works here (.de). Maybe this *is* a SSH issue ? > svn: E210002: To better debug SSH connection problems,

svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.freebsd.org/ports/head'

Hi All, Since a few days I can't update repository (info and cleanup works, but not update and commit) both at local and remote systems. Is it my personal problem/misconfig? --- % svnlite up Updating '.': svn: E170013: Unable to connect to a repository at URL 'svn+ssh://s

Re: Ports still broken by ino64?

I'm sure stas can figure it out! -a On 25 June 2017 at 22:44, Thomas Mueller wrote: > from Adrian Chadd: > >> valgrind broke as part of the ino64 work :( > > Valgrind was not on my mind! Your post sent me to > > ls -d /usr/ports/*/val* > > to find va

Re: Ports still broken by ino64?

from Adrian Chadd: > valgrind broke as part of the ino64 work :( Valgrind was not on my mind! Your post sent me to ls -d /usr/ports/*/val* to find valgrind, and then read the pkg-descr. One less tool for getting debugging information when something crashes?

Re: Ports still broken by ino64?

Hi, valgrind broke as part of the ino64 work :( -a ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Ports still broken by ino64?

> Maybe not, but I think so. synth(8) requires the ada compiler which means > lang/gcc6-aux or lang/gcc5-aux and those DID require work to install on > ino64. I believe that this is now resolved, but I would seriously consider > simply installing synth from the package. It has no run or lib depends

Re: Ports still broken by ino64?

On Fri, Jun 23, 2017 at 8:19 PM, Thomas Mueller wrote: > On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller > wrote: > > > > I remember some ports on FreeBSD-current were rendered nonbuildable by > the > > > introduction of 64-bit inodes (ino64). > > > &g

Re: Ports still broken by ino64?

On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller wrote: > > I remember some ports on FreeBSD-current were rendered nonbuildable by the > > introduction of 64-bit inodes (ino64). > > What is the progress on resolving those snags? > > I haven't heard anything re

Re: Ports still broken by ino64?

On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller wrote: > I remember some ports on FreeBSD-current were rendered nonbuildable by the > introduction of 64-bit inodes (ino64). > > What is the progress on resolving those snags? > > I haven't heard anything recently and was una

Ports still broken by ino64?

I remember some ports on FreeBSD-current were rendered nonbuildable by the introduction of 64-bit inodes (ino64). What is the progress on resolving those snags? I haven't heard anything recently and was unable to find anything on wiki.freebsd.org. So how do I know the current status?

Re: [libltdl] removal from gnu ports

On Wed, Jun 07, 2017 at 11:33:32AM +0100, David Chisnall wrote: > On 7 Jun 2017, at 10:33, blubee blubeeme wrote: > > > > Hi > > > > I'm sure I was reading yesterday on a different machine about the linker > > flag -ld which has something to do with gnu dlopen and how it's ok to > > remove those

Re: [libltdl] removal from gnu ports

On 7 Jun 2017, at 10:33, blubee blubeeme wrote: > > Hi > > I'm sure I was reading yesterday on a different machine about the linker > flag -ld which has something to do with gnu dlopen and how it's ok to > remove those from your Makefile since FreeBSD handles dlopen and a few > other things from

[libltdl] removal from gnu ports

Hi I'm sure I was reading yesterday on a different machine about the linker flag -ld which has something to do with gnu dlopen and how it's ok to remove those from your Makefile since FreeBSD handles dlopen and a few other things from that header in the standard libc. Is that correct? I'm seeing

ports recently marked broken on -current

So during my pass over recent powerpc64 package errorlogs, I found a few ports that were actually broken across all archs on -current, and made those commits. I may not have enough cycles to investigate all these down by myself, so I'm asking for help. Does anyone recognize any of these fa

Re: ports-mgmt/pkg_rmleaves stops working properly on -head after bsdiff became default diff (r317209)

Revised like Boris did for misc/mc [1]. Now attached raw Makefile and patch (renamed), as patch does not handle new files on nonexistent files directory. :-( PORTREVISION bumped, as this port is small enough and NO_BUILD, and need updating for recent -head. But at least 2 ports is affected for

ports-mgmt/pkg_rmleaves stops working properly on -head after bsdiff became default diff (r317209)

Hi. Posting on freebsd-current as this only affects -head. I recently noticed ports-mgmt/pkg_rmleaves failes to process new leaf ports after removal of leaf ports on -head with error messages below. > diff: unrecognized option `--unchanged-line-format=' > usage: diff [-abdilpTtw] [-

arm64.aarch64: cross-compiling ports on AMD64 possible?

Hello, I've already successfully built a "world" and "kernel" on AMD64 (ath this place a thank-you for the developers!) using the port emulators/qemu_usr_static. /usr/src and /usr/ports are up to date on a daily basis. I use poudriere with a great success (and here again

Re: Ports not building due to release not supported

On 13/04/2017 21:50, mmu...@xtra.co.nz wrote: > I am unable to build ports as I am getting the error message – > Ports Collection support for your FreeBSD version has ended, and no ports are > guaranteed to build on this system. Please upgrade to a supported release. > > Bu

Ports not building due to release not supported

Hi, I am unable to build ports as I am getting the error message – Ports Collection support for your FreeBSD version has ended, and no ports are guaranteed to build on this system. Please upgrade to a supported release. But my version is FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r293851

Re: CURRENT: Compile time of ports has increased significantly since LLVM 4.0

There is a similar thread with subject: 'how to mark llvm* forbidden?' going on right now on this list. Regards, Ronald. On Mon, 10 Apr 2017 14:10:03 +0200, O. Hartmann wrote: We build pretty often world and ports. With poudriere as port building backend, The daily/weekly b

CURRENT: Compile time of ports has increased significantly since LLVM 4.0

We build pretty often world and ports. With poudriere as port building backend, The daily/weekly builds have now grown in compile time significantly since approx. the introduction of LLVM 4.0 into FreeBSD. The build box is a LGA1150 IvyBridge XEON system with 3,4 GHz and 16 GB RAM. The

Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min

t; > > > > > > > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017 > > > > amd64) is > > > > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, > > > > updating /usr/ports takes >25 min(!). That i

Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min

2 18:49:28 CET 2017 > > > amd64) is > > > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, > > > updating /usr/ports takes >25 min(!). That is an absolute record now. > > > > > > I do an almost daily update of world and ports tree and have

Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min

ZFS volume, > > updating /usr/ports takes >25 min(!). That is an absolute record now. > > > > I do an almost daily update of world and ports tree and have periodic > > scrubbing ZFS > > volumes every 35 days, as it is defined in /etc/defaults. Prts tree hasn'

Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min

On 2017-03-22 16:02, O. Hartmann wrote: > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017 > amd64) is > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, updating > /usr/ports > takes >25 min(!). That is an absolute record now. > &g

Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min

> On 22 Mar 2017, at 21:02, O. Hartmann wrote: > > CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017 > amd64) is > annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, updating > /usr/ports > takes >25 min(!). That is an absolute

CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min

CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017 amd64) is annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, updating /usr/ports takes >25 min(!). That is an absolute record now. I do an almost daily update of world and ports tree and have perio

Re: CFLAGS for certain ports

how well FreeBSD does as a workstation OS in the >>>> HPC world due to its stability and reliability, as well as LLVM/clang. >>>> I would like to know if FreeBSD has something similar to Gentoo's >>>> /etc/portage/make.conf file and /etc/portage/package.

Re: CFLAGS for certain ports

if FreeBSD has something similar to Gentoo's /etc/portage/make.conf file and /etc/portage/package.use/* files in order to compile certain ports with certain compiler flags. It doesn't, though it would certainly be nice to have something like it at some point. The current idiom is to put

Re: CFLAGS for certain ports

x27;s /etc/portage/make.conf file and /etc/portage/package.use/* files in order to compile certain ports with certain compiler flags. It doesn't, though it would certainly be nice to have something like it at some point. The current idiom is to put something similar to the following in

Re: CFLAGS for certain ports

like to know if FreeBSD has something similar to Gentoo's >> /etc/portage/make.conf file and /etc/portage/package.use/* files in >> order to compile certain ports with certain compiler flags. > > It doesn't, though it would certainly be nice to have something like it > at

Re: CFLAGS for certain ports

e/make.conf file and /etc/portage/package.use/* files in > order to compile certain ports with certain compiler flags. It doesn't, though it would certainly be nice to have something like it at some point. The current idiom is to put something similar to the following in your /etc/make.conf

CFLAGS for certain ports

something similar to Gentoo's /etc/portage/make.conf file and /etc/portage/package.use/* files in order to compile certain ports with certain compiler flags. Currently I mainly use CFLAGS="-O2 -pipe -mtune=native" for most of the applications, so nothing really aggressive (in general). I&

Re: HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild

On Tue, Feb 28, 2017 at 11:24:27PM +0100, Ed Schouten wrote: > 2017-02-28 21:00 GMT+01:00 Konstantin Belousov : > > Ideally, ports should stop shipping mangled system includes, or even better, > > gcc stop doing fixincludes. > > Amen. Please let me know the magic wand you

Re: HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild

2017-02-28 21:00 GMT+01:00 Konstantin Belousov : > Ideally, ports should stop shipping mangled system includes, or even better, > gcc stop doing fixincludes. Amen. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717

Re: HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild

On Tue, Feb 28, 2017 at 11:42:48AM -0800, Steve Kargl wrote: > r313194 defined vm_ooffset_t and vm_pindex_t in sys/types.h. > I believe that forces a recompile of lang/gcc ports, and > probably anything built with the lang/gcc port to avoid > dependency issue. Neither "pkg a

HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild

r313194 defined vm_ooffset_t and vm_pindex_t in sys/types.h. I believe that forces a recompile of lang/gcc ports, and probably anything built with the lang/gcc port to avoid dependency issue. Neither "pkg audit -q" nor "pkg version -vl '<'" pick up this issu

Re: -current with ports in endless loop

On Fri, 13 Jan 2017 14:13:51 -0300 "Nilton Jose Rizzo" wrote > I'm tring to instal xfce4 with optimazed options > but it's run in endless loop. How do I detect the ports > start a loop? If it's possible create a dot (.) > file in directory of port like .

-current with ports in endless loop

I'm tring to instal xfce4 with optimazed options but it's run in endless loop. How do I detect the ports start a loop? If it's possible create a dot (.) file in directory of port like .killloop like other .extrac.done to p

Re: A question about updating src & ports

gt; number of files. > Therefore, I switched to svn. > > Well, svn itself is pumping up /usr/ports/.svn where it keeps all logs. > Depending on the > frequency of updates it grows. I do the same for /usr/src and by the time of > fetching > almost every day several times a da

Re: A question about updating src & ports

On Thu, 29 Dec 2016 18:11:38 +0800 blubee blubeeme wrote: > Can I mix portsnap fetch update or should I just continue to use svn > update /usr/ports As a general rule don't mix methods in the same directory. ___ freebsd-current@freebsd.

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

wrote: > > > > > > > > > > > > Am Wed, 7 Dec 2016 23:31:01 +0100 > > > > Dimitry Andric schrieb: > > > >    > > > > > > > > > > On 07 Dec 2016, at 10:42, O. Hartmann > > > > > wrote:   &

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

On 29 Dec 2016, at 22:24, Ian Lepore wrote: > > On Thu, 2016-12-29 at 21:17 +0100, O. Hartmann wrote: >> Am Thu, 29 Dec 2016 20:26:32 +0100 >> Dimitry Andric schrieb: ... >>> Do you have some Linux rdma or infiniband headers or libraries >>> installed >>> into /usr or /usr/local? This might be

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

; > Dimitry Andric schrieb: > > >    > > > > > > > > On 07 Dec 2016, at 10:42, O. Hartmann > > > > wrote:   > > > > > > > > > > > > > > > I try my first steps in cross compiling ports with poudriere >

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

; > >>> I try my first steps in cross compiling ports with poudriere and > >>> therefore I try to > >>> setup an appropriate jail and QEMU environment. > >>> > >>> Well, I'm failing at the jail setup due to the non-exitence of any &g

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

; > >>> I try my first steps in cross compiling ports with poudriere and > >>> therefore I try to > >>> setup an appropriate jail and QEMU environment. > >>> > >>> Well, I'm failing at the jail setup due to the non-exitence of any &g

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

On 29 Dec 2016, at 17:29, O. Hartmann wrote: > > Am Wed, 7 Dec 2016 23:31:01 +0100 > Dimitry Andric schrieb: > >> On 07 Dec 2016, at 10:42, O. Hartmann wrote: >>> >>> I try my first steps in cross compiling ports with poudriere and therefore >>&g

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

Am Wed, 7 Dec 2016 23:31:01 +0100 Dimitry Andric schrieb: > On 07 Dec 2016, at 10:42, O. Hartmann wrote: > > > > I try my first steps in cross compiling ports with poudriere and therefore > > I try to > > setup an appropriate jail and QEMU environment. > >

Re: A question about updating src & ports

rld, > kernel, etc. > > Okay that part is fine > > I have a question about keeping ports up to date, in the past I did > portsnap fetch update to update the ports but since I totally deleted all > the ports and used svn checkout to get the latest ports. > > Can I mix ports

Re: A question about updating src & ports

gt; I have a question about keeping ports up to date, in the past I did > portsnap fetch update to update the ports but since I totally deleted all > the ports and used svn checkout to get the latest ports. > > Can I mix portsnap fetch update or should I just continue to use svn update >

Re: A question about updating src & ports

; I have a question about keeping ports up to date, in the past I did > portsnap fetch update to update the ports but since I totally deleted all > the ports and used svn checkout to get the latest ports. > > Can I mix portsnap fetch update or should I just continue to use svn update &g

A question about updating src & ports

Howdy I went through the process of building world for the first time, that was interesting but I got it. svn clean up prior object files, build world, kernel, etc. Okay that part is fine I have a question about keeping ports up to date, in the past I did portsnap fetch update to update the

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

On 07 Dec 2016, at 10:42, O. Hartmann wrote: > > I try my first steps in cross compiling ports with poudriere and therefore I > try to setup > an appropriate jail and QEMU environment. > > Well, I'm failing at the jail setup due to the non-exitence of any suitable >

emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

Hello out there. I try my first steps in cross compiling ports with poudriere and therefore I try to setup an appropriate jail and QEMU environment. Well, I'm failing at the jail setup due to the non-exitence of any suitable QEMU environment and for that I tried to figure out to find

Re: a dirty trick: i386 nanobsd ports on amd64

but I also needed a couple of ports installed, which for reasons of paperwork, must be compiled from source. Cross-compiling ports is not something I wanted to get into, but happily amd64 cpus can run in i386 mode these days: That is something poudriere is designed to do. i386 on amd64 is straight fo

a dirty trick: i386 nanobsd ports on amd64

I ran into a interesting problem, and want to share the solution, in case anybody else can use it. I'm upgrading a system which used to be i386 to amd64, but part of its job is to compile i386 nanobsd images. That's a solved problem, but I also needed a couple of ports installed,

Re: stable/11 -r307797 on BPi-M3 (cortex-a7): xgcc's cc1 during lang/gcc6 build gets SIGSYS failures (/usr/ports -r424540)

(signal 12) resulted. > > [I will note that I'v never seen this issue (so far) on the rpi2: This may be > KERNCONF=ALLWINNER specific. But I've not yet updated to -r307797 on the > rpi2. The BPI-M3 context is new for me; the rpi2 I've been using for a long > time

stable/11 -r307797 on BPi-M3 (cortex-a7): xgcc's cc1 during lang/gcc6 build gets SIGSYS failures (/usr/ports -r424540)

seen this issue (so far) on the rpi2: This may be KERNCONF=ALLWINNER specific. But I've not yet updated to -r307797 on the rpi2. The BPI-M3 context is new for me; the rpi2 I've been using for a long time.] This was under/on: root@bananapi-m3:/usr/ports # uname -apKU FreeBSD bananapi-m3 1

Re: Recent -CURRENT unable to build numerous ports

BLE, but this shows 10.3-STABLE? What is it? > ===> Registering installation for gettext-runtime-0.19.8.1 > pkg-static: Unable to access file > /usr/ports/devel/gettext-runtime/work/stage/usr/local/include/autosprintf.h: > No such file or directory > pkg-static: Unable to acc

Re: Recent -CURRENT unable to build numerous ports

On, Fri Oct 21, 2016, Dimitry Andric wrote: > On 21 Oct 2016, at 20:47, Marcus von Appen wrote: > > > > -CURRENT as of r307731 seems to have some serious flaw with its build > > tool environment. Many ports fail to build with some error similar to > > the following (de

Re: Recent -CURRENT unable to build numerous ports

LE FreeBSD 10.3-STABLE #0 r307759: Sat Oct 22 00:14:55 EDT 2016 aryehl@lilith:/usr/obj/usr/src/sys/GENERIC amd64 ===> Registering installation for gettext-runtime-0.19.8.1 pkg-static: Unable to access file /usr/ports/devel/gettext-runtime/work/stage/usr/local/include/autosprintf.h: No

Re: Recent -CURRENT unable to build numerous ports

On 21 Oct 2016, at 20:47, Marcus von Appen wrote: > > -CURRENT as of r307731 seems to have some serious flaw with its build > tool environment. Many ports fail to build with some error similar to > the following (devel/apr1): > > cc -emit-llvm -fno-strict-aliasing -

<    1   2   3   4   5   6   7   8   9   10   >