Re: Are ports supposed to build and run on 10-CURRENT?

[Michael Gmelin]

On Thu, 13 Jun 2013 07:20:13 +0100
Chris Rees  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?

[Michael Gmelin]

On Thu, 13 Jun 2013 08:07:14 +0200
Eitan Adler  wrote:

> On Thu, Jun 13, 2013 at 3:15 AM, Michael Gmelin 
> 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

[Marco Beishuizen]

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

[portscout]

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

[Baptiste Daroussin]

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: lib.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:
lib.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

[Miguel Clara]

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

[Julian H. Stacey]

Hi, Reference:
> From: =?ISO-8859-2?Q?Jo=BEe_Zobec?=  
> 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

[Bernt Hansson]

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

[Bernt Hansson]

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"

Re: [CFT] Fixing/changing LIB_DEPENDS

[olli hauer]

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: lib.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:
> lib.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

___
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

[Adam Strohl]

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

[Baptiste Daroussin]

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: lib.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:
> > lib.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

[olli hauer]

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: lib.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:
>>> lib.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

[Steve Wills]

> 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

[Baptiste Daroussin]

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: lib.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:
> >>> lib.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

[Adam Strohl]

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?

[Koichiro IWAO]

Everyone missing remmina,

I manage to finish updating remmina on this weekend.
Sorry for the long wait.

--
`whois vmeta.jp | nkf -w`
meta 
___
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 ?

[Loïc BLOT]

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 ?

[Patrick Powell]

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

[Super Bisquit]

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

[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"

[QAT] r320839: 4x leftovers

[Ports-QAT]

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=revision&revision=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: 
redports 
___
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 ?

[Loïc BLOT]

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