On Mon, Feb 15, 2021 at 08:44:46PM -0800, Mark Millard wrote:
>
> Do you use:
>
> https://www.freshports.org/ports-mgmt/port-maintenance-tools/
>
First port installed on any system is pkg. Second port
installed is portmaster. Everything after that is installed
with portmaster.
--
Steve
On Mon, Feb 15, 2021 at 08:18:13PM -0800, Mark Millard wrote:
> Steve Kargl sgk at troutmask.apl.washington.edu wrote on
> Tue Feb 16 02:14:06 UTC 2021 :
>
> > On Mon, Feb 15, 2021 at 05:10:54PM -0800, Mark Millard via freebsd-ports
> > wrote:
>
On Mon, Feb 15, 2021 at 05:10:54PM -0800, Mark Millard via freebsd-ports wrote:
> Steve Kargl sgk at troutmask.apl.washington.edu wrote on
> Mon Feb 15 20:39:19 UTC 2021 :
>
> > Step 1). Install FreeBSD 13.0 on empty disk.
> > Step 2). Install git from ports and grab FreeB
On Mon, Feb 15, 2021 at 08:56:51PM +, RW via freebsd-ports wrote:
> On Mon, 15 Feb 2021 12:39:13 -0800
> Steve Kargl wrote:
>
>
> > BTW, there is no documentation as what 'pkg bootstrap -f'
> > does. In particular, the -f option is no descr
On Mon, Feb 15, 2021 at 12:01:47PM -0800, Kevin Oberman wrote:
> On Mon, Feb 15, 2021 at 11:10 AM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > I have a system installed from late January FreeBSD-current
> > sources and at that point an up-to-date por
I have a system installed from late January FreeBSD-current
sources and at that point an up-to-date ports tree. All
installed ports where builtin after I installed FreeBSD. So,
I am running FreeBSD-14.0. For some reason, I am getting
bogus warnings from pkg.
% pkg info > /dev/null
pkg: Warning:
On Sat, Dec 05, 2020 at 01:18:34AM -0800, Mark Millard wrote:
> Steve Kargl sgk at troutmask.apl.washington.edu wrote on:
> >
> > Well, I guess that pretty much kills LLVM_DEFAULT for any
> > modern hardware (even a 8 year old laptop) that uses drm
> > unless a user wan
On Fri, Dec 04, 2020 at 11:41:41PM +0100, Jan Beich wrote:
> Steve Kargl writes:
>
> > It takes a long time to compile on my laptop. I have
> >
> > DEFAULT_VERSIONS+=llvm=90
>
> Why do you need to redefine current default?
Simply changed /etc/make.conf on my lap
It takes a long time to compile on my laptop. I have
DEFAULT_VERSIONS+=llvm=90
in my /etc/make.conf. I go to update gnuplot and get
% portmaster -Byd gnuplot
...
Install devel/llvm10
...
Install devel/llvm90
Does it really take two versions of llvm to compile
gnuplot and depen
Someone ought to apply this patch to the openlibm port.
Index: Makefile
===
--- Makefile (revision 544886)
+++ Makefile (working copy)
@@ -16,6 +16,7 @@
BROKEN_armv6= fails to compile: a parameter list without types is only
allow
On Tue, Jul 21, 2020 at 11:33:13AM +0900, KIRIYAMA Kazuhiko wrote:
>
> lang/gcc9 depends devel/binutils with FLAVOR=native, so gcc9
> compilation stopped at devel/binutils. Why lang/gcc9 depends
> native-binutils ?
>
Just a guess. LTO.
--
Steve
___
On Tue, Jun 09, 2020 at 11:45:28PM -0600, @lbutlr wrote:
> This has happened in the past, but it happened again this weekend when an
> update to ;ibjson-c did not update bind, rendering bind unable to load
> libjson-c.so.4 because it had been replaced with libjson-c.so.5.
>
man libmap.conf
Thi
On Wed, Apr 01, 2020 at 08:01:35PM +0200, Dimitry Andric wrote:
>
> Yeah, this ncurses bump was handled pretty badly, as it breaks almost all
> installed ports (and a bunch of base programs too, if you are unlucky).
> Isn't there any compat package for it yet?
>
% cat /etc/libmap.conf
...
libncu
On Thu, Jan 02, 2020 at 12:22:20PM +0100, Stefan Eßer wrote:
> Am 01.01.20 um 22:04 schrieb Steve Kargl:
> > For users of mail/junkfilter, it now will filter all emails claiming
> > a "Bad Date line". The following patch seems to fix the problem for
> > the next de
For users of mail/junkfilter, it now will filter all emails claiming
a "Bad Date line". The following patch seems to fix the problem for
the next decade.
--- junkfilter.three.orig 2020-01-01 12:59:56.005681000 -0800
+++ junkfilter.three2020-01-01 13:00:26.254199000 -0800
@@ -56,7 +56,7
On Wed, Dec 25, 2019 at 07:05:50PM +, Montgomery-Smith, Stephen wrote:
>
> I agree with Franco. I am surprised that this error has been known for
> so long, and not fixed, when at least one effective solution exists.
>
Surely, you're joking. It took more than 2 years to get a 2-line
patch
On Tue, Dec 10, 2019 at 04:47:06PM -0800, Chris wrote:
> I struggled all day yesterday with various ports barfing with similar
> python messages. So today I blew everything off the disk, and started
> from scratch. Which only repeats what happened yesterday. Is python
> multiplicity no longer avail
On Fri, Dec 06, 2019 at 11:30:29PM +, Dima Pasechnik wrote:
> The patch in question is in Python 3.7, cf.
> https://github.com/python/cpython/pull/12046
> how about switching to this version?
>
Is 3.7 the default version of python used by ports?
How does switching fix ports that require 2.7?
On Fri, Dec 06, 2019 at 03:49:46PM -0700, Adam Weinberger wrote:
> On Fri, Dec 6, 2019 at 11:41 AM Steve Kargl
> wrote:
> >
> > This has been reported for many years and there are open bug reports.
> > Any chance that the this will be fixed.
> >
> &g
This has been reported for many years and there are open bug reports.
Any chance that the this will be fixed.
--- work/Python-3.6.9/Modules/mathmodule.c.orig 2019-12-06 10:33:39.232673000
-0800
+++ work/Python-3.6.9/Modules/mathmodule.c 2019-12-06 10:34:53.288616000
-0800
@@ -67,7 +67,7 @@
On Wed, Nov 27, 2019 at 02:03:33PM -0700, @lbutlr wrote:
> I thought that the maintainer of a port was listed somewhere in the files at
> user/ports//portbase/ but evidently not. What is the easiest way to
> find out, sitting in console on a server without a GUI, to find out who the
> maintainer
On Thu, Sep 26, 2019 at 06:18:17PM +0200, Willem Jan Withagen wrote:
>
> For building ceph14 in I need to use ld from the ports binutils.
> Mainly because of versioning that I can not get to work with the llvm
> linker, and is a know difference between GNU ld en LLVM ld.
>
> Just building in the
On Sat, Apr 13, 2019 at 10:59:41PM +0200, Dima Pasechnik wrote:
> On Sat, Apr 13, 2019 at 10:41 PM Steve Kargl
> >
> > How about taking the patch in my previous email, apply
> > to your tree (any port committer can take the patch),
> > and actually commit it!
> &
On Sat, Apr 13, 2019 at 08:49:43PM +0200, Dima Pasechnik wrote:
> On Sat, Apr 13, 2019 at 8:01 PM Steve Kargl
> >
> > My patches have absolutely nothing to do with making
> > 3.6 the default python version.
> >
> > I have added functions to libm that are include
several the patching doesn't
> appear to be complicated or difficult to maintain.
>
> > On Fri, Apr 12, 2019 at 02:58:22PM -0700, Steve Kargl wrote:
> > For those people following along in the mailing list, Dima
> > sent me a private reply that took this thre
On Fri, Apr 12, 2019 at 02:58:22PM -0700, Steve Kargl wrote:
> On Fri, Apr 12, 2019 at 11:18:50PM +0200, Dima Pasechnik wrote:
> >
> > So there is more "software bureaucracy" here than just applying one patch.
> >
>
> % cd /usr/ports/lang
> % s
On Fri, Apr 12, 2019 at 09:47:54PM -0700, bob prohaska wrote:
>
> Is there any hope of simply replacing python27 with python36? The
> goal at hand is merely to compile a working version of firefox.
>
In general, no. Python 2.7 and 3.6 are incompatible.
--
Steve
___
On Fri, Apr 12, 2019 at 06:45:41PM -0700, bob prohaska wrote:
> In tinkering with compiling firefox on an RPI2 attempts to use
> portmaster fail with
>
> ===> Registering installation for py36-setuptools-40.8.0_1
> Installing py36-setuptools-40.8.0_1...
> pkg-static: py36-setuptools-40.8.0_1 co
On Fri, Apr 12, 2019 at 11:18:50PM +0200, Dima Pasechnik wrote:
>
> So there is more "software bureaucracy" here than just applying one patch.
>
% cd /usr/ports/lang
% svn status
A python27/files/patch-Modules___mathmodule.c
A python35/files/patch-Modules___mathmodule.c
A pytho
On Fri, Apr 12, 2019 at 10:14:19PM +0200, Dima Pasechnik wrote:
> On Fri, Apr 12, 2019 at 9:57 PM Steve Kargl
> >
> > Doesn't matter what the python developer have done.
>
> Thanks, I see that you really appreciate my work...
>
Your work is appreciated as much as
On Fri, Apr 12, 2019 at 09:19:30PM +0200, Dima Pasechnik wrote:
> On Fri, Apr 12, 2019 at 6:29 PM Steve Kargl
> wrote:
> >
> > On Fri, Apr 12, 2019 at 09:17:42AM -0700, Steve Kargl wrote:
> > >
> > > % find . -name math\*
> > > ./work/Python-3.6.8/D
On Fri, Apr 12, 2019 at 09:17:42AM -0700, Steve Kargl wrote:
>
> % find . -name math\*
> ./work/Python-3.6.8/Doc/library/math.rst
> ./work/Python-3.6.8/Modules/mathmodule.c
> ./work/Python-3.6.8/Lib/test/math_testcases.txt
> ./work/stage/usr/local/lib/python3.6/test/math_test
On Fri, Apr 12, 2019 at 09:11:12AM -0700, Steve Kargl wrote:
> cd /usr/ports/lang/python36
> make && make install
>
> ===> Installing for python36-3.6.8_2
> ===> Checking if python36 is already installed
> ===> Registering installation for python36-3.6.8_2
cd /usr/ports/lang/python36
make && make install
===> Installing for python36-3.6.8_2
===> Checking if python36 is already installed
===> Registering installation for python36-3.6.8_2
pkg-static: Unable to access file
/usr/ports/lang/python36/work/stage/usr/local/lib/python3.6/lib-dynload/_as
On Fri, Apr 12, 2019 at 08:32:57AM -0700, bob prohaska wrote:
> Can anybody tell me how to fix an error reported by www/epiphany on an RPi2,
> "libicuuc.so.61" not found, required by "libephymisc.so" with the system
> at 11.2-STABLE #2 r345473 and ports at 498696 ?
>
> Both epiphany and icu are up
On Mon, Feb 25, 2019 at 01:58:01AM +, Dima Pasechnik wrote:
> On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl
>
> > Given that I actually don't
> > program in python, that certainly seems to be an unreasonable
> > request from the python maintainers.
>
> If
On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote:
> On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce wrote:
> > On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote:
> >> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl
> >> wrote:
> >>> O
On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote:
> On Fri, 22 Feb 2019, Tijl Coosemans wrote:
>
> > If I were the lang/gcc maintainer this -rpath problem would be my number
> > one priority. The current maintainer has never proposed any solutions
> > and when I submit patches he al
On Fri, Feb 22, 2019 at 07:09:11PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote:
> >
> > Because FreeBSD usurped the name of a well-known library from a
> > well-known open source project. Users might expect that that
>
On Fri, Feb 22, 2019 at 05:11:20PM +0100, Tijl Coosemans wrote:
> On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl
>
> > BTW, if you compare gcc trunks symbol map
> > ./x86_64-unknown-freebsd13.0/libgcc/libgcc.map
> > with src/lib/libgcc_s/Version.map, you'll find tha
On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
> On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov
> wrote:
> > Yes, we absolutely must avoid situation where two similar libraries
> > (i.e. providing some subset of symbols from other) are linked into the
> > same executing pro
On Fri, Feb 22, 2019 at 12:28:41PM +0100, Tijl Coosemans wrote:
> > PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16)
> > type.
>
> With my patch gfortran resolves the GCC_4.6.0 symbols statically just
> like the C compilers do. If the C compilers didn't do this we'd have
> this l
On Fri, Feb 22, 2019 at 09:32:03AM -0500, Ed Maste wrote:
> 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 co
On Thu, Feb 21, 2019 at 11:18:50PM +0100, Tijl Coosemans wrote:
> On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce wrote:
> > On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
> >> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote:
> >>> Except python doesn't have an rpath which is
On Thu, Feb 21, 2019 at 01:30:41PM -0500, Diane Bruce wrote:
>
> Yes yes and yes. It would be a right PITA. Perhaps it could be done
> with some weak symbols but personally I think that's another hack.
> I'll go look for whatever symbols we are missing and see if we
> can fix our libgcc_s
>
Dia
On Thu, Feb 21, 2019 at 10:24:51AM -0800, Steve Kargl wrote:
>
> As anyone tried adding an empty sections to FreeBSD's
> libgcc_s,
>
> /*
> * Empty sections to work around FreeBSD abusing the name
> * of a well-known GCC library.
> */
> GCC_4.6.0 {
figure
> out what question to ask, because, "libgcc_s? WTF?, this is python!"
> In addition, oftentimes people have sometimes big pipelines of
> different programs executing. So writing a shell script wrapper
> around each and every one of those custom programs... not going
On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote:
> > On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:
> >> So I must dig deeper. Perhaps with rpaths interacting with the system
> >> paths?
> >
> > You got it.
On Sun, Feb 17, 2019 at 12:37:36PM +0700, Eugene Grosbein wrote:
> 17.02.2019 12:11, Steve Kargl wrot:
>
> >
> > There is a problem with the order of libgcc_s.so.1
> > in the cache created by ldconfig. rtld will use
> > the first one it finds. If it fails, it f
On Sun, Feb 17, 2019 at 01:13:15PM +0700, Eugene Grosbein wrote:
> 17.02.2019 12:56, Steve Kargl wrote:
>
> >> 17.02.2019 12:11, Steve Kargl wrot:
> >>>
> >>> There is a problem with the order of libgcc_s.so.1
> >>> in the cache created by ld
On Sun, Feb 17, 2019 at 01:35:31PM +0700, Eugene Grosbein wrote:
> 17.02.2019 13:19, Steve Kargl wrote:
>
> > For whatever reason, there are situations where the rpath
> > isn't set in the library. Read the rtld manpage. You're
> > hitting #5 in the list.
>
On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:
>
> So I must dig deeper. Perhaps with rpaths interacting with the system
> paths?
>
Read the rtld manpage. You're hitting #5 in the list,
because the first 4 aren't satisified. Now, look at
'ldconfig -r | grep libgcc_s'.
--
On Sun, Feb 17, 2019 at 08:21:00AM +0700, Eugene Grosbein wrote:
>
> I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got
> this:
>
> # ldd /usr/local/lib/gcc8/libgfortran.so.5
> /usr/local/lib/gcc8/libgfortran.so.5:
> libquadmath.so.0 => /usr/local/lib/gcc8/libqua
On Sat, Feb 16, 2019 at 06:02:11PM -0700, Russell L. Carter wrote:
>
> /lib/libgcc_s.so.1 version GCC_4.8.0 required by
> /usr/local/lib/gcc8/libgfortran.so.5 not found
>
>
> Question to experienced porters, how is this best practice solved?
>
setenv LD_LIBRARY_PATH /usr/local/lib/gcc8
setenv
On Mon, Feb 11, 2019 at 08:20:20AM -0800, Steve Kargl wrote:
> On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote:
> > Anyone have any idea which recent change broke the
> > drm-legacy-kmod port. This is why I raised an issue
> > with removal of drm2 from src/sys.
On Mon, Feb 11, 2019 at 06:42:29PM +0100, Niclas Zeising wrote:
> >
> > The patch allows the port to be built.
> >
> > kldloading the i915kms module causes a 'black screen
> > of death'
> >
> Hi!
> I assume you load the kernel module either manually with kldload or
> using kld_list in rc.conf,
On Mon, Feb 11, 2019 at 06:42:29PM +0100, Niclas Zeising wrote:
> On 2/11/19 6:36 PM, Steve Kargl wrote:
> >
> > The patch allows the port to be built.
> >
> > kldloading the i915kms module causes a 'black screen
> > of death'
> >
> &g
On Mon, Feb 11, 2019 at 06:05:03PM +0100, Niclas Zeising wrote:
> On 2/11/19 5:20 PM, Steve Kargl wrote:
> > On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote:
> >> Anyone have any idea which recent change broke the
> >> drm-legacy-kmod port. This is why
On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote:
> Anyone have any idea which recent change broke the
> drm-legacy-kmod port. This is why I raised an issue
> with removal of drm2 from src/sys. How is suppose
> to be fixed?
>
It was r343567. The merging of PAE and N
Anyone have any idea which recent change broke the
drm-legacy-kmod port. This is why I raised an issue
with removal of drm2 from src/sys. How is suppose
to be fixed?
--- ttm_bo_manager.o ---
cc -O2 -pipe -march=core2 -fno-strict-aliasing -march=core2 -Werror -D_KERNEL
-DKLD_MODULE -nostdinc
On Mon, Feb 11, 2019 at 10:08:08AM +0100, Tijl Coosemans wrote:
> On Sun, 10 Feb 2019 15:18:20 -0800 Steve Kargl
> wrote:
> > On Sun, Feb 10, 2019 at 03:14:15PM -0800, Mark Millard wrote:
> >>
> >> /usr/ports/Mk/Uses/qt-dist.mk has:
> >>
> >> .
On Sun, Feb 10, 2019 at 03:14:15PM -0800, Mark Millard wrote:
>
> /usr/ports/Mk/Uses/qt-dist.mk has:
>
> .if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
> CONFIGURE_ARGS+=-no-sse2
> .endif
>
Hmmm. Oh well. I set CPUTYPE=core2 in /etc/make.conf.
During configure of qt5-gui, it
On Sun, Feb 10, 2019 at 10:32:50AM -0800, Steve Kargl wrote:
> On Sun, Feb 10, 2019 at 10:24:43AM -0800, Mark Millard wrote:
> >
> > My reference to building for armv7 not having a problem in
> > my builds is an example of a 32-bit-target context for
> > qt5-gui. So
On Sun, Feb 10, 2019 at 10:24:43AM -0800, Mark Millard wrote:
>
> My reference to building for armv7 not having a problem in
> my builds is an example of a 32-bit-target context for
> qt5-gui. So i386 specific or some other aspect of how its
> build was attempted might be involved in your context.
On Sun, Feb 10, 2019 at 02:56:17PM +, Carmel NY wrote:
> On Sun, 10 Feb 2019 06:40:01 -0800, Steve Kargl stated:
>
> >On Sun, Feb 10, 2019 at 08:31:12AM +0100, Tobias C. Berner wrote:
> >> Moin moin
> >>
> >> Make sure all your qt5-(qt5-gui dependency
On Sun, Feb 10, 2019 at 11:34:28AM -0200, Lucas Nali de Magalhães wrote:
> >
> > My lumina builds indirectly build qt5-qui and have been having
> > no problems (targeting amd64, aarch64, armv7, and powerpc64).
> > (My powerpc64 context is not normally gcc 4.2.1 based.)
> >
> > [...]
>
> So it lo
On Sun, Feb 10, 2019 at 08:31:12AM +0100, Tobias C. Berner wrote:
> Moin moin
>
> Make sure all your qt5-(qt5-gui dependency)-ports that are already
> installed are at 5.12.0.
>
The qt5 ports are up to date.
% cd /usr/ports
% svn update
% pkg delete -f qt5-\*
% cd x11-toolkits/qt5-gui
% make
(
On Sun, Feb 10, 2019 at 08:31:12AM +0100, Tobias C. Berner wrote:
> Moin moin
>
> Make sure all your qt5-(qt5-gui dependency)-ports that are already
> installed are at 5.12.0.
>
They are all up to date.
% cd /usr/ports
% svn update
% pkg delete -f qt5-\*
% portmaster -Byd x11-toolkits/qt5-gui
On Sat, Feb 09, 2019 at 07:32:27PM -0800, Steve Kargl wrote:
> Anyone have any pointers on building x11-toolkits/qt5-gui on
> FreeBSD-current? My attempts end with
>
> c++ -Wl,--as-needed
(boat load of info removed).
> qdrawhelper.cpp:(.text+0x2d0ba): undefin
Anyone have any pointers on building x11-toolkits/qt5-gui on
FreeBSD-current? My attempts end with
c++ -Wl,--as-needed -fstack-protector -Wl,--no-undefined
-Wl,--version-script,QtGui.version -pthread -Wl,-rpath,/usr/local/lib/qt5
-shared -Wl,-Bsymbolic-functions
-Wl,--dynamic-list,/usr/ports/x
On Wed, Dec 19, 2018 at 03:46:33AM +0900, Yasuhiro KIMURA wrote:
> From: Steve Kargl
> Subject: Re: devel/jsoncpp and staging?
> Date: Tue, 18 Dec 2018 10:07:05 -0800
>
> > Thanks for the pointer to email thread. Guess I'll
> > upgrade from 341703 to top-of-tree
On Wed, Dec 19, 2018 at 02:35:00AM +0900, Yasuhiro KIMURA wrote:
> From: Steve Kargl
> Subject: Re: devel/jsoncpp and staging?
> Date: Tue, 18 Dec 2018 08:21:46 -0800
>
> >> I cannot reproduce the error you encounter, what version of FreeBSD are
> >> you runni
On Tue, Dec 18, 2018 at 08:54:29AM +0100, Mathieu Arnold wrote:
> On Mon, Dec 17, 2018 at 07:25:10PM -0800, Steve Kargl wrote:
> > On Mon, Dec 17, 2018 at 05:48:57PM -0800, Steve Kargl wrote:
> > > I must be missing a change in how staging works.
> > >
> >
On Mon, Dec 17, 2018 at 05:48:57PM -0800, Steve Kargl wrote:
> I must be missing a change in how staging works.
>
> % cd /usr/ports/devel/jsoncpp
> % make
>
> ===> Staging for jsoncpp-1.8.1_5
> ===> Generating temporary packing list
> (cd /usr/ports/devel/json
I must be missing a change in how staging works.
% cd /usr/ports/devel/jsoncpp
% make
===> Staging for jsoncpp-1.8.1_5
===> Generating temporary packing list
(cd /usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/include/ && /bin/sh -c
'(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2
On Wed, Dec 12, 2018 at 10:29:59AM -0800, Kevin Oberman wrote:
> This morning the PORTREVISION on at least hundreds of ports was bumped
> because gcc8 was declared as the "canonical" version. As a result, I will
> have about 300 ports to rebuild which will take many hours.
> Why?
>
> If a port is
On Mon, Nov 26, 2018 at 07:33:12PM -0500, Diane Bruce wrote:
> On Mon, Nov 26, 2018 at 11:59:36PM +, Montgomery-Smith, Stephen wrote:
> >
> > Original error was: /lib/libgcc_s.so.1: version GCC_4.8.0 required by
> > /usr/local/lib/gcc7/libgfortran.so.4 not found
> >
> >
> > Any ideas?
>
>
On Tue, Nov 20, 2018 at 08:52:58AM -0800, bob prohaska wrote:
> On Mon, Nov 19, 2018 at 04:43:18PM -0800, Steve Kargl wrote:
> > On Mon, Nov 19, 2018 at 03:57:22PM -0800, bob prohaska wrote:
> > > Using pkg delete resolved the ImageMagick vs ImageMagic6 conflict,
> > >
On Mon, Nov 19, 2018 at 03:57:22PM -0800, bob prohaska wrote:
> Using pkg delete resolved the ImageMagick vs ImageMagic6 conflict, allowing
> inkscape to build successfully from ports on an RPI3.
>
> Alas, I somehow deleted libicuuc.so.62, causing a runtime failure. Rebuilding
> devel/icu got ver
On Fri, Oct 26, 2018 at 08:40:07PM +0200, Michael Gmelin wrote:
>
> > On 26. Oct 2018, at 20:03, Steve Kargl
> > wrote:
> >
> > I recently updated to pkg-1.10.5_5, and I now
> > find to command "pkg version -vl '<'" to be
> >
I recently updated to pkg-1.10.5_5, and I now
find to command "pkg version -vl '<'" to be
much slower than previous versions.
Four consecutive executions of "time pkg version -vl '<'"
yields
54.15 real27.28 user25.66 sys
48.80 real26.04 user23.01 sys
On Wed, Jun 13, 2018 at 12:32:28AM +, Montgomery-Smith, Stephen wrote:
> On 06/12/2018 04:20 PM, Steve Kargl wrote:
> > On Tue, Jun 12, 2018 at 08:28:07PM +, Montgomery-Smith, Stephen wrote:
> >>
> >> Or if you just send him a request without a patch, he may get
On Tue, Jun 12, 2018 at 08:28:07PM +, Montgomery-Smith, Stephen wrote:
>
> Or if you just send him a request without a patch, he may get
> around to it sometime.
This seems to work.
cd /usr/ports
svn merge -r 469260:469259 .
--
Steve
___
freebsd-
Is it possible to build math/octave with QT4?
The recent switch to require QT5 in r469260
leads to an unusable octave (unless one's
intention is to debug QT5).
% gdb81
/usr/local/libexec/octave/4.4.0/exec/amd64-portbld-freebsd12.0/octave-gui
octave-gui.core
> bt
#0 0x0002056b244d in QVarian
On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote:
> In review PR 228007, it came to my attention some individuals are
> mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
> issue". See
It seems we've had the same discussion 2 yea
On Thu, May 10, 2018 at 06:21:51PM +0200, Tijl Coosemans wrote:
> On Wed, 9 May 2018 16:45:51 -0700 Steve Kargl
> wrote:
> >
> > So, the runtime loader finds 6 instead of 716, tries to link,
> > fails, and issues an error message. There are a number ways to
> >
On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote:
> On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote:
> > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl <
> > s...@troutmask.apl.washington.edu> wrote:
> >
> > > In review PR 228007, it came
In review PR 228007, it came to my attention some individuals are
mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
issue". See
https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html
The problem can be summarized by the following
% gfortran7 -o z h.f90
% ./z
/
On Tue, May 01, 2018 at 02:57:16PM +1000, Dewayne Geraghty wrote:
> Thanks Steve, I have the same problem via gcc7 (after giving up on
> clang6). You might get a response to a PR. Sadly I
> just reverted both /usr/src and suitesparse, and moved on...
> as there are other problems with i386 and I s
On Tue, May 01, 2018 at 08:39:42AM +0200, Rainer Hurling wrote:
> Am 01.05.2018 um 05:40 schrieb Steve Kargl:
> > Can someone fix math/suitesparse?
> >
> > % make config
> >
> >
> > % make
> > ...
> >
> > h/suitesparse/wor
Can someone fix math/suitesparse?
% make config
% make
...
h/suitesparse/work/SuiteSparse/lib/libcholmod.so.3.0.12 -lm -lamd -lcolamd
-lsuitesparseconfig -lccolamd -lcamd -L/usr/local/lib -lmetis
-Wl,-rpath=/usr/local/lib/gcc7 -L/usr/local/lib/gcc7 -B/usr/local/bin
-L/usr/local/lib -fst
On Sat, Apr 14, 2018 at 02:30:09PM +, Carmel NY wrote:
> On Sat, 14 Apr 2018 14:18:22 +0200, Stefan Esser stated:
>
> {truncated}
>
> >This is another case (after the implementation of FLAVOR support that does
> >not seem well-designed and causes lots of effort and inefficiencies in port
> >m
On Fri, Feb 23, 2018 at 06:43:47PM +, Montgomery-Smith, Stephen wrote:
> Let me do it. I'm not at my FreeBSD computer right now, and
> I don't remember my committer password.
Thanks!
--
Steve
___
freebsd-ports@freebsd.org mailing list
https://list
Per Maho's request can someone please commit the patch at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225073
Maho has also asked to be dropped as maintainer.
--
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/l
On Mon, Jan 22, 2018 at 08:48:48AM -0800, bob prohaska wrote:
> > What happens if you force inclusion by deleting #ifdef HAVE_IEEEFP_H?
> >
> After commenting out the test, running make clean and restarting a single-
> threaded make the process stops with the same error:
>
> src/main.cpp:679:15:
On Sun, Jan 21, 2018 at 08:01:30AM -0800, bob prohaska wrote:
> On Sat, Jan 20, 2018 at 03:04:21PM -0800, Steve Kargl wrote:
> > On Sat, Jan 20, 2018 at 02:26:38PM -0800, bob prohaska wrote:
> > >
> > > use of undeclared identifier 'fpgetmask'
> &
On Sun, Jan 21, 2018 at 09:58:40AM -0800, bob prohaska wrote:
>
> Main.cpp contains a test:
>
> #ifdef HAVE_IEEEFP_H
> #include
> #endif
>
> and, in /usr/ports/graphics/inkscape/work/inkscape-0.92.2/include/config.h is
> found
>
> /* Define to 1 if you have the header file. */
> #define HAVE_
On Sat, Jan 20, 2018 at 02:26:38PM -0800, bob prohaska wrote:
>
> use of undeclared identifier 'fpgetmask'
>
> A web search for the phrase finds a very few references, most prominently
> from the year 2014:
> https://www.where-i-go.com/tag/fpsetmask
> but the context is different (mysql server).
On Sun, Jan 07, 2018 at 04:23:08AM +, Tatsuki Makino wrote:
> Hello.
>
> Are your portmaster outputting the following message?
>
> make: "/usr/ports/Mk/bsd.port.mk" line 1067: FLAVOR may not be
> passed empty as a make argument.
>
> When I tried portmaster -i cmake, portmaster always tries t
On Fri, Jan 05, 2018 at 10:50:11AM -0600, Rob Belics wrote:
> I'm sure I caused this problem when FLAVORS came out by trying to set a
> FLAVOR using "make". Using portmaster as I always have, py27-cffi and
> py27-setuptools update to the latest version that portsnap downloads but
> checking for new
1 - 100 of 249 matches
Mail list logo