Re: [package - 91amd64-quarterly] build failure mail
On 2014-09-24 08:37, pkg-fall...@freebsd.org wrote: You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: vmage...@gmail.com Last committer: olg...@freebsd.org Ident: $FreeBSD: branches/2014Q3/editors/wordgrinder/Makefile 357277 2014-06-10 07:39:01Z olgeni $ Log URL: http://beefy2.isc.freebsd.org/data/91amd64-quarterly/2014-09-24_01h22m09s/logs/wordgrinder-0.3.3.log Build URL: http://beefy2.isc.freebsd.org/build.html?mastername=91amd64-quarterlybuild=2014-09-24_01h22m09s Log: Building editors/wordgrinder build started at Wed Sep 24 05:37:27 UTC 2014 port directory: /usr/ports/editors/wordgrinder building for: FreeBSD 91amd64-quarterly-job-16 9.1-RELEASE-p17 FreeBSD 9.1-RELEASE-p17 amd64 maintained by: vmage...@gmail.com Makefile ident: $FreeBSD: branches/2014Q3/editors/wordgrinder/Makefile 357277 2014-06-10 07:39:01Z olgeni $ Poudriere version: 3.1-pre Host OSVERSION: 1100027 Jail OSVERSION: 901000 Folks, what should I do to not receive these messages? I've already updated the port (long time ago), but I still get mail about build failures in the quarterly branch. ___ 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: [package - 91amd64-quarterly] build failure mail
On Wed, Sep 24, 2014 at 01:36:31PM +0300, Vitaly Magerya wrote: On 2014-09-24 08:37, pkg-fall...@freebsd.org wrote: You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: vmage...@gmail.com Last committer: olg...@freebsd.org Ident: $FreeBSD: branches/2014Q3/editors/wordgrinder/Makefile 357277 2014-06-10 07:39:01Z olgeni $ Log URL: http://beefy2.isc.freebsd.org/data/91amd64-quarterly/2014-09-24_01h22m09s/logs/wordgrinder-0.3.3.log Build URL: http://beefy2.isc.freebsd.org/build.html?mastername=91amd64-quarterlybuild=2014-09-24_01h22m09s Log: Building editors/wordgrinder build started at Wed Sep 24 05:37:27 UTC 2014 port directory: /usr/ports/editors/wordgrinder building for: FreeBSD 91amd64-quarterly-job-16 9.1-RELEASE-p17 FreeBSD 9.1-RELEASE-p17 amd64 maintained by: vmage...@gmail.com Makefile ident: $FreeBSD: branches/2014Q3/editors/wordgrinder/Makefile 357277 2014-06-10 07:39:01Z olgeni $ Poudriere version: 3.1-pre Host OSVERSION: 1100027 Jail OSVERSION: 901000 Folks, what should I do to not receive these messages? I've already updated the port (long time ago), but I still get mail about build failures in the quarterly branch. You should nag the committer who committed the patch to fix the build that he merges the change back to the quartely branch. pgpnelH4RxxGE.pgp Description: PGP signature
Re: FreeBSD Port: x11-servers/xorg-server
On Tuesday 23 Sep 2014 20:46:29 Patrick Powell wrote: I can't check this out right now, BUT are the keyboard/mouse drivers on the WITH_NEW_XORG repo server built correctly? They appear to be built OK, curlew:/home/mike% pkg rquery %n %v %R xf86-input-mouse xf86-input-mouse 1.9.0_4 FreeBSD xf86-input-mouse 1.9.0_4 FreeBSD_new_xorg curlew:/home/mike% pkg rquery %n %v %R xf86-input-keyboard xf86-input-keyboard 1.8.0_5 FreeBSD xf86-input-keyboard 1.8.0_5 FreeBSD_new_xorg Both repos have the same version but when I ran pkg upgrade it used FreeBSD for both these drivers with the result that I couldn't log in with KDM until I forcibly installed them from FreeBSD_new_xorg If that is the case then you can force PKG to fetch them from that REPO and then you can (using some magic I don't understand, setting something in the comment field) force PKG to always fetch from this repo. I have a plan B on this, which is to have a 'repo search order' capability added to PKG. IF you search the WITH_NEW_XORG repo first, THEN search the standard repo AND if you have two packages with the same version, etc, then you get it from the first repository you searched. Would an alternative approach when upgrading a package be to check to see if the existing package is annotated with a repository tag and use its value to decide which repository to use. This would have worked in my above example. curlew:/home/mike% pkg query %n %At %Av xf86-input-mouse xf86-input- keyboard xf86-input-mouse repo_type binary xf86-input-mouse repository FreeBSD_new_xorg xf86-input-keyboard repo_type binary xf86-input-keyboard repository FreeBSD_new_xorg It would however require the repository to be specified by the user when initially installing the package. The instructions in https://lists.freebsd.org/pipermail/freebsd-ports/2013-November/087487.html give the impression that the value of the annotation should influence the choice of repository but this does not appear to happen. -- Mike Clarke ___ 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
Need help compiling use of std::vector
I am trying to compile the new version of a port I maintain and have
trouble related to std::vector. The code producing the error can be
boiled down to the following test case, which compiles as 64bit but
fails as 32bit.
#include stdlib.h
#include vector
int main(int argc, char *argv[])
{
int num_layers = 3;
std::vectorconst char * layers (num_layers, NULL);
exit(0);
}
So that should create a vector containing 3 items initially set to NULL.
10.0 compiles ok - both 32 and 64 bit. (libc++)
8.4, 9.2 and 9.3 compiles 64bit but fails on 32bit. (libstdc++)
Using the above code
clang++ -m32 test.cpp
fails with
/usr/include/c++/4.2/bits/stl_algobase.h:641:15: error: assigning to
'const char *' from incompatible type 'const int'
I often get the following with the test case - not the real code.
error: 'operator new' takes type size_t ('unsigned int') as first parameter
I have tried changing num_layers to unsigned int, size_t, std::size_t
How do I fix this to work on 32 and 64 bit?
The original code is located on line 758 at
https://github.com/imageworks/OpenShadingLanguage/blob/master/src/testshade/testshade.cpp
--
FreeBSD - the place to B...Software Developing
Shane Ambler
___
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: On Docs option and custom build target
On Tue, 23 Sep 2014 23:23:31 +0200 Fernando Apesteguía
fernando.apesteg...@gmail.com wrote:
I have a Makefile for an application that provides both examples and
documentation. I created the two options in the Makefile (both enabled
by default).
The package doesn't provide any flags stock like --with-docs or
--with-examples, so I have a custom target like this:
do-build:
@cd ${BUILD_WRKSRC}/ ${MAKE}
.if ${PORT_OPTIONS:MDOCS}
@cd ${BUILD_WRKSRC}/ ${MAKE_CMD} doc
.endif
You don't have to override do-build like this. You can build the
documentation from a post-build target.
However, when I try to run this in poudriere, I get the following error:
make[1]: don't know how to make doc. Stop
make[1]: stopped in /wrkdirs/usr/ports/graphics/code-eli/work/.build
*** Error code 2
Does the makefile in BUILD_WRKSRC actually have a doc target? Is doc
a subdirectory maybe?
___
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: Need help compiling use of std::vector
Am 24.09.2014 um 17:04 schrieb Shane Ambler:
I am trying to compile the new version of a port I maintain and have
trouble related to std::vector. The code producing the error can be
boiled down to the following test case, which compiles as 64bit but
fails as 32bit.
#include stdlib.h
#include vector
int main(int argc, char *argv[])
{
int num_layers = 3;
std::vectorconst char * layers (num_layers, NULL);
exit(0);
}
So that should create a vector containing 3 items initially set to NULL.
10.0 compiles ok - both 32 and 64 bit. (libc++)
8.4, 9.2 and 9.3 compiles 64bit but fails on 32bit. (libstdc++)
Using the above code
clang++ -m32 test.cpp
fails with
/usr/include/c++/4.2/bits/stl_algobase.h:641:15: error: assigning to
'const char *' from incompatible type 'const int'
I don't think -m32 compilation has ever worked properly for C++ on the
older FreeBSD releases, where older includes 9.3.
You're probably better off trying to build with 32-bit chroots or jails
on your 64-bit host, like poudriere or Tinderbox are doing (but I'm not
sure if they support setting up 32-bit jails on 64-bit computers).
See here
https://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051855.html
so it's a long-standing thing, and for recent developments:
https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042378.html
-so that would have been for 10-CURRENT at the time, and hints that the
headers weren't pure enough for -m32 and similar tricks.
I am not aware that this effort was ever MFH'd.
I am Cc'ing Konstantin Belousov in case he wants to shed more light on
this issue.
HTH
___
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
Poudriere Build of pkg_* repos?
Hi all, Does the EOL of legacy pkg_* tools in FreeBSD Ports affect Poudriere's ability to build legacy package repos? Poudriere was able to build a legacy pkg_* repo from a snapshot of Ports from around the time releng/10.0 received the patch for -p7, but it failed to build a legacy repo from a snapshot taken today and instead built a pkg(8) repo despite make.conf having WITHOUT_PKGNG=yes. Aside: Actually, it seemed to ignore the make.conf altogether as it contains PERL_VERSION=5.14.4 and built 5.16 instead. Provided this is the case, what suggestions are there for patching today's bash remote execution vulnerability[1] in a version of Ports that can be built into a legacy repo? [1] http://seclists.org/oss-sec/2014/q3/650 -- Take care Rick Miller ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: devel/tortoisehg - is not compatible with Mercurial version 3.1
arrowdodger wrote, On 09/21/2014 11:34: On Fri, Sep 19, 2014 at 2:10 PM, Miroslav Lachman 000.f...@quip.cz wrote: Hi, I tried to install TortoiseHG on FreeBSD 10 (PC-BSD), but it doesn't work, because it is not compatible with Mercurial 3.1.1 (version in ports tree). [...] Can you please update TortoiseHG to more current version? The website http://tortoisehg.bitbucket.org/ has: | * 2014-09-04: TortoiseHg 3.1.1 (with Mercurial 3.1.1) released * 2014-08-03: TortoiseHg 3.1 (with Mercurial 3.1+2) released Miroslav Lachman Oh, right. I've got taken away by $WORK. Will update the port ASAP. Thank you, I really appreciate your work. Miroslav Lachman ___ 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: Poudriere Build of pkg_* repos?
On 9/24/2014 3:35 PM, Rick Miller wrote: Hi all, Does the EOL of legacy pkg_* tools in FreeBSD Ports affect Poudriere's ability to build legacy package repos? No. Poudriere still supports it as long as you're using an older ports tree. Poudriere was able to build a legacy pkg_* repo from a snapshot of Ports from around the time releng/10.0 received the patch for -p7, but it failed to build a legacy repo from a snapshot taken today and instead built a pkg(8) repo despite make.conf having WITHOUT_PKGNG=yes. Aside: Actually, it seemed to ignore the make.conf altogether as it contains PERL_VERSION=5.14.4 and built 5.16 instead. It must be /usr/local/etc/poudriere.d/make.conf Provided this is the case, what suggestions are there for patching today's bash remote execution vulnerability[1] in a version of Ports that can be built into a legacy repo? Just apply the patch via files/ and use EXTRA_PATCHES: http://dan.langille.org/2014/06/10/freebsd-custom-port-patches-when-using-poudriere/ [1] http://seclists.org/oss-sec/2014/q3/650 -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: On Docs option and custom build target
On Wed, Sep 24, 2014 at 8:52 PM, Tijl Coosemans t...@freebsd.org wrote:
On Tue, 23 Sep 2014 23:23:31 +0200 Fernando Apesteguía
fernando.apesteg...@gmail.com wrote:
I have a Makefile for an application that provides both examples and
documentation. I created the two options in the Makefile (both enabled
by default).
The package doesn't provide any flags stock like --with-docs or
--with-examples, so I have a custom target like this:
do-build:
@cd ${BUILD_WRKSRC}/ ${MAKE}
.if ${PORT_OPTIONS:MDOCS}
@cd ${BUILD_WRKSRC}/ ${MAKE_CMD} doc
.endif
You don't have to override do-build like this. You can build the
documentation from a post-build target.
Thanks. Changed.
However, when I try to run this in poudriere, I get the following error:
make[1]: don't know how to make doc. Stop
make[1]: stopped in /wrkdirs/usr/ports/graphics/code-eli/work/.build
*** Error code 2
Does the makefile in BUILD_WRKSRC actually have a doc target? Is doc
a subdirectory maybe?
Yes it does.
In fact, with port test builds fine with the same code (change
directory and ${MAKE} doc). There is a doc.dir subdirectory in
BUILD_WRKSRC/CMakeFiles. The doc target basically gets a Doxygen
configuration file and runs doxygen on the whole library code.
___
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: Need help compiling use of std::vector
On 25/09/2014 04:27, Matthias Andree wrote: Am 24.09.2014 um 17:04 schrieb Shane Ambler: Using the above code clang++ -m32 test.cpp fails with /usr/include/c++/4.2/bits/stl_algobase.h:641:15: error: assigning to 'const char *' from incompatible type 'const int' I don't think -m32 compilation has ever worked properly for C++ on the older FreeBSD releases, where older includes 9.3. You're probably better off trying to build with 32-bit chroots or jails on your 64-bit host, like poudriere or Tinderbox are doing (but I'm not sure if they support setting up 32-bit jails on 64-bit computers). See here https://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051855.html so it's a long-standing thing, and for recent developments: https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042378.html -so that would have been for 10-CURRENT at the time, and hints that the headers weren't pure enough for -m32 and similar tricks. I am not aware that this effort was ever MFH'd. I am Cc'ing Konstantin Belousov in case he wants to shed more light on this issue. My poudriere setup is where I encountered the error. The -m32 was just a test compile of the simplified test code, that produced the same error as within a 32 bit jail. While using -m32 does produce the same error, it appears to always produce the error with all the changes I tried. Compiling the variations I tried within a 32 bit jail gives a favourable result that I can test further. I assumed that compiling a small test code would tell me if the change worked. I should have thought about doing it all in a 32bit jail. 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
update port: ftp/vsftpd-ext patched for stageDIR
*vsftpd-ext *expired on: 2014-08-31 DEPRECATED: Not staged. I want to upgrade for staged. 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: squid-3.4.8_1 leaking memory
You seem to be onto something. On a single user testbox I use I see this PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 6100 squid 1 200 612M 84076K kqread 1 4:01 0.00% squid I then restarted squid and saw 73400 squid 1 200 61568K 21456K kqread 0 0:00 0.00% squid I am on the i386 flavor of 10.0-RELEASE-p9 On Wed, Sep 24, 2014 at 9:56 PM, Victor Sudakov v...@mpeks.tomsk.su wrote: Colleagues, squid-3.4.8_1 seems to be leaking memory heavily. Its SIZE and RES are growing several MB per minute until eventually swapping begins. Is anyone using it? Have you encountered this problem? The relevant entries in squid.conf are: cache_mem 128 MB cache_dir ufs /webcache/cache 512 16 256 memory_pools off # neither on nor off have any effect on leaking. As you see, the memory requirements should be rather modest. Running on 8.4-RELEASE-p16 i386. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: devel/tortoisehg - is not compatible with Mercurial version 3.1
On Thu, Sep 25, 2014 at 12:54 AM, Miroslav Lachman 000.f...@quip.cz wrote: arrowdodger wrote, On 09/21/2014 11:34: On Fri, Sep 19, 2014 at 2:10 PM, Miroslav Lachman 000.f...@quip.cz wrote: Hi, I tried to install TortoiseHG on FreeBSD 10 (PC-BSD), but it doesn't work, because it is not compatible with Mercurial 3.1.1 (version in ports tree). [...] Can you please update TortoiseHG to more current version? The website http://tortoisehg.bitbucket.org/ has: | * 2014-09-04: TortoiseHg 3.1.1 (with Mercurial 3.1.1) released * 2014-08-03: TortoiseHg 3.1 (with Mercurial 3.1+2) released Miroslav Lachman Oh, right. I've got taken away by $WORK. Will update the port ASAP. Thank you, I really appreciate your work. Miroslav Lachman Here's a PR [1] with a port patch, if you dont want to wait for the commit. [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193812 ___ 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
bind99 with heimdal port requires a tweak
Bind99 with heimdal enables GSS-TSIG, which is useful when using samba4 (or those pesky Windows Servers) in a production environment. There is a one line change required against /usr/ports/dns/bind99/files/patch-configure to avoid bind 9.9.6 bringing in heimdal base shareable libraries when the intent is to use the heimdal port. Please refer https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193912 My thanks to John Marshall for his generous assistance in the hunt for a solution. 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
