Re: emulators/i386-wine-devel
On Sunday, 16 September 2018 23:51:01 SAST Rozhuk Ivan wrote: > On Sat, 15 Sep 2018 10:06:01 +0200 > Thanks! > I already subscribe to this and post few comments. > I have no choice - I need wine to few win programs. Is the current version of i386-wine(-devel) not working for you? I understand that these are become quite old version. I'm hoping that we can complete the lib32 work (and then the WOW64 patch) before things become too stale. Regards signature.asc Description: This is a digitally signed message part.
Re: RUN_DEPENDS and portmaster
Am 18.09.18 um 14:05 schrieb Matthias Fechner: > Dear Stefan, > > Am 17.09.2018 um 14:31 schrieb Stefan Esser: >> But the behavior of portmaster will not be changed. >> RUN_DEPENDS are dependencies required to run a port, not dependencies >> required to install a port. >> >> >> And I do not care whether bsd.port.mk treats RUN_DEPENDS as if they >> were INSTALL_DEPENDS (which do not exist). The fact that bsd.port.mk >> works in that way is due to the fact, that it generally executes sub >> processes in a depth first manner. Portmaster distinguishes build and >> run dependencies and makes sure, that build dependencies not only exist, >> but are updated before the ports they depend on, while bsd.port.mk will >> use any build dependency that satisfies the range requirements (if any) >> and does not upgrade existing but outdated (in the sense that an upgrade >> is available) dependencies. Portmaster will then upgrade any out-dated >> run dependencies (again if an upgrade is available, not only if it is >> strictly required). Thus portmaster guarantees, that a port is built >> with the latest available build tools, and that run dependency upgrades >> see the upgraded port that requires them, in case they depend on it. > > I fully understand you. > > Maybe it will be a good idea to phase portmaster out as it seems to be a > unmaintable beast? > > Maybe synth can replace it for users that are not used to poudriere? I have been using a portmaster-rewrite for many months, which is ready for release except for some performance tuning. (The portmaster in ports is not un-maintainable, but it's hard to modify a monolithic 4000 line shell script that uses global variables to pass state and recursive invocation of itself to provide local state when required.) The performance problems are caused by bad design of the FLAVOR feature, which ignored the requirements of tools like portmaster (I've written about this at length when FLAVOR support had been committed). Synth is a non-starter for me, since it is written in Ada and only available on i386/amd64. I have plans to implement the functionality of synth in portmaster (not really hard, since the complex parts are the logic that deals with moved ports and conflicts, while the actual port building is simple). Portmaster can already create packages without installing them (unless they are BUILD_DEPENDS of some later port, of course) and you can populate your local repository with portmaster. Different from poudriere or synth, portmaster adapts to the preferences of the user (and e.g. upgrades samba48 used by some port that specifies a dependency on samba46, if the system already has an outdated samba48 installed). Portmaster will use what's available on a system and does allow selective upgrades (keeping some ports at a back-level on purpose, but still upgrade other ports that depend on them), while a poudirere/pkg based upgrade will typically require all dependencies to exactly match what was present at the time the package was built (in a clean environment, not resembling the system the packages are going to be installed on). Both, portmaster and poudriere/pkg have their use-cases, and there is only a partial overlap. There are quite a number of portmaster users, and they use it since their use-cases are not well covered by other tools. The way the ports system handles installs (in that it installs RUN_DEPENDS before the port that needs them) is an artifact of the way Makefiles naturally work, i.e. of the tool the ports system is based on. I do not understand why you intend on having RUN_DEPENDS cause installation of dependencies before your port. If you need those dependencies before the port is installed, then they are not really run dependencies, but dependencies of your particular build process. Portmaster has worked for far more than a decade with >20,000 ports. I do not see that your single port that expects run dependencies to be available before the installation has completed is reasonable cause to change the way portmaster works with dependencies. It pre-dates the "new" ports framework by far, and it used to be common practice, that changes respect established practices. BTW: Your port-install target will not be run when installing from a package (or building a package) anyway. Portmaster will take care of providing the required dependencies, as will pkg. So what's the reasoning that this test in do-install is required at all? You already specify exact versions in the RUN_DEPENDS, which are checked by the ports framework. Portmaster will take care, that all these ports are re-built to the latest level (hopefully satisfying the version test) after gitlab-ce has been installed. If you use pkg, the test is performed at install time, too. Are there any PRs due to lack of that test? Regards, STefan ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To
Re: gnu artanis
On Mon, 17 Sep 2018 21:22:37 +0300 Java House wrote: > Hello > > I decided to start using Gnu Guile and while I managed to > build Gnu Guile > http://nikolasnikou.blogspot.com/2018/08/build-guile-for-freebsd.html > > I am still trying to build Gnu Artanis under FreeBSD 11.2 > I come to the point that gmake fails with following error > > In unknown file: >4 (primitive-load-path "artanis/server/epoll" > #) In ice-9/eval.scm: >626:19 3 (_ # 80509ef00>) 173:47 2 (_ # 80509ef00>epoll) 80509ef00>) > In unknown file: >1 (dynamic-func "epoll_create" > #) In ice-9/boot-9.scm: >752:25 0 (dispatch-exception _ _ _) > > ice-9/boot-9.scm:752:25: In procedure dispatch-exception: > In procedure dynamic-pointer: Symbol not found: > epoll_create gmake: *** [Makefile:77: > obj/artanis/artanis.go] Error 1 > > > I couldnt find any way how to include a library that > supports epoll_create > > Does anyone know how to solve this issue? epoll_create() (and all epoll facility) is Linux-specific. http://man7.org/linux/man-pages/man2/epoll_create.2.html > Thank you for your help > KInd Regards > Nikolas > ___ > 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: RUN_DEPENDS and portmaster
Dear Stefan, Am 17.09.2018 um 14:31 schrieb Stefan Esser: > But the behavior of portmaster will not be changed. > RUN_DEPENDS are dependencies required to run a port, not dependencies > required to install a port. > > > And I do not care whether bsd.port.mk treats RUN_DEPENDS as if they > were INSTALL_DEPENDS (which do not exist). The fact that bsd.port.mk > works in that way is due to the fact, that it generally executes sub > processes in a depth first manner. Portmaster distinguishes build and > run dependencies and makes sure, that build dependencies not only exist, > but are updated before the ports they depend on, while bsd.port.mk will > use any build dependency that satisfies the range requirements (if any) > and does not upgrade existing but outdated (in the sense that an upgrade > is available) dependencies. Portmaster will then upgrade any out-dated > run dependencies (again if an upgrade is available, not only if it is > strictly required). Thus portmaster guarantees, that a port is built > with the latest available build tools, and that run dependency upgrades > see the upgraded port that requires them, in case they depend on it. I fully understand you. Maybe it will be a good idea to phase portmaster out as it seems to be a unmaintable beast? Maybe synth can replace it for users that are not used to poudriere? Gruß Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook ___ 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"
KDE4 ports marked DEPRECATED
A bunch of ports commits at the end of August marked all the KDE4 ports that kde@ is responsible for, as DEPRECATED, e.g. for x11/kdelibs-kde4/ r478483 | adridg | 2018-08-30 20:40:36 +0200 (Thu, 30 Aug 2018) | 10 lines Deprecate KDE4 software, categories www-x11-themes Since not everyone reads the ports commits, or my blog [1], let's repeat the message in some more official places: KDE4 ports have been marked DEPRECATED and will be removed by kde@ around December 31st, after a four month deprecation period. We've tried to contact ports maintainers who have USES=kde:4, to inform them as well of the deprecation. This has been partly successful [2]. Some of those ports are rapidly transitioning to a KDE Frameworks version; others now have flavors. Exactly how removal will work hasn't been decided yet. A one-shot "svn rm" and modification of Mk/Uses/kde.mk is possible, but it will probably be slightly less abrupt than that. kde@ also maintains Qt4 ports. We have not said anything about them yet, but that software has been EOL upstream since 2015, and as soon as the maintainence burden from that ramps up at all, expect it to be cast upon the dungheap of software history as well (via a similar months-long deprecation process). [ade] [1] https://euroquis.nl/bobulate/?p=1969 [2] e.g. getting bounces from bitmail saying "pay $0.15 to deliver" is not a success signature.asc Description: This is a digitally signed message part.
Re: Error building net/librsync2
Den tir. 18. sep. 2018 kl. 13:12 skrev Stefan Esser : > This is the 2nd report of this issue, but I cannot reproduce it on my > amd64-CURRENT system. > > This might be caused by stdio.h being included by header-pollution on > some but not all FreeBSD versions. > > Try adding "#include " at the top of tests/sumset_test.c: > > --- tests/sumset_test.c.orig2018-02-27 11:08:36.0 +0100 > +++ tests/sumset_test.c 2018-09-18 13:10:48.29536 +0200 > @@ -22,6 +22,7 @@ > /* Force DEBUG on so that tests can use assert(). */ > #undef NDEBUG > #include "config.h" > +#include > #include > #include > #include "librsync.h" Thanks a lot. It worked! :-) $ sudo patch < patch0 Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- tests/sumset_test.c.orig2018-02-27 11:08:36.0 +0100 |+++ tests/sumset_test.c 2018-09-18 13:10:48.29536 +0200-- Patching file tests/sumset_test.c using Plan A... Hunk #1 succeeded at 22. done $ cd ../..& make ===> Building for librsync2-2.0.2 [1/18] : && /usr/bin/cc -fPIC -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -fstack-protector -shared -Wl,-soname,librsync.so.2 -o librsync.so.2.0.2 CMakeFiles/rsync.dir/src/prototab.c.o CMakeFiles/rsync.dir/src/base64.c.o CMakeFiles/rsync.dir/src/buf.c.o CMakeFiles/rsync.dir/src/checksum.c.o CMakeFiles/rsync.dir/src/command.c.o CMakeFiles/rsync.dir/src/delta.c.o CMakeFiles/rsync.dir/src/emit.c.o CMakeFiles/rsync.dir/src/fileutil.c.o CMakeFiles/rsync.dir/src/hashtable.c.o CMakeFiles/rsync.dir/src/hex.c.o CMakeFiles/rsync.dir/src/job.c.o CMakeFiles/rsync.dir/src/mdfour.c.o CMakeFiles/rsync.dir/src/mksum.c.o CMakeFiles/rsync.dir/src/msg.c.o CMakeFiles/rsync.dir/src/netint.c.o CMakeFiles/rsync.dir/src/patch.c.o CMakeFiles/rsync.dir/src/readsums.c.o CMakeFiles/rsync.dir/src/rollsum.c.o CMakeFiles/rsync.dir/src/scoop.c.o CMakeFiles/rsync.dir/src/stats.c.o CMakeFiles/rsync.dir/src/stream.c.o CMakeFiles/rsync.dir/src/sumset.c.o CMakeFiles/rsync.dir/src/trace.c.o CMakeFiles/rsync.dir/src/tube.c.o CMakeFiles/rsync.dir/src/util.c.o CMakeFiles/rsync.dir/src/version.c.o CMakeFiles/rsync.dir/src/whole.c.o CMakeFiles/rsync.dir/src/blake2/blake2b-ref.c.o && : [2/18] /usr/local/bin/cmake -E cmake_symlink_library librsync.so.2.0.2 librsync.so.2 librsync.so && : [3/18] /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/src/rollsum.c.o -MF CMakeFiles/sumset_test.dir/src/rollsum.c.o.d -o CMakeFiles/sumset_test.dir/src/rollsum.c.o -c src/rollsum.c [4/18] /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/rollsum_test.dir/src/rollsum.c.o -MF CMakeFiles/rollsum_test.dir/src/rollsum.c.o.d -o CMakeFiles/rollsum_test.dir/src/rollsum.c.o -c src/rollsum.c [5/18] /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/src/hashtable.c.o -MF CMakeFiles/sumset_test.dir/src/hashtable.c.o.d -o CMakeFiles/sumset_test.dir/src/hashtable.c.o -c src/hashtable.c [6/18] /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/rollsum_test.dir/tests/rollsum_test.c.o -MF CMakeFiles/rollsum_test.dir/tests/rollsum_test.c.o.d -o CMakeFiles/rollsum_test.dir/tests/rollsum_test.c.o -c tests/rollsum_test.c [7/18] /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/isprefix_test.dir/tests/isprefix_test.c.o -MF CMakeFiles/isprefix_test.dir/tests/isprefix_test.c.o.d -o CMakeFiles/isprefix_test.dir/tests/isprefix_test.c.o -c tests/isprefix_test.c [8/18] /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/hashtable_test.dir/src/hashtable.c.o -MF CMakeFiles/hashtable_test.dir/src/hashtable.c.o.d -o CMakeFiles/hashtable_test.dir/src/hashtable.c.o -c src/hashtable.c [9/18] : && /usr/bin/cc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -fstack-protector CMakeFiles/rollsum_test.dir/tests/rollsum_test.c.o CMakeFiles/rollsum_test.dir/src/rollsum.c.o -o rollsum_test && : [10/18]
Re: Error building net/librsync2
Am 18.09.18 um 12:23 schrieb Jakob Breivik Grimstveit: > $ uname -a > FreeBSD core2.grimstveit.no 11.2-RELEASE-p3 FreeBSD 11.2-RELEASE-p3 #7 > r338607: Wed Sep 12 13:24:12 CEST 2018 > r...@core2.grimstveit.no:/usr/obj/usr/src/sys/CORE2 > amd64 > > [...] > [22/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc > -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 > -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT > CMakeFiles/rsync.dir/src/scoop.c.o -MF CMakeFiles/rsync.dir/src/scoop.c.o.d > -o CMakeFiles/rsync.dir/src/scoop.c.o -c src/scoop.c > [23/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc > -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 > -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT > CMakeFiles/rsync.dir/src/version.c.o -MF > CMakeFiles/rsync.dir/src/version.c.o.d -o > CMakeFiles/rsync.dir/src/version.c.o -c src/version.c > [24/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc > -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 > -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT > CMakeFiles/rsync.dir/src/util.c.o -MF CMakeFiles/rsync.dir/src/util.c.o.d > -o CMakeFiles/rsync.dir/src/util.c.o -c src/util.c > [25/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc > -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 > -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT > CMakeFiles/rsync.dir/src/mdfour.c.o -MF > CMakeFiles/rsync.dir/src/mdfour.c.o.d -o > CMakeFiles/rsync.dir/src/mdfour.c.o -c src/mdfour.c > [26/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc > -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 > -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT > CMakeFiles/rsync.dir/src/trace.c.o -MF CMakeFiles/rsync.dir/src/trace.c.o.d > -o CMakeFiles/rsync.dir/src/trace.c.o -c src/trace.c > [27/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc > -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 > -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT > CMakeFiles/rsync.dir/src/tube.c.o -MF CMakeFiles/rsync.dir/src/tube.c.o.d > -o CMakeFiles/rsync.dir/src/tube.c.o -c src/tube.c > [28/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc > -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 > -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT > CMakeFiles/rsync.dir/src/whole.c.o -MF CMakeFiles/rsync.dir/src/whole.c.o.d > -o CMakeFiles/rsync.dir/src/whole.c.o -c src/whole.c > [29/53] /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe > -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe > -march=native -fstack-protector -fno-strict-aliasing -MD -MT > CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF > CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o > CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -c tests/sumset_test.c > FAILED: CMakeFiles/sumset_test.dir/tests/sumset_test.c.o > /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe > -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe > -march=native -fstack-protector -fno-strict-aliasing -MD -MT > CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF > CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o > CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -c tests/sumset_test.c > In file included from tests/sumset_test.c:27: > /usr/local/include/librsync.h:430:21: error: unknown type name 'FILE' > void rs_mdfour_file(FILE *in_file, char *result); > ^ > /usr/local/include/librsync.h:432:23: error: unknown type name 'FILE' > rs_result rs_sig_file(FILE *old_file, FILE *sig_file, > ^ > /usr/local/include/librsync.h:432:39: error: unknown type name 'FILE' > rs_result rs_sig_file(FILE *old_file, FILE *sig_file, > ^ > /usr/local/include/librsync.h:437:27: error: unknown type name 'FILE' > rs_result rs_loadsig_file(FILE *, rs_signature_t **, rs_stats_t *); > ^ > /usr/local/include/librsync.h:441:43: error: unknown type name 'FILE' > rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file, > rs_stats_t *); > ^ > /usr/local/include/librsync.h:441:59: error: unknown type name 'FILE' > rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file, > rs_stats_t *); > ^ > /usr/local/include/librsync.h:443:25: error: unknown type name 'FILE' > rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file, > rs_stats_t *); > ^ >
Error building net/librsync2
$ uname -a FreeBSD core2.grimstveit.no 11.2-RELEASE-p3 FreeBSD 11.2-RELEASE-p3 #7 r338607: Wed Sep 12 13:24:12 CEST 2018 r...@core2.grimstveit.no:/usr/obj/usr/src/sys/CORE2 amd64 [...] [22/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT CMakeFiles/rsync.dir/src/scoop.c.o -MF CMakeFiles/rsync.dir/src/scoop.c.o.d -o CMakeFiles/rsync.dir/src/scoop.c.o -c src/scoop.c [23/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT CMakeFiles/rsync.dir/src/version.c.o -MF CMakeFiles/rsync.dir/src/version.c.o.d -o CMakeFiles/rsync.dir/src/version.c.o -c src/version.c [24/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT CMakeFiles/rsync.dir/src/util.c.o -MF CMakeFiles/rsync.dir/src/util.c.o.d -o CMakeFiles/rsync.dir/src/util.c.o -c src/util.c [25/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT CMakeFiles/rsync.dir/src/mdfour.c.o -MF CMakeFiles/rsync.dir/src/mdfour.c.o.d -o CMakeFiles/rsync.dir/src/mdfour.c.o -c src/mdfour.c [26/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT CMakeFiles/rsync.dir/src/trace.c.o -MF CMakeFiles/rsync.dir/src/trace.c.o.d -o CMakeFiles/rsync.dir/src/trace.c.o -c src/trace.c [27/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT CMakeFiles/rsync.dir/src/tube.c.o -MF CMakeFiles/rsync.dir/src/tube.c.o.d -o CMakeFiles/rsync.dir/src/tube.c.o -c src/tube.c [28/53] /usr/bin/cc -Drsync_EXPORTS -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -fPIC -MD -MT CMakeFiles/rsync.dir/src/whole.c.o -MF CMakeFiles/rsync.dir/src/whole.c.o.d -o CMakeFiles/rsync.dir/src/whole.c.o -c src/whole.c [29/53] /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -c tests/sumset_test.c FAILED: CMakeFiles/sumset_test.dir/tests/sumset_test.c.o /usr/bin/cc -I/usr/local/include -Isrc/blake2 -Isrc -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -Wall -O2 -pipe -march=native -fstack-protector -fno-strict-aliasing -MD -MT CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -MF CMakeFiles/sumset_test.dir/tests/sumset_test.c.o.d -o CMakeFiles/sumset_test.dir/tests/sumset_test.c.o -c tests/sumset_test.c In file included from tests/sumset_test.c:27: /usr/local/include/librsync.h:430:21: error: unknown type name 'FILE' void rs_mdfour_file(FILE *in_file, char *result); ^ /usr/local/include/librsync.h:432:23: error: unknown type name 'FILE' rs_result rs_sig_file(FILE *old_file, FILE *sig_file, ^ /usr/local/include/librsync.h:432:39: error: unknown type name 'FILE' rs_result rs_sig_file(FILE *old_file, FILE *sig_file, ^ /usr/local/include/librsync.h:437:27: error: unknown type name 'FILE' rs_result rs_loadsig_file(FILE *, rs_signature_t **, rs_stats_t *); ^ /usr/local/include/librsync.h:441:43: error: unknown type name 'FILE' rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file, rs_stats_t *); ^ /usr/local/include/librsync.h:441:59: error: unknown type name 'FILE' rs_result rs_delta_file(rs_signature_t *, FILE *new_file, FILE *delta_file, rs_stats_t *); ^ /usr/local/include/librsync.h:443:25: error: unknown type name 'FILE' rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file, rs_stats_t *); ^ /usr/local/include/librsync.h:443:43: error: unknown type name 'FILE' rs_result rs_patch_file(FILE *basis_file, FILE *delta_file, FILE *new_file, rs_stats_t *); ^
FreeBSD ports you maintain which are out of date
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/po...@freebsd.org.html Port| Current version | New version +-+ devel/git-lfs | 2.5.1 | v2.5.2 +-+ games/simutrans | 120-2-2 | 120-4 +-+ 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"
Not a portmaster problem
Am 17.09.18 um 22:51 schrieb @lbutlr: > I am using MariaDB 10.0 on FreeBSD 11.3 > > When trying to update rsyslogd via postmaster I get: > > checking for mysql_config... mysql_config > checking for mysql_init in -lmysqlclient... no > configure: error: in `/usr/ports/sysutils/rsyslog8/work/rsyslog-8.37.0': > configure: error: MySQL library is missing > See `config.log' for more details > ===> Script "configure" failed unexpectedly. > Please report the problem to matt...@freebsd.org [maintainer] and attach the > "/usr/ports/sysutils/rsyslog8/work/rsyslog-8.37.0/config.log" including the > output of the failure of your make command. Also, it might be a good idea to > provide an overview of all packages installed on your system (e.g. a > /usr/local/sbin/pkg-static info -g -Ea). > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/sysutils/rsyslog8 > *** Error code 1 > > I’ve disabled the MySQL output for now, but this disconnect between MySQL and > Maria seems to be happening with a lot of ports. > > Is there anything I can do to restore the MySQL output for rsylog? AFAICT, Wolfgang Zenker correctly points at PR 230839. Portmaster does not appear to play a role - the problem exists when building without portmaster, too. Regards, STefan ___ 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 constantly trashing disk
On 9/14/18 8:33 PM, Tijl Coosemans wrote: Is there a way I can see what file Firefox is writing too? I tried "lsof|grep firefox", but that will list some 1200-1300 entries and I still don't know which is the one. Try the patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222356 For Firefox ESR you may need the version hidden behind 'Show Obsolete'. Thanks a lot! You clearly pointed me in the correct direction (although the details are above my ability to understand :). Now I've seen a couple of hangs (which I ever hardly experienced before), but I'm waiting to see if they can be related to this patch. bye & Thanks av. ___ 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"
