Update gcc?
At the risk of starting a kerfuffle, is there any reason to update gcc on 8.4 or 9.2 from the GPLv2 version 4.2.1 to something more current? (I can think of many reasons *not* to, but they all have to do with writing code which I am not doing). I know 10.0 moves to clang (which is familiar to me since OS X changed to clang a while ago because of the GPLv3 issues), but I'm not ready to move to 10.0 and I know there are still issues with clang and that some packages still require gcc. -- The only reason for walking into the jaws of Death is so's you can steal His gold teeth. --Colour of Magic ___ 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 gcc?
2014-02-25 10:57 GMT+01:00 LuKreme krem...@kreme.com: At the risk of starting a kerfuffle, is there any reason to update gcc on 8.4 or 9.2 from the GPLv2 version 4.2.1 to something more current? (I can think of many reasons *not* to, but they all have to do with writing code which I am not doing). I know 10.0 moves to clang (which is familiar to me since OS X changed to clang a while ago because of the GPLv3 issues), but I'm not ready to move to 10.0 and I know there are still issues with clang and that some packages still require gcc. You answered your own question ;) If you need a newer GCC, you can install one from ports / packages: lang/gcc (currently 4.6) or lang/gcc4[6-9] for a specific version. After that set CC and CXX in /etc/make.conf to the newer GCC. Regards, René ___ 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] r345934: 4x leftovers
Support staging - Build ID: 20140225085600-54851 Job owner: eha...@freebsd.org Buildtime: 2 hours Enddate: Tue, 25 Feb 2014 11:23:53 GMT Revision: r345934 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=345934 - Port:ports-mgmt/pkg-rmleaf 0.2 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~eha...@freebsd.org/20140225085600-54851-285856/pkg-rmleaf-0.2.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~eha...@freebsd.org/20140225085600-54851-285857/pkg-rmleaf-0.2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~eha...@freebsd.org/20140225085600-54851-285858/pkg-rmleaf-0.2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~eha...@freebsd.org/20140225085600-54851-285859/pkg-rmleaf-0.2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140225085600-54851 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
Support for pkg_*
Has support for the pkg_* suite of tools gone away? After performing an svn update of my ports tree last night; both openssl and monit failed to build packages, due to missing man pages openssl failed, as follows Creating bzip'd tar ball in '/var/ports/usr/ports/security/openssl/work/openssl-1.0.1_9.tbz' tar: man/man1/CA.pl.1.gz: Cannot stat: No such file or directory tar: man/man1/asn1parse.1.gz: Cannot stat: No such file or directory ... tar: man/man7/des_modes.7.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** [do-package] Error code 1 Stop in /usr/ports/security/openssl. So I reverted /usr/ports/security/openssl to 340722, but now monit also stops with === Building package for monit-5.7 tar: man/man1/monit.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 Creating package /var/ports/usr/ports/sysutils/monit/work/monit-5.7.tbz Registering depends:. Creating bzip'd tar ball in '/var/ports/usr/ports/sysutils/monit/work/monit-5.7.tbz' *** [do-package] Error code 1 Regards, Dewayne. ___ 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: Support for pkg_*
On Tue, Dec 24, 2013 at 3:11 AM, Thomas Mueller from Dewayne Geraghty: Has support for the pkg_* suite of tools gone away? After performing an svn update of my ports tree last night; both openssl and monit failed to build packages, due to missing man pages What version of FreeBSD are you on? pkg_* suite is gone from FreeBSD 10.0 and later, in favor of the new pkgng. I think pkg_* suite will even be gone from FreeBSD 9.3 when and if that comes out. Tom ___ 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: Support for pkg_*
Dewayne Geraghty wrote: Has support for the pkg_* suite of tools gone away? As someone already stated, the pkg_* tools are no longer in FreeBSD 10, but they are still available (and default) on 9.2-RELEASE and earlier. tar: man/man1/CA.pl.1.gz: Cannot stat: No such file or directory tar: man/man1/asn1parse.1.gz: Cannot stat: No such file or directory ... tar: man/man7/des_modes.7.gz: Cannot stat: No such file or directory Please forgive me the pavlov reaction that I get from Cannot stat: bla bla bla, but that actually smells more like a staging issue to me. Have you tried adding NO_STAGE=yes to the port's Makefile and trying again? AvW -- I'm not completely useless, I can be used as a bad example. pgp103bYggvFg.pgp Description: PGP signature
Re: Support for pkg_*
On Tue, Feb 25, 2014 at 03:11:44PM +0100, A.J. 'Fonz' van Werven wrote: Dewayne Geraghty wrote: Has support for the pkg_* suite of tools gone away? As someone already stated, the pkg_* tools are no longer in FreeBSD 10, but they are still available (and default) on 9.2-RELEASE and earlier. tar: man/man1/CA.pl.1.gz: Cannot stat: No such file or directory tar: man/man1/asn1parse.1.gz: Cannot stat: No such file or directory ... tar: man/man7/des_modes.7.gz: Cannot stat: No such file or directory Please forgive me the pavlov reaction that I get from Cannot stat: bla bla bla, but that actually smells more like a staging issue to me. Have you tried adding NO_STAGE=yes to the port's Makefile and trying again? Can we stop advertising the above, this is completly wrong, it hides the dust behind the carpet and won't fix anything! The said port is needed a fix. regards, Bapt pgpCoWFOnhFZY.pgp Description: PGP signature
Re: Support for pkg_*
On Tue, Feb 25, 2014 at 07:42:59PM +1100, Dewayne Geraghty wrote: Has support for the pkg_* suite of tools gone away? After performing an svn update of my ports tree last night; both openssl and monit failed to build packages, due to missing man pages openssl failed, as follows Creating bzip'd tar ball in '/var/ports/usr/ports/security/openssl/work/openssl-1.0.1_9.tbz' tar: man/man1/CA.pl.1.gz: Cannot stat: No such file or directory tar: man/man1/asn1parse.1.gz: Cannot stat: No such file or directory ... tar: man/man7/des_modes.7.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** [do-package] Error code 1 Stop in /usr/ports/security/openssl. So I reverted /usr/ports/security/openssl to 340722, but now monit also stops with === Building package for monit-5.7 tar: man/man1/monit.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 Creating package /var/ports/usr/ports/sysutils/monit/work/monit-5.7.tbz Registering depends:. Creating bzip'd tar ball in '/var/ports/usr/ports/sysutils/monit/work/monit-5.7.tbz' *** [do-package] Error code 1 What options do you have for both prots? regards, Bapt pgpJMaOH7Aug0.pgp Description: PGP signature
Re: Support for pkg_*
On Tue, Feb 25, 2014 at 12:47:47PM +, Thomas Mueller wrote: On Tue, Dec 24, 2013 at 3:11 AM, Thomas Mueller from Dewayne Geraghty: Has support for the pkg_* suite of tools gone away? After performing an svn update of my ports tree last night; both openssl and monit failed to build packages, due to missing man pages What version of FreeBSD are you on? pkg_* suite is gone from FreeBSD 10.0 and later, in favor of the new pkgng. I think pkg_* suite will even be gone from FreeBSD 9.3 when and if that comes out. The exact schedule is described here: http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/ regards, Bapt pgpGtqqjzxtzP.pgp Description: PGP signature
Re: Support for pkg_*
On Tue, Feb 25, 2014, at 2:42, Dewayne Geraghty wrote: Has support for the pkg_* suite of tools gone away? After performing an svn update of my ports tree last night; both openssl and monit failed to build packages, due to missing man pages Port committers are advised to test ports against both pkgng and pkg_tools until pkg_tools is fully retired. Unfortunately this gets overlooked as many in the project strictly use and test against pkgng. Please file PRs when you see this. ___ 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
portmaster, pkg, virtualbox-ose
Hi all, I'm installing a new system (laptop) using 10.0R and pkgng. freshports.org says virtualbox-ose can be installed with pkg but # pkg install virtualbox-ose says no package in the repository. Ok so try # portmaster emulators/virtualbox-ose install all the dependencies with pkg then let it build and it's looking good. But I had to turn off the computer before it finished. I terminated the job with Ctrl-C and portmaster told me: === Build/Install for emulators/virtualbox-ose exiting due to signal === Killing background jobs Terminated === You can restart from the point of failure with this command line: portmaster flags emulators/virtualbox-ose === Exiting But restarting with # portmaster emulators/virtualbox-ose starts by cleaning for virtualbox then starts again. Have I misunderstood something? I checked the work directory before and after the cleaning step and nearly everything was deleted. It's building now and I think it has time to finish so there isn't an immediate problem but I would like to find answers to the above. thanks Chris ___ 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
net/owncloud-csync,deskutils/mirall owncloudcmd segfault
Hi, I see a segfault when trying to sync a directory using the owncloudcmd CLI client. The command line is pretty straightforward: owncloudcmd Documents ownclouds://URL/owncloud/remote.php/webdav/ The backtrace: #0 0x000809f79da4 in SSL_CTX_set_client_cert_cb () from /usr/lib/libssl.so.7 #1 0x00080521eab8 in ne_ssl_context_create (mode=value optimized out) at ne_openssl.c:575 #2 0x00080520f85e in ne_session_create (scheme=0x7fffccc2 https, hostname=0x80c470a60 owncloud.codepro.be, port=value optimized out) at ne_session.c:176 #3 0x000800b6cd92 in dav_connect ( base_url=0x80c46f480 ownclouds://owncloud.codepro.be:443/owncloud/remote.php/webdav) at /var/ports/basejail/usr/ports/net/owncloud-csync/work/ocsync-0.91.4/src/csync_owncloud.c:509 #4 0x000800b6aa55 in owncloud_opendir ( uri=0x80c46f480 ownclouds://owncloud.codepro.be:443/owncloud/remote.php/webdav) at /var/ports/basejail/usr/ports/net/owncloud-csync/work/ocsync-0.91.4/src/csync_owncloud.c:982 #5 0x000800b687c8 in csync_vio_opendir (ctx=0x80c478500, name=0x80c46f480 ownclouds://owncloud.codepro.be:443/owncloud/remote.php/webdav) at /var/ports/basejail/usr/ports/net/owncloud-csync/work/ocsync-0.91.4/src/vio/csync_vio.c:370 #6 0x000800b5eb04 in csync_ftw (ctx=0x80c478500, uri=0x80c46f480 ownclouds://owncloud.codepro.be:443/owncloud/remote.php/webdav, fn=0x800b5d980 csync_walker, depth=50) at /var/ports/basejail/usr/ports/net/owncloud-csync/work/ocsync-0.91.4/src/csync_update.c:449 #7 0x000800b5702b in csync_update (ctx=0x80c478500) at /var/ports/basejail/usr/ports/net/owncloud-csync/work/ocsync-0.91.4/src/csync.c:431 #8 0x0008008a1ec3 in Mirall::CSyncThread::startSync (this=0x7fffd4e0) at /var/ports/basejail/usr/ports/deskutils/mirall/work/mirall-1.5.0/src/mirall/csyncthread.cpp:505 #9 0x004044f5 in main (argc=3, argv=0x7fffd768) at /var/ports/basejail/usr/ports/deskutils/mirall/work/mirall-1.5.0/src/owncloudcmd/owncloudcmd.cpp:140 Looking into this, the crash occurs inside neon, specifically inside ne_ssl_context_create(). It crashes because the call to SSL_CTX_new(SSLv23_client_method()); returns NULL. OpenSSL gives me the following error: error:140A90A1:lib(20):func(169):reason(161) This means that we haven't called SSL_library_init(). Neon does this in ne_ssl_init(), which itself is called by ne_sock_init(). The ne_sock_init() call isn't done by owncloud-csync. The code is present in the dav_connect() function (src/csync_owncloud.c) but it's surrounded by '#if 0'. Removing the '#if 0' fixes my crash. I've noticed that there's a new version of deskutils/mirall (1.5.1) with the following changelog entry: Imported the ocsync library into miralls repository. So, now I'm not sure what the right fix is here. It's quite possible that version 1.5.1 fixes the problem and it's almost certain that the fix will be different. Regards, Kristof ___ 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: portmaster, pkg, virtualbox-ose
On Tue, 25 Feb 2014, Chris Whitehouse wrote: === You can restart from the point of failure with this command line: portmaster flags emulators/virtualbox-ose === Exiting But restarting with # portmaster emulators/virtualbox-ose starts by cleaning for virtualbox then starts again. Have I misunderstood something? I checked the work directory before and after the cleaning step and nearly everything was deleted. It's building now and I think it has time to finish so there isn't an immediate problem but I would like to find answers to the above. Portmaster cleans a port before starting to build. That's the safe thing to do, there is no good way to know why a work directory is still there, and options may have changed. -C can be used to prevent portmaster from cleaning first. ___ 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: Stop in ports/lang/gcc47: Shared object libfl.so.2 not found, required by ar
On Mon, 24 Feb 2014 23:41:22 -0500 Chad J. Milios wrote: I've been getting this same error for a couple days now in ports. 9.2-RELEASE-p3/amd64. Any insight into what I'm doing wrong? My gut is telling me this is my fault though I'm at a loss for how. Try to rebuild devel/binutils. There was a short window in which textproc/flex installed libfl.so.2 and it looks like you rebuilt devel/binutils in that window. ___ 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: net/owncloud-csync,deskutils/mirall owncloudcmd segfault
On 2014-02-25 19:27:29 (+0100), Kristof Provost kris...@sigsegv.be wrote: So, now I'm not sure what the right fix is here. It's quite possible that version 1.5.1 fixes the problem and it's almost certain that the fix will be different. I've managed to build mirall-1.5.1 and the problem is fixed there. Regards, Kristof ___ 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: portmaster, pkg, virtualbox-ose
On 25/02/2014 19:18, Warren Block wrote: On Tue, 25 Feb 2014, Chris Whitehouse wrote: === You can restart from the point of failure with this command line: portmaster flags emulators/virtualbox-ose === Exiting But restarting with # portmaster emulators/virtualbox-ose starts by cleaning for virtualbox then starts again. Have I misunderstood something? I checked the work directory before and after the cleaning step and nearly everything was deleted. It's building now and I think it has time to finish so there isn't an immediate problem but I would like to find answers to the above. Portmaster cleans a port before starting to build. That's the safe thing to do, there is no good way to know why a work directory is still there, and options may have changed. -C can be used to prevent portmaster from cleaning first. Thank you. Apologies for not reading the portmaster man page first, I used portmaster for the first time last night and have a hard deadline of tomorrow to finish the laptop so in a bit of a panic. I'll have a proper read asap. Chris ___ 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: portmaster, pkg, virtualbox-ose
Am 25.02.2014 19:16 schrieb Chris Whitehouse cwhi...@onetel.com: Hi all, I'm installing a new system (laptop) using 10.0R and pkgng. freshports.org says virtualbox-ose can be installed with pkg but # pkg install virtualbox-ose says no package in the repository. virtualbox had a build failure due to iconv issues on 10.0 last week so this is why no package exists right now. It is already fixed so packages should be back with the next build run. Ok so try # portmaster emulators/virtualbox-ose install all the dependencies with pkg then let it build and it's looking good. But I had to turn off the computer before it finished. I terminated the job with Ctrl-C and portmaster told me: === Build/Install for emulators/virtualbox-ose exiting due to signal === Killing background jobs Terminated === You can restart from the point of failure with this command line: portmaster flags emulators/virtualbox-ose === Exiting But restarting with # portmaster emulators/virtualbox-ose starts by cleaning for virtualbox then starts again. Have I misunderstood something? I checked the work directory before and after the cleaning step and nearly everything was deleted. It's building now and I think it has time to finish so there isn't an immediate problem but I would like to find answers to the above. thanks Chris ___ 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
Problem with old package system
I have a system that is still using the old pkg_ system that has had indigestion since the docbook re-work. That operation went well as I didn't try it until I had dealt with my 10.0 system running pkgng. Now, since the docbook upgrade did not recommend the use of '-o' for any updates, I have hundreds of missing dependencies on the various old docbook ports. I figured that a quick run of pkgdb -F would fix it, but pkgdb found nothing to fix. I then looked at the man page for pkgfb and it looks like -L is now required to fix missing dependencies. Is pkgfb -L the right command? Looks like it. Was any information that -F no longer did this posted anywhere? I see an entry in updating that recommends running pkgdb -Ff as recently as Feb-14, but no recommendations anywhere to use the 'L' (fix-lost) option. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@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: Stop in ports/lang/gcc47: Shared object libfl.so.2 not found, required by ar
On 2/25/2014 2:18 PM, Tijl Coosemans wrote: On Mon, 24 Feb 2014 23:41:22 -0500 Chad J. Milios wrote: I've been getting this same error for a couple days now in ports. 9.2-RELEASE-p3/amd64. Any insight into what I'm doing wrong? My gut is telling me this is my fault though I'm at a loss for how. Try to rebuild devel/binutils. There was a short window in which textproc/flex installed libfl.so.2 and it looks like you rebuilt devel/binutils in that window. That is exactly what fixed the problem. Thank you ___ 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: multimedia/tvheadend fails under FreeBSD 9.2-stable
On Sat, Feb 15, 2014 at 1:03 PM, Bernhard Fröhlich de...@bluelife.at wrote: Am 15.02.2014 12:13 schrieb Torfinn Ingolfsen tin...@gmail.com: includes, so let me ask this way: - will / should DVB-C devices (via webcamd) work even without libav? - will CSA / cwc work even without libav? Yes, both should work. It uses libdvbcsa for that. What you loose is transcoding and streaming via the webinterface. Thanks. I'm not having much luck with the ports (as described on the freebsd-multimedia mailinglist). I notice that the latest stable tvheadend is 3.4.27, which includes DVB service discovery bugs fixed. But I'm guessing (based on the ports Makefile, and that you host the distfile) that it will take a bit more than updating the version number in the Makefile and doing 'make makesum' to upgrade the port? -- Regards, Torfinn Ingolfsen ___ 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: Support for pkg_*
Baptiste Daroussin wrote: Can we stop advertising the above, this is completly wrong, it hides the dust behind the carpet and won't fix anything! The said port is needed a fix. Granted: it's not staging itself that is the problem, it's incorrect usage thereof. But anyone possessing even the tiniest trace amount of realism will have to concede that port maintainers do occasionally get it wrong. And when they do the errors as reported by the OP are a tell-tale symptom. Indeed: disabling/avoiding staging doesn't fix the actual problem, but it does usually mitigate the symptom(s) and could in such cases be used as a temporary workaround for those who - for whatever reason - are disinclined to wait for the port to get fixed. I'd even go as far as to say that disabling staging can be used as a diagnostic tool: if a port that (supposedly) supports staging doesn't install properly, but does so with staging disabled, it's a pretty safe bet that the maintainer didn't get the staging bit entirely correct. Of course it would then be a good idea to notify said port maintainer (and submitting patches if at all possible), but in this particular case we didn't even get there. Or to put it another way: I did not mean to suggest that there's something wrong with your precious baby. In fact, I'm actually rather fond of her. However, it appears that not everybody is holding her properly yet ;-) AvW -- I'm not completely useless, I can be used as a bad example. pgpIZMnCfProx.pgp Description: PGP signature
Re: Support for pkg_*
On 2/25/2014 23:08, A.J. 'Fonz' van Werven wrote: Baptiste Daroussin wrote: Can we stop advertising the above, this is completly wrong, it hides the dust behind the carpet and won't fix anything! The said port is needed a fix. Granted: it's not staging itself that is the problem, it's incorrect usage thereof. But anyone possessing even the tiniest trace amount of realism will have to concede that port maintainers do occasionally get it wrong. And when they do the errors as reported by the OP are a tell-tale symptom. No one should have a problem conceding that. The issue is that it seems that many ports are staged without checking in redports / poudriere or otherwise. I was even guilty of this the other day. I was on the road and I created two new ports that easily passed with DEVELOPER_MODE. Neither built in clean environment though and I got rewarded with pkg-fallout messages. A lot of stuff gets committed that it's clear was never remotely tested, not even with portlint. But don't blame the tools -- the port needs to be fixed. I agree that we should never advise NO_STAGE=yes, ever. If the port is broken, so be it. PR, patch, normal process. There's been a lot of understandable grumbling due to growing pains of major infrastructure changes by users, so telling users to revert these changes isn't a good look. Let's just try to get the port fixed in a reasonable timeframe (e.g. get the guy that broke it to take care of it). 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: Support for pkg_*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 25.02.2014 23:08, schrieb A.J. 'Fonz' van Werven: Indeed: disabling/avoiding staging doesn't fix the actual problem, but it does usually mitigate the symptom(s) and could in such cases be used as a temporary workaround for those who - for whatever reason - are disinclined to wait for the port to get fixed. No, it is not a viable workaround. Any nontrivial port that is converted to staging will usually no longer work without. You would have to roll back the port to the SVN checkout from before the conversion to staging, providing it was intact before. Issues are Missing manual pages, missed post-install scripts, and more. You may find an occasional port that works with some magic command line flags added, but those are exceptions. I'd even go as far as to say that disabling staging can be used as a diagnostic tool: if a port that (supposedly) supports staging doesn't install properly, but does so with staging disabled, it's a pretty safe bet that the maintainer didn't get the staging bit entirely correct. Of course it would then be a good idea to notify said port maintainer (and submitting patches if at all possible), but in this particular case we didn't even get there. That isn't a diagnostic tool, but a sure-fire recipe to extend the confusion. The reliable diagnostic means are pretty well known: make clean make DEVELOPER=yes check-orphans package And poudriere testport (with proper options according to jail/ports setup) And using the redports.org online service for test builds. It's pretty simple if you can use SVN and a web browser. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlMNGXEACgkQvmGDOQUufZUrIACgsfFb9ciR1eroaNsEUIbLkGz+ /N4Ani4gllgBsQqwYGmTJz6aMzwtfdTs =MJcF -END PGP SIGNATURE- ___ 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] r346074: 4x leftovers
net-im/kopete-kde4: - Both security/libotr3 and security/libotr install libotr.so. Explicitly require libotr.so.5 from security/libotr because kopete can't be built with old version. PR: ports/186943 Submitted by: amdmi3 - Build ID: 20140225203405-37574 Job owner: m...@freebsd.org Buildtime: 2 hours Enddate: Tue, 25 Feb 2014 22:33:40 GMT Revision: r346074 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=346074 - Port:net-im/kopete-kde4 4.12.2 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140225203405-37574-286456/kopete-4.12.2.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140225203405-37574-286457/kopete-4.12.2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140225203405-37574-286458/kopete-4.12.2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140225203405-37574-286459/kopete-4.12.2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140225203405-37574 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
Re: net/owncloud-csync,deskutils/mirall owncloudcmd segfault
+--On 25 février 2014 20:22:02 +0100 Kristof Provost kris...@sigsegv.be wrote: | On 2014-02-25 19:27:29 (+0100), Kristof Provost kris...@sigsegv.be | wrote: | So, now I'm not sure what the right fix is here. It's quite possible | that version 1.5.1 fixes the problem and it's almost certain that the | fix will be different. | | I've managed to build mirall-1.5.1 and the problem is fixed there. The 1.5.1 update was on my todo, I'll have a look at it tomorrow. -- Mathieu Arnold ___ 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: Support for pkg_*
On 26/02/2014 3:46 AM, Baptiste Daroussin wrote: On Tue, Feb 25, 2014 at 07:42:59PM +1100, Dewayne Geraghty wrote: Has support for the pkg_* suite of tools gone away? After performing an svn update of my ports tree last night; both openssl and monit failed to build packages, due to missing man pages openssl failed, as follows Creating bzip'd tar ball in '/var/ports/usr/ports/security/openssl/work/openssl-1.0.1_9.tbz' tar: man/man1/CA.pl.1.gz: Cannot stat: No such file or directory tar: man/man1/asn1parse.1.gz: Cannot stat: No such file or directory ... tar: man/man7/des_modes.7.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** [do-package] Error code 1 Stop in /usr/ports/security/openssl. So I reverted /usr/ports/security/openssl to 340722, but now monit also stops with === Building package for monit-5.7 tar: man/man1/monit.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 Creating package /var/ports/usr/ports/sysutils/monit/work/monit-5.7.tbz Registering depends:. Creating bzip'd tar ball in '/var/ports/usr/ports/sysutils/monit/work/monit-5.7.tbz' *** [do-package] Error code 1 What options do you have for both prots? regards, Bapt Of course, I should've checked make __MAKE_CONF=/dev/null before sending, but nothing had changed between yesterday and 13 days ago when the last build-set completed. An oversight. After doing the above and working through the make.conf and ports.conf files, the issue is that I use PREFIX=/usr for many ports that provide a common service to various jails. Both openssl and monit, along with 19 other ports use this PREFIX. With everything else fixed, setting PREFIX=/usr/local builds the package, while changing the PREFIX doesn't. For monit the settings in ports.conf are: PREFIX=/usr | monit_SET=SSL for openssl PREFIX=/usr | UNSET=I386 RC5 | openssl_SET=SSE2 ASM MD2 OPENSSL_COMPRESSION PADLOCK EC others port related being: PACKAGES=/packages STAGEDIR=/usr/staging FAVORITE_COMPILER=gcc DEFAULT_VERSIONS=perl5=5.16 python=2.7 python2=2.7 apache=22 WITH_CCACHE_BUILD=yes Further details in the PR http://www.freebsd.org/cgi/query-pr.cgi?pr=187076 Its a reflection of tiredness and frustration that I didn't include the 9.2 Stable version details, which I've frequently asked other listers, offline to provide. Regards, Dewayne. ___ 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: [kde-freebsd] Error using CMake similar to error from earlier list post
Hi Joe, Apologies for taking so long to get back to you. Work got really, really busy. The underlying issue is that gcc pulls in the pthread headers by default while clang does not. I believe clang is following the more correct approach. The files you attached are for traverso however I do not see it in the Port's Collection. Are you building it directly from source? On Wednesday, 11 December 2013 21:02:27 Joe Nosay wrote: I'm attaching files. 1. Undeclared identifier pthread_self:: Does this mean I need to add the pthread.h before every declaration of pthread_self? No, you only need to add it once. Normally there will be a header file. I'm guessing either to src/engine/AudioDeviceThread.cpp or to a header file included by src/engine/AudioDeviceThread.cpp 2. How do I declare an identifier? I don't know what you are referring to, could you please elaborate? 3. CLang crashed somewhat at the beginning. Files are attached. I see. Can you please try with a newer version of clang/traverso. If that does not fix the issue, then please report that upstream to the LLVM developers, this is well beyond my capabilities to fix. The files will probably be too big for the mailing lists. Now, those errors which have references in section 2 of the man pages, do I replace as suggested with cpusetid_t. For others, do I introduce a patch similar to the pthread.h from the kopete patch? Yes, patches similar to pthread.h should work. Once you get the patches working please submit them upstream. It makes our lives easier if those developers maintain the patches, instead of us. Regards signature.asc Description: This is a digitally signed message part.
