FreeBSD ports you maintain which are out of date

2014-01-29 Thread 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
+-+
games/doomsday  | 1.12.2  | 
1.14.0-build1123
+-+


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

Thanks.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: What is the problem with ports PR reaction delays?

2014-01-29 Thread Big Lebowski
Unfortunately, nothing is happening. I expected to hear some voices about
certain ideas that have popped up, like:

* can we cut off old and 'unloved' PR's in order to reduce the amount of
work and make reassessment of that amount
* can we use people who volunteered to work on the PR's
* can we incorporate automation in the PR workflow, for example, the one
provided by redports
* can we introduce new levels of access, the commiters that are commiting
on the ports they're maintaining

But beside few commiters taking part in the discussion, it seems like there
is no action, and no one who would have some decisive powers have taken
care to talk about the issues we're raising.

Kind regards,
B.


On Tue, Jan 28, 2014 at 4:13 PM, Fernando Apesteguía 
fernando.apesteg...@gmail.com wrote:

 El 28/01/2014 16:04, Daniel Siechniewicz dan...@nulldowntime.com
 escribió:
 
  Hi,
 
  Just a little stick in this anthill:
 
  - I've seen a few people volunteering, but so far the reaction seems
  to be: oh, yeah, well, ah, cool. I'd expect, with all the talk about
  how much they are needed, that they will be snatched immediately and
  coerced into doing unspeakable things (like processing a 100 PRs a
  day, ensuring high quality testing and all that :) ). I certainly hope
  this is happening behind the scenes.
 
  - Tools are abundant, focusing on github vs. aegis is really just
  highjacking this thread. If there's a need for new tool set I suppose
  people who actually USE the existing ones for ports will be able to
  identify what's needed FOR THEM. Some form of democracy, I guess.
 
  - Yes, fresh look is very important, but you can't tear down something
  without knowing the consequences, which pretty much means not without
  in depth knowledge of the existing mechanisms. Not everyone in this
  discussion seems to be coming from this perspective.
 
  - Absolutely, automate the shit out of the process, get rid of stale
  PR's (and ports, for that matter), retire inactive commiters, etc.
  But first and foremost, get some stats out of the system, there's no
  point throwing numbers like 50% this, 80% that, if you simply don't
  know. Measure, analyze and focus your attention where it gets the most
  benefits.

 +1

 I wrote the same thing expecting someone to have a look at gnat's database
 and collect some numbers

 
  - And stop petty squabbles.
 
 
  Regards,
  Daniel
  ___
  freebsd-ports@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-ports
  To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

___
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] r341700: 4x leftovers

2014-01-29 Thread Ports-QAT
Set USE_MYSQL=server.
-

  Build ID:  20140129085800-28335
  Job owner: k...@freebsd.org
  Buildtime: 11 minutes
  Enddate:   Wed, 29 Jan 2014 09:08:34 GMT

  Revision:  r341700
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=341700

-

Port:databases/mysql-q4m 0.9.10_1

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20140129085800-28335-265304/mysql55-q4m-0.9.10_1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20140129085800-28335-265305/mysql55-q4m-0.9.10_1.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20140129085800-28335-265306/mysql55-q4m-0.9.10_1.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~k...@freebsd.org/20140129085800-28335-265307/mysql55-q4m-0.9.10_1.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20140129085800-28335
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: What is the problem with ports PR reaction delays?

2014-01-29 Thread Kurt Jaeger
Hi!

 Unfortunately, nothing is happening. I expected to hear some voices about
 certain ideas that have popped up, like:
 
 * can we cut off old and 'unloved' PR's in order to reduce the amount of
 work and make reassessment of that amount

There is the other view of this which says PRs do not eat hay, closing
them does not really fix anything. I think this one is still open
for debate.

 * can we use people who volunteered to work on the PR's

There are people submitting PRs, and those committing changes,
and in between them those people that check/confirm PRs.

They could do that before and they can still do it now, if they want to.

So besides *doing* this there is not much push that can help here.

 * can we incorporate automation in the PR workflow, for example, the one
 provided by redports

I've read through the thread and would like to hear more about
this. Can anybody with knowledge about it please remind us of the
details to this idea ?

 * can we introduce new levels of access, the commiters that are commiting
 on the ports they're maintaining

I would welcome this, and by doing this, I would learn more about
the committing process and would probably apply this to other
ports in the future.

There is another option, which needs to be debated:

Start regular money collection which pays for some full-time staff
that does commits etc.

The downside might be that the volunteers see themselves less valued
and become less involved in committing/reviewing etc, because
someone else ist paid for it and I'm not. This might be
a serious issue, so how could we solve this motivational effect ?

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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: What is the problem with ports PR reaction delays?

2014-01-29 Thread Fernando Apesteguía
On Wed, Jan 29, 2014 at 10:27 AM, Kurt Jaeger li...@opsec.eu wrote:

 Hi!

  Unfortunately, nothing is happening. I expected to hear some voices about
  certain ideas that have popped up, like:
 
  * can we cut off old and 'unloved' PR's in order to reduce the amount of
  work and make reassessment of that amount

 There is the other view of this which says PRs do not eat hay, closing
 them does not really fix anything. I think this one is still open
 for debate.

  * can we use people who volunteered to work on the PR's

 There are people submitting PRs, and those committing changes,
 and in between them those people that check/confirm PRs.

 They could do that before and they can still do it now, if they want to.

 So besides *doing* this there is not much push that can help here.

  * can we incorporate automation in the PR workflow, for example, the one
  provided by redports

 I've read through the thread and would like to hear more about
 this. Can anybody with knowledge about it please remind us of the
 details to this idea ?


redports is a great service to check ports. I use it after testing my
changes in local (with port test and such). Then I upload the changes to
redports and wait for it to compile in multiple groups (different archs and
releases). Once it's compiled succesfully I add the proper log to my PR
submission. This way the commiter (or whoever is looking at it) would save
_a lot of time_ instead of trying to compile again the port just to see if
it is fine. He/She could even try it again in his/her redports account!

I think sending the redports log along with the PR should be kind of
mandatory. And, although I don't know the infrastructure details, it should
be possible to send the redports commit reference, and retrieve the patch
automatically. That would save time.

But again, this is about tooling. Since nobody collected any data (I tried,
but I can't filter GNATS by date for example) we don't what the problem is.



  * can we introduce new levels of access, the commiters that are commiting
  on the ports they're maintaining

 I would welcome this, and by doing this, I would learn more about
 the committing process and would probably apply this to other
 ports in the future.

 There is another option, which needs to be debated:

 Start regular money collection which pays for some full-time staff
 that does commits etc.

 The downside might be that the volunteers see themselves less valued
 and become less involved in committing/reviewing etc, because
 someone else ist paid for it and I'm not. This might be
 a serious issue, so how could we solve this motivational effect ?

 --
 p...@opsec.eu+49 171 3101372 6 years to
 go !
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: devel/libgee 0.8.5 fails to build

2014-01-29 Thread Koop Mast

On 28-1-2014 18:12, Torfinn Ingolfsen wrote:

Hello,

On Tue, Jan 28, 2014 at 5:53 PM, Koop Mast k...@rainbow-runner.nl wrote:

Hmm the element warnings seem to be harmless, but the but the above gvfs
warning seems to be more interesting. Could you rebuild/install gvfs and see
if that would fix this?

reinstalling gvfs does not fix this.


I assume you have gvfs installed with the gphoto and hal options?

Why do you assume I have those options set?
Anyway here is the gvfs config I am using:

root@kg-v7# cd /usr/ports/devel/gvfs
root@kg-v7# make showconfig
=== The following configuration options are available for gvfs-1.12.3_2:
  AVAHI=on: Zeroconf support via Avahi
  CDDA=off: CDDA (enables HAL)
  FUSE=off: FUSE (Filesystem in Userspace) support
  GPHOTO2=off: Gphoto 2 camera support (enables HAL)
  HAL=off: HAL (Hardware Abstraction Layer) support
  SAMBA=on: Samba support
=== Use 'make config' to modify these settings

HTH
I reproduced the problem, will work on a fix when I get back home after 
work.


-Koop
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: net/avahi-app core dumps signal 11

2014-01-29 Thread Koop Mast

On 29-1-2014 4:12, Robert_Burmeister wrote:

People who deleted all ports, removed /usr/local and reinstalled
have reported that they do not have the problem.

I have deleted the contents of /usr/local/lib and am running a portupgrade
-afu

I'll report back if that is a quicker fix.

Amazing, this worked.

Apparently, some Gnome components are finicky about how they are built.
A note from
https://wiki.gnome.org/Projects/Jhbuild/FreeBSD


Remove all .la files from the packages you just installed to prevent
problems during the build.
You'll have to remember to do this again each time you install more
packages.
That wiki page is only for when your trying to build gnome with Jhbuild. 
I should also note that, that page is very WIP heavy.



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: net/avahi-app core dumps signal 11

2014-01-29 Thread Thomas Mueller
On Tue, 21 Jan 2014 23:37:08 -0200, Sergio de Almeida Lenzi wrote:
 avahi-daemon dumps core, and I am unable
 to determinw why because it aborts core just before reaching
 the main()  procedure..
 =
 
 #0  0x000801304604 in pthread_testcancel () from /lib/libthr.so.3
 #1  0x0008012fc706 in open () from /lib/libthr.so.3
 #2  0x000801517227 in __gets_chk () from /lib/libssp.so.0
 #3  0x0008015173d2 in __chk_fail () from /lib/libssp.so.0
 #4  0x000801516ace in .init () from /lib/libssp.so.0
 #5  0x7fffd130 in ?? ()
 #6  0x00080061e6d1 in r_debug_state () from /libexec/ld-elf.so.1
 #7  0x00080061dd57 in __tls_get_addr () from /libexec/ld-elf.so.1
 #8  0x00080061c099 in .text () from /libexec/ld-elf.so.1
 #9  0x in ?? ()
 =
 
 any ideas???

Seems like a bad interaction with stack protector (libssp).

I managed to get working binaries (10.0-STABLE, amd64) by adding
--disable-stack-protector to CONFIGURE_ARGS

-- 
Thomas Mueller
___
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: lang/ruby19: fails to build on 9.2-STABLE: don't know how to make OPENSSL_CFLAGS. Stop

2014-01-29 Thread Herbert J. Skuhra

Den 29.01.2014 02:22, skrev Steve Wills:

On Mon, Jan 27, 2014 at 04:14:14PM +0100, Herbert J. Skuhra wrote:

Den 27.01.2014 11:48, skrev O. Hartmann:
 On all FreeBSD 9.2-STABLE oboxes, the update of port lang/ruby19 fails
 with

 checking for nroff... /usr/bin/nroff
 .ext/include/amd64-freebsd9/ruby/config.h updated
 ruby library version = 1.9
 configure: creating ./config.status
 config.status: creating Makefile
 config.status: creating ruby-1.9.pc
 ===  Building for ruby-1.9.3.484_1,1
 make: don't know how to make OPENSSL_CFLAGS. Stop
 *** [do-build] Error code 1

 Stop in /usr/ports/lang/ruby19.
 *** [build] Error code 1

This is caused by: r341335


I'm unable to reproduce on r341678, perhaps there is something in your
make.conf that's triggering it? Can you share your make.conf?


Yes, bapt has already fixed it! (r341445?)

Thanks.

--
Herbert

___
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


ossec-hids-local-2.7 on FreeBSD 10

2014-01-29 Thread Robin Brocks

Hello Ports Team,

since the port ossec-hids-local-2.7 does not have a maintainer, i am 
using this mail address instead.
Currently i am not  sure if i have a individual problem, but for me it 
seems it could be a general problem with the port or the project OSSEC 
itself.


I can not make OSSEC ossec-hids-local-2.7 run on FreeBSD 10.
I always get the error message

2014/01/29 09:32:26 ossec-rootcheck(1210): ERROR: Queue 
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Socket 
operation on non-socket'.


when starting syscheckd.

I already deleted the file queue, chmodded it to 666 or 777, but 
nothing changed. ossec owns the complete folder tree. Any idea?
I am pretty sure it has something to do with the FBSD Version 10, when 
is was running FBSD 9.1, those problems did not occur.




/usr/local/ossec-hids/bin/ossec-control start

Starting OSSEC HIDS v2.7 (by Trend Micro Inc.)...
ossec-analysisd: Configuration error. Exiting.

/usr/local/ossec-hids/bin/ossec-control enable debug
/usr/local/ossec-hids/bin/ossec-analysisd
/usr/local/ossec-hids/bin/ossec-syscheckd
2014/01/29 10:00:49 ossec-syscheckd(1210): ERROR: Queue 
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Socket 
operation on non-socket'.
2014/01/29 10:00:49 ossec-rootcheck(1210): ERROR: Queue 
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Socket 
operation on non-socket'.
2014/01/29 10:00:57 ossec-syscheckd(1210): ERROR: Queue 
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Socket 
operation on non-socket'.
2014/01/29 10:00:57 ossec-rootcheck(1210): ERROR: Queue 
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Socket 
operation on non-socket'.
2014/01/29 10:01:10 ossec-syscheckd(1210): ERROR: Queue 
'/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Socket 
operation on non-socket'.
2014/01/29 10:01:10 ossec-rootcheck(1211): ERROR: Unable to access 
queue: '/usr/local/ossec-hids/queue/ossec/queue'. Giving up..

whoami

root

file /usr/local/ossec-hids/queue/ossec/queue

/usr/local/ossec-hids/queue/ossec/queue: empty

ls -al

total 16
drwxrwx---   2 ossec  ossec  512 Jan 29 09:25 .
dr-xr-x---  11 root   ossec  512 Jan 28 14:05 ..
-rwxrwxrwx   1 ossec  ossec0 Jan 29 09:25 queue

Any hint or idea? Anyone maintaining this port who could help?


best regards,
Robin

___
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] r341713: 4x leftovers

2014-01-29 Thread Ports-QAT
Update to 7.0.50 release.
-

  Build ID:  20140129113000-40173
  Job owner: a...@freebsd.org
  Buildtime: 30 minutes
  Enddate:   Wed, 29 Jan 2014 12:00:27 GMT

  Revision:  r341713
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=341713

-

Port:www/tomcat7 7.0.50

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20140129113000-40173-265376/tomcat7-7.0.50.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20140129113000-40173-265377/tomcat7-7.0.50.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20140129113000-40173-265378/tomcat7-7.0.50.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~a...@freebsd.org/20140129113000-40173-265379/tomcat7-7.0.50.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20140129113000-40173
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


configure scripts and FreeBSD-10

2014-01-29 Thread Montgomery-Smith, Stephen
I have ports with configure scripts that include lines like

freebsd1*)

Now obviously the script will choose this case when I am running
FreeBSD-10 as well as FreeBSD-1.

What solutions have people used to deal with this?Does anyone have
good examples of ports I can look at where this was solved?  Somebody
sent me a patch that replaces freebsd1*) with freebsd1[!0]*), but that
will fail when FreeBSD-11 comes out.

Thanks, Stephen
___
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: configure scripts and FreeBSD-10

2014-01-29 Thread Thierry Thomas
Hello Stephen,

Le mer 29 jan 14 à 14:15:51 +0100, Montgomery-Smith, Stephen 
step...@missouri.edu
 écrivait :
 I have ports with configure scripts that include lines like
 
 freebsd1*)
 
 Now obviously the script will choose this case when I am running
 FreeBSD-10 as well as FreeBSD-1.
 
 What solutions have people used to deal with this?Does anyone have
 good examples of ports I can look at where this was solved?  Somebody
 sent me a patch that replaces freebsd1*) with freebsd1[!0]*), but that
 will fail when FreeBSD-11 comes out.

Just suppress the corresponding lines: we don't support FreeBSD-1!
And check that one of the other case is relevant.

Regards,
-- 
Th. Thomas.


smime.p7s
Description: S/MIME cryptographic signature


Re: configure scripts and FreeBSD-10

2014-01-29 Thread Montgomery-Smith, Stephen
On 01/29/2014 07:27 AM, Thierry Thomas wrote:
 Hello Stephen,
 
 Le mer 29 jan 14 à 14:15:51 +0100, Montgomery-Smith, Stephen 
 step...@missouri.edu
  écrivait :
 I have ports with configure scripts that include lines like

 freebsd1*)

 Now obviously the script will choose this case when I am running
 FreeBSD-10 as well as FreeBSD-1.

 What solutions have people used to deal with this?Does anyone have
 good examples of ports I can look at where this was solved?  Somebody
 sent me a patch that replaces freebsd1*) with freebsd1[!0]*), but that
 will fail when FreeBSD-11 comes out.
 
 Just suppress the corresponding lines: we don't support FreeBSD-1!
 And check that one of the other case is relevant.
 
 Regards,

That means I have to read through these configure files (and I have a
huge number of them).  Maybe I'll replace it with freebsd-nada). :-)
___
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 does not accept installed net/openldap24-sasl-client

2014-01-29 Thread Dr. Peter Voigt
I have a fresh installation of FreeBSD 10.0-RELEASE and I am having
trouble with portmaster. Portmaster does not accept the installed port
net/openldap24-sasl-client when I try to upgrade or install ports that
depend on openldap-client.

One the other hand, when installing ports with make install clean
these ports immediately accept the installed net/openldap24-sasl-client.

I have summarized my observations in the FreeBSD forum:
https://forums.freebsd.org/viewtopic.php?f=5t=44576

Please let me know, if you need any other information to clarify this
issue.

Should I inform the port maintainer of OpenLDAP? From the Makefile of
this port I conclude Xin LI delp...@freebsd.org should be the right
one. Can you confirm this - I am still rather new to FreeBSD?

Regards,
Peter
___
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: configure scripts and FreeBSD-10

2014-01-29 Thread Dimitry Andric
On 29 Jan 2014, at 14:15, Montgomery-Smith, Stephen step...@missouri.edu 
wrote:
 I have ports with configure scripts that include lines like
 
 freebsd1*)
 
 Now obviously the script will choose this case when I am running
 FreeBSD-10 as well as FreeBSD-1.
 
 What solutions have people used to deal with this?Does anyone have
 good examples of ports I can look at where this was solved?  Somebody
 sent me a patch that replaces freebsd1*) with freebsd1[!0]*), but that
 will fail when FreeBSD-11 comes out.

Please have a look at /usr/ports/Mk/bsd.port.mk, and search for
run-autotools-fixup.  This stage is run automagically before the
configure stage, and replaces instances of freebsd1*, freebsd2* etc with
freebsd1.*, freebsd2.*, etc.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail


distinfo of port devel/boehm-gc are not correct.

2014-01-29 Thread timo . pallach
   Hi,

   I tried to install the devel/boehm-gc port an got errors because of a
   wrong filesize.
   Updating the distinfo file was fixing this issue.

   Maybe you could update the distinfo file.

   THX!!!
   Timo.
___
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: What is the problem with ports PR reaction delays?

2014-01-29 Thread Bernhard Fröhlich
On Wed, Jan 29, 2014 at 11:12 AM, Fernando Apesteguía
fernando.apesteg...@gmail.com wrote:
 On Wed, Jan 29, 2014 at 10:27 AM, Kurt Jaeger li...@opsec.eu wrote:

 Hi!

  Unfortunately, nothing is happening. I expected to hear some voices about
  certain ideas that have popped up, like:
 
  * can we cut off old and 'unloved' PR's in order to reduce the amount of
  work and make reassessment of that amount

 There is the other view of this which says PRs do not eat hay, closing
 them does not really fix anything. I think this one is still open
 for debate.

  * can we use people who volunteered to work on the PR's

 There are people submitting PRs, and those committing changes,
 and in between them those people that check/confirm PRs.

 They could do that before and they can still do it now, if they want to.

 So besides *doing* this there is not much push that can help here.

  * can we incorporate automation in the PR workflow, for example, the one
  provided by redports

 I've read through the thread and would like to hear more about
 this. Can anybody with knowledge about it please remind us of the
 details to this idea ?

The idea is pretty simple. redports.org is able to build various patches on
top of the FreeBSD portstree already. So all that is missing is just a small
script that runs periodically and fetches the patches from GNATS and
commits them to the redports repository to trigger automated builds. The
resulting buildlogs can be send to the GNATS database as a followup to
nform the submitter about failures. Well the code for that has been written
in large parts a year ago already. So all it needs is a consensus that this
is a good thing and some cleanup to get it ready for automatic operation.

 redports is a great service to check ports. I use it after testing my
 changes in local (with port test and such). Then I upload the changes to
 redports and wait for it to compile in multiple groups (different archs and
 releases). Once it's compiled succesfully I add the proper log to my PR
 submission. This way the commiter (or whoever is looking at it) would save
 _a lot of time_ instead of trying to compile again the port just to see if
 it is fine. He/She could even try it again in his/her redports account!

 I think sending the redports log along with the PR should be kind of
 mandatory. And, although I don't know the infrastructure details, it should
 be possible to send the redports commit reference, and retrieve the patch
 automatically. That would save time.

Yeah I am working on some scripts that help with that and also allow to work
more efficient with port PRs. Right now all people I know have written their own
set of scripts to kind of optimize their workflow but most of them are quite
simple and don't work for more than one person.

With redports.org being the central place where more people work in a similar
fashion I think it makes sense to write some tools that help with the
usual tasks.

The result is rptools which is still quite rough so don't use it yet
please unless
you want to help developing it:

https://redports.org/browser/decke/ports-mgmt/rptools
https://github.com/decke/rptools

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


FreeBSD Port: apache24-2.4.6_1

2014-01-29 Thread s!mon roy
Hi,

When's the release of Apache 2.4.7 planed for FreeBSD ports?

I also want to thank you for maintaining!

KRs,
Simon
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: FreeBSD Port: apache24-2.4.6_1

2014-01-29 Thread olli hauer
On 2014-01-29 18:55, s!mon roy wrote:
 Hi,
 
 When's the release of Apache 2.4.7 planed for FreeBSD ports?
 
 I also want to thank you for maintaining!
 
 KRs,
 Simon

Hi Simon,

the upgrade is planned together with the release of apr-1.5.1.

One important point from the apache-2.4.7 Changelog.
  *) APR 1.5.0 or later is now required for the event MPM.

However, apr-1.5.0 has some issues on FreeBSD 10 (hanging)
that are fixed in the upcoming apr-1.5.1

Users running on FreeBSD 10 are welcome to test the fixes
included in the upcoming apr-1.5.1.

Just send a test request to the apache@FreeBSD list and I
will shape a patch ;)



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


[QAT] r341767: 2x leftovers, 2x fetch

2014-01-29 Thread Ports-QAT
Add libcxxrt into the ports tree, that is a necessary piece of bringing
a one true unique c++ ABI for the ports tree
-

  Build ID:  20140129182000-60116
  Job owner: b...@freebsd.org
  Buildtime: 67 minutes
  Enddate:   Wed, 29 Jan 2014 19:27:11 GMT

  Revision:  r341767
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=341767

-

Port:devel/libcxxrt 20141225

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   FETCH
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129182000-60116-265868/libcxxrt-20141225.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   FETCH
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129182000-60116-265869/libcxxrt-20141225.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129182000-60116-265870/libcxxrt-20141225.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129182000-60116-265871/libcxxrt-20141225.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20140129182000-60116
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: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.

2014-01-29 Thread arrowdodger
On Wed, Jan 29, 2014 at 7:22 AM, Robert_Burmeister 
robert.burmeis...@utoledo.edu wrote:

 Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD
 i386 10.0 Release.

 A)
 Clang does not need to to be installed first.


  B)
  FreeBSD 10's change to pkg(8) (a.k.a. PKGNG) affects the portupgrade
 tools
  as
  well as the package tools.
  Even if you are not using packages,
  before upgrading to FreeBSD 10 install pkg(8) as described in:
  http://www5.us.freebsd.org/doc/handbook/pkgng-intro.html
  and be sure to run pkg2ng.
 
  C)
  FreeBSD 10 moves converters/libiconv into the base system, which directly
  or
  indirectly affects many ports.
  This migration has largely been taken care of for the official packages,
  however, if you are rebuilding from the ports tree
  pkg_delete libiconv must be run,
  or converters/libiconv must be deinstalled,
  before your post OS recompile of all your ports.
 
  Most of the iconv hardcodes have been addressed in the ports tree, but
  this is
  still being worked on.

 D)
 Many Gnome ports still had issues with continuing to link to
 libiconv.so.3,
 such as avahi-app and gdm.


It's because gnome stuff uses libtool machinery and all *.la files from
corresponding gnome libs had libiconv.so.3 line inside. I've just grepped
through all .la files in /usr/local/lib, fed them to pkg which and
rebuilt needed ports.


 People who deleted all ports, removed /usr/local and reinstalled
 have reported that they do not have the problem.

 Apparently, some Gnome components are finicky about how they are built.
 A note from
 https://wiki.gnome.org/Projects/Jhbuild/FreeBSD

  Remove all .la files from the packages you just installed to prevent
  problems during the build.
  You'll have to remember to do this again each time you install more
  packages.

 I deleted the contents of /usr/local/lib and ran portupgrade -afu
 which rebuilt most of the problematic ports.




 --
 View this message in context:
 http://freebsd.1045724.n5.nabble.com/Lessons-learned-from-source-upgrade-from-FreeBSD-i386-9-2-Stable-to-FreeBSD-i386-10-0-Release-tp5878893p5880956.html
 Sent from the freebsd-ports mailing list archive at Nabble.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

___
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: devel/libgee 0.8.5 fails to build

2014-01-29 Thread Koop Mast

On 29-1-2014 11:17, Koop Mast wrote:

On 28-1-2014 18:12, Torfinn Ingolfsen wrote:

Hello,

On Tue, Jan 28, 2014 at 5:53 PM, Koop Mast k...@rainbow-runner.nl 
wrote:
Hmm the element warnings seem to be harmless, but the but the above 
gvfs
warning seems to be more interesting. Could you rebuild/install gvfs 
and see

if that would fix this?

reinstalling gvfs does not fix this.


I assume you have gvfs installed with the gphoto and hal options?

Why do you assume I have those options set?
Anyway here is the gvfs config I am using:

root@kg-v7# cd /usr/ports/devel/gvfs
root@kg-v7# make showconfig
=== The following configuration options are available for 
gvfs-1.12.3_2:

  AVAHI=on: Zeroconf support via Avahi
  CDDA=off: CDDA (enables HAL)
  FUSE=off: FUSE (Filesystem in Userspace) support
  GPHOTO2=off: Gphoto 2 camera support (enables HAL)
  HAL=off: HAL (Hardware Abstraction Layer) support
  SAMBA=on: Samba support
=== Use 'make config' to modify these settings

HTH
I reproduced the problem, will work on a fix when I get back home 
after work.


-Koop

Should be fixed now, thanks for reporting!

-Koop
___
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


best way to add www to wheel

2014-01-29 Thread Aryeh Friedman
I have the following line in my pkg-install:

pw groupmod wheel -m www

The reason is I have files that are created by a user account that also
gets made but are modified using it or tomcat... these particular files are
shell scripts that must run as root (they are for controlling bhyve and
other hyperv's as well as other rootly things like setting up and tarring
down nic's) keep in mind also since almost all user level commands
(including those that trigger rootly actions) are run via the web and that
the data (except actual web content) should not be owned by www

My gut says that the above while it works is almost certainly not the right
way to do it.
-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?

2014-01-29 Thread Fernando Apesteguía
On Wed, Jan 29, 2014 at 5:27 PM, Bernhard Fröhlich de...@freebsd.orgwrote:

 On Wed, Jan 29, 2014 at 11:12 AM, Fernando Apesteguía
 fernando.apesteg...@gmail.com wrote:
  On Wed, Jan 29, 2014 at 10:27 AM, Kurt Jaeger li...@opsec.eu wrote:
 
  Hi!
 
   Unfortunately, nothing is happening. I expected to hear some voices
 about
   certain ideas that have popped up, like:
  
   * can we cut off old and 'unloved' PR's in order to reduce the amount
 of
   work and make reassessment of that amount
 
  There is the other view of this which says PRs do not eat hay, closing
  them does not really fix anything. I think this one is still open
  for debate.
 
   * can we use people who volunteered to work on the PR's
 
  There are people submitting PRs, and those committing changes,
  and in between them those people that check/confirm PRs.
 
  They could do that before and they can still do it now, if they want to.
 
  So besides *doing* this there is not much push that can help here.
 
   * can we incorporate automation in the PR workflow, for example, the
 one
   provided by redports
 
  I've read through the thread and would like to hear more about
  this. Can anybody with knowledge about it please remind us of the
  details to this idea ?

 The idea is pretty simple. redports.org is able to build various
 patches on
 top of the FreeBSD portstree already. So all that is missing is just a
 small
 script that runs periodically and fetches the patches from GNATS and
 commits them to the redports repository to trigger automated builds. The
 resulting buildlogs can be send to the GNATS database as a followup to
 nform the submitter about failures. Well the code for that has been written
 in large parts a year ago already. So all it needs is a consensus that this
 is a good thing and some cleanup to get it ready for automatic operation.


That's good to hear.



  redports is a great service to check ports. I use it after testing my
  changes in local (with port test and such). Then I upload the changes to
  redports and wait for it to compile in multiple groups (different archs
 and
  releases). Once it's compiled succesfully I add the proper log to my PR
  submission. This way the commiter (or whoever is looking at it) would
 save
  _a lot of time_ instead of trying to compile again the port just to see
 if
  it is fine. He/She could even try it again in his/her redports account!
 
  I think sending the redports log along with the PR should be kind of
  mandatory. And, although I don't know the infrastructure details, it
 should
  be possible to send the redports commit reference, and retrieve the patch
  automatically. That would save time.

 Yeah I am working on some scripts that help with that and also allow to
 work
 more efficient with port PRs. Right now all people I know have written
 their own
 set of scripts to kind of optimize their workflow but most of them are
 quite
 simple and don't work for more than one person.

 With redports.org being the central place where more people work in a
 similar
 fashion I think it makes sense to write some tools that help with the
 usual tasks.

 The result is rptools which is still quite rough so don't use it yet
 please unless
 you want to help developing it:

 https://redports.org/browser/decke/ports-mgmt/rptools
 https://github.com/decke/rptools


Thanks, I'll have a look at it.

On the other side of the story, can you confirm if the rate of new ports
(or updates to existent ports) has increased? Or is the rate of commited
patches decreased? Do we _actually_ know what the problem is?



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


[QAT] r341791: 2x leftovers, 2x linker_error

2014-01-29 Thread Ports-QAT
Add -nostdlib to avoid linking to any stl lib
-

  Build ID:  20140129230200-16032
  Job owner: b...@freebsd.org
  Buildtime: 17 minutes
  Enddate:   Wed, 29 Jan 2014 23:19:23 GMT

  Revision:  r341791
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=341791

-

Port:devel/libcxxrt 20131225_1

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LINKER_ERROR
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129230200-16032-265964/libcxxrt-20131225_1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129230200-16032-265965/libcxxrt-20131225_1.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LINKER_ERROR
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129230200-16032-265966/libcxxrt-20131225_1.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129230200-16032-265967/libcxxrt-20131225_1.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20140129230200-16032
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: Braindead site configuration...

2014-01-29 Thread Dag-Erling Smørgrav
Matthew Seaman m.sea...@infracaninophile.co.uk writes:
 Can we drop at.cpan.org from the list of CPAN sites please?  It does
 stupid things like this:

Fixed in r341758 and merged to 2014Q1.  I also emailed c...@perl.org
about the issue.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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] r341794: 2x leftovers, 2x clang

2014-01-29 Thread Ports-QAT
Update to r200401
Use libcxxrt from ports if not in base
Add stage support
Convert libc++.so into a ldscript
Create a testing lib/c++/libstdc++ ldscript to cheat with g++
-

  Build ID:  20140129234800-29102
  Job owner: b...@freebsd.org
  Buildtime: 44 minutes
  Enddate:   Thu, 30 Jan 2014 00:32:05 GMT

  Revision:  r341794
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=341794

-

Port:devel/libc++ 200401

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   CLANG
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129234800-29102-265976/libc++-200401.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   CLANG
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129234800-29102-265977/libc++-200401.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129234800-29102-265978/libc++-200401.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129234800-29102-265979/libc++-200401.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20140129234800-29102
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


[QAT] r341792: 4x leftovers

2014-01-29 Thread Ports-QAT
Use a c++11 compiler

Reported by:QAT
-

  Build ID:  20140129232800-26922
  Job owner: b...@freebsd.org
  Buildtime: 68 minutes
  Enddate:   Thu, 30 Jan 2014 00:36:14 GMT

  Revision:  r341792
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=341792

-

Port:devel/libcxxrt 20131225_1

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129232800-26922-265968/libcxxrt-20131225_1.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129232800-26922-265969/libcxxrt-20131225_1.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129232800-26922-265970/libcxxrt-20131225_1.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129232800-26922-265971/libcxxrt-20131225_1.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20140129232800-26922
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


Sage update

2014-01-29 Thread Montgomery-Smith, Stephen
I have just updated sage to version 6.0.  I have also made some changes
to help it work with FreeBSD-10, using ideas given to me by Daniel
Smith.  Since I don't have a fast computer using FreeBSD-10, I would
appreciate it if any of you guys could try it out and see if it works.
___
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: Sage update

2014-01-29 Thread Montgomery-Smith, Stephen
On 01/29/2014 07:00 PM, Montgomery-Smith, Stephen wrote:
 I have just updated sage to version 6.0.  I have also made some changes
 to help it work with FreeBSD-10, using ideas given to me by Daniel
 Smith.  Since I don't have a fast computer using FreeBSD-10, I would
 appreciate it if any of you guys could try it out and see if it works.

I meant math/sage (for those who don't normally use it.)
___
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] r341771: 2x leftovers, 2x fetch

2014-01-29 Thread Ports-QAT
Bring back to the past the release date ;)

Submitted by:   decke
-

  Build ID:  20140129193000-28234
  Job owner: b...@freebsd.org
  Buildtime: 7 hours
  Enddate:   Thu, 30 Jan 2014 02:00:25 GMT

  Revision:  r341771
  Repository:
https://svnweb.freebsd.org/ports?view=revisionrevision=341771

-

Port:devel/libcxxrt 20131225

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   FETCH
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129193000-28234-265880/libcxxrt-20131225.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   FETCH
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129193000-28234-265881/libcxxrt-20131225.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129193000-28234-265882/libcxxrt-20131225.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~b...@freebsd.org/20140129193000-28234-265883/libcxxrt-20131225.log


--
Buildarchive URL: https://qat.redports.org/buildarchive/20140129193000-28234
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


ports/math/hexcalc restored from 8.2 now runs on 9.1 9.2 10.0

2014-01-29 Thread Julian H. Stacey
Hi ports@
I changed Subject: 
 From:
  Re: How to find removed ports in general  math/hexcalc in particular.
 To:
  ports/math/hexcalc restored from 8.2 now runs on 9.1  9.2  10.0

+ cc'd FYI Maintainer of x11/xcalc (a scientific not hexadecimal calculator)


 grep hexcalc /usr/ports/MOVED
 math/hexcalc||2011-08-01|Has expired: Looks like abandonware, no more public 
 distfiles
 
 I have a local:
   25129 Dec 20  1995 hexcalc..tar.Z
 (no idea why 2 dots), anyway its a valid tar.  I have put it up here
   http://berklix.com/~jhs/ftp/FreeBSD/ports/distfiles/hexcalc..tar.Z
 I'll look at creating a port.  (unless people know of a newer
 nice hexcalc ? but this one was always OK for me)


I have restored ports/math/hexcalc from 8.2; it now runs on 9.1  9.2  10.0
  http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/math/hexcalc/

Anyone know what to fix for 10.0 Mk/ ?  After installing it bleats:
  ===   Registering installation for hexcalc-1.11_2
  pkg-static: 
lstat(/usr1/release/10.0-RELEASE/ports/math/hexcalc/work/stage/usr/local/bin/hexcalc):
 No such file or directory
  pkg-static: 
lstat(/usr1/release/10.0-RELEASE/ports/math/hexcalc/work/stage/usr/local/man/man1/hexcalc.1.gz):
 No such file or directory

Cheers,
Julian
-- 
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
 Interleave replies below like a play script.  Indent old text with  .
 Send plain text, not quoted-printable, HTML, base64, or 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: Sage update

2014-01-29 Thread Montgomery-Smith, Stephen
On 01/29/2014 07:26 PM, Montgomery-Smith, Stephen wrote:
 On 01/29/2014 07:00 PM, Montgomery-Smith, Stephen wrote:
 I have just updated sage to version 6.0.  I have also made some changes
 to help it work with FreeBSD-10, using ideas given to me by Daniel
 Smith.  Since I don't have a fast computer using FreeBSD-10, I would
 appreciate it if any of you guys could try it out and see if it works.
 
 I meant math/sage (for those who don't normally use it.)

So I tried it on my slow i386 computer.  It dies on the subpackage
r-3.0.2.p0.  I would be interested if other people are seeing the same
problem.

I think it is because in the build, it creates libR.so using a command
like this:

cc -std=gnu99 -shared -fopenmp
-L/usr/home/stephen/sage/work/sage-6.0/local/lib/
-Wl,-rpath=/usr/home/stephen/sage/work/sage-6.0/local/lib
-Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46  -o libR.so
CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o
arithmetic.o array.o attrib.o bind.o builtin.o character.o coerce.o
colors.o complex.o connections.o context.o cum.o dcf.o datetime.o
debug.o deparse.o devices.o dotcode.o dounzip.o dstruct.o duplicate.o
edit.o engine.o envir.o errors.o eval.o format.o gevents.o gram.o
gram-ex.o graphics.o grep.o identical.o inlined.o inspect.o internet.o
iosupport.o lapack.o list.o localecharset.o logic.o main.o mapply.o
match.o memory.o names.o objects.o options.o paste.o platform.o plot.o
plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o
qsort.o random.o raw.o registration.o relop.o rlocale.o saveload.o
scan.o seq.o serialize.o sort.o source.o split.o sprintf.o startup.o
subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o
version.o vfonts.o xxxpr.o   `ls ../unix/*.o ../appl/*.o ../nmath/*.o`
../extra/zlib/libz.a ../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a
../extra/tre/libtre.a
-L/usr/home/stephen/sage/work/sage-6.0/local/lib -lf77blas -latlas
-lgfortran -lm -lquadmath  -lintl -lreadline  -llzma -lrt -lm -liconv

Now -Wl,-rpath is set, so it should find libreadline in
/usr/home/stephen/sage/work/sage-6.0/local/lib.  But instead it finds
libreadline in /lib.  So later when it does the following compilation to
build R.bin:

gcc -std=gnu99 -export-dynamic -fopenmp
-L/usr/home/stephen/sage/work/sage-6.0/local/lib/
-Wl,-rpath=/usr/home/stephen/sage/work/sage-6.0/local/lib
-Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -o R.bin Rmain.o
 -L../../lib -lR

...it comes up with an error saying that rl_sort_completion_matches
isn't found.  And when I do an ldd or readelf -d on libR.so, I can see
that it is trying to link to the wrong libreadline, and
rl_sort_completion_matches is only defined in the other libreadline.

I tried googling to find a fix.  And it works fine with FreeBSD-8.  This
has me completely stumped.  One web page suggested I added -Wl,-z,origin
to the list of flags when building libR.so.  But I really don't know
what I am doing.  Anyway, it didn't work.

___
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: ports/math/hexcalc restored from 8.2 now runs on 9.1 9.2 10.0

2014-01-29 Thread Kevin Oberman
On Wed, Jan 29, 2014 at 7:04 PM, Julian H. Stacey j...@berklix.com wrote:

 Hi ports@
 I changed Subject:
  From:
   Re: How to find removed ports in general  math/hexcalc in particular.
  To:
   ports/math/hexcalc restored from 8.2 now runs on 9.1  9.2  10.0

 + cc'd FYI Maintainer of x11/xcalc (a scientific not hexadecimal
 calculator)


  grep hexcalc /usr/ports/MOVED
  math/hexcalc||2011-08-01|Has expired: Looks like abandonware, no more
 public distfiles
 
  I have a local:
25129 Dec 20  1995 hexcalc..tar.Z
  (no idea why 2 dots), anyway its a valid tar.  I have put it up here
http://berklix.com/~jhs/ftp/FreeBSD/ports/distfiles/hexcalc..tar.Z
  I'll look at creating a port.  (unless people know of a newer
  nice hexcalc ? but this one was always OK for me)


 I have restored ports/math/hexcalc from 8.2; it now runs on 9.1  9.2 
 10.0

 http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/math/hexcalc/

 Anyone know what to fix for 10.0 Mk/ ?  After installing it bleats:
   ===   Registering installation for hexcalc-1.11_2
   pkg-static:
 lstat(/usr1/release/10.0-RELEASE/ports/math/hexcalc/work/stage/usr/local/bin/hexcalc):
 No such file or directory
   pkg-static:
 lstat(/usr1/release/10.0-RELEASE/ports/math/hexcalc/work/stage/usr/local/man/man1/hexcalc.1.gz):
 No such file or directory

 Cheers,
 Julian


Quick workaround is to turn off staging for the port.  It needs fixing, but
that will let it build immediately. Add the following to the Makefile:
NO_STAGE=  yes
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org