Portmanager vs portupgrade
I lately read more often that Portmaster is preferred about portupdate. Can you tell me why this is? I know that portupdate is Ruby driven, but furthermore I cannot detect the real advantages one above the other? Best regards, Jos Chrispijn ___ 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
Drop Maintainer
Hi, I'm currently the maintainer of graphics/fotoxx and I want to stop maintaining that since I no longer use it and wish to concentrate on other things that I actually use. What is the official procedure, if any, for be dropped as the maintainer. Also, for anyone that picks it up, I did submit a PR that updates the port to version 13. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177643 -- Rod The lips of wisdom are closed, except to the ears of understanding - The Kybalion ___ 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: Portmanager vs portupgrade
On 01/23/14 11:35, Jos Chrispijn wrote: I lately read more often that Portmaster is preferred about portupdate. Can you tell me why this is? I know that portupdate is Ruby driven, but furthermore I cannot detect the real advantages one above the other? It used to be that portmaster was preferred because it had an active maintainer and also fewer dependencies, as it is written in pure shell. However, the original maintainer of portmaster (dougb) has moved away from FreeBSD-ish things, and both portmaster and portupgrade are now maintained by the same people (bdrewery mostly). portupgrade requires you to install ruby as well: that's probably the biggest deciding factor still extant. Mostly it's just a matter of personal preference. Of course, nowadays there are alternatives 3 and 4: (3) Use pkg(8) and the precompiled packages from pkg.freebsd.org (4) Use pkg(8) and set up your own package repo using poudriere or similar. Option (4) is (IMHO) the most effective way to manage an environment with several FreeBSD servers[*] needing any software with non-standard options settings today. (3) is quite usable for many purposes right now, but there are enhancements in the pipeline which will make it even better over the next few years. Cheers, Matthew [*] ie. two or more, including counting jails and virtualized machines. signature.asc Description: OpenPGP digital signature
Re: Portmanager vs portupgrade
On Thu, 23 Jan 2014 12:39:59 + Matthew Seaman wrote: maintained by the same people (bdrewery mostly). portupgrade requires you to install ruby as well: that's probably the biggest deciding factor still extant. For me the biggest factor is that portupgrade doesn't stop on the first error, it carries on building ports that don't depend on failed ports and then presents a summary of the problems at the end. This is a big advantage on desktop installations where there are a lot more ports and they are generally less reliable. ___ 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: Portmanager vs portupgrade
Hi! I lately read more often that Portmaster is preferred about portupdate. Can you tell me why this is? I know that portupdate is Ruby driven, but furthermore I cannot detect the real advantages one above the other? I use portupgrade to do daily rebuilds of ports on 8 reference hosts. It's not perfect, but it does its job. If one port does not build, portupgrade still builds those that do build. Which is nice 8-) -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: Portmanager vs portupgrade
On Thursday 23 January 2014 13:08:17 RW wrote: On Thu, 23 Jan 2014 12:39:59 + Matthew Seaman wrote: maintained by the same people (bdrewery mostly). portupgrade requires you to install ruby as well: that's probably the biggest deciding factor still extant. For me the biggest factor is that portupgrade doesn't stop on the first error, it carries on building ports that don't depend on failed ports and then presents a summary of the problems at the end. This is a big advantage on desktop installations where there are a lot more ports and they are generally less reliable. ___ 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 I am portmaster user from FreeBSD 7.0 and I want to switch to portupgrade. Should I expected some problems becaue everything is install with portmaster? Thank you. -- Mitja --- http://www.redbubble.com/people/lumiwa ___ 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: Portmanager vs portupgrade
Hi, On Thu, 23 Jan 2014 08:55:20 -0500 Ajtim lum...@gmail.com wrote: On Thursday 23 January 2014 13:08:17 RW wrote: On Thu, 23 Jan 2014 12:39:59 + Matthew Seaman wrote: maintained by the same people (bdrewery mostly). portupgrade requires you to install ruby as well: that's probably the biggest deciding factor still extant. For me the biggest factor is that portupgrade doesn't stop on the first error, it carries on building ports that don't depend on failed ports and then presents a summary of the problems at the end. This is a big advantage on desktop installations where there are a lot more ports and they are generally less reliable. ___ 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 I am portmaster user from FreeBSD 7.0 and I want to switch to portupgrade. Should I expected some problems becaue everything is install with portmaster? I use portupgrade and make whenever I want. I did not notice any problems as portupgrade just looks at the installed ports and then tries them to update via ports or packages. You have to tell portupgrade what to use. The main advantage for me is that it continues after errors and prints a summary at the end. You can then try to fix the problem or wait for a new ports tree in which the problem might be fixed. Important for me is that portupgrade never left me with an unusable system. Worst case is that nothing gets upgraded. Erich ___ 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: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.
On 23 Jan 2014, at 05:49, Robert Burmeister robert.burmeis...@utoledo.edu wrote: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release. A) Clang is needed to compile FreeBSD 10 due to use of the updated libstdc++ in world. Ehrm, no? You should be able to run stock 9-stable, which has gcc as the default compiler, and build 10.0 release without any trouble. Can you please explain which problems you encountered with libstdc++? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Portmanager vs portupgrade
On Thu, 23 Jan 2014, Jos Chrispijn wrote: I lately read more often that Portmaster is preferred about portupdate. Can you tell me why this is? I know that portupdate is Ruby driven, but furthermore I cannot detect the real advantages one above the other? Your subject line mentions portmanager, which is an old system that has apparently been removed from ports. I used portupgrade for something like a decade. It works, but now I have switched to portmaster. It also works, but is just a shell script and can be run without Ruby and bdb, which in turn depend on other things. Portupgrade is more mature and has a few features that come in handy at rare times, like being able to upgrade a given port and everything it depends on. Portmaster is simpler, has less overhead, and has default behavior that learned from some of portupgrade's mistakes, like fetching distfiles and showing config screens all at the start of the process instead of mixed in with the build. It also parallelizes some things rather than doing them serially, like checking for distfiles, and can be faster because of that. There is no problem switching between them, the ports that are installed are the same. I would suggest using portmaster, and installing and using portupgrade only if you need one of the features it provides that portmaster lacks. ___ 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: Drop Maintainer
On Thu, Jan 23, 2014, at 5:54, Rod Person wrote: Hi, I'm currently the maintainer of graphics/fotoxx and I want to stop maintaining that since I no longer use it and wish to concentrate on other things that I actually use. What is the official procedure, if any, for be dropped as the maintainer. Also, for anyone that picks it up, I did submit a PR that updates the port to version 13. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177643 Hi Rod, Looks like maintainership has been reset. Thanks for your time maintaining this port. ___ 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: USE_GCC doesn't set rpath
On 01/21/2014 15:31, Shane Ambler wrote: I think you will find that qbittorrent will need to be built with the same gcc version as libtorrent-rasterbar. I believe qbittorrent is loading /usr/lib/libstdc++.so.6 then it loads libtorrent-rasterbar.so.7 which tries to load libstdc++ and it is given the already open copy which doesn't have GLIBCXX_3.4.15 that it needs to run. Yes, you are right, thst's what is happening. So if any dependency has USE_GCC set, all dependent packages should also have USE_GCC set. Can ports build infrastructure automatically set USE_GCC for dependent ports? Because doing this by hand in each port is tedious and error prone. Yuri ___ 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
ports-mgmt/pkg failing to link when cross-compiling with qemu
When trying the instructions on https://wiki.freebsd.org/QemuUserModeHowTo, I encountered a fairly basic port (ports-mgmt/pkg) failing to link properly: [... - everything fine until here] cc -static -O -pipe -DPORTSDIR=\/usr/ports\ -I../libpkg -I/usr/ports/ports-mg/work/pkg-1.2.5/pkg/../external/expat/lib -std=gnu99 -Qunused-arguments -Wsystemprototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwritepts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-int -static -o pkg-static add.o annotate.o audit.o autoremove.o backup.o check.ock.o main.o plugins.o progressmeter.o query.o register.o repo.o rquery.o update.otch.o shell.o stats.o ssh.o -L/usr/ports/ports-mgmt/pkg/work/pkg-1.2.5/pkg/../lib -lcrypto -lmd -lz -lbz2 -llzma -ljail -lelf -larchive -lsbuf -lfetch -lpt add.o: In function `exec_add': add.c:(.text+0x11c): undefined reference to `pkgdb_access' add.c:(.text+0x13c): undefined reference to `pkgdb_open' add.c:(.text+0x164): undefined reference to `pkg_manifest_keys_new' add.c:(.text+0x344): undefined reference to `pkg_fetch_file' add.c:(.text+0x364): undefined reference to `pkg_add' add.c:(.text+0x42c): undefined reference to `pkg_manifest_keys_free' add.c:(.text+0x434): undefined reference to `pkgdb_close' [ ... - they are all alike] version.o: In function `print_version': version.c:(.text+0x14fc): undefined reference to `pkg_get2' version.c:(.text+0x1514): undefined reference to `pkg_version_cmp' version.c:(.text+0x1590): undefined reference to `pkg_asprintf' version.c:(.text+0x15a4): undefined reference to `pkg_asprintf' version.c:(.text+0x1650): undefined reference to `pkg_printf' which.o: In function `exec_which': which.c:(.text+0xe8): undefined reference to `pkgdb_open' which.c:(.text+0xf8): undefined reference to `pkgdb_close' which.c:(.text+0x18c): undefined reference to `pkgdb_query_which' which.c:(.text+0x1ac): undefined reference to `pkgdb_it_next' which.c:(.text+0x250): undefined reference to `pkg_printf' which.c:(.text+0x260): undefined reference to `pkg_printf' which.c:(.text+0x284): undefined reference to `pkg_printf' which.c:(.text+0x298): undefined reference to `pkgdb_it_next' which.c:(.text+0x2a8): undefined reference to `pkg_free' which.c:(.text+0x2b0): undefined reference to `pkgdb_it_free' which.c:(.text+0x2b8): undefined reference to `pkgdb_close' fetch.o: In function `exec_fetch': fetch.c:(.text+0xa4): undefined reference to `pkg_config_bool' fetch.c:(.text+0xb0): undefined reference to `pkg_config_bool' fetch.c:(.text+0x1e8): undefined reference to `pkgdb_set_case_sensitivity' fetch.c:(.text+0x2c0): undefined reference to `pkgdb_access' fetch.c:(.text+0x2e0): undefined reference to `pkgdb_access' fetch.c:(.text+0x314): undefined reference to `pkgdb_open' fetch.c:(.text+0x330): undefined reference to `pkg_jobs_new' fetch.c:(.text+0x34c): undefined reference to `pkg_jobs_set_repository' fetch.c:(.text+0x360): undefined reference to `pkg_jobs_set_flags' fetch.c:(.text+0x37c): undefined reference to `pkg_jobs_add' fetch.c:(.text+0x38c): undefined reference to `pkg_jobs_solve' fetch.c:(.text+0x39c): undefined reference to `pkg_jobs_count' fetch.c:(.text+0x418): undefined reference to `pkg_jobs_apply' fetch.c:(.text+0x420): undefined reference to `pkg_jobs_free' fetch.c:(.text+0x428): undefined reference to `pkgdb_close' shell.o: In function `exec_shell': shell.c:(.text+0x54): undefined reference to `pkgdb_cmd' stats.o: In function `exec_stats': stats.c:(.text+0xe8): undefined reference to `pkgdb_open' stats.c:(.text+0x120): undefined reference to `pkgdb_stats' stats.c:(.text+0x13c): undefined reference to `pkgdb_stats' stats.c:(.text+0x1cc): undefined reference to `pkg_repos_total_count' stats.c:(.text+0x1e8): undefined reference to `pkgdb_stats' stats.c:(.text+0x204): undefined reference to `pkgdb_stats' stats.c:(.text+0x220): undefined reference to `pkgdb_stats' stats.c:(.text+0x23c): undefined reference to `pkgdb_stats' stats.c:(.text+0x294): undefined reference to `pkgdb_close' ssh.o: In function `exec_ssh': ssh.c:(.text+0x98): undefined reference to `pkg_sshserve' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[3]: stopped in /usr/ports/ports-mgmt/pkg/work/pkg-1.2.5/pkg *** Error code 1 Stop. make[2]: stopped in /usr/ports/ports-mgmt/pkg/work/pkg-1.2.5 *** Error code 1 Stop. make[1]: stopped in /usr/ports/ports-mgmt/pkg *** Error code 1 Stop. make: stopped in /usr/ports/ports-mgmt/pkg Has anybody encountered something similar and would know how to fix that? Thanks and cheers, -- Christopher TZ: GMT + 1h GnuPG/GPG: 0xE8DE2C14 FreeBSD 9.2-STABLE #1 r256184: Thu Oct 10 19:12:54 CEST 2013 c...@dijkstra.cruwe.de:/usr/obj/usr/home/cjr/media/src/freebsd/base/stable/9/sys/GEN_WDTRACE Punctuation matters: Lets eat Grandma. or Lets eat, Grandma. - Punctuation saves lives. A panda eats shoots and leaves. or A panda eats, shoots, and leaves. -
Re: USE_GCC doesn't set rpath
Am 23.01.2014 20:04 schrieb Yuri y...@rawbw.com: On 01/21/2014 15:31, Shane Ambler wrote: I think you will find that qbittorrent will need to be built with the same gcc version as libtorrent-rasterbar. I believe qbittorrent is loading /usr/lib/libstdc++.so.6 then it loads libtorrent-rasterbar.so.7 which tries to load libstdc++ and it is given the already open copy which doesn't have GLIBCXX_3.4.15 that it needs to run. Yes, you are right, thst's what is happening. So if any dependency has USE_GCC set, all dependent packages should also have USE_GCC set. Can ports build infrastructure automatically set USE_GCC for dependent ports? Because doing this by hand in each port is tedious and error prone. Yuri No it can't right now and this is why we need a ports compiler. Right now we are hiding this problems by the fact that we are able to build 95% percent of the tree with clang and everyone is happy. We add dozens of patches to compile with clang or add this rpath workarounds to even more ports just because nobody wants to acknowledge that this is shit and won't work properly unless really everything is build with one compiler. The rpath stuff is only a workaround that works in a few cases but it doesn't work in all cases. You will still see very hard to diagnose runtime crashes. ___ 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 Port: www/chromium
Hello, I just updated to the latest version of chromium, now as soon as I attempt any operation chromium crashes with the following error. [77827:318843904:0123/145145:ERROR:form_data.cc(108)] Bad pickle of FormData, no version present [77827:318843904:0123/145145:ERROR:form_data.cc(108)] Bad pickle of FormData, no version present [77827:318843904:0123/145145:ERROR:form_data.cc(108)] Bad pickle of FormData, no version present Thanks. ___ 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: USE_GCC doesn't set rpath
On 1/23/2014 20:53, Bernhard Fröhlich wrote: Am 23.01.2014 20:04 schrieb Yuri y...@rawbw.com: On 01/21/2014 15:31, Shane Ambler wrote: I think you will find that qbittorrent will need to be built with the same gcc version as libtorrent-rasterbar. I believe qbittorrent is loading /usr/lib/libstdc++.so.6 then it loads libtorrent-rasterbar.so.7 which tries to load libstdc++ and it is given the already open copy which doesn't have GLIBCXX_3.4.15 that it needs to run. Yes, you are right, thst's what is happening. So if any dependency has USE_GCC set, all dependent packages should also have USE_GCC set. Can ports build infrastructure automatically set USE_GCC for dependent ports? Because doing this by hand in each port is tedious and error prone. Yuri No it can't right now and this is why we need a ports compiler. Right now we are hiding this problems by the fact that we are able to build 95% percent of the tree with clang and everyone is happy. We add dozens of patches to compile with clang or add this rpath workarounds to even more ports just because nobody wants to acknowledge that this is shit and won't work properly unless really everything is build with one compiler. The rpath stuff is only a workaround that works in a few cases but it doesn't work in all cases. You will still see very hard to diagnose runtime crashes. While I basically agree with this sentiment, is not it just ports that use C++ that are affected? Could not this be narrowed down to We need a single compiler for ports that use C++ ? John ___ 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: USE_GCC doesn't set rpath
Am 23.01.2014 20:53, schrieb Bernhard Fröhlich: Am 23.01.2014 20:04 schrieb Yuri y...@rawbw.com: On 01/21/2014 15:31, Shane Ambler wrote: I think you will find that qbittorrent will need to be built with the same gcc version as libtorrent-rasterbar. I believe qbittorrent is loading /usr/lib/libstdc++.so.6 then it loads libtorrent-rasterbar.so.7 which tries to load libstdc++ and it is given the already open copy which doesn't have GLIBCXX_3.4.15 that it needs to run. Yes, you are right, thst's what is happening. So if any dependency has USE_GCC set, all dependent packages should also have USE_GCC set. Can ports build infrastructure automatically set USE_GCC for dependent ports? Because doing this by hand in each port is tedious and error prone. Yuri No it can't right now and this is why we need a ports compiler. Right now we are hiding this problems by the fact that we are able to build 95% percent of the tree with clang and everyone is happy. We add dozens of patches to compile with clang or add this rpath workarounds to even more ports just because nobody wants to acknowledge that this is shit and won't work properly unless really everything is build with one compiler. No reason to use offensive language. We can technically provide/use different ports compilers, the only thing is that we need to make sure to separate ports by their ABI. I. e. clang-built C++ ports require clang-built C++ requisites. Meaning that you may need to install the same library twice, once with GCC47 ABI, once with clang ABI - and of course the rpath needs to be set accordingly. Possibly we also need to provide only static versions of compiler-dependent libs (such as libcompiler-rt for clang and libgcc* for GCC) to overcome the particular problem Bernhard is describing. Again, this mostly affects C++ ports, and to a lesser extent Objective-C ports. The rpath stuff is only a workaround that works in a few cases but it doesn't work in all cases. You will still see very hard to diagnose runtime crashes. If the ABIs are not compatible, then linking should not work - for instance, if I compile rawtherapee with GCC, it will not link against requisites built with clang. ___ 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: USE_GCC doesn't set rpath
On 01/23/2014 11:56, John Marino wrote: While I basically agree with this sentiment, is not it just ports that use C++ that are affected? Could not this be narrowed down to We need a single compiler for ports that use C++ ? It's not necessarily just C++. Python ports bound to C++ libraries with USE_GCC would create even more grave problem. It will be needed to create a special version of python with this rpath in it. And if there is a mix of different versions of gcc in various dependencies it would be just impossible to run such program due to conflicts. Yuri ___ 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: USE_GCC doesn't set rpath
Am 23.01.2014 21:00 schrieb Matthias Andree matthias.and...@gmx.de: Am 23.01.2014 20:53, schrieb Bernhard Fröhlich: Am 23.01.2014 20:04 schrieb Yuri y...@rawbw.com: On 01/21/2014 15:31, Shane Ambler wrote: I think you will find that qbittorrent will need to be built with the same gcc version as libtorrent-rasterbar. I believe qbittorrent is loading /usr/lib/libstdc++.so.6 then it loads libtorrent-rasterbar.so.7 which tries to load libstdc++ and it is given the already open copy which doesn't have GLIBCXX_3.4.15 that it needs to run. Yes, you are right, thst's what is happening. So if any dependency has USE_GCC set, all dependent packages should also have USE_GCC set. Can ports build infrastructure automatically set USE_GCC for dependent ports? Because doing this by hand in each port is tedious and error prone. Yuri No it can't right now and this is why we need a ports compiler. Right now we are hiding this problems by the fact that we are able to build 95% percent of the tree with clang and everyone is happy. We add dozens of patches to compile with clang or add this rpath workarounds to even more ports just because nobody wants to acknowledge that this is shit and won't work properly unless really everything is build with one compiler. No reason to use offensive language. The reason is my frustration on that topic. We can technically provide/use different ports compilers, the only thing is that we need to make sure to separate ports by their ABI. I. e. clang-built C++ ports require clang-built C++ requisites. Meaning that you may need to install the same library twice, once with GCC47 ABI, once with clang ABI - and of course the rpath needs to be set accordingly. From what I know about how we build packaged and how the portstree works I think it's nearly impossible to do that. The bloat and resources we waste with that sounds even worse. Possibly we also need to provide only static versions of compiler-dependent libs (such as libcompiler-rt for clang and libgcc* for GCC) to overcome the particular problem Bernhard is describing. Again, this mostly affects C++ ports, and to a lesser extent Objective-C ports. Yes that's true but since a lot of desktop stuff is c++ based nowadays and uses boost this affects quite a few people. The rpath stuff is only a workaround that works in a few cases but it doesn't work in all cases. You will still see very hard to diagnose runtime crashes. If the ABIs are not compatible, then linking should not work - for instance, if I compile rawtherapee with GCC, it will not link against requisites built with clang. No the problems I mean are at runtime. An example is if you have a gcc programm that loads other components like Qt stuff that was compiled with clang them there are some subtile differences that will cause crashes. This might also be some strange bug in our old gcc toolchain but so far nobody had a clue what is going wrong there. http://lists.freebsd.org/pipermail/freebsd-emulation/2013-September/010769.html ___ 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
port hyperic-sigar - marked broken, is anybody fixing this port?
Hi Java is probably not the first programming language which comes to mind, when working with FreeBSD. But still I sadly had to forgive to deploy OpenKM because it can't start LibreOffice as service due to the fact, that the author used hyperic-sigar for this functionality. My question: Is anybody working on this problem, that instead of using utmp.h and diddling with the related files directly, one should rely on utmpx.h and its db manipulating functionality. I could give it a try for FreeBSD9, but I'm mostly a noob, be it Java or Java extensions and also for ports. Maybe some kindred soul could fill me in such, that this itch can be scratched. Werner ___ 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: USE_GCC doesn't set rpath
Am 23.01.2014 21:41, schrieb Bernhard Fröhlich: Am 23.01.2014 21:00 schrieb Matthias Andree matthias.and...@gmx.de mailto:matthias.and...@gmx.de: If the ABIs are not compatible, then linking should not work - for instance, if I compile rawtherapee with GCC, it will not link against requisites built with clang. No the problems I mean are at runtime. An example is if you have a gcc programm that loads other components like Qt stuff that was compiled with clang them there are some subtile differences that will cause crashes. This might also be some strange bug in our old gcc toolchain but so far nobody had a clue what is going wrong there. http://lists.freebsd.org/pipermail/freebsd-emulation/2013-September/010769.html I understand that, but I still expect the link to fail when the ABI is compatible. If not, some part of the system has a bad design, and requires fixing. One of the fixes we do not have, but that we need, is making linking libraries of incompatible ABIs fail at link-time, rather than at run-time. Rationale: If you can't get it built and installed, it obviously won't fail at runtime. I'd say the options are just two: 1. the canonical lang/gcc version (the one without version suffixes) and 2. the base system compiler (which won't give you OpenMP, for instance, on 10.0 - it uses a clang version that isn't OpenMP-enabled). Anything else is going to blow up. And to be really precise, it's down to the ABI and default libraries rather than the compiler. (Only it's so much easier to get clang to link with libstdc++ than getting GCC to link with libc++.) ___ 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: USE_GCC doesn't set rpath
On Thu, Jan 23, 2014 at 9:56 PM, John Marino freebsd.cont...@marino.stwrote: On 1/23/2014 20:53, Bernhard Fröhlich wrote: Am 23.01.2014 20:04 schrieb Yuri y...@rawbw.com: On 01/21/2014 15:31, Shane Ambler wrote: I think you will find that qbittorrent will need to be built with the same gcc version as libtorrent-rasterbar. I believe qbittorrent is loading /usr/lib/libstdc++.so.6 then it loads libtorrent-rasterbar.so.7 which tries to load libstdc++ and it is given the already open copy which doesn't have GLIBCXX_3.4.15 that it needs to run. Yes, you are right, thst's what is happening. So if any dependency has USE_GCC set, all dependent packages should also have USE_GCC set. Can ports build infrastructure automatically set USE_GCC for dependent ports? Because doing this by hand in each port is tedious and error prone. Yuri No it can't right now and this is why we need a ports compiler. Right now we are hiding this problems by the fact that we are able to build 95% percent of the tree with clang and everyone is happy. We add dozens of patches to compile with clang or add this rpath workarounds to even more ports just because nobody wants to acknowledge that this is shit and won't work properly unless really everything is build with one compiler. The rpath stuff is only a workaround that works in a few cases but it doesn't work in all cases. You will still see very hard to diagnose runtime crashes. While I basically agree with this sentiment, is not it just ports that use C++ that are affected? Could not this be narrowed down to We need a single compiler for ports that use C++ ? No. Everything that uses language- or feature-support library are affected. I'm, for example, unable to use OpenMP higher than 2.5 even if compiler is gcc-4.8, which is openmp-3.x capable). But, from my point of view, the problem is not a compiler nor rpath. rpath is unneeded indeed, and library indeed may be only one (under /lib). The real problem is that this is ancient library, not the most recent one. They are especially designed to be backward compatible and have the same so-number for a reason. -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ 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: ports/185614: editors/openoffice-4 does not configure, dbus-deps missing
As MAINTAINER has timed out anyway, I cc freebsd-ports@. As of at least svn path=/head/; revision=340861, the problem of dbus not being pulled by editors/openoffice-4 disappears. I do not believe compilation without dbus has any practical relevance. I suggest to close the PR. -- Christopher J. Ruwe, Dipl.-Kfm. u. M.Comp.Sc. TZ: GMT + 1h GnuPG/GPG: 0xE8DE2C14 FreeBSD 9.2-STABLE #1 r256184: Thu Oct 10 19:12:54 CEST 2013 c...@dijkstra.cruwe.de:/usr/obj/usr/home/cjr/media/src/freebsd/base/stable/9/sys/GEN_WDTRACE Punctuation matters: Lets eat Grandma. or Lets eat, Grandma. - Punctuation saves lives. A panda eats shoots and leaves. or A panda eats, shoots, and leaves. - Punctuation teaches proper biology. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (RFC 1925) ___ 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
[QAT] r340875: 4x fail
- Add dependency on avbin - Install more docs PR: 182517 Submitted by: nemysis - Build ID: 20140124012600-5208 Job owner: amd...@freebsd.org Buildtime: 42 minutes Enddate: Fri, 24 Jan 2014 02:07:35 GMT Revision: r340875 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=340875 - Port:graphics/py-pyglet 1.1.4_3 Buildgroup: 8.4-QAT/amd64 Buildstatus: FAIL Buildgroup: 8.4-QAT/i386 Buildstatus: FAIL Buildgroup: 9.2-QAT/amd64 Buildstatus: FAIL Buildgroup: 9.2-QAT/i386 Buildstatus: FAIL -- Buildarchive URL: https://qat.redports.org/buildarchive/20140124012600-5208 redports https://qat.redports.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
INDEX now builds successfully on 8.x
___ 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
Errors building p5-Mouse port
Hi all, I have a poudriere server used to rebuild packages for my Fbsd8 and Fbsd10 servers. Due to some dependencies, p5-Mouse port needs to be installed for both releases. But for both releases, build fails for this port with the following errors: xs-src/MouseAccessor.xs = xs-src/MouseAccessor.c xs-src/MouseAttribute.xs = xs-src/MouseAttribute.c xs-src/MouseTypeConstraints.xs = xs-src/MouseTypeConstraints.c xs-src/MouseUtil.xs = xs-src/MouseUtil.c cc -I. -Ixs-src -I/usr/local/lib/perl5/5.14/mach/CORE -DPIC -fPIC -Wall -Wextra -Wdeclaration-after-statement -Wc++-compat -c -O2 -pipe -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -o xs-src/MouseUtil.o xs-src/MouseUtil.c xs-src/MouseTypeConstraints.xs: In function 'boot_Mouse__Util': xs-src/MouseTypeConstraints.xs:609: warning: implicit declaration of function 'setup_my_cxt' xs-src/MouseTypeConstraints.xs:612: warning: implicit declaration of function 'DEFINE_TC' xs-src/MouseTypeConstraints.xs:612: error: 'Any' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:612: error: (Each undeclared identifier is reported only once xs-src/MouseTypeConstraints.xs:612: error: for each function it appears in.) xs-src/MouseTypeConstraints.xs:613: error: 'Undef' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:614: error: 'Defined' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:615: error: 'Bool' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:616: error: 'Value' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:617: error: 'Ref' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:618: error: 'Str' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:619: error: 'Num' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:620: error: 'Int' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:621: error: 'ScalarRef' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:622: error: 'ArrayRef' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:623: error: 'HashRef' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:624: error: 'CodeRef' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:625: error: 'GlobRef' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:626: error: 'FileHandle' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:627: error: 'RegexpRef' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:628: error: 'Object' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:629: error: 'ClassName' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:630: error: 'RoleName' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:695: error: 'MTC_CLASS' undeclared (first use in this function) xs-src/MouseTypeConstraints.xs:695: error: expected ')' before string constant xs-src/MouseTypeConstraints.xs:695: error: too few arguments to function 'Perl_newXS' xs-src/MouseTypeConstraints.xs:699: error: expected ')' before string constant xs-src/MouseTypeConstraints.xs:699: error: too few arguments to function 'Perl_get_sv' xs-src/MouseTypeConstraints.xs:706: error: expected ')' before string constant xs-src/MouseTypeConstraints.xs:706: error: too few arguments to function 'Perl_get_cv' xs-src/MouseTypeConstraints.xs:708: error: expected ')' before 'MTC_CLASS' xs-src/MouseTypeConstraints.xs:708: error: expected ')' before string constant xs-src/MouseTypeConstraints.xs:715: error: expected ')' before string constant xs-src/MouseTypeConstraints.xs:715: error: too few arguments to function 'Perl_get_cv' xs-src/MouseTypeConstraints.xs:717: error: expected ')' before 'MTC_CLASS' xs-src/MouseTypeConstraints.xs:717: error: expected ')' before string constant xs-src/MouseTypeConstraints.xs:724: error: expected ')' before string constant xs-src/MouseTypeConstraints.xs:724: error: too few arguments to function 'Perl_get_cv' xs-src/MouseTypeConstraints.xs:726: error: expected ')' before 'MTC_CLASS' xs-src/MouseTypeConstraints.xs:726: error: expected ')' before string constant error building xs-src/MouseUtil.o from 'xs-src/MouseUtil.c' at /usr/local/lib/perl5/5.14/ExtUtils/CBuilder/Base.pm line 175, DATA line 1. *** Error code 2 Stop in /usr/ports/devel/p5-Mouse. === Cleaning for p5-Mouse-2.1.0,1 build of /usr/ports/devel/p5-Mouse ended at Thu Jan 23 12:41:26 UTC 2014 build time: 00:00:14 I am not the only user with this problem: http://freebsd.1045724.n5.nabble.com/devel-p5-Mouse-td5865703.html Any idea why this port fails to build?? Thanks. P.D: Sorry for the cross posting, but I am not sure which mailing list to choose. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to
