Re: Are ports supposed to build and run on 10-CURRENT?
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.
I would add something like
.if ${OSVERSION} ${WHEREEVERITBROKE}
BROKEN= Unit tests fail
.endif
to the port's Makefile.
--
Eitan Adler
___
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?
It's worth bearing in mind that head becomes a release every so often. If you don't make sure your ports build there, it makes life harder for people running and testing it, and makes for a mad rush and scramble to fix broken ports before a major release. Since the port can often be fixed with a USE_GCC=any conditional on OSVERSION, I must question how much of a hardship it really is... 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: Are ports supposed to build and run on 10-CURRENT?
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 -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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 07:20:13 +0100
Chris Rees utis...@gmail.com wrote:
It's worth bearing in mind that head becomes a release every so
often. If you don't make sure your ports build there, it makes life
harder for people running and testing it, and makes for a mad rush
and scramble to fix broken ports before a major release.
Thanks for stating the obvious, but usually I'm crossing that bridge
once we have a release candidate available. As far as I remember
personally, the FreeBSD project didn't do a release by surprise within
the last 15 years :). Right now there's not even a planned release date
for 10 on the release engineering web site. Not even as TBD.
Since the port can often be fixed with a USE_GCC=any conditional on
OSVERSION, I must question how much of a hardship it really is...
This was a general question and the hardship lies in the extra time
spent testing on CURRENT, including dependencies.
The fact that it builds using gcc doesn't mean that it runs correctly
on that version. In this case the unit tests provided upstream test
for many things and are able to find catastrophic failures, but part of
the QA I do as a maintainer is also testing more subtle scenarios
including staging real life software built using the port, which is
extremely time consuming and revealed mission critical problems in the
past. I can't guarantee that for 10, so why pretend it builds ok if it
hasn't been tested thoroughly?
So in this specific case I think going with Eitan's suggestion makes the
most sense:
.if ${OSVERSION} ${WHEREEVERITBROKE}
BROKEN= Unit tests fail
.endif
Which probably should be (since the unit tests fail for a good reason):
.if ${OSVERSION} = 100)
BROKEN= Not ready for FreeBSD 10
.endif
Should I add a new patch to the PR or is this something the committer
could just put in there by herself?
Two more notes:
- As a user of the ports tree, I would expect committers to QA
submissions on RELEASE version of the OS as well.
- If committers find a port that works on RELEASE but not on CURRENT,
I would suggest to simply add a version specific BROKEN message to
the Makefile by default, inform the submitter and not delay the
submission any further.
Cheers,
Michael
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
--
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
Re: Are ports supposed to build and run on 10-CURRENT?
On Thu, 13 Jun 2013 08:07:14 +0200
Eitan Adler li...@eitanadler.com wrote:
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.
I would add something like
.if ${OSVERSION} ${WHEREEVERITBROKE}
BROKEN= Unit tests fail
.endif
to the port's Makefile.
Thanks for your helpful response. I followed your advice and filed a new
version of the patch marking it BROKEN for 10:
http://www.freebsd.org/cgi/query-pr.cgi?pr=179233#reply4
I will look into making the port work on 10 as soon as we have an
actual release date and the C++ compiler tool chain stabilized, so that
I'm not dealing with a moving target,
--
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
Re: Unable to print from firefox
On Wed, 12 Jun 2013, the wise Warren Block wrote: Me too: Firefox used to print, now it just coredumps. This is on xfce4 and printing with lpr, the real one. I will reinstall gtk and report back. No change after rebuilding x11-toolkits/gtk20, Firefox still dumps core very quickly after choosing File/Print. I do have the cups client installed, something required it, but it is not configured. I had this too. Using the real lpr, I just deinstalled cups completely and FF stopped coredumping when printing. Regards, Marco -- People will accept your ideas much more readily if you tell them that Benjamin Franklin said it 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
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/ocaml-res | 4.0.2 | 4.0.3 +-+ devel/rubygem-notify| 0.4.0 | 0.5.2 +-+ 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
[CFT] Fixing/changing LIB_DEPENDS
Hi,
Here is a patch to fix LIB_DEPENDS.
First what is/are the problem of LIB_DEPENDS.
LIB_DEPENDS relies on of ldconfig -r to get its valid or not installed shared
libraries, problem is:
liba-5.2.so and liba-5.so.2 will both be a-5.2 for ldconfig -r, which is not
really what we want.
secondly ldconfig -r is only able to print something for libraries in the form
of: libname.so[.number], while we have no technical limitation to enforce this
form and it is more and more common to find libraries in the following form:
libname.so.major.minor.patch and to get them working properly right know we
have to patch the upstream build system, to send some magic tricks on libtool
etc, all that kind of things all of us loves to deal with.
What I do propose is a new form of LIB_DEPENDS in addition to the current one:
LIB_DEPENDS=bla.so[numberwithlongorwhatever]:${PORTSDIR}/cat/bla
What the framework will do, is lookup in all libraries directories for
libbla.so[numberwithdotsorwhatever] test if it exists (test -f also validate the
symlink is pointing to a regular file) if /usr/bin/file is present on your
system it will validate the pointed file is really a shared library.
Any review welcome: http://people.freebsd.org/~bapt/fix-libdepends.patch
This idea behind this patch is on mid/long term to remove the other LIB_DEPENDS
forms.
I do plan to commit this on next friday 2013-06-21.
regards,
Bapt
pgpoq2965CClq.pgp
Description: PGP signature
[SOLVED] Re: Can't build Xorg -- make failed for ports-mgmt/pkg
I did a make deinstall removing pkg... make clean and made sure work dir was gone! Then I tried pkg command, because if its no installed i will ask you to do it! I accepted the install of pkg-1.0.11 After this I tried portmaster -f x11/xorg, pkg was again mentioned for update, and again it failed! I cleaned dirs again rebooted... 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! Thanks everyone for the replies ___ 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: Suggesting a new experimental fork for ports tree
Hi, Reference: From: =?ISO-8859-2?Q?Jo=BEe_Zobec?= jozze.z...@gmail.com Date: Wed, 12 Jun 2013 20:04:30 +0200 Apart from the maintainer of the port, there would also be sub maintainerswhich would be those people who helped patch the port into the good shape: # make -C /usr/ports/section/someport maintainer would return the maintainer (1st address) and additional addresses to turn for questions. When the port would be committed to the good ports tree, sub-maintainers would be left out. Maybe it'd help to break jozze.zepl's suggestions in to 2 parts ? - Working non working ports tree (No comment from me on that) - Multiple maintainers I believe MAINTAINER= value is currently a unitary mail address, which is [usually] an individual or a freebsd mail list. I recall before we've discussed adding names of alternates/ extras, (perhaps comma seperated), that some who maintain .mk macros shell scripts pointed out some difficulties if changed. Even within the current unchanged syntax, handfulls of maintainers might already co-operate on a per port basis, with eg MAINTAINER=port_xyz_maintain...@their-domain.com their-domain.com /etc/mail/aliases: port_xyz_maintainers: port_xyz_maint0, port_xyz_maint1 port_xyz_maint0:j...@upthehill.com port_xyz_maint1:j...@downthehill.com Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with . Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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: Unable to print from firefox
On 2013-06-12 22:19, Warren Block wrote: On Wed, 12 Jun 2013, Warren Block wrote: On Wed, 12 Jun 2013, Bernt Hansson wrote: What windowmanager do you use. Do you print with cups or lpr or both. Try reinstalling gtk. Me too: Firefox used to print, now it just coredumps. This is on xfce4 and printing with lpr, the real one. I will reinstall gtk and report back. No change after rebuilding x11-toolkits/gtk20, Firefox still dumps core very quickly after choosing File/Print. I do have the cups client installed, something required it, but it is not configured. What version of firefox do you use. I'm running 15.0.1 att the office and firefox 21.0 at home The office machine is amd64 8.3-STABLE home machine is i386 8.3-STABLE Printing works without errors. Even with cups client installed. ___ 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: Unable to print from firefox
On 2013-06-12 11:01, Albert Shih wrote: Hi I'm unable to print from firefox/chrome/opera so that really s***.. When I try to print something in firefox I got this message (firefox:45435): Gtk-WARNING **: Unknown paper size A4 Do you have for example print/libpaper, print/papersize-default-a4 or any other paper size stuff installed. ___ 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
rubygem-nokogiri error: \xE2 from ASCII-8BIT to UTF-8
Hello, I just attempted to upgrade Ruby Redmine and one of the gems, nokogiri, (and a few others) die with the same ASCII-8BIT to UTF-8 error durring the doc install phase which prevents the port from completing the install. I've searched and search and cannot find anything that relates to this specifically, anyone have any ideas? Let me know if I can provide more info, here is the error lead up: === Building for rubygem-nokogiri-1.5.0 Successfully built RubyGem Name: nokogiri Version: 1.5.0 File: nokogiri-1.5.0.gem === Installing for rubygem-nokogiri-1.5.0 === rubygem-nokogiri-1.5.0 depends on file: /usr/local/bin/gem19 - found === rubygem-nokogiri-1.5.0 depends on file: /usr/local/bin/ruby19 - found === rubygem-nokogiri-1.5.0 depends on file: /usr/local/lib/ruby/1.9/amd64-freebsd9/iconv.so - found === Generating temporary packing list === Checking if textproc/rubygem-nokogiri already installed Building native extensions. This could take a while... Successfully installed nokogiri-1.5.0 1 gem installed Installing RDoc documentation for nokogiri-1.5.0... ERROR: While generating documentation for nokogiri-1.5.0 ... MESSAGE: \xE2 from ASCII-8BIT to UTF-8 ... RDOC args: --op /usr/local/lib/ruby/gems/1.9/doc/nokogiri-1.5.0/rdoc --main README.rdoc lib Manifest.txt README.ja.rdoc CHANGELOG.rdoc CHANGELOG.ja.rdoc README.rdoc ext/nokogiri/xml_sax_push_parser.c ext/nokogiri/xml_relax_ng.c ext/nokogiri/html_sax_parser_context.c ext/nokogiri/html_entity_lookup.c ext/nokogiri/xml_text.c ext/nokogiri/nokogiri.c ext/nokogiri/xml_element_decl.c ext/nokogiri/xml_encoding_handler.c ext/nokogiri/html_document.c ext/nokogiri/xslt_stylesheet.c ext/nokogiri/xml_attribute_decl.c ext/nokogiri/xml_io.c ext/nokogiri/xml_document_fragment.c ext/nokogiri/xml_namespace.c ext/nokogiri/xml_libxml2_hacks.c ext/nokogiri/xml_sax_parser_context.c ext/nokogiri/xml_comment.c ext/nokogiri/xml_sax_parser.c ext/nokogiri/html_element_description.c ext/nokogiri/xml_xpath_context.c ext/nokogiri/xml_syntax_error.c ext/nokogiri/xml_document.c ext/nokogiri/xml_entity_decl.c ext/nokogiri/xml_node.c ext/nokogiri/xml_node_set.c ext/nokogiri/xml_reader.c ext/nokogiri/xml_processing_instruction.c ext/nokogiri/xml_element_content.c ext/nokogiri/xml_dtd.c ext/nokogiri/xml_attr.c ext/nokogiri/xml_schema.c ext/nokogiri/xml_cdata.c ext/nokogiri/xml_entity_reference.c --title nokogiri-1.5.0 Documentation --quiet *** [do-install] Error code 1 Stop in /usr/ports/textproc/rubygem-nokogiri. *** [run-depends] Error code 1 Stop in /usr/ports/devel/rubygem-capybara. *** [run-depends] Error code 1 Stop in /usr/ports/www/redmine. *** [install] Error code 1 Stop in /usr/ports/www/redmine. -- Adam Strohl http://www.ateamsystems.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: [CFT] Fixing/changing LIB_DEPENDS
On Thu, Jun 13, 2013 at 06:58:16PM +0200, olli hauer wrote:
On 2013-06-13 15:07, Baptiste Daroussin wrote:
Hi,
Here is a patch to fix LIB_DEPENDS.
First what is/are the problem of LIB_DEPENDS.
LIB_DEPENDS relies on of ldconfig -r to get its valid or not installed
shared
libraries, problem is:
liba-5.2.so and liba-5.so.2 will both be a-5.2 for ldconfig -r, which is not
really what we want.
secondly ldconfig -r is only able to print something for libraries in the
form
of: libname.so[.number], while we have no technical limitation to enforce
this
form and it is more and more common to find libraries in the following form:
libname.so.major.minor.patch and to get them working properly right know
we
have to patch the upstream build system, to send some magic tricks on
libtool
etc, all that kind of things all of us loves to deal with.
What I do propose is a new form of LIB_DEPENDS in addition to the current
one:
LIB_DEPENDS=bla.so[numberwithlongorwhatever]:${PORTSDIR}/cat/bla
What the framework will do, is lookup in all libraries directories for
libbla.so[numberwithdotsorwhatever] test if it exists (test -f also
validate the
symlink is pointing to a regular file) if /usr/bin/file is present on your
system it will validate the pointed file is really a shared library.
Any review welcome: http://people.freebsd.org/~bapt/fix-libdepends.patch
This idea behind this patch is on mid/long term to remove the other
LIB_DEPENDS
forms.
I do plan to commit this on next friday 2013-06-21.
regards,
Bapt
Hm,
so this is a modern extended incarnation of the old LIB_DEPENDS notation
For example pcre.3:... becomes pcre:...
Isn't this something that can be handled with some additional code in pathfix?
--
regards,
olli
Either I m missing something, or I don't see the point about pathfix.
It is not a matter of path, but rather allowing the ports tree to handle
properly all kind of library name, right now we have some false limitation and
library name collision because we wrongly rely on ldconfig -r.
we have lots of patches so convert library names to a format
libname.so.asinglenumber, just for the sake of a technical limitation of the
ports tree.
That is what I m trying to fix.
regards,
Bapt
pgpDHh_IJMMgs.pgp
Description: PGP signature
Re: [CFT] Fixing/changing LIB_DEPENDS
On 2013-06-13 19:50, Baptiste Daroussin wrote:
On Thu, Jun 13, 2013 at 06:58:16PM +0200, olli hauer wrote:
On 2013-06-13 15:07, Baptiste Daroussin wrote:
Hi,
Here is a patch to fix LIB_DEPENDS.
First what is/are the problem of LIB_DEPENDS.
LIB_DEPENDS relies on of ldconfig -r to get its valid or not installed
shared
libraries, problem is:
liba-5.2.so and liba-5.so.2 will both be a-5.2 for ldconfig -r, which is not
really what we want.
secondly ldconfig -r is only able to print something for libraries in the
form
of: libname.so[.number], while we have no technical limitation to enforce
this
form and it is more and more common to find libraries in the following form:
libname.so.major.minor.patch and to get them working properly right know
we
have to patch the upstream build system, to send some magic tricks on
libtool
etc, all that kind of things all of us loves to deal with.
What I do propose is a new form of LIB_DEPENDS in addition to the current
one:
LIB_DEPENDS=bla.so[numberwithlongorwhatever]:${PORTSDIR}/cat/bla
What the framework will do, is lookup in all libraries directories for
libbla.so[numberwithdotsorwhatever] test if it exists (test -f also
validate the
symlink is pointing to a regular file) if /usr/bin/file is present on your
system it will validate the pointed file is really a shared library.
Any review welcome: http://people.freebsd.org/~bapt/fix-libdepends.patch
This idea behind this patch is on mid/long term to remove the other
LIB_DEPENDS
forms.
I do plan to commit this on next friday 2013-06-21.
regards,
Bapt
Hm,
so this is a modern extended incarnation of the old LIB_DEPENDS notation
For example pcre.3:... becomes pcre:...
Isn't this something that can be handled with some additional code in
pathfix?
--
regards,
olli
Either I m missing something, or I don't see the point about pathfix.
It is not a matter of path, but rather allowing the ports tree to handle
properly all kind of library name, right now we have some false limitation and
library name collision because we wrongly rely on ldconfig -r.
we have lots of patches so convert library names to a format
libname.so.asinglenumber, just for the sake of a technical limitation of the
ports tree.
That is what I m trying to fix.
regards,
Bapt
Sorry, I was meaning USE_GNOME=ltverhack not gnomehack ...
for example in www/neon we use it to change libneon.so.29 to libneon.so.27
I haven't tested what is the result with a library that comes with so.x.x
but maybe ltverhack works also there.
--
regards,
olli
___
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: rubygem-nokogiri error: \xE2 from ASCII-8BIT to UTF-8
Hello, I just attempted to upgrade Ruby Redmine and one of the gems, nokogiri, (and a few others) die with the same ASCII-8BIT to UTF-8 error durring the doc install phase which prevents the port from completing the install. I've searched and search and cannot find anything that relates to this specifically, anyone have any ideas? I've seen errors like this, although not with this specific port. I haven't come up with a good solution yet, but often setting LC_LANG or LANG or LC_ALL to en_us.utf-8 (or whatever is appropriate for you) helps. FWIW, bsd.ruby.mk sets LC_CTYPE=UTF-8, but maybe it needs to set more. The problem is it's generating docs and needs this, but we don't set a LANG by default. Steve ___ 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: [CFT] Fixing/changing LIB_DEPENDS
On Thu, Jun 13, 2013 at 08:02:38PM +0200, olli hauer wrote:
On 2013-06-13 19:50, Baptiste Daroussin wrote:
On Thu, Jun 13, 2013 at 06:58:16PM +0200, olli hauer wrote:
On 2013-06-13 15:07, Baptiste Daroussin wrote:
Hi,
Here is a patch to fix LIB_DEPENDS.
First what is/are the problem of LIB_DEPENDS.
LIB_DEPENDS relies on of ldconfig -r to get its valid or not installed
shared
libraries, problem is:
liba-5.2.so and liba-5.so.2 will both be a-5.2 for ldconfig -r, which is
not
really what we want.
secondly ldconfig -r is only able to print something for libraries in the
form
of: libname.so[.number], while we have no technical limitation to
enforce this
form and it is more and more common to find libraries in the following
form:
libname.so.major.minor.patch and to get them working properly right
know we
have to patch the upstream build system, to send some magic tricks on
libtool
etc, all that kind of things all of us loves to deal with.
What I do propose is a new form of LIB_DEPENDS in addition to the current
one:
LIB_DEPENDS= bla.so[numberwithlongorwhatever]:${PORTSDIR}/cat/bla
What the framework will do, is lookup in all libraries directories for
libbla.so[numberwithdotsorwhatever] test if it exists (test -f also
validate the
symlink is pointing to a regular file) if /usr/bin/file is present on your
system it will validate the pointed file is really a shared library.
Any review welcome: http://people.freebsd.org/~bapt/fix-libdepends.patch
This idea behind this patch is on mid/long term to remove the other
LIB_DEPENDS
forms.
I do plan to commit this on next friday 2013-06-21.
regards,
Bapt
Hm,
so this is a modern extended incarnation of the old LIB_DEPENDS notation
For example pcre.3:... becomes pcre:...
Isn't this something that can be handled with some additional code in
pathfix?
--
regards,
olli
Either I m missing something, or I don't see the point about pathfix.
It is not a matter of path, but rather allowing the ports tree to handle
properly all kind of library name, right now we have some false limitation
and
library name collision because we wrongly rely on ldconfig -r.
we have lots of patches so convert library names to a format
libname.so.asinglenumber, just for the sake of a technical limitation of the
ports tree.
That is what I m trying to fix.
regards,
Bapt
Sorry, I was meaning USE_GNOME=ltverhack not gnomehack ...
for example in www/neon we use it to change libneon.so.29 to libneon.so.27
I haven't tested what is the result with a library that comes with so.x.x
but maybe ltverhack works also there.
That is exactly the kind of hacks I do want do eliminate.
regards,
Bapt
pgpQ516NdoMdb.pgp
Description: PGP signature
Re: rubygem-nokogiri error: \xE2 from ASCII-8BIT to UTF-8
On 6/14/2013 1:10, Steve Wills wrote: Hello, I just attempted to upgrade Ruby Redmine and one of the gems, nokogiri, (and a few others) die with the same ASCII-8BIT to UTF-8 error durring the doc install phase which prevents the port from completing the install. I've searched and search and cannot find anything that relates to this specifically, anyone have any ideas? I've seen errors like this, although not with this specific port. I haven't come up with a good solution yet, but often setting LC_LANG or LANG or LC_ALL to en_us.utf-8 (or whatever is appropriate for you) helps. FWIW, bsd.ruby.mk sets LC_CTYPE=UTF-8, but maybe it needs to set more. The problem is it's generating docs and needs this, but we don't set a LANG by default. BINGO. Thank you both Michael Gmelin (who replied privately) and Steve. My defaults were C or blank when I ran locale, and per both of your suggestions setting this let nokogiri build: export LANG=en_US.UTF-8; export LC_ALL=en_US.UTF-8; Awesomeness: Building native extensions. This could take a while... Successfully installed nokogiri-1.5.0 1 gem installed Installing RDoc documentation for nokogiri-1.5.0... === Registering installation for rubygem-nokogiri-1.5.0 I also want to note (in case anyone else searches for this) that rubygem-net-ldap port also had the same issue for me and this fixed that port as well. Thanks again! -- Adam Strohl http://www.ateamsystems.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: Updates to net/remmina?
Everyone missing remmina, I manage to finish updating remmina on this weekend. Sorry for the long wait. -- `whois vmeta.jp | nkf -w` meta m...@vmeta.jp ___ 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
Broken SNMP::Info ?
Hi all, i have updated my netdisco today, and some perl libraries due to long unupdated system (1 month). I have a strange problem, i cannot resolve. When i launch netdisco, it says: netdisco -d You need the SNMP::Info perl module, version 3.01 or newer. Please install it and try again. Can't locate SNMP.pm in @INC (@INC contains: /usr/local/bin /usr/local/lib/perl5/5.16/BSDPAN /usr/local/lib/perl5/site_perl/5.16/mach /usr/local/lib/perl5/site_perl/5.16 /usr/local/lib/perl5/5.16/mach /usr/local/lib/perl5/5.16 .) at /usr/local/lib/perl5/site_perl/5.16/SNMP/Info.pm line 16. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.16/SNMP/Info.pm line 16. Compilation failed in require at (eval 12) line 2. BEGIN failed--compilation aborted at (eval 12) line 2. (Before i was in 5.14.4 version and the problem was the same). I have the SNMP-Info port: pkg info|grep SNMP-Info p5-SNMP-Info-3.01 Perl5 module for gathering information from network devices I also tried to upgrade netdisco from recent 1.2 to 1.3, and also downgrade it to 1.1 but the problem persists. I also use MRTG and there is no problem. Anyone have an idea what i can check more, or how to resolve this problem (google doesn't help me)? Thanks for advance ! -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr signature.asc Description: This is a digitally signed message part
Re: Broken SNMP::Info ?
On 06/13/13 14:09, Loïc BLOT wrote: Hi all, i have updated my netdisco today, and some perl libraries due to long unupdated system (1 month). I have a strange problem, i cannot resolve. When i launch netdisco, it says: netdisco -d You need the SNMP::Info perl module, version 3.01 or newer. Please install it and try again. Can't locate SNMP.pm in @INC (@INC contains: /usr/local/bin /usr/local/lib/perl5/5.16/BSDPAN /usr/local/lib/perl5/site_perl/5.16/mach /usr/local/lib/perl5/site_perl/5.16 /usr/local/lib/perl5/5.16/mach /usr/local/lib/perl5/5.16 .) at /usr/local/lib/perl5/site_perl/5.16/SNMP/Info.pm line 16. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.16/SNMP/Info.pm line 16. Compilation failed in require at (eval 12) line 2. BEGIN failed--compilation aborted at (eval 12) line 2. (Before i was in 5.14.4 version and the problem was the same). I have the SNMP-Info port: pkg info|grep SNMP-Info p5-SNMP-Info-3.01 Perl5 module for gathering information from network devices I also tried to upgrade netdisco from recent 1.2 to 1.3, and also downgrade it to 1.1 but the problem persists. I also use MRTG and there is no problem. Anyone have an idea what i can check more, or how to resolve this problem (google doesn't help me)? Thanks for advance ! Make sure you are using 'use SNMP::Info' and not 'use SNMP'. -- Patrick Powell Astart Technologies papow...@astart.com1530 Jamacha Road, Suite X, Network and System El Cajon, CA 92019 Consulting 858-874-6543 Web Site: www.astart.com FAX 858-357-9931 ___ 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
Make flags with clang:: GCC type options
http://www.rqna.net/qna/kqhyzk-g-undefined-reference-to-boost-system-system-category.html Looking to use the -Wall and -m32 as options along with sse, sse2, and sse3. This is for the Ardour3-beta version. Are these options set in the Makefile or can they be set in /etc/make.conf? ___ 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
portaudit: Wrong vulnerability information for devel/dbus
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
[QAT] r320839: 4x leftovers
Update to 1.3.4. - Build ID: 20130613204200-62686 Job owner: h...@freebsd.org Buildtime: 8 hours Enddate: Fri, 14 Jun 2013 04:52:37 GMT Revision: r320839 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=320839 - Port:security/ipv6toolkit 1.3.4 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20130613204200-62686-151352/ipv6toolkit-1.3.4.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20130613204200-62686-151353/ipv6toolkit-1.3.4.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20130613204200-62686-151354/ipv6toolkit-1.3.4.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20130613204200-62686-151355/ipv6toolkit-1.3.4.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20130613204200-62686 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: Broken SNMP::Info ?
Hello Patrick as you see in my first mail, it's SNMP::Info himself which said SNMP.pm not found -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr Le jeudi 13 juin 2013 à 14:50 -0700, Patrick Powell a écrit : On 06/13/13 14:09, Loïc BLOT wrote: Hi all, i have updated my netdisco today, and some perl libraries due to long unupdated system (1 month). I have a strange problem, i cannot resolve. When i launch netdisco, it says: netdisco -d You need the SNMP::Info perl module, version 3.01 or newer. Please install it and try again. Can't locate SNMP.pm in @INC (@INC contains: /usr/local/bin /usr/local/lib/perl5/5.16/BSDPAN /usr/local/lib/perl5/site_perl/5.16/mach /usr/local/lib/perl5/site_perl/5.16 /usr/local/lib/perl5/5.16/mach /usr/local/lib/perl5/5.16 .) at /usr/local/lib/perl5/site_perl/5.16/SNMP/Info.pm line 16. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.16/SNMP/Info.pm line 16. Compilation failed in require at (eval 12) line 2. BEGIN failed--compilation aborted at (eval 12) line 2. (Before i was in 5.14.4 version and the problem was the same). I have the SNMP-Info port: pkg info|grep SNMP-Info p5-SNMP-Info-3.01 Perl5 module for gathering information from network devices I also tried to upgrade netdisco from recent 1.2 to 1.3, and also downgrade it to 1.1 but the problem persists. I also use MRTG and there is no problem. Anyone have an idea what i can check more, or how to resolve this problem (google doesn't help me)? Thanks for advance ! Make sure you are using 'use SNMP::Info' and not 'use SNMP'. signature.asc Description: This is a digitally signed message part
