Re: math/R doesn't compile
Looks like the port doesn't compile when LTO is set: OPTIONS_FILE_SET+=LTO I have raised a new bug as I couldn't find one mentioning this issue yet: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222553 GrzegorzJ On 12/09/2017 10:12, Otacílio wrote: Em 11/09/2017 20:07, Grzegorz Junka escreveu: ../extra/tre/libtre.a: error adding symbols: Malformed archive collect2: error: ld returned 1 exit status gmake[4]: *** [Makefile:177: libR.so] Error 1 gmake[4]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1/src/main' gmake[3]: *** [Makefile:135: R] Error 2 gmake[3]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1/src/main' gmake[2]: *** [Makefile:28: R] Error 1 gmake[2]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1/src' gmake[1]: *** [Makefile:61: R] Error 1 gmake[1]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1' Which option may be responsible for this problem? I can only set libr to be compiled or not. GrzegorzJ ___ Maybe this is a local problem on your system because I have just finished a build and install of math/R on my machine (FreeBSD 11.1 amd64 ports Revision: 449667, default R options): install -m 0644 "./dir" "/usr/ports/math/R/work/stage/usr/local/info" installing R info pages ... updating '/usr/local/info/dir' ... gmake[3]: Leaving directory '/usr/ports/math/R/work/R-3.4.1/doc/manual' gmake[2]: Leaving directory '/usr/ports/math/R/work/R-3.4.1' > Compressing man pages (compress-man) ===> Installing ldconfig configuration file > Running Q/A tests (stage-qa) root@nostromo:/usr/ports/math/R # make deinstall install ===> Deinstalling for R ===> Deinstalling R-3.4.0_2 Updating database digests format: 100% Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: R-3.4.0_2 Number of packages to be removed: 1 The operation will free 61 MiB. [1/1] Deinstalling R-3.4.0_2... [1/1] Deleting files for R-3.4.0_2: 100% ===> Installing for R-3.4.1_7 ===> R-3.4.1_7 depends on executable: gmake - found ===> R-3.4.1_7 depends on executable: wget - found ===> R-3.4.1_7 depends on executable: gfortran6 - found ===> R-3.4.1_7 depends on package: ghostscript9-agpl-base>=9.16_2 - found ===> R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/ice.pc - found ===> R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/sm.pc - found ===> R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found ===> R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found ===> R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/xmu.pc - found ===> R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/xscrnsaver.pc - found ===> R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/xt.pc - found ===> R-3.4.1_7 depends on executable: indexinfo - found ===> R-3.4.1_7 depends on shared library: libcurl.so - found (/usr/local/lib/libcurl.so) ===> R-3.4.1_7 depends on shared library: libpcre.so - found (/usr/local/lib/libpcre.so) ===> R-3.4.1_7 depends on shared library: libicui18n.so - found (/usr/local/lib/libicui18n.so) ===> R-3.4.1_7 depends on shared library: libpng.so - found (/usr/local/lib/libpng.so) ===> R-3.4.1_7 depends on shared library: libtiff.so - found (/usr/local/lib/libtiff.so) ===> R-3.4.1_7 depends on shared library: libreadline.so.7 - found (/usr/local/lib/libreadline.so.7) ===> R-3.4.1_7 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so) ===> R-3.4.1_7 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so) ===> R-3.4.1_7 depends on shared library: libtk86.so - found (/usr/local/lib/libtk86.so) ===> R-3.4.1_7 depends on shared library: libtcl86.so - found (/usr/local/lib/libtcl86.so) ===> R-3.4.1_7 depends on shared library: libcairo.so - found (/usr/local/lib/libcairo.so) ===> R-3.4.1_7 depends on shared library: libglib-2.0.so - found (/usr/local/lib/libglib-2.0.so) ===> R-3.4.1_7 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so) ===> R-3.4.1_7 depends on shared library: libpango-1.0.so - found (/usr/local/lib/libpango-1.0.so) ===> Checking if R already installed ===> Registering installation for R-3.4.1_7 Installing R-3.4.1_7... On 11.1 and later, there is a problem downloading R packages when gfortran is chosen as the fortran compiler. Use either of these workarounds until a permanent solution is found. 1. If you are on an amd64 system, you can use flang as the fortran compiler. 2. If you choose gfortran as the fortran compiler, you can add options(download.file.method="wget") to ~/.Rprofile followed by a newline. Details: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221127 =
Re: EXTRA_PATCHES considered harmful?
On 24/9/17 6:37 am, Adam Weinberger wrote: On 23 Sep, 2017, at 15:39, Julian Elischer wrote: currently if you set EXTRA_PATCHES and the port you are making decides to build a second port as a dependency, EXTRA_PATCHES is passed to the second port which them obiously fails to patch it. e.g. cd /usr/ports/emulators/open-vm-tools-nox11; Make EXTRA_PATCHES=/foo/bar/patch1 will fail when it tries to apply the patch files to each dependency. AM I doing something wrong here? Hi Julian, I think EXTRA_PATCH_TREE is a better option for what you're looking for. You put patches in there in a tree that gets essentially overlaid on the ports tree. EXTRA_PATCH_TREE=/usr/patches Then put your patch1 in /usr/patches/emulators/open-vm-tools-nox11 # Adam You are correct and I am moving to that.. In fact I submitted the idea of EXTRA_PATCH_TREE, though it was reimplemented during a rewrite. (but the comments saying what it is are still mine). ___ 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"
Question: How to add a configuration file with autoplist ?
Hi, According to https://www.freebsd.org/doc/en/books/porters-handbook/plist-config.html , I need to add a @sample macro in pkg-plist to add a configuration file. But I am also using USE_PYTHON= autoplist in my Makefile, so I don't have the pkg-plist file. Should I remove autoplist and generate the pkg-plist by hand? Or is there another way to do this? I'll need this to update the version of the package sysutils/py-google-compute-engine. Thanks Helen ___ 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"
dns/unbound patch error
I remember something was mentioned on this list about unbound. Currently it fails for me with the following error: ===> Patching for unbound-1.6.6 /bin/cat /wrkdirs/usr/ports/dns/unbound/work/unbound-1.6.6/contrib/-filter-iterator.patch | /usr/bin/patch -d /wrkdirs/usr/ports/dns/unbound/work/unbound-1.6.6 -p1 -s 1 out of 3 hunks failed--saving rejects to iterator/iterator.h.rej *** Error code 1 Stop. make: stopped in /usr/ports/dns/unbound >> Cleaning up wrkdir ===> Cleaning for unbound-1.6.6 build of dns/unbound ended at Mon Sep 25 00:40:44 UTC 2017 build time: 00:00:06 !!! build failure encountered !!! Is this a known issue? GrzegorzJ ___ 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"
/usr/ports/Mk/Uses/execinfo.mk and r450351
Hello all, I'm running FreeBSD dane.localdomain 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320599 with a ports tree synced with svn and package update management with portmaster(8). I synced the tree up to 450554 today and portmaster spat out the following. /usr/ports# portmaster -m BATCH=yes -D --update-if-newer --no-confirm -a make: "/usr/ports/Mk/bsd.port.mk" line 1439: Cannot open /usr/ports/Mk/Uses/execinfo.mk make: Fatal errors encountered -- cannot continue This occurs for what appears to be six of the ports I have installed. I notice that r450351--r450354 deal with execinfo, specifically r450351 removes execinfo support. The ports complaining for my own situation were: devel/qt5-core x11-toolkits/wxgtk30 devel/cmake sysutils/fusefs-ext4fuse lang/ruby23 I've remove the execinfo USES references in these ports' Makefiles and portmaster no longer complains during the update. I'm still cutting my teeth on freebsd's ports system, I'm unsure if I should submit a PR about this (a grep command seemed to find about 163 instances of USES containing execinfo) or if I simply don't realize I that I've hosed my ports tree :/ TiA for any advice, -- Keith Hellman #include khell...@mcprogramming.comfrom disclaimer import standard khell...@mines.edugpg key 9FCF40FD freenode.net as mrtuple If they want really buzzword-compliant "redundancy" they could add another exchange server as part of a "cluster" of "Windows 2003" servers with "active directory" so that when things break they break spectacularly. -- Jim Ockers, P.Eng. (http://www.ockers.net/); CLUE-Tech mailing list signature.asc Description: PGP signature
Re: dns/unbound patch error
On Mon, Sep 25, 2017 at 12:49:37AM +, Grzegorz Junka wrote: > I remember something was mentioned on this list about unbound. Currently it > fails for me with the following error: > > ===> Patching for unbound-1.6.6 > /bin/cat > /wrkdirs/usr/ports/dns/unbound/work/unbound-1.6.6/contrib/-filter-iterator.patch > | /usr/bin/patch -d /wrkdirs/usr/ports/dns/unbound/work/unbound-1.6.6 -p1 -s > 1 out of 3 hunks failed--saving rejects to iterator/iterator.h.rej > *** Error code 1 > > Stop. > make: stopped in /usr/ports/dns/unbound > >> Cleaning up wrkdir > ===> Cleaning for unbound-1.6.6 > build of dns/unbound ended at Mon Sep 25 00:40:44 UTC 2017 > build time: 00:00:06 > !!! build failure encountered !!! > > Is this a known issue? > > GrzegorzJ Hi. This is a problem with option FILTER_ (non default), it was already reported[1] upstream. For now you can try/test this patch[2]. 1 - https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1450 2 - https://people.freebsd.org/~dbaio/unbound-1.6.6-FILTER_.patch Regards. -- Danilo G. Baio (dbaio) signature.asc Description: PGP signature
Re: /usr/ports/Mk/Uses/execinfo.mk and r450351
On 24 Sep, Keith Hellman wrote: > Hello all, > > I'm running > > FreeBSD dane.localdomain 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320599 > > with a ports tree synced with svn and package update management with > portmaster(8). I synced the tree up to 450554 today and portmaster > spat out the following. > > /usr/ports# portmaster -m BATCH=yes -D --update-if-newer --no-confirm -a > make: "/usr/ports/Mk/bsd.port.mk" line 1439: Cannot open > /usr/ports/Mk/Uses/execinfo.mk > make: Fatal errors encountered -- cannot continue > > This occurs for what appears to be six of the ports I have installed. > > I notice that r450351--r450354 deal with execinfo, specifically r450351 > removes execinfo support. The ports complaining for my own situation > were: > > devel/qt5-core > x11-toolkits/wxgtk30 > devel/cmake > sysutils/fusefs-ext4fuse > lang/ruby23 > > I've remove the execinfo USES references in these ports' Makefiles and > portmaster no longer complains during the update. > > I'm still cutting my teeth on freebsd's ports system, I'm unsure if I > should submit a PR about this (a grep command seemed to find about 163 > instances of USES containing execinfo) or if I simply don't realize I > that I've hosed my ports tree :/ There is something funny going on with your copy of the ports tree. My copy is currently at r450422 and I looked at Makefile for the first two ports that you list and don't see USES=execinfo. In my copy of the tree, Makefile for each of those two ports was last changed by r450351, which removed the USES=. %svn diff -c 450351 /usr/ports/devel/qt5-core/Makefile Index: /usr/ports/devel/qt5-core/Makefile === --- /usr/ports/devel/qt5-core/Makefile (revision 450350) +++ /usr/ports/devel/qt5-core/Makefile (revision 450351) @@ -12,7 +12,6 @@ LIB_DEPENDS= libicui18n.so:devel/icu \ libpcre.so:devel/pcre -USES= execinfo USE_GNOME= glib20 USE_QT5= qmake_build buildtools_build QT_DIST= base Checking https://svnweb.freebsd.org/ports/head/devel/qt5-core/Makefile, I see that it was changed again today with r450556, but that was only a PORTREVISION bump and didn't undo the removal of USES=. ___ 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: /usr/ports/Mk/Uses/execinfo.mk and r450351
On Sun, Sep 24, 2017 at 06:44:22PM -0700, Don Lewis wrote: > There is something funny going on with your copy of the ports tree. My > copy is currently at r450422 and I looked at Makefile for the first two That's what I thought might be the case :( Thanks for setting me straight. -- Keith Hellman #include khell...@mcprogramming.comfrom disclaimer import standard khell...@mines.edugpg key 9FCF40FD freenode.net as mrtuple "How many of you do your curly braces this way? And by this way I mean the indisputably correct way?" -- Josh Thomas Graduate Teaching Fellow, CSCI 262 signature.asc Description: PGP signature
Porters Handbook section 4.4
Hi, Section 4.3 of the porters handbook talks about making modifications to a private copy of a tarball and recording the steps. Section 4.4 talks about changing directories into the affected ports dir and running make makepatch to generate patch files. I am unsure how the makepatch target is supposed to find my private directory. Since I was confused, I created patches, added them to the port, ran make, then ran make makepatch and the system re-generated new "makepatch" patches. So, my question is thus: To me, section 4.4 seems vague about where changes should be made, which is compounded by the information in section 4.3. Can the makepatch target ask for and find a private directory, or should the handbook be clarified to state that the changes should be made to the 'work' folder? If the later is true, I assume there is some proper workflow to keep changes from being destroyed while testing? If there is a section in the handbook clarifying this, please just say so and I will go find it. Thanks! Russ ___ 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: Question: How to add a configuration file with autoplist ?
On 9/25/17 6:16 AM, Helen Koike wrote: > Hi, > > According to > https://www.freebsd.org/doc/en/books/porters-handbook/plist-config.html > , I need to add a @sample macro in pkg-plist to add a configuration file. > > But I am also using USE_PYTHON= autoplist in my Makefile, so I don't > have the pkg-plist file. > > Should I remove autoplist and generate the pkg-plist by hand? Or is > there another way to do this? > > I'll need this to update the version of the package > sysutils/py-google-compute-engine. > > Thanks > Helen Hi Helen, As far as I'm aware, autoplist, PLIST_* definitions and pkg-plist entries can be used cumulatively (in combination with each other) to produce a correct and complete installed files list ./koobs ___ 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: Porters Handbook section 4.4
On 9/25/17 2:08 PM, Russell Haley wrote: > Hi, > > Section 4.3 of the porters handbook talks about making modifications > to a private copy of a tarball and recording the steps. > > Section 4.4 talks about changing directories into the affected ports > dir and running make makepatch to generate patch files. > > I am unsure how the makepatch target is supposed to find my private > directory. Since I was confused, I created patches, added them to the > port, ran make, then ran make makepatch and the system re-generated > new "makepatch" patches. Quite a number of new users have raised the same question on IRC. > So, my question is thus: > > To me, section 4.4 seems vague about where changes should be made, > which is compounded by the information in section 4.3. Can the > makepatch target ask for and find a private directory, or should the > handbook be clarified to state that the changes should be made to the > 'work' folder? If the later is true, I assume there is some proper > workflow to keep changes from being destroyed while testing? The handbook section needs to be updated to be less ambiguous with regard to where things should be done. I'd be happy to provide a docs committer with verbiage if they can help with formatting/commit. > If there is a section in the handbook clarifying this, please just say > so and I will go find it. > > Thanks! > Russ ./koobs ___ 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"
