Re: portaudit: Wrong vulnerability information for devel/dbus
Am 2013-06-14 06:19, schrieb RyōTa SimaMoto: Hi, portaudit rejects the latest version (1.6.12) of devel/dbus because acceptable version is set too higher (1.16.12) than it. http://portaudit.FreeBSD.org/4e9e410b-d462-11e2-8d57-080027019be0.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 Yup, happens for me too -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ 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
Rebuild all ports for perl minor version update?
I see in the $PORTSDIR/UPDATING file that perl has been updated. perl5.16 has been updated from 5.16.2 to 5.16.3 . Since this is only (?) a minor-version update, why should it be necessary to upgrade all ports that depend on perl? portmaster -r perl In that case, why didn't they go to perl 5.18? Since so many ports depend on perl, and png too, maybe they should have updated perl and png (to 1.6.x) at the same time, then two massive portmaster or portupgrade runs could have been done together, as one even bigger portmaster or portupgrade run? 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: Rebuild all ports for perl minor version update?
On 6/14/2013 10:12, Thomas Mueller wrote: Since this is only (?) a minor-version update, why should it be necessary to upgrade all ports that depend on perl? In that case, why didn't they go to perl 5.18? According to OpenBSD's Marc Espie on a pkgsrc list, a lot of established scripts will break on perl 5.18. Apparently it is not highly backwards compatible. A large % of the perl packages would cease to build if they just moved to 5.18. A minor upgrade is definitely better. 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: [SOLVED] Re: Can't build Xorg -- make failed for ports-mgmt/pkg
On 13/06/2013 15:24, Miguel Clara wrote: Than I tried to rebuild just libdrm and not xorg, with portmaster -f, pkg was mentioned again but this time the update worked and I'm now with pkg-1.0.13 pkg info | grep pkg pkg-1.0.13 New generation package manager I'm not exactly sure why it worked now and not before... The only difference now is that I made a make deinstall, I'm glad its solved... still having issues with xorg but that is a totally different discussion! The errors you were seeing are symptomatic of your build system not finding pkg.h or libpkg.so.0 in your build tree, but using the installed copies from the previous version of pkg already installed on your system. That is works when you remove the instaleld version of pkg means the problem is incorrect ordering of the include file (-I) or shared library (-L) search path options. This works fine if you eg. just check the sources out of git and run make -- meaning there is something in your environment overriding the default settings and causing mayhem. Cheers, Matthew ___ 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: Rebuild all ports for perl minor version update?
On Fri, 14 Jun 2013 10:18:31 +0200 John Marino articulated: According to OpenBSD's Marc Espie on a pkgsrc list, a lot of established scripts will break on perl 5.18. Apparently it is not highly backwards compatible. A large % of the perl packages would cease to build if they just moved to 5.18. A minor upgrade is definitely better. So what does that mean for the future of Perl-5.18 FreeBSD? I haven't seen any unusual chatter in other forums for other OSs regarding a problem with Perl-5.18. Hell, even SlashDot has not had any negative chatter that I am aware of and they are always the first to jump on any software problem, real or imaginary. Is this a FreeBSD specific problem and if so, what is being done to eradicate it? -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ If you don't have time to do it right, where are you going to find the time to do it over? ___ 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: Rebuild all ports for perl minor version update?
On Fri, Jun 14, 2013 at 01:12:09AM -0700 I heard the voice of Thomas Mueller, and lo! it spake thus: In that case, why didn't they go to perl 5.18? I should hope that lang/perl5.16 _NEVER_ goes to 5.18 8-} -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: Rebuild all ports for perl minor version update?
On Fri, Jun 14, 2013 at 05:49:41AM -0400, Jerry wrote: On Fri, 14 Jun 2013 10:18:31 +0200 John Marino articulated: According to OpenBSD's Marc Espie on a pkgsrc list, a lot of established scripts will break on perl 5.18. Apparently it is not highly backwards compatible. A large % of the perl packages would cease to build if they just moved to 5.18. A minor upgrade is definitely better. So what does that mean for the future of Perl-5.18 FreeBSD? I haven't seen any unusual chatter in other forums for other OSs regarding a problem with Perl-5.18. Hell, even SlashDot has not had any negative chatter that I am aware of and they are always the first to jump on any software problem, real or imaginary. Is this a FreeBSD specific problem and if so, what is being done to eradicate it? This is not a FreeBSD specific problem given that Marc Espie is from OpenBSD and so was speaking of problems found on OpenBSD. using google I found the said mail quite quickly: http://mail-index.netbsd.org/tech-pkg/2013/06/03/msg011435.html Where Marc gives example of changes in perl 5.18 that can lead to breakage. regards, Bapt pgp4yQ8Amc_pY.pgp Description: PGP signature
Rebuild all ports for perl minor version update?
from my priginal post: I see in the $PORTSDIR/UPDATING file that perl has been updated. perl5.16 has been updated from 5.16.2 to 5.16.3 . Since this is only (?) a minor-version update, why should it be necessary to upgrade all ports that depend on perl? portmaster -r perl In that case, why didn't they go to perl 5.18? Since so many ports depend on perl, and png too, maybe they should have updated perl and png (to 1.6.x) at the same time, then two massive portmaster or portupgrade runs could have been done together, as one even bigger portmaster or portupgrade run? John Marino responded: According to OpenBSD's Marc Espie on a pkgsrc list, a lot of established scripts will break on perl 5.18. Apparently it is not highly backwards compatible. A large % of the perl packages would cease to build if they just moved to 5.18. A minor upgrade is definitely better. But then why must all FreeBSD ports that depend on perl be rebuilt for a minor-version upgrade, 5.16.2 to 5.16.3? 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: Rebuild all ports for perl minor version update?
Le 14/06/2013 10:12, Thomas Mueller a écrit : I see in the $PORTSDIR/UPDATING file that perl has been updated. perl5.16 has been updated from 5.16.2 to 5.16.3 . Since this is only (?) a minor-version update, why should it be necessary to upgrade all ports that depend on perl? portmaster -r perl In that case, why didn't they go to perl 5.18? Since so many ports depend on perl, and png too, maybe they should have updated perl and png (to 1.6.x) at the same time, then two massive portmaster or portupgrade runs could have been done together, as one even bigger portmaster or portupgrade run? Tom If you don't want to rebuild *really* everything depending on perl, you can first give a shot en perl modules: pkg info | sed -rn 's/^(p5.*)-[0-9]+.*/\1/p' | xargs portmaster Maybe this can be done using only pkg query but I'm too lazy for the moment 8-} But you should know that it can make other perl dependent ports not working anymore. -- Florent Peterschmitt | Please: flor...@peterschmitt.fr| * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | Thank you :) signature.asc Description: OpenPGP digital signature
Re: Rebuild all ports for perl minor version update?
On Fri, 14 Jun 2013 12:10:17 +0200 Baptiste Daroussin articulated: On Fri, Jun 14, 2013 at 05:49:41AM -0400, Jerry wrote: On Fri, 14 Jun 2013 10:18:31 +0200 John Marino articulated: According to OpenBSD's Marc Espie on a pkgsrc list, a lot of established scripts will break on perl 5.18. Apparently it is not highly backwards compatible. A large % of the perl packages would cease to build if they just moved to 5.18. A minor upgrade is definitely better. So what does that mean for the future of Perl-5.18 FreeBSD? I haven't seen any unusual chatter in other forums for other OSs regarding a problem with Perl-5.18. Hell, even SlashDot has not had any negative chatter that I am aware of and they are always the first to jump on any software problem, real or imaginary. Is this a FreeBSD specific problem and if so, what is being done to eradicate it? This is not a FreeBSD specific problem given that Marc Espie is from OpenBSD and so was speaking of problems found on OpenBSD. using google I found the said mail quite quickly: http://mail-index.netbsd.org/tech-pkg/2013/06/03/msg011435.html Where Marc gives example of changes in perl 5.18 that can lead to breakage. Just so I am understanding this correctly, the problem is not with Perl-5.18, but rather applications that were written for earlier versions that may not have in fact been written in tight compliance with the specifications of the earlier versions and those problems seem to reside on *BSD platforms more readily than other OSs. Is that a fair statement? In my opinion, rather than just issuing a blanket embargo of the newer version, I would think that issuing a warning of its potential problems, (and I do stress the use of POTENTIAL as opposed to GUARANTEED ramifications) to be a more suitable solution to the situation. Users would be free to make their own decisions. Unless the intent is to lock *.BSD into versions 5.18 ad infinitum, at some point the action must be taken anyway. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ signature.asc Description: PGP signature
Re: Rebuild all ports for perl minor version update?
On Fri, 14 Jun 2013 04:52:08 -0500 Matthew D. Fuller articulated: On Fri, Jun 14, 2013 at 01:12:09AM -0700 I heard the voice of Thomas Mueller, and lo! it spake thus: In that case, why didn't they go to perl 5.18? I should hope that lang/perl5.16 _NEVER_ goes to 5.18 8-} The past may be nostalgic, but it is one hell of a place to live your life. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: Rebuild all ports for perl minor version update?
On 6/14/2013 12:40, Jerry wrote: Just so I am understanding this correctly, the problem is not with Perl-5.18, but rather applications that were written for earlier versions that may not have in fact been written in tight compliance with the specifications of the earlier versions and those problems seem to reside on *BSD platforms more readily than other OSs. Is that a fair statement? I don't think that's a fair statement. First, where is your support your statement that the broken applications didn't have tight compliance with the specifications? That sounds like conjecture. I also don't see how you make the leap that BSD has more problems than other architectures. In my opinion, rather than just issuing a blanket embargo of the newer version, I would think that issuing a warning of its potential problems, (and I do stress the use of POTENTIAL as opposed to GUARANTEED ramifications) to be a more suitable solution to the situation. Users would be free to make their own decisions. Unless the intent is to lock *.BSD into versions 5.18 ad infinitum, at some point the action must be taken anyway. I despise languages that aren't backwards compatible, so if 5.18 actually broke compatibility intentionally then I for one would vote for staying on 5.16 for a long, long time. I am reserving judgement for the full story. 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: Updates to net/remmina?
2013-06-13 22:15, Koichiro IWAO skrev: Everyone missing remmina, I manage to finish updating remmina on this weekend. Sorry for the long wait. We appreciate you work. Thank you :-) どうもありがとうございました /Leslie ___ 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: Rebuild all ports for perl minor version update?
On 6/14/2013 13:21, John Marino wrote: I despise languages that aren't backwards compatible, so if 5.18 actually broke compatibility intentionally then I for one would vote for staying on 5.16 for a long, long time. I am reserving judgement for the full story. I just realize that Perl default is still 5.14, I was thinking it was 5.16 based on how the topic started. 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: Rebuild all ports for perl minor version update?
On Fri, Jun 14, 2013 at 06:40:03AM -0400, Jerry wrote: On Fri, 14 Jun 2013 12:10:17 +0200 Baptiste Daroussin articulated: This is not a FreeBSD specific problem given that Marc Espie is from OpenBSD and so was speaking of problems found on OpenBSD. using google I found the said mail quite quickly: http://mail-index.netbsd.org/tech-pkg/2013/06/03/msg011435.html Where Marc gives example of changes in perl 5.18 that can lead to breakage. Just so I am understanding this correctly, the problem is not with Perl-5.18, but rather applications that were written for earlier versions Yes. Each major release of perl5 (such as 16.0 and 18.0) contains changes to the language. Marc Espie's summary covers the main changes; perldelta lists the full details for each release: https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldelta.pod those problems seem to reside on *BSD platforms more readily than other OSs. No, the significant changes in 5.18.0 affect all platforms that perl5 runs on. On Fri, Jun 14, 2013 at 01:21:48PM +0200, John Marino wrote: I despise languages that aren't backwards compatible, so if 5.18 actually broke compatibility intentionally then I for one would vote for staying on 5.16 for a long, long time. I am reserving judgement for the full story. The perl5-porters share your distate for backwards incompatibility. They work hard to ensure old perl code continues to work with minimal changes. Perl5 still supports many 20 year old scripts, as well as more recent features such as Unicode support. It's hard to get the balance right. The decision to remove smart match was not taken easily, but the perl5-porters found no way to remove the confusion and ambiguity that arose from its real-world use. Security concerns prompted a reimplementation of hashes that has exposed bugs in third-party code. To a lesser extent perl-5.14.0 and perl-5.16.0 introduced minor problems with popular CPAN modules and other tools written in Perl. For both these release, as well as perl-5.18, the CPAN Testers have submitted bug reports, often with fixes or workarounds, and over time these releases, and the tools that depend upon them have matured. I expect we'll see something similar with perl-5.18. 5.18.1 will fix any regressions found in the core language from previous releases, and third-party scripts and modules will get fixed over time. In many ways, a new release of perl5 comes with similar problems and benefits to a new release of FreeBSD. Both projects have similar release management styles. Both remain backwards compatibile in many cases whilst offering improved feature sets. 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: Are ports supposed to build and run on 10-CURRENT?
On Thu, 13 Jun 2013 08:24:18 +0200 Matthias Apitz g...@unixarea.de wrote: El día Thursday, June 13, 2013 a las 08:07:14AM +0200, Eitan Adler escribió: On Thu, Jun 13, 2013 at 3:15 AM, Michael Gmelin free...@grem.de wrote: So my question is: Are we port maintainers now really supposed to make ports work with CURRENT? This is generally up to the maintainer; however many committers run -CURRENT and test on that by default. This was a widely general question and a general answer too; I'm afraid that not all committers run tests with -CURRENT and on both architectures (amd64 and i386); at least for KDE4 I can confirm that it is unable to build on -CURRENT r250588 i386 due to: 1. certain required ports does not compile with clang 2. for kdelibs4 (and others) the tool automoc4 SIGSEGV randomly (i.e. for different source files and if you run it again it works) all this on a SVN clean ports tree; the current situation with CURRENT/clang/ports is highly a concern; matthias To be perfectly honest, the fact that some committers seem to *solely* test on CURRENT seems like bad QA practice to me. -- Michael Gmelin ___ 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
[HEADSUP] configuring options in make.conf
Hi all,
When building a port for the first time a dialog may appear to configure
options for that port. This configuration is saved such that later
builds no longer show the dialog. This behaviour has now been extended
to include options set in /etc/make.conf. It allows you to configure
options like DOCS, NLS, X11, etc. once for all ports and not have option
dialogs pop up if those are the only options. You can still make the
dialog appear by running make config.
The following variables can be used in make.conf to configure options.
They are processed in the order listed below, i.e. later variables
override the effects of previous variables. Options saved using the
options dialog are processed right before OPTIONS_SET_FORCE.
OPTIONS_SET - List of options to enable for all ports.
OPTIONS_UNSET - List of options to disable for all ports.
${UNIQUENAME}_SET - List of options to enable for a specific port.
${UNIQUENAME}_UNSET - List of options to disable for a specific port.
OPTIONS_SET_FORCE - List of options to enable for all ports.
OPTIONS_UNSET_FORCE - List of options to disable for all ports.
${UNIQUENAME}_SET_FORCE - List of options to enable for a specific port.
${UNIQUENAME}_UNSET_FORCE
- List of options to disable for a specific port.
To know the UNIQUENAME of a port you can run make -V UNIQUENAME in
a port directory.
An example configuration is given below.
OPTIONS_SET=NLS # enable NLS for all ports unless configured
# otherwise using the option dialog
OPTIONS_UNSET= DOCS# aka NOPORTDOCS
# configuration for xorg-server overriding the configuration from the
# option dialog
xorg-server_SET_FORCE= AIGLX
xorg-server_UNSET_FORCE=HAL SUID
signature.asc
Description: OpenPGP digital signature
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 +-+ audio/oss | 4.2-build2007 | 4.2-build2008 +-+ 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 If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org 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
no db after crash; portmaster unhappy
One of my machines crashed this morning, and lost /usr/ports/db - the directory and everything in it. Portmaster refuses to run. How do I re-create that information? Respectfully, Robert Huff ___ 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: Are ports supposed to build and run on 10-CURRENT?
On Fri, Jun 14, 2013 at 2:36 PM, Michael Gmelin free...@grem.de wrote: On Thu, 13 Jun 2013 08:24:18 +0200 Matthias Apitz g...@unixarea.de wrote: El día Thursday, June 13, 2013 a las 08:07:14AM +0200, Eitan Adler escribió: On Thu, Jun 13, 2013 at 3:15 AM, Michael Gmelin free...@grem.de wrote: So my question is: Are we port maintainers now really supposed to make ports work with CURRENT? This is generally up to the maintainer; however many committers run -CURRENT and test on that by default. This was a widely general question and a general answer too; I'm afraid that not all committers run tests with -CURRENT and on both architectures (amd64 and i386); at least for KDE4 I can confirm that it is unable to build on -CURRENT r250588 i386 due to: 1. certain required ports does not compile with clang 2. for kdelibs4 (and others) the tool automoc4 SIGSEGV randomly (i.e. for different source files and if you run it again it works) all this on a SVN clean ports tree; the current situation with CURRENT/clang/ports is highly a concern; matthias To be perfectly honest, the fact that some committers seem to *solely* test on CURRENT seems like bad QA practice to me. This is true and also the reason why ports on CURRENT were always not supported but only on best effort basis. This is not only the responsibility of ports people but ALSO each and every src committer. We usually just have to catch up things that change on current and break a number of ports. Things like changing the default compiler, changing version numbers to something that break each and every autoconf dependent port are just the well known problems. Many ports break because of smaller changes in the toolchain and libraries and it takes some time to fix all affected ports. If that is something you don't want then CURRENT is not suitable for you. -- Bernhard Froehlich http://www.bluelife.at/ ___ 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 hangs on 9.1 Release
I'm updating machines, and the updates all work fine except a machine running 9.1 Release. On that machine, portmaster hangs. This is what I see: === Building for xorg-macros-1.17 === Creating a backup package for old version xorg-macros-1.16.1 I tried using -B to eliminate the backups, but then it hangs on Builiding. Anyone else seen this? Know of a solution? Did I miss something in UPDATING? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ 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 hangs on 9.1 Release
--On June 14, 2013 11:13:25 AM -0500 Paul Schmehl pschmehl_li...@tx.rr.com wrote: I'm updating machines, and the updates all work fine except a machine running 9.1 Release. On that machine, portmaster hangs. This is what I see: === Building for xorg-macros-1.17 === Creating a backup package for old version xorg-macros-1.16.1 I tried using -B to eliminate the backups, but then it hangs on Builiding. Anyone else seen this? Know of a solution? Did I miss something in UPDATING? Never mind. I did miss something in UPDATING. Running make -C /usr/ports/ports-mgmt/portmaster build deinstall install clean fixed the problem. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ 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
Could someone commit ports/172355?
This PR was submitted to allow portconf to handle dash symbols (as well as plus symbols), which is highly important because of the new OPTIONS framework. It was submitted in Oct 2012 but has been untouched since then. I have been using the patch myself and it works fine, without it, I would be unable to use something like xorg-servers_SET=WHATEVER in port.conf at all. Thanks, Naram Qashat ___ 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 devel/gobject-introspection
As I had no answer on this problem, I ask again for this. It seems to me that the port needs to be fixed. # uname -a FreeBSD atom0 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 The problem with devel/gobject-introspection is: In file included from /usr/local/include/glib-2.0/glib/deprecated/gthread.h:124, from /usr/local/include/glib-2.0/glib.h:108, from giscanner/sourcescanner.h:26, from giscanner/giscannermodule.c:26: /usr/local/include/pth/pthread.h:285: error: conflicting types for 'pthread_t' /usr/include/sys/_pthreadtypes.h:65: error: previous declaration of 'pthread_t' was here /usr/local/include/pth/pthread.h:286: error: conflicting types for 'pthread_attr_t' /usr/include/sys/_pthreadtypes.h:68: error: previous declaration of 'pthread_attr_t' was here /usr/local/include/pth/pthread.h:288: error: conflicting types for 'pthread_once_t' /usr/include/sys/_pthreadtypes.h:74: error: previous declaration of 'pthread_once_t' was here /usr/local/include/pth/pthread.h:289: error: conflicting types for 'pthread_mutexattr_t' /usr/include/sys/_pthreadtypes.h:70: error: previous declaration of 'pthread_mutexattr_t' was here /usr/local/include/pth/pthread.h:290: error: conflicting types for 'pthread_mutex_t' /usr/include/sys/_pthreadtypes.h:69: error: previous declaration of 'pthread_mutex_t' was here /usr/local/include/pth/pthread.h:291: error: conflicting types for 'pthread_condattr_t' /usr/include/sys/_pthreadtypes.h:72: error: previous declaration of 'pthread_condattr_t' was here /usr/local/include/pth/pthread.h:292: error: conflicting types for 'pthread_cond_t' /usr/include/sys/_pthreadtypes.h:71: error: previous declaration of 'pthread_cond_t' was here /usr/local/include/pth/pthread.h:293: error: conflicting types for 'pthread_rwlockattr_t' /usr/include/sys/_pthreadtypes.h:76: error: previous declaration of 'pthread_rwlockattr_t' was here /usr/local/include/pth/pthread.h:294: error: conflicting types for 'pthread_rwlock_t' /usr/include/sys/_pthreadtypes.h:75: error: previous declaration of 'pthread_rwlock_t' was here /usr/local/include/pth/pthread.h:357: error: conflicting types for 'pthread_kill' /usr/include/signal.h:71: error: previous declaration of 'pthread_kill' was here In file included from /usr/local/include/glib-2.0/glib/deprecated/gthread.h:124, from /usr/local/include/glib-2.0/glib.h:108, from giscanner/sourcescanner.h:26, from giscanner/giscannermodule.c:26: /usr/local/include/pth/pthread.h:517:1: warning: fork redefined In file included from /usr/local/include/python2.7/Python.h:166, from giscanner/giscannermodule.c:25: /usr/local/include/pth/pth.h:557:1: warning: this is the location of the previous definition In file included from /usr/local/include/glib-2.0/glib/deprecated/gthread.h:124, from /usr/local/include/glib-2.0/glib.h:108, from giscanner/sourcescanner.h:26, from giscanner/giscannermodule.c:26: /usr/local/include/pth/pthread.h:518:1: warning: sleep redefined In file included from /usr/local/include/python2.7/Python.h:166, from giscanner/giscannermodule.c:25: /usr/local/include/pth/pth.h:562:1: warning: this is the location of the previous definition In file included from /usr/local/include/glib-2.0/glib/deprecated/gthread.h:124, from /usr/local/include/glib-2.0/glib.h:108, from giscanner/sourcescanner.h:26, from giscanner/giscannermodule.c:26: /usr/local/include/pth/pthread.h:519:1: warning: nanosleep redefined /usr/local/include/pth/pth.h:570:1: warning: this is the location of the previous definition In file included from /usr/local/include/glib-2.0/glib/deprecated/gthread.h:124, from /usr/local/include/glib-2.0/glib.h:108, from giscanner/sourcescanner.h:26, from giscanner/giscannermodule.c:26: /usr/local/include/pth/pthread.h:529:1: warning: write redefined In file included from /usr/local/include/python2.7/Python.h:166, from giscanner/giscannermodule.c:25: /usr/local/include/pth/pth.h:571:1: warning: this is the location of the previous definition In file included from /usr/local/include/glib-2.0/glib/deprecated/gthread.h:124, from /usr/local/include/glib-2.0/glib.h:108, from giscanner/sourcescanner.h:26, from giscanner/giscannermodule.c:26: /usr/local/include/pth/pthread.h:530:1: warning: readv redefined In file included from /usr/local/include/python2.7/Python.h:166, from giscanner/giscannermodule.c:25: /usr/local/include/pth/pth.h:572:1: warning: this is the location of the previous definition In file included from /usr/local/include/glib-2.0/glib/deprecated/gthread.h:124,
Adding gcc type flags to mk.conf
Where would -Wall -msse3 be included? /etc/make.conf or within /usr/portsMk? ___ 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: no db after crash; portmaster unhappy
On Fri, 14 Jun 2013 09:45:44 -0400 Robert Huff wrote: One of my machines crashed this morning, and lost /usr/ports/db - the directory and everything in it. Portmaster refuses to run. How do I re-create that information? IIRC there's a backup under /var/backups made by the period scripts. ___ 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: i2p-0.8.7
Hi. I've noticed few things about i2p port: - i2p package doesn't have openjdk as dependency but it needs openjdk to run; - there is unsubstituted strings in i2prouter, runplain.sh and eepget after install (/usr/local/etc/rc.d/i2p install): %INSTALL_PATH and %SYSTEM_java_io_tmpdir. This strings have to be /usr/home/username/i2p and /var/tmp/ accordingly; - I've tried manual update using java -jar -console described at i2p site, and lastest versions works, so is there any reasons to hold rather old version? Regards, Vans. ___ 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
