Re: Error reinstalling python 3.8.10 from ports

2021-05-19 Thread Gleb Popov
On Wed, May 19, 2021 at 6:55 PM Xavier Humbert  wrote:

> Hi,
>
> I got trouble with python 3.8.10 at reinstall stage :
>
> > ===>   Registering installation for python38-3.8.10
> > pkg-static: Unable to access file
> >
> /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_asyncio.cpython-38.so:No
>
> > such file or directory
> > pkg-static: Unable to access file
> >
> /usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_bisect.cpython-38.so:No
>
> > such file or directory
> And a bunch of others (the whole lib-dynload directory actually)
>
> In fact those files are almost present : the are not  named eg
> _asyncio.cpython-38.so , but asyncio.cpython-38*d*.so
>
> Where from comes this *d* letter, which is not in pkg-plist ?
>

Just a guess - are you building with WITH_DEBUG=yes ?
___
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: audio/alsa-plugins compiles OK, install fails

2021-05-12 Thread Gleb Popov
On Wed, May 12, 2021 at 3:01 PM Robert Huff  wrote:

> Stop.
> make[1]: stopped in /usr/ports/audio/alsa-plugins
> *** Error code 1
>

Hello. This is being worked on in https://reviews.freebsd.org/D30223
___
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: Changing daemon user, dir ownership and updating packages

2021-04-27 Thread Gleb Popov
On Mon, Apr 26, 2021 at 10:13 PM Dewayne Geraghty <
dewa...@heuristicsystems.com.au> wrote:

> On 26/04/2021 6:03 pm, Stefan Bethke wrote:
> > But that still leaves pkg updating the ownership/mode of existing
> directories as a surprise on updating a package. I think the "right" thing
> here would be a kind of three-way merge between changes an updated package
> brings in vs. changes the user has made on their system.
>
> Sometimes the right thing isn't easy ;)
>
> There are some cases where I explicitly assign ownership and more
> restrictive modes to installed ports.  Would "pkg add -I" prevent file
> ownership/mode changes or just prevent the execution of installation
> scripts... (hint for a flag to prevent file mode/ownership changes on
> existing systems)
>
> I suspect Gleb's paradigm of a separate file to explicitly control file
> attributes (after upgrades) is reasonable, but this is problematic and
> negates the value of a packaging system.
>

It only shifts the task of organizing runtime files/dirs to the software
upstream, which is a right thing, IMO. The same way we use automatic
pkg-plist generation for Python easyinstall-based ports.

That tmpfiles.d thing seems to be an established way to do that sort of
stuff in the Linux world, so I believe we should get on the train too.
___
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: Changing daemon user, dir ownership and updating packages

2021-04-26 Thread Gleb Popov
On Mon, Apr 26, 2021 at 11:03 AM Stefan Bethke  wrote:

> Am 13.04.2021 um 10:24 schrieb Stefan Bethke :
> >
> > As the maintainer, I've received this bug report:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255009
> >
> > If you'd like to run the daemon under a user different from the default
> git, you also need to change the ownership of the working directories,
> especially /var/*/gitea.
> >
> > The expectation is that upgrading the package will not change the
> ownership of already existing directories. When installing a newer version
> of the package, pkg appears to reset the ownership to those specified in
> the package.
> >
> > The pkg-plist has this:
> > @owner git
> > @group git
> > @dir /var/db/gitea
> > @dir /var/log/gitea
> > @dir /var/run/gitea
> >
> > I believe this to be best practice. Is there a better way to have pkg
> create these dirs if they're missing, but not touch them if they are there
> already?
>
> Adam has suggested a couple of approaches, but what I would really like is
> a common, documented way for ports to handle this situation.
>
> Updating ownership and mode of entries in the rc script automatically
> feels wrong to me, especially if it's a custom one-off for a single port.
> Kinda creating a POLA violation.
>
> I think as a general approach, checking that directories and files that
> the port knows will need to be writable for compatible access rights might
> be the safe choice.
>
> But that still leaves pkg updating the ownership/mode of existing
> directories as a surprise on updating a package. I think the "right" thing
> here would be a kind of three-way merge between changes an updated package
> brings in vs. changes the user has made on their system. That sound
> complicated to get right.
>
>
> Stefan
>
> --
> Stefan BethkeFon +49 151 14070811
>

I believe the general approach is what is called tmpfiles.d in systemd. It
is a startup script that reads configuration files installed by 3rd-party
software and creates file system hierarchies according to them. This is an
example of such configuration file:
https://github.com/Xpra-org/xpra/blob/master/fs/lib/tmpfiles.d/xpra.conf

Maybe we need to grow our own implementation of tmpfiles.d.
___
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: Firefox error

2021-04-19 Thread Gleb Popov
On Mon, Apr 19, 2021 at 8:52 AM The Doctor via freebsd-ports <
freebsd-ports@freebsd.org> wrote:

> Why am I getting:
>
> In file included from Unified_cpp_libsoundtouch_src0.cpp:47:
> /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/InterpolateShannon.cpp:71:9:
> warning: 'PI' macro redefined [-Wmacro-redefined]
> #define PI 3.1415926536
> ^
> /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/AAFilter.cpp:45:9:
> note: previous definition is here
> #define PI   M_PI
> ^
> In file included from Unified_cpp_image_decoders0.cpp:11:
> /usr/ports/www/firefox/work/firefox-88.0/image/decoders/nsAVIFDecoder.cpp:656:60:
> error: use of undeclared identifier 'AOM_PLANE_ALPHA'
>   MOZ_ASSERT(aImage->stride[AOM_PLANE_Y] ==
> aImage->stride[AOM_PLANE_ALPHA]);
>  ^
> /usr/ports/www/firefox/work/firefox-88.0/image/decoders/nsAVIFDecoder.cpp:656:60:
> error: use of undeclared identifier 'AOM_PLANE_ALPHA'
> In file included from Unified_cpp_libsoundtouch_src0.cpp:92:
> /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/cpu_detect_x86.cpp:48:12:
> warning: 'bit_MMX' macro redefined [-Wmacro-redefined]
> #define bit_MMX (1 << 23)
>^
> /usr/local/llvm11/lib/clang/11.0.1/include/cpuid.h:130:9: note: previous
> definition is here
> #define bit_MMX 0x0080
>^
> In file included from Unified_cpp_libsoundtouch_src0.cpp:92:
> /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/cpu_detect_x86.cpp:49:12:
> warning: 'bit_SSE' macro redefined [-Wmacro-redefined]
> #define bit_SSE (1 << 25)
>  ^
> /usr/local/llvm11/lib/clang/11.0.1/include/cpuid.h:133:9: note: previous
> definition is here
> #define bit_SSE 0x0200
>  ^
> In file included from Unified_cpp_libsoundtouch_src0.cpp:92:
> /usr/ports/www/firefox/work/firefox-88.0/media/libsoundtouch/src/cpu_detect_x86.cpp:50:12:
> warning: 'bit_SSE2' macro redefined [-Wmacro-redefined]
> #define bit_SSE2(1 << 26)
>   ^
> /usr/local/llvm11/lib/clang/11.0.1/include/cpuid.h:134:9: note: previous
> definition is here
> #define bit_SSE20x0400
> ^
> 4 warnings generated.
>
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist
> rising!
> Look at Psalms 14 and 53 on Atheism
> https://www.empire.kred/ROOTNK?t=94a1f39b
> When one lacks enemies, one can always make them.  -unknown
> ___
> 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"
>

Are you building the port on a live system? Try upgrading multimedia/aom
first.
___
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: FreeBSD Port: kf5-kparts-5.80.0 error update

2021-03-21 Thread Gleb Popov
On Sat, Mar 20, 2021 at 7:29 PM Alex V. Petrov 
wrote:

> What does dirty mean?
> I only update the previously installed ports (portmaster -a).
>
> What need do in my case?
>

Try `pkg delete -f kf5-kparts` and then `portmaster kf5-kparts` again.


> 20.03.2021 22:59, Adriaan de Groot пишет:
> > On Saturday, 20 March 2021 04:42:32 CET Alex V. Petrov wrote:
> >
> >> ===>>> Update for kf5-kparts-5.79.0 failed
> >> ===>>> Aborting update
> >
> > Looks like you're trying to install in a dirty (previous version is
> installed)
> > system. Please don't do that.
> >
> > The log isn't all that useful: it looks like the build is repeatedly
> > regenerating itself, which might be https://bugs.freebsd.org/bugzilla/
> > show_bug.cgi?id=239512 , but for that we'd need to know why the build is
> re-
> > generating.
> >
> > [ade]
> >
>
> --
> -
> Alex.
> ___
> 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"
>
___
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: Need some guidance on port Makefile with stage-qa errors

2021-02-17 Thread Gleb Popov
On Sun, Feb 14, 2021 at 6:52 AM Adam Jimerson  wrote:

> Hello,
>
> I'm working on making a new port and I have the Makefile and everything
> mostly
> done, but currently it is failing on stage-qa when ran through poudriere
> testport. The error that I get is as follows:
>
> Error: 'lib/python3.7/site-packages/adblock/__pycache__/
> __init__.cpython-37.pyc' is referring to /wrkdirs/usr/ports/www/py-adblock/
> work-py37/stage
>
>
Could it be that this file is actually a symlink? In this case you have to
fix its target.
___
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: CMAKE_PREFIX_PATH and /usr/local

2021-01-16 Thread Gleb Popov
On Sat, Jan 16, 2021 at 12:17 AM Tomasz CEDRO  wrote:

> On Fri, Jan 15, 2021 at 10:05 AM Gleb Popov wrote:
> > On Fri, Jan 15, 2021 at 12:50 AM Tomasz CEDRO wrote:
> >> Hello world :-)
> >> I am porting LimeSuite to FreeBSD. Local patch fixes missing
> >> "/usr/local/" path in CMakeLists.txt so the package now builds fine on
> >> FreeBSD. On Linux probably most of the libraries and includes are
> >> located in /usr/ do problem does not exist.
> >> Upstream has some objections to accept this patch and considers
> >> "/usr/local" a non-standard path [1]. But they propose to use
> >> CMAKE_PREFIX_PATH to add "/usr/local". This however does not seem to
> >> be supported in Ports (yet?).
> >> The question is how to tell CMake about "/usr/local/include" without
> >> source code modification? :-)
> >> Below is the proposed patch:
> >> > @@ -171,6 +171,11 @@ if (ENABLE_NEW_GAIN_BEHAVIOUR)
> >>  add_definitions(-DNEW_GAIN_BEHAVIOUR)
> >>  endif()
> >> +if (CMAKE_SYSTEM_NAME MATCHES "BSD")
> >> +include_directories("/usr/local/include")
> >
> > This is most certainly a wrong thing to do. Instead of simply adding
> -I/usr/local/include everywhere, you should fix problems for each
> dependency that the software requires.
> >
> > What error do you get without your patch?
>
> Hello Gleb :-) This seems the LimeSuite CMake issue not to use
> /usr/local/include where some GL includes are located. Without it
> there is a build problem as GL.h (something like this) is not found. I
> am not sure it this is the only occurrence of this symptom. Simply
> adding /usr/local/include solves the problem.
>

The correct fix is to call find_package(OpenGL) and then use variables it
sets.
___
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: CMAKE_PREFIX_PATH and /usr/local

2021-01-15 Thread Gleb Popov
On Fri, Jan 15, 2021 at 12:50 AM Tomasz CEDRO  wrote:

> Hello world :-)
>
> I am porting LimeSuite to FreeBSD. Local patch fixes missing
> "/usr/local/" path in CMakeLists.txt so the package now builds fine on
> FreeBSD. On Linux probably most of the libraries and includes are
> located in /usr/ do problem does not exist.
>
> Upstream has some objections to accept this patch and considers
> "/usr/local" a non-standard path [1]. But they propose to use
> CMAKE_PREFIX_PATH to add "/usr/local". This however does not seem to
> be supported in Ports (yet?).
>
> The question is how to tell CMake about "/usr/local/include" without
> source code modification? :-)
>
> Below is the proposed patch:
>
> > @@ -171,6 +171,11 @@ if (ENABLE_NEW_GAIN_BEHAVIOUR)
>  add_definitions(-DNEW_GAIN_BEHAVIOUR)
>  endif()
>
> +if (CMAKE_SYSTEM_NAME MATCHES "BSD")
> +include_directories("/usr/local/include")
>

This is most certainly a wrong thing to do. Instead of simply adding
-I/usr/local/include everywhere, you should fix problems for each
dependency that the software requires.

What error do you get without your patch?
___
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: gvfs delay on login?

2020-10-16 Thread Gleb Popov
On Fri, Oct 16, 2020 at 1:45 PM Christoph Moench-Tegeder 
wrote:

> Hi,
>
> ## Jonathan Chen (j...@chen.org.nz):
>
> > I recently updated my ports, and with the update of gvfs-1.46_1, I'm
> > noticing a 20s delay when I log in with mate-session. The closest
> > indication as to what may be the problem is in one of my logs:
> >
> > ** Message: 15:35:14.744: Initializing gksu extension...
> > Error creating proxy: Error calling StartServiceByName for
> > org.gtk.vfs.GoaVolumeMonitor: Timeout was reached (g-io-error-quark,
> > 24)
>
> Yes, that's the problem. The most basic workaround is to build
> gvfs without option GOA ("Gnome Online Accounts"), that's what
> I did (I don't use mate and don't have that specific login problem,
> but a lot of other stuff shows related troube, timouts, failures, ...).
>
> The real fix would be to figure out how to get the required dbus
> services running - gvfs source provides some systemd units, which
> are not that helpful for us (obvious reasons, yeah).
>

It is sufficient to provide service files to enable D-Bus autostart
functionality:
https://foss.heptapod.net/bsdutils/bsdisks/-/blob/branch/default/org.freedesktop.UDisks2.service.in
___
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: net/qt5-network

2020-07-08 Thread Gleb Popov
On Wed, Jul 8, 2020 at 4:28 PM Carmel NY  wrote:

> >On Wed, 8 Jul 2020 at 13:10, Carmel NY  wrote:
> >>
> >> FreeBSD 11.4-RELEASE
> >>
> >> With a freshly updated ports tree, when I attempt to run poudriere to
> >> update the installed ports, I am greeted with this warning:
> >>
> >> [00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is marked
> >> as broken: Qt5 requires Openssl 1.1.1, upgrade to FreeBSD 12.x/13.x
> >> or add DEFAULT_VERSIONS+=ssl=[openssl|libressl*] to /etc/make.conf
> >>
> >> Subsequently, 339 ports are skipped, and now I cannot get 'X' to
> >> start. I have "DEFAULT_VERSIONS+=ssl=openssl" in both the
> >> '/etc/make.conf' file and the 'poudriere.d/make.conf' file.
> >>
> >> $ openssl version
> >> OpenSSL 1.1.1g  21 Apr 2020
> >>
> >> I cannot install version 12 or 13 of FreeBSD because of an squashed
> >> bug, "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666;
> >>
> >> I have I correct this problem?
> >>
> >> Thanks
>
> On Wed, 8 Jul 2020 13:20:39 +0200, Tobias C. Berner stated:
> >Moin moin
> >
> >As you see the Ignore-message, I would say that your make.conf is not
> >used by poudriere.
>
> I think that is obvious. What I am trying to determine is how to
> correct the situation.
>

man poudriere, section "CUSTOMISATION", subsection "Create optional
make.conf"
___
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: Out of memory building lang/ghc-8.8.3

2020-05-05 Thread Gleb Popov
On Tue, May 5, 2020 at 1:37 PM andrew clarke  wrote:

> Beware anyone building lang/ghc-8.8.3 from the ports tree. Building it
> here on FreeBSD 12.1-REL AMD64 with Poudriere, the build ran out of swap,
> despite the PC having 8 GB RAM, 8 GB swap and not much else running.
>
> My /usr/local/etc/poudriere.conf:
>
> BASEFS=/poudriere
> ZPOOL=zroot
> FREEBSD_HOST=http://mirror.internode.net/
> POUDRIERE_DATA=/poudriere/data
> RESOLV_CONF=/etc/resolv.conf
> DISTFILES_CACHE=/usr/ports/distfiles
> USE_TMPFS=yes
> ALLOW_MAKE_JOBS=yes
> KEEP_OLD_PACKAGES=yes
> PARALLEL_JOBS=8
>
> Maybe I can retune the last three parameters to use less memory. I've not
> tried yet.
>
> This isn't really a whinge, I'm just surprised it failed. I'd have thought
> 8 GB was enough.
>
> (ghc is a build dependency of textproc/hs-pandoc)
>

Did you have something else building at the same time?

On my laptop with 16 Gb of RAM I also see OOM failures when building
multiple "heavy" packages (llvmXX, gccX, ghc, rust, libreoffice)
simultaneously. In this case I use -J poudriere option to limit number of
jobs.


> Cheers.
> ___
> 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"
>
___
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: How to use base OpenSSL with meson-based ports?

2020-04-01 Thread Gleb Popov
On Wed, Apr 1, 2020 at 8:43 AM Koichiro Iwao  wrote:

> In my ports, I patch configure.ac to find OpenSSL not relying on
> pkg-config.
>
>
> https://svnweb.freebsd.org/ports/head/net/xrdp/files/patch-configure.ac?revision=469777=markup#l8
>
> See also this.
>
>
> http://empt1e.blogspot.com/2011/05/dealing-with-pkg-config-detection-of.html
> https://github.com/neutrinolabs/xrdp/pull/514
>
>
Yes, I know how to deal with autotools. The problem is meson.

Maybe settings CFLAGS/LDFLAGS would help, indeed.

On Tue, Mar 31, 2020 at 11:24:58AM +0400, Gleb Popov wrote:
> > Hello.
> >
> > Meson build system uses pkg-config to locate dependencies. However,
> OpenSSL
> > in base does not provide a .pc file (unlike, say, zlib - see
> > /usr/libdata/pkgconfig/). I haven't found a way in meson to manually set
> up
> > a dependency in this case.
> >
> > I got a suggestion to write my own .pc file and hook it into the build of
> > my port, but this looks somewhat hackish for me. Why can't we provide a
> > proper .pc file in the base system?
> >
> > Thanks in advance.
> > ___
> > 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"
>
> --
> meta 
>
___
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"


How to use base OpenSSL with meson-based ports?

2020-03-31 Thread Gleb Popov
Hello.

Meson build system uses pkg-config to locate dependencies. However, OpenSSL
in base does not provide a .pc file (unlike, say, zlib - see
/usr/libdata/pkgconfig/). I haven't found a way in meson to manually set up
a dependency in this case.

I got a suggestion to write my own .pc file and hook it into the build of
my port, but this looks somewhat hackish for me. Why can't we provide a
proper .pc file in the base system?

Thanks in advance.
___
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: x11/xpra - anyone porting the Python3 version?

2020-02-24 Thread Gleb Popov
On Tue, Feb 25, 2020 at 12:00 AM Torfinn Ingolfsen  wrote:

> Hello,
> Is anyone working on a Python3 supported port of xpra?
> The homepage mentions that Python3 support was completed late
> September last year
>

You are welcome to test it: https://reviews.freebsd.org/D23743


> HAND
> --
> Regards,
> Torfinn Ingolfsen
> ___
> 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"
>
___
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: pkg install no longer works on my newly installed system

2020-02-04 Thread Gleb Popov
On Wed, Feb 5, 2020 at 12:48 AM Bob Willcox  wrote:

> On a newly installed 12.1 stable system for some reason I am now getting
> this error
> whenever I attempt to install any package via 'pkg install':
>
> root@jar-jar:1 /.amd_mnt/vader/host/stor/home/bob> pkg install ctags
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> The following 1 package(s) will be affected (of 0 checked):
>
> New packages to be INSTALLED:
> ctags: 5.8
>
> Number of packages to be installed: 1
>
> 125 KiB to be downloaded.
>
> Proceed with this action? [y/N]: y
> [1/1] Fetching ctags-5.8.txz: 100%  125 KiB 128.3kB/s00:01
> pkg: cached package ctags-5.8: size mismatch, fetching from remote
> Fetching ctags-5.8.txz: 100%  125 KiB 128.3kB/s00:01
> pkg: cached package ctags-5.8: size mismatch, cannot continue
>
> Previously I was able to install some packages on this system. I did
> update the
> system via downloading the src and building/installing world and a new
> kernel.
>
> Anyone have any idea what is wrong with my system now and how to fix it?
>
> Thanks,
> Bob
>

I wonder if https://github.com/freebsd/pkg/issues/1807 is related.


> --
> Bob Willcox| It's possible that the whole purpose of your life is to
> b...@immure.com | serve as a warning to others.
> Austin, TX |
> ___
> 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"
>
___
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"


math/hs-Agda: Need help with defining LICENSE

2019-06-03 Thread Gleb Popov
Hello.

I'm having troubles setting LICENSE properly for math/hs-Agda port. Its
LICENSE file looks like this:
https://hackage.haskell.org/package/Agda-2.6.0.1/src/LICENSE

I've figured out that I surely need LICENSE_COMB= multi, but I'm unsure of
the rest.

I'd be grateful, if someone would write LICENSE block for me.
___
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: The hs-* issue

2019-05-12 Thread Gleb Popov
On Sun, May 12, 2019 at 10:11 PM The Doctor 
wrote:

> On Sat, May 11, 2019 at 09:20:29PM +0400, Gleb Popov wrote:
> > On Sat, May 11, 2019 at 4:07 PM The Doctor 
> wrote:
> >
> > > On Sat, May 11, 2019 at 10:47:37AM +0400, Gleb Popov wrote:
> > > > On Sat, May 11, 2019 at 12:49 AM The Doctor <
> doc...@doctor.nl2k.ab.ca>
> > > > wrote:
> > > >
> > > > > On Fri, May 10, 2019 at 11:25:20PM +0400, Gleb Popov wrote:
> > > > > > On Fri, May 10, 2019 at 8:54 PM The Doctor via freebsd-ports <
> > > > > > freebsd-ports@freebsd.org> wrote:
> > > > > >
> > > > > >
> > > > > > Can't reproduce this locally. What FreeBSD version are you
> running,
> > > and
> > > > > > what SVN revision are you on?
> > > > > >
> > > > >
> > > > > FreeBSD 12.0
> > > > >
> > > > > svn, version 1.12.0 (r1857323)
> > > > >compiled Apr 26 2019, 08:07:07 on amd64-portbld-freebsd12.0
> > > > >
> > > >
> > > > I meant FreeBSD ports tree revision. Or are you using portsnap to
> obtain
> > > > ports tree?
> > > >
> > >
> > > portsnap!
> > >
> >
> > I'm puzzled what's wrong with your system. Things to try:
> >
> > 1. Do another `portsnap fetch update`.
> > 2. make -C /usr/ports/devel/hs-cabal-install clean
> > 3. Use binary package for hs-cabal-install.
>
> Where can I find a binary?
>

pkg install hs-cabal-install


> > 4. If nothing helps, provide me an ssh access to the problematic system.
> >
> >
>
___
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: The hs-* issue

2019-05-11 Thread Gleb Popov
On Sat, May 11, 2019 at 4:07 PM The Doctor  wrote:

> On Sat, May 11, 2019 at 10:47:37AM +0400, Gleb Popov wrote:
> > On Sat, May 11, 2019 at 12:49 AM The Doctor 
> > wrote:
> >
> > > On Fri, May 10, 2019 at 11:25:20PM +0400, Gleb Popov wrote:
> > > > On Fri, May 10, 2019 at 8:54 PM The Doctor via freebsd-ports <
> > > > freebsd-ports@freebsd.org> wrote:
> > > >
> > > >
> > > > Can't reproduce this locally. What FreeBSD version are you running,
> and
> > > > what SVN revision are you on?
> > > >
> > >
> > > FreeBSD 12.0
> > >
> > > svn, version 1.12.0 (r1857323)
> > >compiled Apr 26 2019, 08:07:07 on amd64-portbld-freebsd12.0
> > >
> >
> > I meant FreeBSD ports tree revision. Or are you using portsnap to obtain
> > ports tree?
> >
>
> portsnap!
>

I'm puzzled what's wrong with your system. Things to try:

1. Do another `portsnap fetch update`.
2. make -C /usr/ports/devel/hs-cabal-install clean
3. Use binary package for hs-cabal-install.
4. If nothing helps, provide me an ssh access to the problematic system.


> > > >
> > > > > --
> > > > > Member - Liberal International This is doctor@@nl2k.ab.ca Ici
> doctor@@
> > > > > nl2k.ab.ca
> > > > > Yahweh, Queen & country!Never Satan President Republic!Beware
> > > AntiChrist
> > > > > rising!
> > > > > https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and
> 53 on
> > > > > Atheism
> > > > > Newfoundland on 16 May 2019, do not vote PC nor NDP!
> > > > > ___
> > > > > 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"
> > > > >
> > > > ___
> > > > 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"
> > >
> > > --
> > > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> > > nl2k.ab.ca
> > > Yahweh, Queen & country!Never Satan President Republic!Beware
> AntiChrist
> > > rising!
> > > https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on
> > > Atheism
> > > Newfoundland on 16 May 2019, do not vote PC nor NDP!
> > >
> > ___
> > 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"
>
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist
> rising!
> https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on
> Atheism
> Newfoundland on 16 May 2019, do not vote PC nor NDP!
>
___
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: The hs-* issue

2019-05-11 Thread Gleb Popov
On Sat, May 11, 2019 at 12:49 AM The Doctor 
wrote:

> On Fri, May 10, 2019 at 11:25:20PM +0400, Gleb Popov wrote:
> > On Fri, May 10, 2019 at 8:54 PM The Doctor via freebsd-ports <
> > freebsd-ports@freebsd.org> wrote:
> >
> >
> > Can't reproduce this locally. What FreeBSD version are you running, and
> > what SVN revision are you on?
> >
>
> FreeBSD 12.0
>
> svn, version 1.12.0 (r1857323)
>compiled Apr 26 2019, 08:07:07 on amd64-portbld-freebsd12.0
>

I meant FreeBSD ports tree revision. Or are you using portsnap to obtain
ports tree?

> >
> > > --
> > > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> > > nl2k.ab.ca
> > > Yahweh, Queen & country!Never Satan President Republic!Beware
> AntiChrist
> > > rising!
> > > https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on
> > > Atheism
> > > Newfoundland on 16 May 2019, do not vote PC nor NDP!
> > > ___
> > > 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"
> > >
> > ___
> > 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"
>
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist
> rising!
> https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on
> Atheism
> Newfoundland on 16 May 2019, do not vote PC nor NDP!
>
___
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: The hs-* issue

2019-05-10 Thread Gleb Popov
On Fri, May 10, 2019 at 8:54 PM The Doctor via freebsd-ports <
freebsd-ports@freebsd.org> wrote:

> All right  you are getting rid of the hs-modules
>
> and getting us to use devel/stack.
>
> When I ran devel/stack this morning, I got:
>
>
> Script started on Fri May 10 10:32:32 2019
> root@doctor:/usr/ports/devel/stack # make
>
> mkdir -p /usr/ports/devel/hs-happy/work/cabal-home/.cabal
> touch /usr/ports/devel/hs-happy/work/cabal-home/.cabal/config
> ===>  Patching for hs-happy-1.19.9
> ===>  Applying FreeBSD patches for hs-happy-1.19.9
> ===>   hs-happy-1.19.9 depends on executable: cabal - not found
> ===>  Building for hs-cabal-install-2.4.0.0_1
> cd /usr/ports/devel/hs-cabal-install/work/cabal-install-2.4.0.0 &&
> /usr/bin/env EXTRA_CONFIGURE_OPTS="--disable-library-profiling"
> HOME=/usr/ports/devel/hs-cabal-install/work/home
> PREFIX=/usr/ports/devel/hs-cabal-install/work/prefix
> /usr/ports/devel/hs-cabal-install/work/cabal-install-2.4.0.0/bootstrap.sh
> --no-doc --jobs 1
> mktemp: illegal option -- p
> usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
>mktemp [-d] [-q] [-u] -t prefix
> Using clang for C compiler. If this is not what you want, set CC.
> Using /usr/bin/ld instead.
> Checking installed packages for ghc-8.6.3...
> deepseq is already installed and the version is ok.
> binary is already installed and the version is ok.
> time is already installed and the version is ok.
> transformers is already installed and the version is ok.
> mtl is already installed and the version is ok.
> text is already installed and the version is ok.
> parsec is already installed and the version is ok.
> network-uri-2.6.1.0 will be installed from local tarball.
> network-2.7.0.0 will be installed from local tarball.
> HTTP-4000.3.12 will be installed from local tarball.
> zlib-0.6.2 will be installed from local tarball.
> random-1.1 will be installed from local tarball.
> stm is already installed and the version is ok.
> hashable-1.2.7.0 will be installed from local tarball.
> async-2.2.1 will be installed from local tarball.
> base16-bytestring-0.1.1.6 will be installed from local tarball.
> base64-bytestring-1.0.0.1 will be installed from local tarball.
> cryptohash-sha256-0.11.101.0 will be installed from local tarball.
> resolv-0.1.1.1 will be installed from local tarball.
> mintty-0.1.2 will be installed from local tarball.
> echo-0.1.3 will be installed from local tarball.
> edit-distance-0.2.2.1 will be installed from local tarball.
> ed25519-0.0.5.0 will be installed from local tarball.
> tar-0.5.1.0 will be installed from local tarball.
> digest-0.0.1.2 will be installed from local tarball.
> zip-archive-0.3.3 will be installed from local tarball.
> hackage-security-0.5.3.0 will be installed from local tarball.
> Cabal is already installed and the version is ok.
>
> Using local tarball for network-uri-2.6.1.0.
> [1 of 1] Compiling Main ( Setup.hs, Setup.o )
> Linking Setup ...
> Setup: No cabal file found.
> Please create a package description file .cabal
>
> Error during cabal-install bootstrap:
> Configuring the network-uri package failed.
> *** Error code 2
>
> Stop.
> make[3]: stopped in /usr/ports/devel/hs-cabal-install
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/ports/devel/hs-happy
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/devel/hs-happy
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/devel/stack
> root@doctor:/usr/ports/devel/stack # exit
>
> exit
>
> Script done on Fri May 10 10:34:49 2019
>
> Any explanation?
>

Can't reproduce this locally. What FreeBSD version are you running, and
what SVN revision are you on?

>
> --
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@
> nl2k.ab.ca
> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist
> rising!
> https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on
> Atheism
> Newfoundland on 16 May 2019, do not vote PC nor NDP!
> ___
> 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"
>
___
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"


Request for wllvm port (should be trivial)

2019-04-02 Thread Gleb Popov
Hello.

I need the following python application as build dependency of a port I'm
wokring on: https://pypi.org/project/wllvm/

I think, it should be pretty easy to port, I just don't have much time for
it ATM. It would be awesome if someone would pick this up and create the
port for me.

Thanks in advance.
___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1

2019-03-30 Thread Gleb Popov
Sorry for being late to the party, but this Differential revision looks
related: https://reviews.freebsd.org/D11482
___
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: FreeBSD ports you maintain which are out of date

2019-03-17 Thread Gleb Popov
On Sun, Mar 17, 2019 at 1:08 AM Alfred Perlstein  wrote:

> How do I stop these emails?
>
> I just retired my commit bit and stopped committing to ports after some
> folks yelled at me for committing to ports without signoff even though I
> was doing ports before the src/ports split.
>
> thanks,
>
> -Alfred
>

Giving up commit bit doesn't mean you stop being maintainer. These mails
are sent to ports
maintainers, so if you don't want to receive them, reset MAINTAINER field
to po...@freebsd.org


>
>
>  Forwarded Message 
> Subject:FreeBSD ports you maintain which are out of date
> Date:   Thu, 14 Mar 2019 11:27:00 +
> From:   portsc...@freebsd.org
> To: alf...@freebsd.org
>
>
>
> Dear port maintainer,
>
> The portscout new distfile checker has detected that one or more of your
> ports appears to be out of date. Please take the opportunity to check
> each of the ports listed below, and if possible and appropriate,
> submit/commit an update. If any ports have already been updated, you can
> safely ignore the entry.
>
> You will not be e-mailed again for any of the port/version combinations
> below.
>
> Full details can be found at the following URL:
> http://portscout.freebsd.org/alf...@freebsd.org.html
>
>
> Port | Current version | New version
>
> +-+
> www/py-djangorestframework-filters | 0.10.2 | 0.11.0
>
> +-+
>
>
> If any of the above results are invalid, please check the following page
> for details on how to improve portscout's detection and selection of
> distfiles on a per-port basis:
>
> http://portscout.freebsd.org/info/portscout-portconfig.txt
>
> Thanks.
>
> ___
> 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"
>
___
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: OpenVPN produces garbage on TAP on -current

2018-08-06 Thread Gleb Popov
On Sun, Aug 5, 2018 at 11:51 PM, Lars Schotte  wrote:

> Here a bit of paste:
> https://paste.fedoraproject.org/paste/Hn4M2JqZ~5xccLWOVD1xUw/raw
> just to illustrate how it does not work.
>
> TAP device works good inside OS (FreeBSD current) however, everything
> that comes over OpenVPN is just garbage.
>

I'm using CURRENT from June 10 and tap device works fine for me with
OpenVPN 2.4.6_1


> --
>  Lars Schotte
>  Mudroňova 13
> 92101 Piešťany
> ___
> 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"
>
___
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: How to install phpMyAdmin as a package

2018-06-15 Thread Gleb Popov
On Fri, Jun 15, 2018 at 5:51 PM, Jos Chrispijn 
wrote:

> Sorry for asking as I think the question hasbeen raised some time
> before(ducking):
>
> Can somebody tell me how I can install phpMyAdmin from the packages?
> Seems that it is not partof the current pkg-repository:
>
>  pkg install phpmyadmin
>

pkg install -x phpmyadmin

Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> pkg: No packages available to install matching 'phpmyadmin' have been
> found in the repositories
>
> Thanks, Jos
>
>
> ___
> 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"
>
___
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"


Offload maintaining burden of Haskell packages to the Haskell community

2018-06-05 Thread Gleb Popov
[Resending to ports@ to gain wider audience]

Our ports tree contains 565 Haskell ports at the moment. Only 51 of them
are executables (like pandoc or cgrep), while other 500 are just
LIB_DEPENDS of those 51. Haskell packages are obtained from Hackage [1], a
package database much like Python's PyPI or Perl's CPAN. There was a reason
to have all these Haskell library ports in tree - Hackage provide no
guarantee that packages it holds can work together. It was easy to get into
"dependency hell" situation, for instance. Due to this, our ports tree was
playing a role of a "known-to-be-working subset of Hackage". Thanks to
poudriere and our package builders we were sure that all hs-* ports do work
together and there are no dependency issues.

Then, the Stackage [2] appeared. Stackage provides lists of Haskell package
sets known to be working together for a given compiler version. It is
solving the same problem we are solving in ports.

The last lang/ghc upgrade took about a month for me, as I was fighting
through */hs-* ports failures. The maintaining burden is too high and has
no sense, because we are duplicating the work that Stackage does.

So, my idea is simple:

1. Remove all */hs-* ports that are just library dependencies to other
*/hs-* .
2. Except, probably, ones that need patching.
3. Convert remaining (executable) */hs-* ports to use Stackage as
dependency source.

There is a problem, though. Unlike Python or Perl, Haskell is a compiled
language. This means that if we compile 2 apps that has, say, 100 Haskell
library dependencies, we would have to compile these 100 packages twice.
These deps would be statically linked into 2 both apps. There would be no
build-time sharing now. I think, when building straight from ports some
caching could be arranged, but I doubt it will work out for poudriere.

What do you all think of this? What cource of action should we take?

[1]: http://hackage.haskell.org/
[2]: http://stackage.org/
___
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: Runtime loader issue

2018-05-10 Thread Gleb Popov
On Thu, May 10, 2018 at 2:45 AM, Steve Kargl <
s...@troutmask.apl.washington.edu> 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
>
> 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
> /lib/libgcc_s.so.1: version GCC_4.8.0 required by \
>   /usr/local/lib/gcc7/libgfortran.so.4 not found
>
> gfortran7 is installed from ports/lang/gcc7.  This is not
> a "gfortran's FreeBSD issue".  This is a FreeBSD loader issue.
>
> Specifically, there is a shared library name clash.
>
> % ldconfig -r | grep gcc_
>  6:-lgcc_s.1 => /lib/libgcc_s.so.1
>716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1
>
> % ldd z
> z:
>libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000)
>libm.so.5 => /lib/libm.so.5 (0x200a17000)
>libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000)
>libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000)
>libc.so.7 => /lib/libc.so.7 (0x200ca3000)
>
> So, the runtime loader finds 6 instead of 716, tries to link,
> fails, and issues an error message.  There are a number ways to
> fix this issue.
>
> 1) By far, the best solution would be to stop hijacking the libgcc
>name in libraries installed on FreeBSD that are not related to
>actual GCC software.
>
> % ls -l /lib/libgcc* /usr/lib/libgcc*
> (trimming lines)
> /lib/libgcc_s.so.1
> /usr/lib/libgcc.a@ -> libcompiler_rt.a
> /usr/lib/libgcc_eh.a
> /usr/lib/libgcc_eh_p.a
> /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a
> /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1
>
>Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)?  Yes, I'm
>aware that clang does not work on all archs and the ancient gcc
>lives on.
>
> 2) Given the expected push back againt solution 1), this solution
>proposes bumping the library version for /lib/libgcc_s.so.1 from
>1 to some larger value, say, 10.  It is unlikely that GCC will
>bump its shared library number anytime soon.  GCC bumped it from
>0 to 1 some 16 years ago.
>
>https://gcc.gnu.org/viewcvs/gcc?view=revision=43316
>
>This solution, however, papers over the general problem with
>name clashes.
>
> 3) This solution is to actually fix the runtime loader.  If an error
>occurs with loading a shared library, then iterate over the entries
>in the hints file to check to see if another hint would satisfy
>the linking.  Here, instead of issuing the above error, the loader
>would find entry 716, and load the correct libgcc_s.so.1.
>
>Admittedly, I haven't looked to see how difficult this solution
>would be.
>
> 4) Bump the shared library number of the individual ports.  As a proof
>of concept, I've done this with ports/lang/gcc6.
>
> % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc
> --- libgcc/config/t-slibgcc.orig2018-05-08 12:47:42.334495000 -0700
> +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700
> @@ -20,7 +20,7 @@
>
>  SHLIB_EXT = .so
>  SHLIB_SOLINK = @shlib_base_name@.so
> -SHLIB_SOVERSION = 1
> +SHLIB_SOVERSION = 2
>  SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION)
>  SHLIB_MAP = @shlib_map_file@
>  SHLIB_OBJS = @shlib_objs@
>
> % ldconfig -r | grep gcc_
>  6:-lgcc_s.1 => /lib/libgcc_s.so.1
>716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1
>766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2
>
> % gfortran6 -o z h.f90
> % ./z
>  hello
> % ldd z
> z:
>libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000)
>libm.so.5 => /lib/libm.so.5 (0x20096c000)
>libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a)
>libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000)
>libc.so.7 => /lib/libc.so.7 (0x200df7000)
>
>This works for this particular name conflict.  Hopefully, FreeBSD
>never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2.  This,
>however, introduces an incompatibility with what is actually distributed
>by GCC.
>
> Finally, can people stop referring to the above error as
> "gfortran's FreeBSD issue".  This is a FreeBSD runtime loader issue.
>

Our libgcc also lacks some functionality compared to the original one:
https://reviews.freebsd.org/D11482


> --
> Steve
> ___
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
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: 6100 subdirectories in /usr/ports/devel!

2018-02-19 Thread Gleb Popov
On Mon, Feb 19, 2018 at 9:45 AM, Julian Elischer  wrote:

> On 29/12/17 5:16 am, Bob Willcox wrote:
>
>> On Fri, Dec 29, 2017 at 03:54:28AM +0700, Eugene Grosbein wrote:
>>
>>> 29.12.2017 3:36, Bob Willcox wrote:
>>>
>>> Does anyone else feel that having 6100 subdirectories (939 are for py-*
> stuff)
> is a bit excessive?
>
 It is. But py-* stuff has second place only:

 $ ls /usr/ports/devel | sed 's/-.*//' | sort | uniq -c | sort -rn | head
 1908 p5
   964 py
   600 rubygem
   280 hs
   176 pear
57 R
56 pecl
48 elixir
47 geany
43 erlang

>>> In fact, ports/devel is first but not only category having similar
>>> problem with p5-* stuff:
>>>
>>> $ cd /usr/ports
>>> $ find . -type d -mindepth 1 -maxdepth 1 | while read category; do
>>> printf "%15s " ${category#./}; ls $category | sed 's/-.*//' | sort | uniq
>>> -c | sort -rn | head -1; done | sort -k 2,2 -rn | head -15
>>>devel 1908 p5
>>>  www  807 p5
>>> textproc  617 p5
>>>  net  327 p5
>>>databases  259 p5
>>> security  258 p5
>>> math  146 p5
>>> mail  145 p5
>>> graphics  100 p5
>>>  editors   98 libreoffice
>>> sysutils   75 rubygem
>>>   converters   72 p5
>>> misc   63 p5
>>> net-mgmt   56 p5
>>> x11-toolkits   49 p5
>>>
>>> Yeah, I happened to notice the py-* stuff due to some problems I have
>> been
>> having with synth. I did notice the large number of p5-* subdirs but
>> didn't
>> count them.  :)
>>
>> Certainly seems to be out of control...
>>
>> the py and p5 stuff is a symptom of another problem, which is that we are
> only second level for those files...
>
> the correct behaviour in my point of view is for our packages/ports system
> to delegate to pypi or similar for python and to CPAN for perl.
>
> maybe with the ability to add some patches on the way through.. There is
> just too much going on there for us to follow properly.


I double this thought! This is what I'm goinf to head to with Haskell ports
one time.

There is a hitch, though. Hackage, the haskell package database, is a dump.
You easily can get a version clash between to packages. No one curates
them. So, while there was only Hackage maintaining hs- ports made sense -
we've been cheking all the packages we have to compile/work together. But
now Stackage emerged, which is a curated package DB, so our ports is a
duplicated work now. The port is only needed if it is not present on
Stackage or if it require FreeBSD specific patches that haven't been
upstreamed yet.

If PyPi and CPAN has the same notion of curated package set, we should not
duplicate this effort and remove much of our py- and p5- ports.


>
>
> ___
> 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"
>
___
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"


Mk/uses/ncurses.mk: NCURSESINC is broken?

2018-02-14 Thread Gleb Popov
This PR [1] brought my attention to the following problem with ncurses.mk.

The value of NCURSESINC can't be used as a value to -I compiler flag,
because in case of ports ncurses it is set to /usr/local/include/ncurses.
At the same time, /usr/local/include/ncurses/ncurses.h header includes
other headers in this way: #include  This implies
that -I/usr/local/include should be passed to the compiler, not
-I/usr/local/include/ncurses. Is it a bug, or I'm just missing something?

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225834
___
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: lang/ghc -8.0.2_2 mismatched checksums

2018-01-03 Thread Gleb Popov
On Wed, Jan 3, 2018 at 8:32 AM, Kevin Oberman  wrote:

> On Tue, Jan 2, 2018 at 4:42 AM, Mike Clarke 
> wrote:
>
> >
> > My daily periodic security run comes up with with these errors:
> >
> > Checking for packages with mismatched checksums:
> > ghc-8.0.2_2: /usr/local/bin/haddock
> > ghc-8.0.2_2: /usr/local/lib/ghc-8.0.2/package.conf.d/package.cache
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-33.h
> > tml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-36.h
> > tml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-43.h
> > tml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-46.h
> > tml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-58.h
> > tml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-60.h
> > tml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-61.h
> > tml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-62.h
> > tml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-92.h
> > tml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-A.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-All.
> > html
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-B.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-C.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-D.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-E.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-F.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-G.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-H.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-I.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-J.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-K.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-L.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-M.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-N.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-O.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-P.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-Q.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-R.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-S.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-T.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-U.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-V.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-W.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-Y.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2
> /html/libraries/doc-index-Z.ht
> > ml
> > ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2/html/libraries/index.html
> >
> > -- End of security output --
> >
> > I've reinstalled the package but still get the errors.
> >
> > curlew:/home/mike% pkg info  ghc
> > ghc-8.0.2_2
> > Name   : ghc
> > Version: 8.0.2_2
> > Installed on   : Mon Jan  1 09:35:19 2018 GMT
> > Origin : lang/ghc
> > Architecture   : FreeBSD:11:amd64
> > Prefix : /usr/local
> > Categories : haskell lang
> > Licenses   : BSD3CLAUSE
> > Maintainer : hask...@freebsd.org
> > WWW: http://www.haskell.org/ghc/
> > Comment: Compiler for the functional language Haskell
> > Options:
> > BOOT   : off
> > BOOTH  : off
> > DOCS   : on
> > DYNAMIC: on
> > PROFILE: on
> > Shared Libs required:
> > libgmp.so.10
> > libiconv.so.2
> > libcharset.so.1
> > Shared Libs provided:
> > libHSrts_thr-ghc8.0.2.so
> > libHSrts-ghc8.0.2.so
> > libHSfilepath-1.4.1.1-ghc8.0.2.so
> > libHSghc-boot-th-8.0.2-ghc8.0.2.so
> > libffi.so.6
> > libHSghc-prim-0.5.0.0-ghc8.0.2.so
> > libHSCabal-1.24.2.0-ghc8.0.2.so
> > libHSrts_thr_debug-ghc8.0.2.so
> > libHSrts_debug-ghc8.0.2.so
> > libHSpretty-1.1.3.3-ghc8.0.2.so
> > libHSarray-0.5.1.1-ghc8.0.2.so
> > libHStransformers-0.5.2.0-ghc8.0.2.so
> > 

Using lua and luajit.

2017-11-09 Thread Gleb Popov
Hello.

I'm working on porting Torch7, a scientific framework written in Lua:
https://reviews.freebsd.org/D12559

Torch7 has a generic install script and I'm using it to determine
dependencies need for the port. Amongst other things, Torch7 seems to
prefer LuaJIT over other lua implementations, so I decided to do the same.

The first problem I faced is lua.mk doesn't have any support for luajit. Is
there a reason for this? I have to manually define LUA_DIR and other vars,
because they gets defined only when using lua51 or lua52.

Another question is how to handle lua packages that can work with different
lua versions (like py27- and py36- ports, for instance). The example of
such port is devel/lua-Penlight, as you can see it is basically a bunch of
.lua files, which I decided to install everything into lua/5.1/ subdir.
What's proper way to handle this?

General comments on the review are also welcome.

Thanks in advance.
___
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: Firefox became much slower

2017-11-01 Thread Gleb Popov
On Wed, Nov 1, 2017 at 7:12 PM, Kevin Oberman  wrote:

> On Wed, Nov 1, 2017 at 8:15 AM, Andriy Gapon  wrote:
>
> > On 01/11/2017 14:18, Stefan Esser wrote:
> > > uMatrix has lots of pre-configured rules (blocks trackers and known
> > > malware sites), but I'm using it in conjunction with uBlock from the
> > > same developers.
> >
> > I used to use uBlock but at the time I got an impression that the addon
> > itself
> > ate away resources and slowed down my browser.
> > What's your impression of it at this time?
> >
> > Thank you.
> > --
> > Andriy Gapon
>
>
> When I had firefox slow dramatically,  I learned that quite a few
> extensions will disable multiprocessing. This can totally destroy the
> performance.
>
> Use about:support ti see if Multiprocess Windows is enabled. If not,
> disable add-ons until that changes.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> ___
> 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"
>

That was super useful suggestion. Thanks!
___
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"


Firefox became much slower

2017-11-01 Thread Gleb Popov
Hello.

I'm using Firefox on quite ancient machine (amd64, though) and after
updating from firefox-56.0.1_3 to 56.0.2_3,1 it has become much more
sluggish - whole UI hangs during page loading, scrolling isn't smooth
anymore.

Anyone also see this?
___
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: ports with no SONAME

2017-10-30 Thread Gleb Popov
On Mon, Oct 30, 2017 at 7:17 PM, blubee blubeeme 
wrote:

> Can anyone help with this library. I ran objdump on it and got this output
> --
> objdump -x work/stage/usr/local/lib/libtogl.so
>
> work/stage/usr/local/lib/libtogl.so: file format elf64-x86-64-freebsd
> work/stage/usr/local/lib/libtogl.so
> architecture: i386:x86-64, flags 0x0150:
> HAS_SYMS, DYNAMIC, D_PAGED
> start address 0x2980
>
> Program Header:
> LOAD off0x vaddr 0x paddr
> 0x align 2**21
>  filesz 0x70a8 memsz 0x70a8 flags r-x
> LOAD off0x70b0 vaddr 0x002070b0 paddr
> 0x002070b0 align 2**21
>  filesz 0x0a58 memsz 0x2a90 flags rw-
>  DYNAMIC off0x70f0 vaddr 0x002070f0 paddr
> 0x002070f0 align 2**3
>  filesz 0x0150 memsz 0x0150 flags rw-
>STACK off0x vaddr 0x paddr
> 0x align 2**3
>  filesz 0x memsz 0x flags rw-
>
> Dynamic Section:
>   NEEDED  libX11.so.6
>   NEEDED  libGL.so.1
>   NEEDED  libXmu.so.6
>   HASH0x120
>   STRTAB  0xe60
>   SYMTAB  0x458
>   STRSZ   0x60b
>   SYMENT  0x18
>   PLTGOT  0x207258
>   PLTRELSZ0x558
>   PLTREL  0x7
>   JMPREL  0x2088
>   RELA0x1470
>   RELASZ  0xc18
>   RELAENT 0x18
>   RELACOUNT   0x80
>
> Sections:
> Idx Name  Size  VMA   LMA   File off
>  Algn
>   0 .hash 0338  0120  0120  0120
>  2**3
>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   1 .dynsym   0a08  0458  0458  0458
>  2**3
>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   2 .dynstr   060b  0e60  0e60  0e60
>  2**0
>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   3 .rela.dyn 0c18  1470  1470  1470
>  2**3
>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 .rela.plt 0558  2088  2088  2088
>  2**3
>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   5 .plt  03a0  25e0  25e0  25e0
>  2**2
>   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   6 .text 350f  2980  2980  2980
>  2**4
>   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   7 .rodata   0a6d  5e90  5e90  5e90
>  2**4
>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   8 .eh_frame 07a8  6900  6900  6900
>  2**3
>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   9 .data.rel.ro  0040  002070b0  002070b0  70b0
>  2**4
>   CONTENTS, ALLOC, LOAD, DATA
>  10 .dynamic  0150  002070f0  002070f0  70f0
>  2**3
>   CONTENTS, ALLOC, LOAD, DATA
>  11 .got  0018  00207240  00207240  7240
>  2**3
>   CONTENTS, ALLOC, LOAD, DATA
>  12 .got.plt  01e0  00207258  00207258  7258
>  2**3
>   CONTENTS, ALLOC, LOAD, DATA
>  13 .data 06c8  00207440  00207440  7440
>  2**4
>   CONTENTS, ALLOC, LOAD, DATA
>  14 .bss  2030  00207b10  00207b10  7b08
>  2**4
>   ALLOC
>  15 .comment  0055      7b08
>  2**0
>   CONTENTS, READONLY
> SYMBOL TABLE:
> no symbols
>
> running the same code on libjpeg i see the SONAME field.
>
>  objdump -x /usr/local/lib/libjpeg.so
>
> /usr/local/lib/libjpeg.so: file format elf64-x86-64-freebsd
> /usr/local/lib/libjpeg.so
> architecture: i386:x86-64, flags 0x0150:
> HAS_SYMS, DYNAMIC, D_PAGED
> start address 0x4860
>
> Program Header:
> LOAD off0x vaddr 0x paddr
> 0x align 2**21
>  filesz 0x0007094c memsz 0x0007094c flags r-x
> LOAD off0x00071000 vaddr 0x00271000 paddr
> 0x00271000 align 2**21
>  filesz 0x0c40 memsz 0x0c48 flags rw-
>  DYNAMIC off0x000715c0 vaddr 0x002715c0 paddr
> 0x002715c0 align 2**3
>  filesz 0x01c0 memsz 0x01c0 flags rw-
> EH_FRAME off0x0006c8c0 vaddr 0x0006c8c0 paddr
> 0x0006c8c0 align 2**2
>  filesz 0x0bcc memsz 0x0bcc flags r--
>STACK off0x vaddr 0x paddr
> 0x align 2**3
>  

Using blaslapack

2017-10-16 Thread Gleb Popov
Hello.

I'm porting an application (DLib, https://reviews.freebsd.org/D12559) that
uses BLAS and LAPACK, and I have some questions.

1. Is there any pure C implementation that does not require Fortran
compiler?

2. My application looks for cblas_ddot function in BLAS library, but the
default library (netlib) doesn't seem to have that. It has ddot, though, so
I'm not sure if it is a wrong check on app's side, or netlib is indeed
doesn't suit there. For now I've used openblas, but I'm also not sure if it
is a right choice.

3. How to link properly to any of BLAS libraries? All BLAS implementations
blaslapack.mk features require Fortran. This implies USE_GCC=yes, so these
are compiled with GCC, not Clang. Now when I try to link Clang-compiled
DLib to GCC-compiled openblas, I get undefined references:

//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__getf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__floatunditf@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__subtf3@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__multf3@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__unordtf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__lttf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__addtf3@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__gttf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__divtf3@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__letf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__netf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__floatditf@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__eqtf2@GCC_4.6.0'
//usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
`__floatsitf@GCC_4.6.0'

I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there is
also /usr/lib/libgcc_s.so and it doesn't have such symbols. I suspect this
is the source of the error, but I wasn't able to fix it. Passing -Wl,-rpath
as advised by lang/gcc6 pkg-message doesn't help. The only workaround I
came up with is USE_GCC=yes to compile DLib itself, but that's pretty
unsatisfactory.

Thanks in advance.
___
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: Wxlua / Zbstudio

2016-07-07 Thread Gleb Popov
On Thu, Jul 7, 2016 at 6:51 PM, Torsten Zuehlsdorff <
mailingli...@toco-domains.de> wrote:

> Hello Raymond,
>
> I'm a developer of Lua/torch. Currently, I use Ubuntu to write my codes.
>> However, Ubuntu has frequent updates and make my environment unstable.
>>
>> I tried to install Ghost BSD and compile wxlua and zbstudio but both
>> failed. Do you have any plan to port these two to FreeBSD?
>>
>
> I started some work on an wxlua port. I got some small progress, but i'm
> hacking at this error:
>
> [  7%] Building CXX object
> modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxstc_bind.cpp.o
> In file included from
> /usr/ports/x11-toolkits/wxlua/work/wxLua-2.8.12.3-src/modules/wxbind/src/wxgl_bind.cpp:19:
> In file included from
> /usr/ports/x11-toolkits/wxlua/work/wxLua-2.8.12.3-src/modules/wxbind/include/wxgl_bind.h:47:
> In file included from /usr/local/include/wx-3.0/wx/glcanvas.h:192:
> In file included from /usr/local/include/wx-3.0/wx/gtk/glcanvas.h:14:
> /usr/local/include/wx-3.0/wx/unix/glx11.h:13:10: fatal error: 'GL/glx.h'
> file not found
> #include 
>
>
> Since i never wrote cmake ports before, i do not know how to tell cmake,
> that the file is there:
>
> $ ls -lah /usr/local/include/GL/glx.h
> -rw-r--r--  1 root  wheel14K  3 Jun 16:18 /usr/local/include/GL/glx.h
>
> Any idea?
>
> Until now i can say i just works with lua 5.1. 5.2 fails because of
> missing compat-mode. 5.3 is untested.
>
> Makefile of port looks currently like this:
>
> === Start ===
>
> PORTNAME=   wxlua
> PORTVERSION=2.8.12.3
> CATEGORIES= x11-toolkits
> MASTER_SITES=   SF/${PORTNAME}/${PORTNAME}/${PORTVERSION}
> DISTNAME= wxLua-${PORTVERSION}-src
>
> MAINTAINER= t...@freebsd.org
> COMMENT=Follows later
>
> RUN_DEPENDS=wxgtk30:x11-toolkits/wxgtk30
>
> CMAKE_ARGS=
>  -DwxWidgets_CONFIG_EXECUTABLE=/usr/local/bin/wxgtk2u-3.0-config
> CMAKE_ARGS+=-DwxLua_LUA_INCLUDE_DIR=${LUA_INCDIR}
> CMAKE_ARGS+=-DwxLua_LUA_LIBRARY=${LUA_LIBDIR}
> CMAKE_ARGS+=-DwxLua_LUA_LIBRARY_USE_BUILTIN=FALSE
>
> CMAKE_BUILD_TYPE=   Release
>
> USES=   cmake:outsource lua:51
>
> .include 
>
> .include 
>
> === End ===
>
> Greetings,
> Torsten
>
> ___
> 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"
>

I guess, USE_GL=gl
___
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: Please commit this maintainer times out patch: Bug 199364 - emulators/virtualbox-ose: Fix for the KDE dialog problem (edit)

2016-05-09 Thread Gleb Popov
On Tue, May 10, 2016 at 8:29 AM, Kurt Jaeger  wrote:

> Hi!
>
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199364
> >
> > It fixes the long standing problem of file dialog in VirtualBox UI under
> > kde.
>
> Done.
>
> --
> p...@opsec.eu+49 171 3101372 4 years to
> go !
> ___
> 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"
>

That bug was pretty annoying, thanks.
___
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: deskutils/owncloudclient dumps core

2015-05-20 Thread Gleb Popov
On Wed, May 20, 2015 at 1:42 AM, Guido Falsi m...@madpilot.net wrote:

 On 05/20/15 00:24, Guido Falsi wrote:
  On 05/19/15 14:50, Tobias Berner wrote:
  Hi
 
 
 
  The problem imho is, that it mixes qt4 and qt5.
 
  Easiest work around is just to build the qt5 gui -- that's what
 
  I've been doing for a year now.
 
 
 
  How do you compile against qt5?
 
  At present the security/qtkeychain port is quite updated and inadequate.
  It's impossible at present to have it installed for both qt4 and qt5.
 
  Now that I've looked at it I suspect that's the real cause of problems
  and what makes qt5 symbols get mixed in. If qt is present qtkeychain
  will happily pick up that one.
 
  This would also explain why the bug does not show up in poudriere built
  ports.

 A quick test on my machine which showed the problem exposed that the
 cause of the problem is really in qtkeychain.

 I'll perform a quick fix for that, to avoid the core dump. A better
 solution (both ports able to build both on qt4 and qt5) will require
 some more time.


I've created a PR to update both owncloudclient and qtkeychain to their
recent versions, but it's stalled for a month:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198785


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

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


Re: FreeBSD Port: valgrind-3.10.0.20150126_1,1

2015-04-09 Thread Gleb Popov
On Thu, Apr 9, 2015 at 2:17 PM, Pracheth Javali prach...@juniper.net
wrote:

 Hey,

 Is there a valgrind port for mips64/freebsd platform?


 Regards,
 Pracheth



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


Our intelligence reports there is an development repo:
https://bitbucket.org/stass/valgrind-freebsd/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Enlightenment

2015-04-02 Thread Gleb Popov
On Sat, Feb 28, 2015 at 7:21 PM, cpet c...@sdf.org wrote:

 On 2015-02-28 07:21, Amit Sengupta wrote:

 Hi Chris,

 I have been using Enlightenment for a while now and I do like it the best
 of all Window Managers. However as you already know it has some quirks, so
 it would be great if someone takes the trouble of trying to fix them. I
 can
 send bug reports or related inputs if it helps.

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


 Send issues on the github project named EPorts please. so once of us can
 fix them.

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


Is this initiative still active? I've made a pull request and i have more
patches in queue, but no one seems to be around.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Update editors/abiword to 3.0.1

2015-03-31 Thread Gleb Popov
On Tue, Mar 31, 2015 at 6:00 PM, Ben Woods woods...@gmail.com wrote:

 I am trying to update editors/abiword from 2.8.6 to 3.0.1.

 Part way through compiling my new test port, I get the following errors:

 gmake[7]: Entering directory
 '/wrkdirs/usr/ports/editors/abiword/work/abiword-3.0.1/src/text/fmt/xp'
   CXX  fl_Squiggles.lo
   CXX  fb_Alignment.lo
 In file included from fb_Alignment.cpp:22:
 ./fb_Alignment.h:114:8: warning: private field 'm_iSpaceCountLeft' is
 not used [-Wunused-private-field]
 int m_iSpaceCountLeft;
 ^
 ./fb_Alignment.h:115:8: warning: private field 'm_iSpaceCount' is not
 used [-Wunused-private-field]
 int m_iSpaceCount;
 ^
 2 warnings generated.
   CXX  fb_ColumnBreaker.lo
 In file included from fb_ColumnBreaker.cpp:22:
 ./fb_ColumnBreaker.h:53:24: warning: private field 'm_pCurrentBlock'
 is not used [-Wunused-private-field]
 fl_BlockLayout *  m_pCurrentBlock;
   ^
 1 warning generated.
   CXX  fb_LineBreaker.lo
   CXX  fg_Graphic.lo
   CXX  fg_GraphicRaster.lo
   CXX  fg_GraphicVector.lo
   CXX  fl_AutoLists.lo
   CXX  fl_AutoNum.lo
   CXX  fl_BlockLayout.lo
   CXX  fl_ContainerLayout.lo
   CXX  fl_DocLayout.lo
   CXX  fl_DocListener.lo
   CXX  fl_FootnoteLayout.lo
   CXX  fl_FrameLayout.lo
   CXX  fl_Layout.lo
   CXX  fl_SectionLayout.lo
   CXX  fl_SelectionPreserver.lo
   CXX  fl_TableLayout.lo
   CXX  fl_TestRoutines.lo
   CXX  fl_TOCLayout.lo
 In file included from fl_TOCLayout.cpp:32:
 ./fl_TOCLayout.h:82:20: warning: private field 'm_iStartAt' is not
 used [-Wunused-private-field]
 UT_sint32 m_iStartAt;
   ^
 1 warning generated.
   CXX  fp_AnnotationRun.lo
   CXX  fp_RDFAnchorRun.lo
 In file included from fp_RDFAnchorRun.cpp:23:
 In file included from ./fp_Run.h:33:
 In file included from ../../../../src/af/util/xp/ut_misc.h:39:
 In file included from /usr/include/c++/v1/string:439:
 In file included from /usr/include/c++/v1/algorithm:627:
 In file included from /usr/include/c++/v1/memory:601:
 /usr/include/c++/v1/__functional_base:63:21: error: invalid operands
 to binary expression ('const PD_URI' and 'const PD_URI')
 {return __x  __y;}
 ~~~ ^ ~~~
 /usr/include/c++/v1/map:457:17: note: in instantiation of member
 function 'std::__1::lessPD_URI::operator()' requested here
 {return static_castconst _Compare(*this)(__x.__cc.first,
 __y.__cc.first);}
 ^
 /usr/include/c++/v1/__tree:1573:29: note: in instantiation of member
 function 'std::__1::__map_value_comparePD_URI,
 std::__1::__value_typePD_URI, PD_Object, std::__1::lessPD_URI,
 true::operator()' requested here
 if (__hint == end() || !value_comp()(*__hint, __v))  // check before
 ^
 /usr/include/c++/v1/__tree:1912:36: note: in instantiation of member
 function 'std::__1::__treestd::__1::__value_typePD_URI, PD_Object,
 std::__1::__map_value_comparePD_URI, std::__1::__value_typePD_URI,
 PD_Object, std::__1::lessPD_URI, true,
 std::__1::allocatorstd::__1::__value_typePD_URI, PD_Object 
 ::__find_leaf' requested here
 __node_base_pointer __child = __find_leaf(__p, __parent, __v);
^
 /usr/include/c++/v1/map:1779:25: note: in instantiation of member
 function 'std::__1::__treestd::__1::__value_typePD_URI, PD_Object,
 std::__1::__map_value_comparePD_URI, std::__1::__value_typePD_URI,
 PD_Object, std::__1::lessPD_URI, true,
 std::__1::allocatorstd::__1::__value_typePD_URI, PD_Object 
 ::__insert_multi' requested here
 __tree_.__insert_multi(__e.__i_, *__f);
 ^
 /usr/include/c++/v1/map:1612:13: note: in instantiation of function
 template specialization 'std::__1::multimapPD_URI, PD_Object,
 std::__1::lessPD_URI, std::__1::allocatorstd::__1::pairconst
 PD_URI, PD_Object 

 ::insertstd::__1::__map_const_iteratorstd::__1::__tree_const_iteratorstd::__1::__value_typePD_URI,
 PD_Object, std::__1::__tree_nodestd::__1::__value_typePD_URI,
 PD_Object, void * *, long  ' requested here
 insert(__m.begin(), __m.end());
 ^
 ../../../../src/text/ptbl/xp/pd_DocumentRDF.h:198:18: note: in
 instantiation of member function 'std::__1::multimapPD_URI,
 PD_Object, std::__1::lessPD_URI,
 std::__1::allocatorstd::__1::pairconst PD_URI, PD_Object 
 ::multimap' requested here
 class ABI_EXPORT PD_RDFModelIterator
  ^
 ../../../../src/af/util/xp/ut_string_class.h:124:17: note: candidate
 function not viable: no known conversion from 'const PD_URI' to 'const
 UT_String' for 1st argument
 ABI_EXPORT bool operator(const UT_String s1, const UT_String s2);
 ^
 ../../../../src/af/util/xp/ut_string_class.h:277:17: note: candidate
 function not viable: no