date:20180119

glib-compile-schemas

2018-01-19 Thread blubee blubeeme

I am building a gnome based port.

The port builds and installs successfully but it doesn't work.

Looking around I need to run glib-compile-schemas like this:

glib-compile-schemas /usr/local/share/glib-2.0/schemas/

After running that command the port works as expected, is there a standard
way to handle this in the port's Makefile?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

openshadinglanguage

2018-01-19 Thread Stari Karp

Hi!

The Openshadinglanguage doesn't build on my FreeBSD 11.1 RELEASE
(amd64):

===>   openshadinglanguage-1.8.10_6 depends on file:
/usr/local/sbin/pkg - found
===> Fetching all distfiles required by openshadinglanguage-1.8.10_6
for building
===>  Extracting for openshadinglanguage-1.8.10_6
=> SHA256 Checksum OK for imageworks-OpenShadingLanguage-Release-
1.8.10_GH0.tar.gz.
===>  Patching for openshadinglanguage-1.8.10_6
===>  Applying FreeBSD patches for openshadinglanguage-1.8.10_6
===>   openshadinglanguage-1.8.10_6 depends on executable: llvm-
config40 - found
===>   openshadinglanguage-1.8.10_6 depends on executable: bison -
found
===>   openshadinglanguage-1.8.10_6 depends on file:
/usr/local/bin/cmake - found
===>   openshadinglanguage-1.8.10_6 depends on executable: ninja -
found
===>   openshadinglanguage-1.8.10_6 depends on file:
/usr/local/lib/libncurses.so.6 - found
===>   openshadinglanguage-1.8.10_6 depends on file:
/usr/local/bin/ccache - found
===>   openshadinglanguage-1.8.10_6 depends on shared library:
libboost_thread.so - found (/usr/local/lib/libboost_thread.so)
===>   openshadinglanguage-1.8.10_6 depends on shared library:
libIlmImf.so - found (/usr/local/lib/libIlmImf.so)
===>   openshadinglanguage-1.8.10_6 depends on shared library:
libImath.so - found (/usr/local/lib/libImath.so)
===>   openshadinglanguage-1.8.10_6 depends on shared library:
libOpenImageIO.so - found (/usr/local/lib/libOpenImageIO.so)
===>  Configuring for openshadinglanguage-1.8.10_6
===>  Performing out-of-source build
/bin/mkdir -p /usr/ports/graphics/openshadinglanguage/work/.build
-- The C compiler identification is Clang 4.0.0
-- The CXX compiler identification is Clang 4.0.0
-- Check for working C compiler: /usr/local/libexec/ccache/cc
-- Check for working C compiler: /usr/local/libexec/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/local/libexec/ccache/c++
-- Check for working CXX compiler: /usr/local/libexec/ccache/c++ --
works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMake version is 3.10.1
-- Project build dir =
/usr/ports/graphics/openshadinglanguage/work/.build
-- CMAKE_CXX_COMPILER is /usr/local/libexec/ccache/c++
-- CMAKE_CXX_COMPILER_ID is Clang
-- Building for C++11
-- Setting Namespace to: 
-- platform = FreeBSD
-- Using OpenImageIO 1.7.17
-- LLVM version  = 4.0.1
-- Using clang internals for preprocessing
CMake Warning at /usr/local/share/cmake/Modules/FindBoost.cmake:801
(message):
  New Boost version may have incorrect or missing dependencies and
imported
  targets
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/FindBoost.cmake:906
(_Boost_COMPONENT_DEPENDENCIES)
  /usr/local/share/cmake/Modules/FindBoost.cmake:1541
(_Boost_MISSING_DEPENDENCIES)
  src/cmake/externalpackages.cmake:173 (find_package)
  CMakeLists.txt:358 (include)


CMake Warning at /usr/local/share/cmake/Modules/FindBoost.cmake:801
(message):
  New Boost version may have incorrect or missing dependencies and
imported
  targets
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/FindBoost.cmake:906
(_Boost_COMPONENT_DEPENDENCIES)
  /usr/local/share/cmake/Modules/FindBoost.cmake:1541
(_Boost_MISSING_DEPENDENCIES)
  src/cmake/externalpackages.cmake:173 (find_package)
  CMakeLists.txt:358 (include)


CMake Warning at /usr/local/share/cmake/Modules/FindBoost.cmake:801
(message):
  New Boost version may have incorrect or missing dependencies and
imported
  targets
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/FindBoost.cmake:906
(_Boost_COMPONENT_DEPENDENCIES)
  /usr/local/share/cmake/Modules/FindBoost.cmake:1541
(_Boost_MISSING_DEPENDENCIES)
  src/cmake/externalpackages.cmake:173 (find_package)
  CMakeLists.txt:358 (include)


CMake Warning at /usr/local/share/cmake/Modules/FindBoost.cmake:801
(message):
  New Boost version may have incorrect or missing dependencies and
imported
  targets
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/FindBoost.cmake:906
(_Boost_COMPONENT_DEPENDENCIES)
  /usr/local/share/cmake/Modules/FindBoost.cmake:1541
(_Boost_MISSING_DEPENDENCIES)
  src/cmake/externalpackages.cmake:173 (find_package)
  CMakeLists.txt:358 (include)


CMake Warning at /usr/local/share/cmake/Modules/FindBoost.cmake:801
(message):
  New Boost version may have incorrect or missing dependencies and
imported
  targets
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/FindBoost.cmake:906
(_Boost_COMPONENT_DEPENDENCIES)
  /usr/local/share/cmake/Modules/FindBoost.cmake:1541
(_Boost_MISSING_DEPENDENCIES)
  src/cmake/externalpackages.cmake:173 (find_package)
  CMakeLists.txt:358 (include)


CMake Warning at /usr/local/share/cmake/Modules/FindBoost.cmake:801
(message):

Re: mousepad memory leak

2018-01-19 Thread Guido Falsi

On 01/19/2018 08:41, Erich Dollansky wrote:
> Hi,
> 
> when I open more than nine or ten mousepads in parallel, I can still
> use one or two of the open windows but the other mousepad windows start
> to allocate memory until it is exhausted.

It's not easy to diagnose such a problem for people not knowing the
details of mousepad sources and the libraries it uses.

The people who are most able to help you are the XFCE guys (mousepad
being part of the xfce desktop). Is this issue FreeBSD specific? If not
you should definitely report this to the upstream developers.

I'll make a pair of tests in virtual machines to see what happens.

Can you confirm simple steps to reproduce as follows:

- Open 2 mousepad windows and open documents in them
- do some work in one or both
- wait, the leak happens in idle windows

have I correctly understood the problem?

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Can't makepatch to a port (graphics/py-gdal)

2018-01-19 Thread Sergey Akhmatov




On 19/01/2018 09:01, L.Bartoletti wrote:

Hi,

A dummy question, but, I haven't be able to make a simple patch to a 
port (graphics/py-gdal).


My patch (using diff -u) is:

   --- swig/include/gdal_array.i.orig  2018-01-19
   06:46:50.571482000 +0100
   +++ swig/include/gdal_array.i   2018-01-19 06:46:50.571393000 +0100
   @@ -1065,6 +1065,7 @@

     %pythoncode %{
     import numpy
   +from . import _gdal_array

     import gdalconst
     import gdal

> make makepatch

produces nothing

running the "make patch", I got

===>  Patching for py27-gdal-2.2.3
===>  Applying FreeBSD patches for py27-gdal-2.2.3
File to patch:

and unable to apply the patch.

Any hint?


Hello/

The port has
WRKSRC_SUBDIR=  swig/python

Everything, including 'make patch' is running inside this dir. 
swig/include is not there.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

mousepad memory leak

2018-01-19 Thread Erich Dollansky

Hi,

when I open more than nine or ten mousepads in parallel, I can still
use one or two of the open windows but the other mousepad windows start
to allocate memory until it is exhausted.

I am using FreeBSD 10.4 with mousepad 0.4.0 running under blackbox. It
is easy to reproduce by opening one mousepad window with one document
contained in one.

I am using mousepad on an older machine with only 4GB of RAM. On a
machine with more RAM, top looks like this after 12 mousepads have
been opened:

Swap: 16G Total, 1666M Used, 14G Free, 10% Inuse, 12K In

  PID JID USERNAMETHR PRI NICE   SIZERES STATE   C
TIMEWCPU COMMAND 

25003   0 erich 5  200   645M
425M kqread  2   5:53 100.39% mousepad 

11076   0 erich 3
220 46132K  3916K select  1   2:57 49.17% dconf-service

It is only one mousepad process eating up all the memory. It seems to
me random which of the mousepad processes can be used but this one
works normal while other do not react to any event. It stays then like
this until mousepad took all the swap space and RAM. It is not possible
to kill mousepad from blackbox but it is possible to kill mousepad from
top.

I know, it is a minor issue.

Erich
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

glib-compile-schemas

openshadinglanguage

Re: mousepad memory leak

Re: Can't makepatch to a port (graphics/py-gdal)

mousepad memory leak

5 matches

Site Navigation

Mail list logo

Footer information