Re: Error reinstalling python 3.8.10 from ports
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
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
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
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
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
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
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
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
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?
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
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
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?
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?
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?
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
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
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
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
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
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
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)
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
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
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
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
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
[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
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!
On Mon, Feb 19, 2018 at 9:45 AM, Julian Elischerwrote: > 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?
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
On Wed, Jan 3, 2018 at 8:32 AM, Kevin Obermanwrote: > 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.
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
On Wed, Nov 1, 2017 at 7:12 PM, Kevin Obermanwrote: > 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
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
On Mon, Oct 30, 2017 at 7:17 PM, blubee blubeemewrote: > 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
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
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)
On Tue, May 10, 2016 at 8:29 AM, Kurt Jaegerwrote: > 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
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
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
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
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