Re: No update for a day on ports?

[Steve Wills]

Hi,

On 4/2/21 9:44 AM, The Doctor via freebsd-ports wrote:


Then the question is : Moving forward, how do we update
the ports?


There are a number of ways. You can use the prebuilt git package or one 
of it's variants or substitutes. If you prefer to build git yourself, 
you can use the upstream source or fetch the ports tree tar from:


https://download.freebsd.org/ftp/ports/ports/

and use that to build git. Or you could simply delete your tree and 
re-fetch the tarball each time you update, if you prefer. I'm sure there 
are others I'm forgetting, but either way the choice is yours.


Cheers,

Steve


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

Re: Removing sysutils/polkit dependency from sysutils/libudisks?

[Steve Wills]

Hi,
On 1/17/21 3:17 AM, Kurt Jaeger wrote:

Hi!

Can you tell us the reason behind this opinion ? Is it generally
buggy, does polkit violate some general design policy for apps etc ?


* There's one part of polkit, pkexec, which is suid and linked to some 
libs that really aren't designed to be used in suid binaries.


* It uses spidermonkey to parse javascript policies, but aparently 
doesn't use it correctly[1]. It has a number of open issues[2] which 
have been open a while, but aren't addressed.


* The project doesn't look terribly active.

* Merge requests which look ready to commit aren't merged[3].

* The default policy gives everyone in wheel root access.

So, to me, the features it provides don't seem worth it. I have removed 
it from my local system with some local patches and it seems to work 
fine. I haven't missed it at all. Anyway, just my $0.02.


Cheers,
Steve


1: https://gitlab.freedesktop.org/polkit/polkit/-/issues/97
2: https://gitlab.freedesktop.org/polkit/polkit/-/issues
3: https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Removing sysutils/polkit dependency from sysutils/libudisks?

[Steve Wills]

Hi,

On 1/15/21 5:45 AM, Pau Amma wrote:
Several months ago, someone (swills@ IIRC) asked me to look into 
removing the sysutils/polkit dependency from sysutils/libudisks which I 
maintain. I just had a chance to look at that request and it would 
require at least removing the udisksctl utility from the default options 
and possibly removing it from the build altogether. However, its 
presence in the default options was expressly requested in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240138#c18 when I was 
initially porting libudisks. Is the request for removal still relevant? 
I think it was made with an eye toward removing sysutils/polkit 
altogether. If it is relevant, does it warrant removing udisksctl, which 
I found useful for port smoke testing and troubleshooting, in addition 
to the reasons for its presence listed in the Bugzilla comment linked 
above?


Personally, I'm still very much of the opinion that the less polkit is 
used the better.


Steve

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

Re: Github redirects for go based ports seems to be not working as expected

[Steve Wills]

Hi,

On 10/22/20 9:51 AM, Matthias Fechner wrote:
Does anyone have an idea why ports cannot download the old version but 
must use the one with renamed group and project?


Probably some GitHub internal issue with the codeload.github.com site. 
Probably not much we can do except update the URLs. I'd love to be wrong 
tho.


Steve

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

Re: Fwd: ports Makefile for gitlab subdirs

[Steve Wills]

Hi,
On 9/7/20 12:28 PM, MR wrote:

Hi,
I want to migrate the kicad-devel port from github to gitlab.
How should one handle the case if - like kicad - the project contains 
subgroups:


   like https://gitlab.com/kicad/code/kicad.git

Specifying:

GL_ACCOUNT= kicad
GL_PROJECT= code/kicad
GL_COMMIT=  bd23d003d219cb513b01feb4d9763879c9248f53

works for the download and extract but fails then:

...
cd: 
/usr/ports/cad/kicad-devel/work/code/kicad-bd23d003d219cb513b01feb4d9763879c9248f53-bd23d003d219cb513b01feb4d9763879c9248f53: 
No such file or directory

*** Error code 2
...

This gets extracted:
kicad-bd23d003d219cb513b01feb4d9763879c9248f53-bd23d003d219cb513b01feb4d9763879c9248f53/ 



Try adding this:

WRKSRC= ${WRKDIR}/${PORTNAME}-${GL_COMMIT}-${GL_COMMIT}

Steve

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

Re: [HEADS UP] Planned deprecation of portsnap

[Steve Wills]

Hi,

On 8/10/20 9:28 AM, Lars Engels wrote:

On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote:

I'm probably fine with this and I think that all of the (now) supported
methods have pros and cons.
To leverage the UX flaws of git and svn(lite) compared to portsnap
having a wrapper script around the two tools would be very appreciated.

Something like

# portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch 
extract
   The package devel/git does not seem to be installed, do you want to install 
it? (Y/n) _

With sane defaults, so you can just run portsnap fetch extract like
you're used to and this
downloads the latest ports tree to /usr/ports using base svnlite(1).

While we're here: Can we please have a separate user that is used to
checkout the tree?

Lars


P.S.: Please DO NOT name the wrapper portsnap-ng. :-)



I think something like this will likely in many ways perpetuate many of 
the problems I listed in my original email, particularly with folks 
being on the wrong branch and not properly generating patches.


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

Re: [HEADS UP] Planned deprecation of portsnap

[Steve Wills]

Hi,

On 8/7/20 6:19 AM, Michael Gmelin wrote:



On Fri, 7 Aug 2020 01:24:00 -0400
Steve Wills  wrote:


Hi,


[snip]


2. Use svnlite to checkout a ports tree. (There will be git -> svn
replication.


Will this be a long-term option? 


I don't know yet exactly how long the git to svn migration is planned to 
be maintained. I would expect quite some time.


[snip]

3. Download a tar of the ports tree either from:
  https://download.freebsd.org/ftp/ports/ports/

or cgit.


Would work too, but relatively expensive. Also, how often would it be
updated?


I believe that's updated daily and the tars from cgit are generated at 
least that frequently, if not more.


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

Re: [HEADS UP] Planned deprecation of portsnap

[Steve Wills]

Hi,

On 8/5/20 6:17 PM, Michael Gmelin wrote:



What will be the process to bootstrap git?



There are several options:

1. Install the git package provided by the FreeBSD project
2. Use svnlite to checkout a ports tree. (There will be git -> svn 
replication.

3. Download a tar of the ports tree either from:
https://download.freebsd.org/ftp/ports/ports/

or cgit.

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

Re: [HEADS UP] Planned deprecation of portsnap

[Steve Wills]

Hi,

On 8/5/20 12:31 PM, Ernie Luzar wrote:


I seems this is a done deal as changes are already being done now. So 
the real question is, when is the portsnap utility going to be removed 
from the base system? Will it happen in 12.2 or 13.0?


Full removal may not happen before 13.0 but hopefully disabling it by 
default, so that it is not installed unless one explicitly enables it, 
will happen before 13.0.


I maintain ports that use the portsnap utility. One is currently going 
through a maintenance cycle right now. Should the use of portsnap be 
removed from the port now?


Not necessarily, as 11.x and 12.x will have it of course, but it should 
definitely handle portsnap not being present on the system in any case, 
since it can be disabled via WITHOUT_PORTSNAP (even on 11.x and 12.x).


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

Git migration - was Re: [HEADS UP] Planned deprecation of portsnap

[Steve Wills]

Hi,

On 8/5/20 5:42 AM, Yasuhiro KIMURA wrote:

From: Kurt Jaeger 
Subject: Re: [HEADS UP] Planned deprecation of portsnap
Date: Wed, 5 Aug 2020 06:40:39 +0200


There's a list where the git topic is discussed:

https://lists.freebsd.org/pipermail/freebsd-git/

Have a look at the archive, and yes, subversion as version control
system for the FreeBSD project will probably be replaced by git.


It's a bit hard for me to read entire archive;-). So is there summary
of git migration project (about purpose, plan, current status, etc)?


Can we please keep the discussion about git in a different thread, I'm 
trying to monitor the portsnap related thread for issues related to that.


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

[HEADS UP] Planned deprecation of portsnap

[Steve Wills]

We are planning to deprecate use of portsnap in ports.

The reasons are as follows (in no particular order):

* Portsnap doesn't support quarterly branches, even years after 
quarterly branches were created and changed to the default for non-HEAD 
packages.


* Portsnap doesn't seem to save disk space compared to svn or git, if 
you count the metadata (stored in /var/db/portsnap by default) and you 
do an apples-to-apples comparison of svn or git without history and 
ignoring possible ZFS compression. That is, you use "svn export" or git 
"clone --depth 1", you see this disk usage:


342Msvnexport
426Mgit
477Mportsnap

* Portsnap also doesn't work offline which git does. With git, you can 
also easily add the history by running "git pull --unshallow"


* This migration away from portsnap fits well with the planned migration 
to git.


* Also based on the patches we've seen in Bugzilla for some time, usage 
of portsnap causes folks to too easily accidentally submit patches to 
Bugzilla which don't apply easily.


* Since portsnap doesn't support quarterly branches, it often causes 
users to build on the wrong branch or end up with mismatched packages. 
That is, they install packages from quarterly via pkg, then want to 
customize so run portsnap and build from head, which can cause problems, 
as we often see. Even when this doesn't happen, it adds to 
troubleshooting to verify that it didn't.


We are aware people have gotten used to portsnap, but believe:

* People should be able to easily use svnlite in base or git from pkgs. 
(Very few people seem to actually use WITHOUT_SVNLITE).


* There is also the possibility of falling back to fetching a tar or zip 
from https://cgit-beta.freebsd.org/ports/ although this does make 
updating harder.


How it will be done, in order:

* Update poudriere to use svn by default. This is already done:

  https://github.com/freebsd/poudriere/pull/764

https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10

* Update docs not to mention portsnap. This is already in progress:

  https://reviews.freebsd.org/D25800
  https://reviews.freebsd.org/D25801
  https://reviews.freebsd.org/D25803
  https://reviews.freebsd.org/D25805
  https://reviews.freebsd.org/D25808
  https://svnweb.freebsd.org/changeset/base/363798

  Many thanks to the folks who have worked and are working on this!

* Make WITHOUT_PORTSNAP default in base. Currently not certain when this 
will happen. May not happen before 13.0, but hopefully it will.


* Eventually, portsnap servers will see low enough usage they can be 
disabled.


We welcome any constructive feedback. All input would be heard, and if 
the plans need to be amended, we will come back to you with the amended 
plan in a couple of weeks. This process will take some time and 
hopefully won't be too disruptive to anyone's usual workflow.


Steve (with portmgr@ hat)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: purple-discord-g20200802

[Steve Wills]

Hi,

On 8/3/20 7:52 AM, Alex V. Petrov wrote:

===>>> Building the port required 2 seconds
===>  Staging for purple-discord-g20200802
===>   Generating temporary packing list
gmake[1]: Entering directory
'/usr/ports/net-im/purple-discord/work/purple-discord-8fd7ceb'
convert -strip -background none discord-alt-logo.svg -resize 16x16
discord16.png
convert: attempt to perform an operation not allowed by the security
policy `MVG' @ error/constitute.c/IsCoderAuthorized/412.
convert: no images defined `discord16.png' @
error/convert.c/ConvertImageCommand/3226.
gmake[1]: *** [Makefile:138: discord16.png] Error 1
gmake[1]: Leaving directory
'/usr/ports/net-im/purple-discord/work/purple-discord-8fd7ceb'
*** Error code 2



Sorry, no idea. Never seen those errors and can't reproduce.

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

Re: FreeBSD Port: openblas-0.3.7_1,1 error install

[Steve Wills]

Hi,

On 1/31/20 6:31 PM, Alex V. Petrov wrote:

and other machine:
-rw-r--r--  1 root  wheel  30159104  1 февр. 06:28
/usr/local/lib/libopenblas_penrynp-r0.3.7.a
-rwxr-xr-x  1 root  wheel  14597176  1 февр. 06:29
/usr/local/lib/libopenblas_penrynp-r0.3.7.so
lrwxr-xr-x  1 root  wheel28  1 февр. 06:29
/usr/local/lib/libopenblas.a -> libopenblas_penrynp-r0.3.7.a
lrwxr-xr-x  1 root  wheel29  1 февр. 06:29
/usr/local/lib/libopenblas.so -> libopenblas_penrynp-r0.3.7.so



It's expected that the port will build different (host optimized) libs 
when the DYNAMIC_ARCH option is off. Are you experiencing an issue 
besides the complaint from portmaster? The libopenblas.so symlink is 
there, so I think there shouldn't be any issues using the lib.


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

Re: FreeBSD Port: openblas-0.3.7_1,1 error install

[Steve Wills]

Hi,

On 1/31/20 5:47 PM, ajtiM via freebsd-ports wrote:


ls -al /usr/local/lib/libopenblas*
-rw-r--r--  1 root  wheel  32273330 Jan 31 10:45
/usr/local/lib/libopenblas_nehalemp-r0.3.7.a -rwxr-xr-x  1 root  wheel
15492200 Jan 31 10:45 /usr/local/lib/libopenblas_nehalemp-r0.3.7.so
lrwxr-xr-x  1 root  wheel29 Jan 31 10:45
/usr/local/lib/libopenblas.a -> libopenblas_nehalemp-r0.3.7.a
lrwxr-xr-x  1 root  wheel30 Jan 31 10:45
/usr/local/lib/libopenblas.so -> libopenblas_nehalemp-r0.3.7.so



Are you seeing any other issues besides the complaint from portmaster?

Steve

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

Re: FreeBSD Port: openblas-0.3.7_1,1 error install

[Steve Wills]

Hi,

On 1/31/20 11:42 AM, ajtiM wrote:

On Fri, 31 Jan 2020 10:01:42 -0500
Steve Wills  wrote:


Hi,

On 1/30/20 9:25 PM, Alex V. Petrov wrote:

===>  Installing for openblas-0.3.7_1,1
===>  Checking if openblas is already installed
===>   Registering installation for openblas-0.3.7_1,1
pkg-static: Unable to access file
/usr/ports/math/openblas/work/stage/usr/local/lib/libopenblasp-r0.3.7.a:No
such file or directory
pkg-static: Unable to access file
/usr/ports/math/openblas/work/stage/usr/local/lib/libopenblasp-r0.3.7.so:No
such file or directory
*** Error code 74


I believe this is fixed by r243739, please reopen this bug if there
is still an issue:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243739

Steve

Thank you. It is fixed but there are still problem:

portmaster --check-depends
Checking all packages: 100%
py27-numpy is missing a required shared library: libopenblas.so
py37-numpy is missing a required shared library: libopenblas.so
py37-scipy is missing a required shared library: libopenblas.so
suitesparse is missing a required shared library: libopenblas.so

py-numpy and suitesparse are rebuilt.



I think perhaps this is an issue with portmaster. Can you send output of:

ls -al /usr/local/lib/libopenblas*

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

Re: FreeBSD Port: openblas-0.3.7_1,1 error install

[Steve Wills]

Hi,

On 1/30/20 9:25 PM, Alex V. Petrov wrote:

===>  Installing for openblas-0.3.7_1,1
===>  Checking if openblas is already installed
===>   Registering installation for openblas-0.3.7_1,1
pkg-static: Unable to access file
/usr/ports/math/openblas/work/stage/usr/local/lib/libopenblasp-r0.3.7.a:No
such file or directory
pkg-static: Unable to access file
/usr/ports/math/openblas/work/stage/usr/local/lib/libopenblasp-r0.3.7.so:No
such file or directory
*** Error code 74


I believe this is fixed by r243739, please reopen this bug if there is 
still an issue:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243739

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

Re: How to best check a configuration of another port/package?

[Steve Wills]

Hi,

On 6/9/19 11:48 AM, Adam Weinberger wrote:


No, you're absolutely right. Flavours is the right way to do it now. I
keep forgetting about them, because I don't in any way understand how
to use them.


Hmm, flavors have to be something that can be installed in parallel, 
right? How does that impact binutils?


The approach I would have taken would have been to make the static 
option in binutils also install an empty file in DATADIR and have GCC 
check that file. Maybe that isn't ideal.


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

Re: New pkg audit FNs

[Steve Wills]

Hi,

On 10/09/2017 17:55, Jan Beich wrote:

Steve Wills  writes:


Hi,

On 10/09/2017 16:34, Jan Beich wrote:

Matthew Seaman  writes:


On 09/10/2017 16:57, Roger Marquis wrote:


Can anyone say what mechanisms the ports-security team might have in
place to monitor CVEs and port software versions?


I've been hacking at a prototype for scanning what I can find:

https://github.com/swills/nvd_to_new_vuxml


Wouldn't that encourage copypasta, exacerbating filesize issue? 


The VuXML data does need to be split up and all tools that process it 
need to be taught to deal with multiple files.



Why not
teach pkg-audit(8) to query NVD based on CPE annotations in *binary* packages?
Doing so would also provide a workaround for VuXML entries cancelled
to reduce bloat.


I agree, pkg-audit needs to be taught to do that. Along those lines, we 
could create a port for cvechecker:


https://github.com/sjvermeu/cvechecker

But both solutions only handle installed packages.

We would still need something to alert us to CVEs in non-installed 
software, I think.


Also, I've just looked and it seems only a little over 1000 ports have 
CPE strings. Adding something to portlint that warned ports developers 
to add any needed CPE info would be helpful. I think that type of 
warning has helped us improve LICENSE entries.


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

Re: New pkg audit FNs

[Steve Wills]

Hi,

On 10/09/2017 16:34, Jan Beich wrote:

Matthew Seaman  writes:


On 09/10/2017 16:57, Roger Marquis wrote:


Can anyone say what mechanisms the ports-security team might have in
place to monitor CVEs and port software versions? 


I've been hacking at a prototype for scanning what I can find:

https://github.com/swills/nvd_to_new_vuxml

It's more of a proof of concept than anything. The entry for this issue 
is still incomplete though, and the web page for it lists it as "waiting 
for analysis":


https://nvd.nist.gov/vuln/detail/CVE-2017-12617


The reason I ask is CVE-2017-12617 was announced almost a week ago yet
there's no mention of it in the vulnerability database  The tomcat8


It looks like it's there to me:

https://svnweb.freebsd.org/ports/head/security/vuxml/vuln.xml?r1=451185&r2=451415

https://www.vuxml.org/freebsd/c0dae634-4820-4505-850d-b1c975d0f67d.html

And added days ago.


port's Makefile also still points to the older, vulnerable version.


True, the maintainer needs to update it. I've copied him on this message.


Tomcat is one of those popular, internet-facing applications that sites
need to check and/or update quickly when CVEs are released and most
admins probably don't expect "pkg audit" to throw false negatives.


Ports-secteam (and secteam, for that matter) will update VuXML when they
know about vulnerabilities that affect FreeBSD ports, however the usual
mechanism is that the port maintainer either updates VuXML themselves
directly or tells the appropriate people that there are vulnerabilities
that need to be recorded.


Correct, but it doesn't have to be the port maintainer, anyone can 
submit a bug report with a patch to ports/security/vuxml/vuln.xml



What happened to querying CVE database using CPE strings? ENOTIME is a
common disease in volunteer projects, ports-secteam@ is no exception.
Finding missing entries is trivial if one looks at Debian tracker.
Let's pick something popular e.g., tiff-4.0.8 has 6 CVEs none of which
are fixed in the port.

https://wiki.freebsd.org/Ports/CPE


Indeed, I've wanted to try matching up ports/packages to the CVE entries 
by using CPE data. I will try to look at that again, but as always 
patches welcome.


I'll try to add the missing tiff entries and any others anyone cares to 
point out.


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

Re: Blender and opencv2-core

[Steve Wills]

Hi,

On 07/23/2017 15:57, Herbert J. Skuhra wrote:

Grzegorz Junka skrev:


On 23/07/2017 12:42, Grzegorz Junka wrote:

I am getting the following error when setting up blender
dependencies in poudriere:

===> Setting user-specified options for blender-2.78c_3 and dependencies
blender-2.78c_3:
"/usr/local/poudriere/ports/local/graphics/opencv2-core"
non-existent -- dependency list incomplete

Has this been removed but not updated in one of dependent ports?

Grzegorz J



Sent too early, this is the actual error when trying to compile:

[00:00:17] >> Error: graphics/openimageio depends on nonexistent
origin 'graphics/opencv2-core'; Please contact maintainer of the port
to fix this.
[00:00:33] >> Error: Fatal errors encountered calculating dependencies

This is of course when OpenImageIO setting is enabled in blender.


Have you tried to modify Makefile?

Index: graphics/openimageio/Makefile
===
--- graphics/openimageio/Makefile   (revision 446433)
+++ graphics/openimageio/Makefile   (working copy)
@@ -69,7 +69,7 @@
  OPENCV_CMAKE_ON=  -DUSE_OPENCV:BOOL=ON
  OPENCV_CMAKE_OFF= -DUSE_OPENCV:BOOL=OFF
  OPENCV_LIB_DEPENDS=   libopencv_highgui.so:graphics/opencv \
-   libopencv_core.so:graphics/opencv2-core \
+   libopencv_core.so:graphics/opencv-core \
libopenjpeg.so:graphics/openjpeg15
  
  OPENJPEG_CMAKE_ON=	-DUSE_OPENJPEG:BOOL=ON




Fix committed, sorry about that, thanks for the heads up.

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

Re: situation with www/node6 and www/node

[Steve Wills]

Can execjs work with node6? What else would have to change to get it all
onto node6?

Steve

On 05/18/2017 13:22, Joseph Mingrone wrote:
> Hello,
> 
> I am hitting an issue where the conflicting www/node6 and www/node
> packages are attempting to be installed together.  For example, the
> upcoming net-im/mastodon pulls in www/yarn (which depends on www/node6
> by default), and indirectly depends on devel/rubygem-execjs (which
> depends on www/node by default).
> 
> It would be ideal if all ports depended on the same node version by
> default.  Looking at the current state of the ports tree, it would make
> sense for everything to depend on www/node since the only two ports
> depending on www/node6 by default are www/npm3 and www/yarn.  But, Luca
> makes the point that version 7 of node is not what upstream recommends.
> 
> Could we come to a consensus here?
> 
> Thanks,
> 
> Joseph
> 



signature.asc
Description: OpenPGP digital signature

[CFT] emulators/open-vm-tools{,-nox11} update to 10.1.5

[Steve Wills]

Hello Everyone,

It's that time again, time to test another open-vm-tools update.
Everything is in basically the same place as last time.

The patch is here:

https://people.freebsd.org/~swills/open-vm-tools/open-vm-tools-10.1.5.diff

Note there are a good number of patches being renamed, so be sure to
delete empty patch files if necessary.

The packages are here:

https://people.freebsd.org/~swills/open-vm-tools/

And there's a repo setup script here:

https://people.freebsd.org/~swills/open-vm-tools/ovmsetup.sh

There shouldn't be a ton of changes on the upstream side this time, but
a good number of them on the port side, mostly cleanups. Please let me
know if any issues you encounter.

Steve



signature.asc
Description: OpenPGP digital signature

Re: Packaging Go Libs

[Steve Wills]

I've thought about that or perhaps a quick script to turn a vendor.json
in the the appropriate GH_TUPLE for a port Makefile, but even that seems
less necessary these days as more and more projects included a vendor
dir in their source tree.

Thanks to everyone for their input, seems we all agree, so I'll go ahead
with this plan.

Thanks,
Steve

On 04/18/2017 10:24, Julien Laffaye wrote:
> I agree with you.
> Maybe we should provide helpers to do the "fetching dependencies" part so
> that will be less cumbersome.
> 
> On Mon, Apr 17, 2017 at 4:20 PM, Steve Wills  wrote:
> 
>> Hi,
>>
>> I'd like to propose eliminating packaging of Go libs.
>>
>> Almost every Go app is developed with a different version of any given
>> lib than what another Go app might use. Forcing a Go app to use a
>> different version than what upstream might have chosen is error prone at
>> best and likely to produce a build that's unsupported upstream. So for
>> the packaged libs to even be useful, we would have to have as many
>> versions of each lib as there are consumers, or nearly as many.
>>
>> Further, best practice in the Go community is for Go apps to vendor all
>> their dependencies and almost all apps do that. This is the reason most
>> Go apps use different versions of it's libs.
>>
>> So to me, packaging Go libs doesn't make sense and I think we should
>> remove the Go libs from ports.
>>
>> Existing ports which use the Go libs should be updated to not use the Go
>> lib ports by doing one of these, in priority order:
>>
>> * Converted to using vendored deps included with the package source if
>> possible (preferred)
>> * Fetching the versions of deps specified by upstream (in the case of
>> vendor.json)
>> * As a last resort (deps are not included nor versions specified
>> exactly) fetching versions of deps available at the time of upstream
>> development
>>
>> Further, documentation should be added to the Porters Handbook saying
>> that we don't package Go libs and portlint should be updated to check
>> for installing files in GO_SRCDIR and GO_LIBDIR (exceot lang/go*).
>>
>> For reference, here's the list of Go lib ports that I found at the moment:
>>
>> archivers/go-compress
>> databases/gomdb
>> databases/gosqlite3
>> databases/levigo
>> databases/radix.v2
>> databases/redigo
>> devel/go-bayesian
>> devel/go-cobra
>> devel/go-codec
>> devel/go-cpuid
>> devel/go-crc32
>> devel/go-faker
>> devel/go-form
>> devel/go-go.uuid
>> devel/go-goregen
>> devel/go-hashicorp-logutils
>> devel/go-json-rest
>> devel/go-logrus
>> devel/go-metrics
>> devel/go-nuid
>> devel/go-pflag
>> devel/go-protobuf
>> devel/go-raw
>> devel/go-runewidth
>> devel/go-slices
>> devel/go-sql-driver
>> devel/go-uuid
>> devel/go-yaml
>> devel/goprotobuf
>> net/go-amqp
>> net/go-geoip
>> net/go-httppath
>> net/go-httptreemux
>> net/go-nats
>> net/go.net
>> security/go.crypto
>> security/goptlib
>> textproc/go.text
>> www/go-fasthttp
>> www/webgo
>>
>> Does anyone have any objection or reasoning why this doesn't make sense?
>>
>> Thanks,
>> Steve
>>
>>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 



signature.asc
Description: OpenPGP digital signature

Packaging Go Libs

[Steve Wills]

Hi,

I'd like to propose eliminating packaging of Go libs.

Almost every Go app is developed with a different version of any given
lib than what another Go app might use. Forcing a Go app to use a
different version than what upstream might have chosen is error prone at
best and likely to produce a build that's unsupported upstream. So for
the packaged libs to even be useful, we would have to have as many
versions of each lib as there are consumers, or nearly as many.

Further, best practice in the Go community is for Go apps to vendor all
their dependencies and almost all apps do that. This is the reason most
Go apps use different versions of it's libs.

So to me, packaging Go libs doesn't make sense and I think we should
remove the Go libs from ports.

Existing ports which use the Go libs should be updated to not use the Go
lib ports by doing one of these, in priority order:

* Converted to using vendored deps included with the package source if
possible (preferred)
* Fetching the versions of deps specified by upstream (in the case of
vendor.json)
* As a last resort (deps are not included nor versions specified
exactly) fetching versions of deps available at the time of upstream
development

Further, documentation should be added to the Porters Handbook saying
that we don't package Go libs and portlint should be updated to check
for installing files in GO_SRCDIR and GO_LIBDIR (exceot lang/go*).

For reference, here's the list of Go lib ports that I found at the moment:

archivers/go-compress
databases/gomdb
databases/gosqlite3
databases/levigo
databases/radix.v2
databases/redigo
devel/go-bayesian
devel/go-cobra
devel/go-codec
devel/go-cpuid
devel/go-crc32
devel/go-faker
devel/go-form
devel/go-go.uuid
devel/go-goregen
devel/go-hashicorp-logutils
devel/go-json-rest
devel/go-logrus
devel/go-metrics
devel/go-nuid
devel/go-pflag
devel/go-protobuf
devel/go-raw
devel/go-runewidth
devel/go-slices
devel/go-sql-driver
devel/go-uuid
devel/go-yaml
devel/goprotobuf
net/go-amqp
net/go-geoip
net/go-httppath
net/go-httptreemux
net/go-nats
net/go.net
security/go.crypto
security/goptlib
textproc/go.text
www/go-fasthttp
www/webgo

Does anyone have any objection or reasoning why this doesn't make sense?

Thanks,
Steve



signature.asc
Description: OpenPGP digital signature

Re: [CFT] emulators/open-vm-tools{,-nox11} update to 10.1.0

[Steve Wills]

Hi All,

Thanks to everyone who tested.

I've updated the patch and packages in the same location and fixed a
number of issues. Please re-test if you can.

The only remaining issue that I know of is building with libunwind
installed. If you run into an issue buidling, uninstall libunwind.
Upstream is looking at that.

This is likely the final change before I commit this, which currently I
plan to do on 3/15. So if you use it, now is your chance to test and
report issues.

Steve

On 01/19/2017 16:59, Steve Wills wrote:
> Hi,
> 
> I'd like anyone possible to test an updated version of
> emulators/open-vm-tools{,-nox11}. I have the patch here for those who
> wish to build themselves:
> 
> https://people.freebsd.org/~swills/open-vm-tools/open-vm-tools-10.1.0.diff
> 
> And for those who wish to test using packages, I've built packages with
> the new version and it's deps from the quarterly ports branch here:
> 
> https://people.freebsd.org/~swills/open-vm-tools/
> 
> with sub-directories for various FreeBSD versions and archs. There's
> also a script which can help you configure the repo so that you can
> install using pkg, here:
> 
> https://people.freebsd.org/~swills/open-vm-tools/ovmsetup.sh
> 
> Just grab the script, run it, then pkg install the open-vm-tools
> package, or update it if you already have it installed. This is a bit of
> a new testing method for me, so don't be surprised if there are some bumps.
> 
> I would be really nice see tests with both various versions of VMWare
> ESXi, particularly ESXi 6.0 and 6.5, and also VMWare desktop products.
> Any help testing would be appreciated. Even just a "worked OK for me" is
> helpful.
> 
> One particular note about this version, it no longer includes vmhgfs.
> Instead, there's support for using fuse to share files, though I haven't
> found documentation on that yet.
> 
> So, if you can try it out, please do and let me know how it goes.
> 
> Thanks,
> Steve
> 



signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 12:00, Franco Fichtner wrote:
> 
> Let me try another way:
> 
> Since pkg has feature macros for building correctly on different
> FreeBSD versions, namely 10.0, 10.1, 10.2 and 10.3, the way to
> provide binaries without missing symbols is to build pkg with a
> fixed set of feature macros for 10.0.
> 
> I've done this for projects to retain upgrade paths.  It's not
> hard.  It doesn't violate a policy or promise FreeBSD makes, does
> it?
> 

Just because you don't use any features of the newer version doesn't
mean it's safe to run binaries built for the newer version on the older
version, as far as I understand it.

Steve




signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 11:44, Miroslav Lachman wrote:
> Why don't add some check in to "pkg" to deny (or warn user) upgrade or
> install on unsupported / EOLed system?
> Just check version on current system against some metadata info in
> repository.

I would be happy to see a patch that showed how this might be done.

> Is it too much to ask?

It's always too much to ask another to do work for you for free. :)

Steve



signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 11:24, Franco Fichtner wrote:
> 
>> On 9 Feb 2017, at 5:21 PM, Steve Wills  wrote:
>>
>> We provide backwards compatibility, not forwards compatibility.
> 
> But don't you see that users won't know this?

Users who don't know their software is no longer supported and refuse to
update can't be helped, IMHO.

> This is a good theory, yet it is difficult in practice because it is
> not being enforced.

What would enforcement look like? Something like "Sorry, you can't pkg
update because this system isn't supported any more."? But how would
that be possible without also breaking things for those who build/ship
their own OS and packages?

Steve




signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 11:14, Franco Fichtner wrote:
> 
> You're contradicting yourself here.  Either it's compatible or it isn't?
> 

Not at all. There's a difference between backwards compatibility (binary
built on older release works on newer release) and forwards
compatibility (binary built on newer release works on older release).

We provide backwards compatibility, not forwards compatibility.

Steve



signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 11:01, Franco Fichtner wrote:
> 
>> On 9 Feb 2017, at 4:47 PM, Steve Wills  wrote:
>>
>> They're supposed to upgrade to a supported version of FreeBSD.
> 
> pkg won't refuse the upgrade.  And at least if it upgraded, it
> should not break itself.

Even if the update of pkg were done before the upgrade of the OS, if the
user ran "freebsd-update" to upgrade to 10.3, the version of pkg that it
updated to would work properly.

> Imagine a GUI-driven appliance being bricked.  There is nobody
> who can tell it "fetch ports and build pkg to keep using it".

Vendors should be building their own packages.

> Don't get me wrong.  Automation around pkg is really good, though
> that doesn't warrant it's perfect (yet).

I agree it's good, and nothing is ever perfect.

Steve



signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 10:30, Franco Fichtner wrote:
> Hi Steve,
> 
>> On 9 Feb 2017, at 4:09 PM, Steve Wills  wrote:
>>
>> Ports and packages are maintained on the assumption that the user is
>> using a supported version of the OS. We didn't decide when to end
>> support for 10.1 or 10.2. How long after the end of life for 10.1 would
>> you have ports maintain support?
> 
> The issue is quite simple and cause of multiple issues:
> 
> FreeBSD package management makes an ABI promise in the form of
> "FreeBSD:10:amd64", but not even pkg code itself adheres to this,
> and thus we have had subtle and yet fatal breakage in 10.2 and 10.3.
> 
> And since pkg acts according to the imposed paradigm of a unified
> ABI, this will continue to be a source of problems for users who
> cannot know what's going on, lest even know how to fix it.
> 
> They simply run:
> 
> # pkg upgrade
> 
> And then their systems are unusable *and* not fixable with pkg.
> 
> What are they supposed to do?  They come here.  They want to make
> everyone aware that this is a serious issue that shouldn't repeat
> in FreeBSD 11.  It's not to late to do that by pinning the pkg ABI
> to 11.0 by forcing the proper feature macros.

They're supposed to upgrade to a supported version of FreeBSD.

Steve




signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/09/2017 03:55, Franco Fichtner wrote:
> 
>> On 9 Feb 2017, at 9:49 AM, Kirill Ponomarev  wrote:
>>
>> I don't understand all critics I see in this thread and in your mail,
>> the fate of this project is all in your hands - try to contribute more,
> 
> I'm going to stop you right there.
> 
> That's not entirely true.  Too few committers, substantial lack of
> maintainer feedback, apparently no mentors to pick up newcomers, and
> worst of all no newcomers.

I'm currently mentoring or co-mentoring 5 people. I've done everything
else I can to encourage others to mentor, I think. If you have
suggestions of someone who needs mentoring, let us know and we can try
to find a mentor.

There's nothing we can do about lack of maintainer feedback except reset
maintainers. But keep in mind that lack of maintainer feedback shouldn't
be an issue, we can commit changes after maintainer feedback timeout.

> Decide for yourself which of these are true and which are self-made
> due to project management policies.

What policies do you think need to be changed and in what specific ways?

Steve



signature.asc
Description: OpenPGP digital signature

Re: Install of pkg fuse-ntfs fails because of undefined symbol in pkg!?!

[Steve Wills]

Hi,

On 02/08/2017 12:34, scratch65...@att.net wrote:
> 
> I *did* check for bug reports.  I did a search on "utimenstat"
> and found exactly one, which had been withdrawn as not being a
> bug. 
> 
> But it *is* a bug.  It's a bug on several levels, the most
> significant of which is that the overly frantic schedule makes
> versions have the lifespan of a mayfly.   And we're told "just
> upgrade", as though there's some physical law mandating the
> craziness.

Ports and packages are maintained on the assumption that the user is
using a supported version of the OS. We didn't decide when to end
support for 10.1 or 10.2. How long after the end of life for 10.1 would
you have ports maintain support?

> There are people for whom the system is a tool, not a hobby. They
> don't want to have to rebuild their tools any more than
> carpenters want to replace their hammers and levels every year or
> two.  

If you've having trouble upgrading that are causing you to rebuild, then
that's a different issue, but not one I can help with. It doesn't change
the fact that we don't support unsupported versions of the OS.

> For those people (I'm one) long version lifespans and bug-free
> operation  is a much bigger desideratum than winning the secret
> race (I presume there is some kind of secret race going on, since
> otherwise the crazy scheduling makes No Sense At All).  I can't
> work out what the strategy for winning is, if there is a
> strategy, but I do know that it's not working.   Linux has all
> but won already, and that's sickening.

Ports are maintained by volunteers. If you would like to volunteer to
support branches for longer periods of time, let's talk about that.

> I've been using the o/s since before v2 (I still have the cds)
> and have watched FreeBSD go from being the leading Unix on Intel
> boxes to all-but-dead.  I don't know how to express how saddened
> I feel about that.

I think ports are really improving and the rate of improvement is going up.

Steve



signature.asc
Description: OpenPGP digital signature

Re: ports and dependency hell

[Steve Wills]

Hi Julian,

On 02/07/2017 13:03, Julian Elischer wrote:
> This is a serious post  on a serious issue that ports framework people
> seem unaware of.

To be honest, it's kind of a confusing post, at least to me.

> It' getting too easy to get into dependency hell here (I've spent the
> last week fighting this)
> 
> In  a production system we have to choose packages from different eras.
> 
> This is because on an average product different teams are responsible
> for different parts of the product, and they all have their own
> requirements. Not to mention the stuff that comes in from third party
> vendors which "must use version X of bar and Version Z of foo". This is
> something that is a fact of life in commercial vendors. Ports needs to
> support it, and fast because currently ports is a reason to switch to
> Linux. (ammunition for the Linux fanboys). We are only staying for the
> ZFS support but that reason will evaporate soon.
> 
> We may need node.js 6.95 and a particular version of an apache mod for
> example, and a specific version off npm, which all only appeared in the
> ports tree at different times, so either we completely ditch the ports
> tree all together and import buildroot2 , which allows every package to
> have its own revision (but is Linux centric), or we need to generate
> frankenports trees. My curent iteration has 359 different packages, so
> you an imagine the hilarity  if I need to slide 20 of those back or
> forth, all independently.
> 
> There doesn't seem to be any understanding of this fact from the ports
> framework, and it means one has to keep one's own ports tree in source
> control, as a branch off the FreeBSD one. (maybe I should look at pkgsrc)..

I found this all confusing and vague, but it sounds like what's
happening is you need older versions of some software for whatever
reason and to provide that you are pulling older versions of ports into
a newer ports tree. Is that right?

> the problem is that the internal APIs of ports are changing too much.

Sorry, what do you mean? Can you define "too much" change?

> If you are going to change the API, then you need to be able to declare
> the version separately, maybe in a version/distinfo file that can be
> pulled in separately at a different rev, rather than having it built
> into the main Makefile of each port. Maybe the Makefile specifies a
> revision range it can be used with, but that would make a huge
> improvement right there.

The idea of having ports/packages support a version range for
dependencies is an interesting one, but I'm not sure how that would work.

> You can not just slide one port up by 3 months, and another down by 3
> months to get the revs one needs because the damned Mk files have
> changed. If I coudl leave the bulk of the Makefile alone and just slide
> the 'distingo/rev' file, (or be able to select a rev from one htat gives
> many alternatives, that woudl be "wonderful".

You're better off finding the tree that has the right version of the
oldest thing you need to use and then updating the things that you need
updated.

> Please, ports framework people,  think about how this can be done, If I
> have to edit a file, the game is lost.
> 
> Can we please get some understanding from ports people that they are
> making things REALLY HARD on vendors and it really strengthens the hands
> of  the "ditch FreeBSD and go to Linux" crowd when I need to spend a
> whole week trying to integrate in a set of 5 new ports into the product.
> 
> The call "It just works under linux, select the versions you want of
> each package and type make" is often heard around the company. And
> management is not totally deaf.
> 
> If you want to see how its' done better (still not perfect), go build a
> busybox system. you can effectively select any version of any tool and
> they all communicate via the pkgconf mechanism and you get the result
> you want.(mostly). And the API is stable.

Sounds like you've got a lot of folks who are used to the "LTS" mindset
where they never have to update their software to work with newer
versions. But ports is a rolling release in the head branch and
quarterly for those branches, and that's how it is going to be unless
someone wants to volunteer to maintain branches for longer. The LTS
thing works because people are paid to back port fixes and you can get
those for free.

> On the pkg side of things we need the ability for pkg to say "yeah I
> know I'm looking for foo-1.2.3.txz as a perfect match, but I've been
> given some slack on the third digit and I can see a foo-1.2.1.txz, so
> I'll install that instead".

I'm not sure how you would do that in a general way that didn't add
extra work for package maintainers.

> Otherwise we just have to spend WAY too much time generating dozens of
> "matching sets" of packages , that must be kept around forever if just
> one machine shipped with that set, not to mention the fact that making
> the matching set is often a real task.

Packages should gen

Re: updating ruby

[Steve Wills]

Hi,

On 02/09/2017 09:55, Herbert J. Skuhra wrote:
> 
> DEFAULT_VERSIONS+=ruby=2.3

Err, yeah, sorry, was too early for me... Thanks for the correction.

Steve




signature.asc
Description: OpenPGP digital signature

Re: updating ruby

[Steve Wills]

Hi,

On 02/08/2017 11:20, Gerard Seibert wrote:
> On or about 20170109, the default version of ruby was updated from 2.2
> to 2.3. However, "pkg install" wants to install version 2.2 for ports
> that require ruby. Is there a way to override this behavior?
> 

The packages are built from the quarterly branch, where 2.2 is still
default.

You could build your own packages from the head branch, or build from
quarterly branch with RUBY_DEFAULT=2.3 in /etc/make.conf.

Steve



signature.asc
Description: OpenPGP digital signature

Re: [CFT] emulators/open-vm-tools{,-nox11} update to 10.1.0

[Steve Wills]

Hi,

On 01/21/2017 09:13, Kurt Jaeger wrote:
> Hi!
> 
>> I'd like anyone possible to test an updated version of
>> emulators/open-vm-tools{,-nox11}. I have the patch here for those who
>> wish to build themselves:
>>
>> https://people.freebsd.org/~swills/open-vm-tools/open-vm-tools-10.1.0.diff
> 
> I tried to built it on 
> 
> 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r307013:311651M
> 
> (why does it say r307013:311651M, btw?)

Because some of your source is r307013 and other parts of your src tree
has been updated to r31165. The M stands for "modified", which can mean
you have local patches, but in this case may just mean the whole tree
isn't at the same rev. I'm not completely sure at the moment.

> 
> and it failed to build with:
> 
> utilBacktrace.c:155:20: error: implicit declaration of function 
> '_Unwind_GetCFA'
>   is invalid in C99 [-Werror,-Wimplicit-function-declaration]
>uintptr_t cfa = _Unwind_GetCFA(ctx);
>^
> utilBacktrace.c:357:4: error: implicit declaration of function
>   '_Unwind_Backtrace' is invalid in C99
>   [-Werror,-Wimplicit-function-declaration]
>_Unwind_Backtrace(UtilBacktraceFromPointerCallback, &data);
>^
> utilBacktrace.c:357:4: note: did you mean 'Util_Backtrace'?
> 
> Any ideas ?
> 

No, that's odd. I built on r311854 and had no issue. Maybe you could see
if you see the same?

Steve



signature.asc
Description: OpenPGP digital signature

Re: [CFT] emulators/open-vm-tools{,-nox11} update to 10.1.0

[Steve Wills]

Hi,

On 01/22/2017 07:26, Julian Elischer wrote:
> A bug problem I had with the previous version is the huge fanout of
> dependencies.
> 
> it was all OK until we hit libglib2, after which we ended up having to
> install all sorts of things.
> 
> I'm guessing there was not much you can do about this but just thought
> I'd mention it.

Well, I did have one mistake, which was not making the gdkpixbuf2
dependency conditional on the X11 OPTION. I've done that, updated the
patch and packages. Please give it a go, glib2 is still required but
that shouldn't pull in X11 dependencies, so it should be better.

Steve




signature.asc
Description: OpenPGP digital signature

Re: [CFT] emulators/open-vm-tools{,-nox11} update to 10.1.0

[Steve Wills]

Hi,

On 01/20/2017 10:14, Julian Elischer wrote:
> On 20/01/2017 5:59 AM, Steve Wills wrote:
>> Hi,
>>
>> I'd like anyone possible to test an updated version of
>> emulators/open-vm-tools{,-nox11}. I have the patch here for those who
>> wish to build themselves:
> 
> the problem we had with the existing on is that it ended up installing
> vi dependencies, a LOT of added stuff.
> Is htere any way to reduce the footprint?

That's the reason for the open-vm-tools-nox11 package. There maybe a way
to further reduce dependencies though, are there specific ones you had
in mind?

Steve



signature.asc
Description: OpenPGP digital signature

[CFT] emulators/open-vm-tools{,-nox11} update to 10.1.0

[Steve Wills]

Hi,

I'd like anyone possible to test an updated version of
emulators/open-vm-tools{,-nox11}. I have the patch here for those who
wish to build themselves:

https://people.freebsd.org/~swills/open-vm-tools/open-vm-tools-10.1.0.diff

And for those who wish to test using packages, I've built packages with
the new version and it's deps from the quarterly ports branch here:

https://people.freebsd.org/~swills/open-vm-tools/

with sub-directories for various FreeBSD versions and archs. There's
also a script which can help you configure the repo so that you can
install using pkg, here:

https://people.freebsd.org/~swills/open-vm-tools/ovmsetup.sh

Just grab the script, run it, then pkg install the open-vm-tools
package, or update it if you already have it installed. This is a bit of
a new testing method for me, so don't be surprised if there are some bumps.

I would be really nice see tests with both various versions of VMWare
ESXi, particularly ESXi 6.0 and 6.5, and also VMWare desktop products.
Any help testing would be appreciated. Even just a "worked OK for me" is
helpful.

One particular note about this version, it no longer includes vmhgfs.
Instead, there's support for using fuse to share files, though I haven't
found documentation on that yet.

So, if you can try it out, please do and let me know how it goes.

Thanks,
Steve



signature.asc
Description: OpenPGP digital signature

Re: Porting a Go implementation: dealing with dependencies

[Steve Wills]

Hi,

On 11/18/2016 10:35, Stefan Bethke wrote:
> I’m trying to create a port for Gitea
> (https://github.com/go-gitea/gitea). The basics seem easy enough, but
> I’m not sure how to deal with it’s dependencies.

Use the GH_* macros to fetch them. See:

https://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html#makefile-master_sites-github-description

Or if the upstream vendors their deps like many do these days you can
use the GH_SUBDIR macro to put them in the proper place.

There are examples to look at if that helps, see sysutils/consul as one
that has vendored deps or sysutils/serf for one that doesn't.

> 
> After downloading tag 0.97, I start building with
> 
> do-build:
>   (cd ${GO_WRKSRC} ; ${SETENV} ${GO_ENV} go build)
> 
> The result is a long list of unfulfilled dependencies:
> $ sudo make
> ===>  License APACHE20 accepted by the user
> ===>   gitea-0.9.97 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by gitea-0.9.97 for building
> ===>  Extracting for gitea-0.9.97
> => SHA256 Checksum OK for go-gitea-gitea-v0.9.97_GH0.tar.gz.
> ===>  Patching for gitea-0.9.97
> ===>   gitea-0.9.97 depends on executable: git - found
> ===>   gitea-0.9.97 depends on file: /usr/local/bin/go - found
> ===>   gitea-0.9.97 depends on executable: gmake - found
> ===>  Configuring for gitea-0.9.97
> ===>  Building for gitea-0.9.97
> (cd /var/ports/work/home/vagrant/gitea/work/src/github.com/go-gitea/gitea ; 
> /usr/bin/env 
> GOPATH="/var/ports/work/home/vagrant/gitea/work:/usr/local/share/go"  
> CGO_CFLAGS="-I/usr/local/include"  CGO_LDFLAGS="-L/usr/local/lib"  GOBIN="" 
> go build)
> cmd/dump.go:16:2: cannot find package "github.com/Unknwon/cae/zip" in any of:
>   /usr/local/go/src/github.com/Unknwon/cae/zip (from $GOROOT)
>   /var/ports/work/home/vagrant/gitea/work/src/github.com/Unknwon/cae/zip 
> (from $GOPATH)
>   /usr/local/share/go/src/github.com/Unknwon/cae/zip
> cmd/serve.go:16:2: cannot find package "github.com/Unknwon/com" in any of:
>   /usr/local/go/src/github.com/Unknwon/com (from $GOROOT)
>   /var/ports/work/home/vagrant/gitea/work/src/github.com/Unknwon/com 
> (from $GOPATH)
>   /usr/local/share/go/src/github.com/Unknwon/com
> …
> 
> Very few, if any, are available as ports.  I could use go get to download 
> these, but I think that’s not how it’s supposed to work with a port.
> 

Yep, see above. And it's best not to add the deps as separate ports.

Steve



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD Port: consul-0.7.1

[Steve Wills]

Ah, I see. Seems like version/version_base.go isn't overriding
version/version.go properly, so I have to patch it. I'm not sure why
that's happening right now.

Should be fixed now.

Steve

On 11/13/2016 17:43, Douglas Thrift via freebsd-ports wrote:
> Hmm,
> 
> I upgraded to 0.7.1_1 and "consul -v" is correctly showing v0.7.1, but
> now the "Build" column in the output of "consul members" is just blank.
> 
> Douglas William Thrift
> <http://douglasthrift.net/>
> 
> On 11/12/2016 3:41 PM, Steve Wills wrote:
>> Fixed, thanks for the heads up.
>>
>> Steve
>>
>> On 11/12/2016 12:29, Douglas Thrift wrote:
>>> Hello,
>>>
>>> It looks like the new update to consul 0.7.1 is reporting its version as
>>> "unknown-unknown" rather than "0.7.1". I'm guessing something changed in
>>> the upstream build process.
>>>
>>> This shows up when running "consul -v" and in the "Build" column when
>>> running "consul members".
>>>
>>> I'm guessing something changed in the way that the upstream build
>>> process determines the build version number.
>>>
>>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD Port: consul-0.7.1

[Steve Wills]

Fixed, thanks for the heads up.

Steve

On 11/12/2016 12:29, Douglas Thrift wrote:
> Hello,
> 
> It looks like the new update to consul 0.7.1 is reporting its version as
> "unknown-unknown" rather than "0.7.1". I'm guessing something changed in
> the upstream build process.
> 
> This shows up when running "consul -v" and in the "Build" column when
> running "consul members".
> 
> I'm guessing something changed in the way that the upstream build
> process determines the build version number.
> 



signature.asc
Description: OpenPGP digital signature

Re: Is there still broken lang/ruby23 ?

[Steve Wills]

Yes, I haven't looked at it yet, but if you want to take a look, I'd
welcome patches.

Steve

On 06/28/16 06:12 PM, KIRIYAMA Kazuhiko wrote:
> Hi,
> 
> Is there still broken lang/ruby23[1]. Or can build in latest
> 11.0-* ? 
> 
> [1] http://permalink.gmane.org/gmane.os.freebsd.devel.pkg-fallout/294364
> 
> ---
> KIRIYAMA Kazuhiko
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Feedback needed: www/redmine Update

[Steve Wills]

Hi,

On 06/ 6/16 12:23 PM, Steve Wills wrote:
> Hi,
> 
> On 06/ 6/16 08:10 AM, Torsten Zuehlsdorff wrote:
>> Aloha,
>>
>> The patch can be found here:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209938
>>
> 

I updated the PR with a new patch. With that, it works fine for me. I
also tested backlogs and sidebar_hide. Sidebar_hide works fine, backlogs
does not.

Steve

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

Re: Feedback needed: www/redmine Update

[Steve Wills]

Hi,

On 06/ 6/16 08:10 AM, Torsten Zuehlsdorff wrote:
> Aloha,
> 
> The patch can be found here:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209938
> 

This doesn't work for me. There are 3 issues at least, perhaps more. In
order of discovery:

The nokogiri reference from the Gemfile in redmine needs to be removed
or else you get complaints from bundler about specifying it twice, once
with version and once without.

The file www/redmine/bundler.d/rmagic.rb needs to be world readable or
the web server (in my case passenger) can't read it on startup, so
bundler bombs on that.

The Gemfile specifies jquery-rails ~> 3.1.4 but your patch specifies
www/rubygem-jquery-rails which is currently 4.1.1.


> If i read the scheming correct, 3.0 and 3.1 were also major version. But
> since i'm not a user, i'm not sure.
> 

Well, upstream may have made major changes, but in terms of version
numbers, the major version number only changed by one. :)

> This could be differ. I researched some, for example
> www/redmine-backlogs. There homepage http://www.redminebacklogs.net/
> states, that it only works with redmine 2.2 or 2.3. Since we have 2.6 in
> the ports i'm not sure, that the port really works. Maybe it does and
> will against 3.2 also.
> 
> Since i'm not using any of them, i'm not sure if i could state, that the
> ports will work correctly after the update, even if i install everyone.
> I just would not know how to long for.
> 

I don't think we can test them all. I can test backlogs and sidebar_hide
at least.

Steve

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

Re: Feedback needed: www/redmine Update

[Steve Wills]

Hi,

On 06/ 6/16 06:26 AM, Torsten Zuehlsdorff wrote:
> Hello,
> 
> i wrote an update for www/redmine. It would be very nice if some more
> people can test it, 

That's awesome, I'm glad to hear that, thanks for the work! I have an
install of redmine that I could use for testing. Where is the patch?

> since its skipping multiple major versions. The
> patch brings the port from 2.6.9 to 3.2.2.
> 

Wouldn't that just be upgrading by one major version from 2.x to 3.x?

> Also i notices some more ports related to www/redmine. Namley:
> 
> $ cd /usr/ports/ && find .  -name "*redmine*" -type d
> ./devel/rubygem-redmine_plugin_support
> ./www/redmine-backlogs
> ./www/redmine-basecamp
> ./www/redmine-http-auth
> ./www/redmine-sidebar_hide
> ./www/redmine
> ./www/rubygem-redmine_acts_as_taggable_on
> ./www/redmine-default_assign
> ./www/redmine-graphs
> ./www/redmine-issue_templates
> ./www/redmine-knowledgebase
> ./www/redmine-qa_contact
> ./www/redmine-redcarpet_formatter
> ./www/redmine-stuff_to_do
> ./www/redmine-wiki_notes
> 
> Is there anybody who uses this ports and could verify if they still work
> after the update?
> 

Do the plugins need to be updated too? Or just tested that they still
work? My install uses the sidebar_hide plugin and maybe one or two
others (can't recall right now, but will test).

Steve

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

Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains?

[Steve Wills]

Hi,

On 04/24/16 10:16 AM, Mark Millard wrote:
> 
> For all the port update activity (including ruby) I used gcc49, 
> /etc/make.conf being:
> 
> # more /etc/make.conf DEFAULT_VERSIONS+=perl5=5.22 
> WRKDIRPREFIX=/usr/obj/portswork
> WITH_DEBUG=
> WITH_DEBUG_FILES= 
> MALLOC_PRODUCTION=
> #
> #
> # For trying gcc49...
> # 
> CC=/usr/local/bin/gcc49
> CXX=/usr/local/bin/g++49 
> CPP=/usr/local/bin/cpp49
> . . . (binutils macros omitted here) . . .
> 
> 
> (I do not know if lang/gcc [or lang/gcc48] would work or not. I
> prefer a tool chain with a more modern C++ available but gcc49 is not
> yet what lang/gcc builds.)
> 
> 
> 
> I've seen notation like:
> 
> USE_GCC=4.9+
> 
> in port Makefiles. Also notation like:
> 
> .if ${ARCH} == powerpc64
> 
> and:
> 
> .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64"
> 
> 
> So may be the extra notation in the Makefile(s) in question could be 
> something like:
> 
> # clang 3.8.0 and before is still broken in various ways for powerpc and 
> powerpc64:
> .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64"
> USE_GCC=4.9+
> .endif
> 

Yep, this sounds right to me. I will test this with at least lang/ruby22
and lang/gcc6-devel when my current build finishes, or sooner if I get
impatient. :)


> I list both powerpc variants because powerpc and powerpc64 both have
> clang problems making buildworld a no-go by default and if gcc 4.2.1
> rejects a port for one it would normally also reject for the other.
> There may be other ${ARCH} values that would also be appropriate
> because they are also stuck at gcc 4.2.1 .

Makes sense.

> I do not claim to know necessary vs. sufficient status: more might be
> needed for some configurations (rpath issues? mixture of libraries
> compiled by distinct gcc's?). But I expect that the above should be
> better than being marked broken.

We'll find this out when we test! :)

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

Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains?

[Steve Wills]

So lang/gcc6-devel builds fine using gcc49 (which builds fine and isn't
currently marked broken. Can we patch the lang/gcc6-devel port so that
it uses gcc49 when building on powerpc64?

Also, which compiler are you using for building ruby?

Steve

On 04/24/16 03:19 AM, Mark Millard wrote:
> [A top-post of the results of my test build of lang/gcc6-devel using gcc49 to 
> do the build (until it switches over to xgcc). I do not have lang/gcc or 
> lang/gcc48 installed.]
> 
> lang/gcc6-devel's update built fine in my 
> powerpc64-xtoolchain-gcc/powerpc64-gcc and gcc49 environment on a powerpc64 
> PowerMac. The options were as I normally use:
> 
>> # more /var/db/ports/lang_gcc6-devel/options
>> # This file is auto-generated by 'make config'.
>> # Options for gcc6-devel-6.0.0.s20160110
>> _OPTIONS_READ=gcc6-devel-6.0.0.s20160110
>> _FILE_COMPLETE_OPTIONS_LIST=BOOTSTRAP GRAPHITE JAVA MULTILIB
>> OPTIONS_FILE_UNSET+=BOOTSTRAP
>> OPTIONS_FILE_UNSET+=GRAPHITE
>> OPTIONS_FILE_UNSET+=JAVA
>> OPTIONS_FILE_UNSET+=MULTILIB
> 
> 
> I will note that ruby is implicitly in use in my environment and it too had 
> been marked as broken for powerpc64: lang/ruby21 , lang/ruby22 , and 
> lang/ruby23 all were so marked. (So I commented those marks out.)
> 
> My build that upgraded from ruby21 to ruby22 went fine.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2016-Apr-23, at 5:21 PM, Mark Millard  wrote:
>>
>> On 2016-Apr-23, at 4:17 PM, Steve Wills  wrote:
>>>
>>> Hi,
>>>
>>> On 04/23/16 05:50 PM, Mark Millard wrote:
>>>> Recently a large block of ports (including lang/gcc6-devel) were
>>>> marked in their Makefiles with
>>>>
>>>>> BROKEN_powerpc64=   Does not build
>>>>
>>>>
>>>> Does this only apply for use of gcc/g++ 4.2.1 or specific other
>>>> verions? If so that is not the only way to have a powerpc64
>>>> environment. For example: how "official" is use of
>>>> devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and
>>>> lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)? 
>>>
>>>
>>> The intent was just that they don't build with the default config, ie,
>>> gcc 4.2.1 from base. If there are ways to make things build with other
>>> compilers, we should look at getting those changes into ports.
>>>
>>> You can find the logs of the build that I based all those changes on here:
>>>
>>> http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default&build=2016-04-02_20h57m16s
>>>
>>> Specifically the gcc6-devel one is here:
>>>
>>> http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log
>>>
>>> Though I realize now that was simply a timeout and perhaps shouldn't
>>> have been marked as broken. A few of the llvm ones timed out and I
>>> didn't mark those as broken and meant to not mark any that timed out as
>>> broken, and to go back and retry them, but didn't notice this one was a
>>> timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if it
>>> builds for you.
>>
>> Since my original note -r413919 has updated devel/gcc6-devel. So I'll end up 
>> testing that update once I get to that point.
>>
>> I'll note that the svn-ports-head entry for -r412746 lists several llvm 
>> items:
>>
>>  head/devel/llvm-cheri/Makefile
>>  head/devel/llvm-devel/Makefile
>>  head/devel/llvm33/Makefile
>>  head/devel/llvm34/Makefile
>>  head/devel/llvm38/Makefile
>>
>> But I do not build any of those normally. llvm38 likely is toolchain vintage 
>> dependent for if it builds or not. Others may be as well.
>>
>>> Also note that build was using the 2016Q2 branch, but the
>>> BROKEN_powerpc64 was committed to the main branch. Perhaps that change
>>> should be merged to the 2016Q2 branch.
>>>
>>> Anyway, I'm currently retrying the build, after fixing pixman and
>>> merging that to the 2016Q2 and then locally patching in the
>>> BROKEN_powerpc64 things into my local tree. You can see the progress of
>>> that here:
>>>
>>> http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default&build=2016-04-21_17h38m55s
>>>
>>>
>>>> Can broken be marked for only specific tool chains?
>>>>
>>>
>>> Not trivially, but

Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains?

[Steve Wills]

Hi,

On 04/23/16 05:50 PM, Mark Millard wrote:
> Recently a large block of ports (including lang/gcc6-devel) were
> marked in their Makefiles with
> 
>> BROKEN_powerpc64=   Does not build
> 
> 
> Does this only apply for use of gcc/g++ 4.2.1 or specific other
> verions? If so that is not the only way to have a powerpc64
> environment. For example: how "official" is use of
> devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and
> lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)? 


The intent was just that they don't build with the default config, ie,
gcc 4.2.1 from base. If there are ways to make things build with other
compilers, we should look at getting those changes into ports.

You can find the logs of the build that I based all those changes on here:

http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default&build=2016-04-02_20h57m16s

Specifically the gcc6-devel one is here:

http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log

Though I realize now that was simply a timeout and perhaps shouldn't
have been marked as broken. A few of the llvm ones timed out and I
didn't mark those as broken and meant to not mark any that timed out as
broken, and to go back and retry them, but didn't notice this one was a
timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if it
builds for you.

Also note that build was using the 2016Q2 branch, but the
BROKEN_powerpc64 was committed to the main branch. Perhaps that change
should be merged to the 2016Q2 branch.

Anyway, I'm currently retrying the build, after fixing pixman and
merging that to the 2016Q2 and then locally patching in the
BROKEN_powerpc64 things into my local tree. You can see the progress of
that here:

http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default&build=2016-04-21_17h38m55s


> Can broken be marked for only specific tool chains?
> 

Not trivially, but it's probably doable somehow.

>> # freebsd-version -ku 11.0-CURRENT 11.0-CURRENT # uname -aKU 
>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #29 r297769M:
>> Sat Apr  9 22:22:19 PDT 2016
>> root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG
>> powerpc 1100105 1100105
> 
> For the rest of this note I'll focus on lang/gcc-devel since I happen
> to build and install it.
> 
>> # pkg info '*gcc*' gcc49-4.9.4.s20160406 
>> gcc6-devel-6.0.0.s20160410 powerpc64-gcc-5.3.0 
>> powerpc64-xtoolchain-gcc-0.1
> 
> gcc6-devel-6.0.0.s20160410 was built from -r413230 svn source on the
> that same old PowerMac. -r413188 is the prior lang/gcc-devel check in
> before being marked broken for powerpc64. For how I build it was not
> broken at the time.
> 
> I historically use devel/powerpc64-xtoolchain-gcc (so
> devel/powerpc64-gcc as well) for the so-called "cross build" stages
> of buildworld/buildkernel (11.0-CURRENT). (I also do true cross
> builds for TARGET_ARCH=powerpc64 from an amd64 context sometimes.)
> 
> gcc 4.2.1 is not present before, during, or after on the old
> PowerMac. I do build clang and various related materials but do not
> use clang for buildworld/buildkernel related activity. I experiment
> with using clang for other things at times.
> 
> I historically use lang/gcc49 on the old PowerMac for:
> 
> A) building devel/powerpc64-gcc (not the only way to try to build
> it) B) the "host" stages of buildworld/buildkernel (11.0-CURRENT) C)
> building lang/gcc6-devel (not the only way to try to build it)
> 
> [I do not have lang/gcc5 built/installed only because it and
> devel/powerpc64-gcc have file conflicts when they are based on the
> same gcc version. Getting devel/powerpc64-gcc to build and install on
> a powerpc64 requires some workarounds because it is not a true cross
> compile environment and some file names are odd for self-hosted and
> so not found during staging's copy activities.]
> 
> [I do build the system's clang 3.8.0 but do not use it other than for
> exploring/checking its current powerpc64 FreeBSD limitations. It does
> work for various things but not everything. Those experiments do not
> include buildworld or buildkernel. For example: clang 3.8.0 targeting
> powerpc64 can not build libstand due to lack of software floating
> point support. C++ exception handling built via clang for powerpc64
> is messed up as well.]
> 
> 

It would be nice if we could fix those things and get powerpc(64) built
with clang.

> 
> I have started a powerpc64 self-hosted buildworld/buildkernel for an
> update to 11.0-CURRENT -r298518 in preparation for then updating my
> ports to -r413907 or so.
> 
> My intent is to comment out the BROKEN_powerpc64 line in
> lang/gcc6-devel/Makefile and see if lang/gcc6-devel still (re-)builds
> once everything else is up to date.
> 
> But the builds involved take many hours so I'll likely not have a
> result to report until tomorrow (or later).
> 
> 
> S

Swift programming language

[Steve Wills]

Hi,

I've been working on porting the Swift programming language. There's a
port here:

https://people.freebsd.org/~swills/swift.shar

if folks would like to test it before I commit. The swiftpm component
hasn't been ported yet, so you can't build native executables. Any
feedback would be appreciated.

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

default ruby version

[Steve Wills]

Hi,

Just FYI, baring any objections or major issues coming up, I plan to
make Ruby 2.2 the default Ruby in the ports tree on March 1.

Puppet users in particular probably want to migrate to sysutils/puppet4
or work on testing some sort of patch that makes puppet 3.x work with
ruby 2.2 before then.

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

Re: Rubygem .js files fubar?

[Steve Wills]

Hi,

On 01/17/16 10:29 AM, Matthew Seaman wrote:
> On 17/01/2016 06:33, Steve Wills wrote:
>> On 01/17/16 12:57 AM, Steve Wills wrote:
>>>
>>> As for why the original file isn't deleted, I'm not sure. I don't see
>>> this in my local tree, but I have some changes that may be masking it.
>>>
>>
>> Oh, I wasn't seeing it because I was testing with Ruby 2.1 and it only
>> happens with Ruby 2.2 (and presumably 2.3). I'll look into that.
> 
> Yes, this is with ruby-2.2.x -- sorry, should have mentioned that.
> 
> There seems to be a lot of duplicated files installed, some in both
> compressed and uncompressed forms:
> 

This is a gem issue really. It enables running "gem server" and getting
a web server with browse-able docs for all your gems. The fact that it
duplicates some of the bits is a side effect of how the templates work.
Some folks find it nice for development. It's not so useful for servers.
You could complain to upstream. You could also add this to make.conf:

.if ${.CURDIR:M*/*rubygem-*}
OPTIONS_UNSET=  DOCS
.endif

A patch to make DOCS default to off for all gems would be interesting.

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

Re: Rubygem .js files fubar?

[Steve Wills]

On 01/17/16 12:57 AM, Steve Wills wrote:
> 
> As for why the original file isn't deleted, I'm not sure. I don't see
> this in my local tree, but I have some changes that may be masking it.
> 

Oh, I wasn't seeing it because I was testing with Ruby 2.1 and it only
happens with Ruby 2.2 (and presumably 2.3). I'll look into that.

Steve

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

Re: Rubygem .js files fubar?

[Steve Wills]

Hi,

On 01/12/16 06:11 AM, Matthew Seaman wrote:
> On 01/11/16 16:41, Matthew Seaman wrote:
>> lucid-nonsense:...svn2git-2.3.2/rdoc/js:% ls -la
>> total 140
>> drwxr-xr-x  2 matthew  wheel576 Jan 11 16:20 ./
>> drwxr-xr-x  7 matthew  wheel640 Jan 11 13:01 ../
>> -rw-r--r--  1 matthew  wheel   4666 Jan 11 13:01 darkfish.js
>> -rw-r--r--  1 matthew  wheel  91669 Jan 11 13:01 jquery.js
>> -rw-r--r--  1 matthew  wheel   3663 Jan 11 13:01 navigation.js
>> -rw-r--r--  1 matthew  wheel   1127 Jan 11 13:01 navigation.js.gz
>> -rw-r--r--  1 matthew  wheel   2992 Jan 11 13:01 search.js
>> -rw-r--r--  1 matthew  wheel   3310 Jan 11 13:01 search_index.js
>> -rw-r--r--  1 matthew  wheel920 Jan 11 13:01 search_index.js.gz
>> -rw-r--r--  1 matthew  wheel   6603 Jan 11 13:01 searcher.js
>> -rw-r--r--  1 matthew  wheel   1791 Jan 11 13:01 searcher.js.gz
>>
>> As far as I can tell these are boilerplate installed by something to do
>> with rdoc.  A quick find(1) over my /usr/local/lib/ruby shows this same
>> pattern in a number of installed rubygems.
>>
>> What's going on here?
>>
>> This makes poudriere sad, although the error message doesn't say
>> anything about "I can't decompress this, because there's already a
>> decompressed copy in the way" instead claiming the .gz files refer to
>> some path under staging.
> 
> So, it seems this affects every rubygem port -- there's compressed and
> uncompressed copies of the same files installed for each and every gem.
>  And they all fail 'poudriere testport'.

I can't recall all the details as it's been a while since I looked at
this, but basically the original file name is getting stored in the .gz
file (see gzip's -n flag). Fixing this will take patching ruby's
ext/zlib/zlib.c. (rubygem is just calling that.) I've looked at patching
this, but not completed it. I'll try to work on it some more.

As for why the original file isn't deleted, I'm not sure. I don't see
this in my local tree, but I have some changes that may be masking it.

Poudriere is just grepping files for references to the wrkdir path and
finding them.

> Given that, I think I'll commit rubygem-svn2git as it seems to be
> working at least as well as any other rubygem port.
> 

This is fine.

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

Re: poudriere, Go and networking

[Steve Wills]

Hi,

On 12/11/2015 10:55, Malcolm Matalka wrote:
> Piotr Florczyk  writes:
> 
>> W dniu 11.12.2015 o 15:36, Kurt Jaeger pisze:
>>> Hi!
>>>
 Recently I had to package couple of programs written in Go and godep is
 becoming the standard for dependency tracking in Go projects.
 For example I currently had to package telegraf. Here is the thing. 
 Poudriere
 disables networking after fetch phase and I don't know before extract
 phase what dependencies are inside.
>>>
>>> We recently upgraded maven, the java-world 'make and godep' and all
>>> the ports that need maven to build have the same problem, see:
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188110#c37
>>>

I'll just note here that Go at least downloads source, where I believe
Maven downloads pre-compiled jars (correct me if I'm wrong), so
comparing them isn't completely apples to apples.

Perhaps in the maven case having a port for each dep does make sense.

At the moment, I see quite a few ports with pre-compiled jars in their
distinfo.

 So here is the question: would it be possible to have networking
 enabled during extract phase ?
 Or maybe there is another solution (some flag in ports maybe that
 I'm missing ?)

I don't think packaging each go dep separately is a good idea, though
I've noticed the Fedora project does it.

Some ports of go apps do list each dep as a separate dist file and this
seems the best way to me. But I can understand it's too much work for
some ports and it does increase the work a great deal.

Have you considered using "godep restore" and making your own dist file?

This has the advantage of being quick, easy, reliable and arguably
correct as it is just doing what upstream expects a developer to do.
It's still better than just packaging up the compiled binary that the
upstream distributes and preserves the local build and lets users
inspect source easily if they want. The downside is wasted disk space
for distfiles, but it's not a huge amount as go projects aren't
typically very large source bases.

>>>
>>> I think we need some fancy fetch target per distfile which basically
>>> uses technology-dependend (maven, godep, etc) ways to trigger
>>> the 'fetch' during the fetch-phase. Probably some sort
>>> of base-fetch vrs. dep-fetch ?
>>>
>> New target might not be needed but I think this is good idea. Altough it 
>> does not solve my problem with poudriere. In my case, the soonest I
>> can fetch dependencies is in post-extract target. So if poudriere didn't cut 
>> off networking at this stage we wouldn't need any changes and
>> every one would be happy.
> 
> This sounds like it would be a security hole to let a package download
> extra things that the FreeBSD package system does not know about and
> cannot validate.
> 

Yes, this is not something we want in general. Using "godep restore" and
making your own distfile at least prevents the deps from changing later.
Though "godep restore" should be using the git checksums and comparing
those, I don't think "go get" does. So "godep restore and making your
distfile is more secure.

>> Even if we come up with proper solution it will require cutting off network 
>> at some later stage than post-extract. In my opinion we might
>> aswell move it to that point right now.
> 
> Perhaps you should make a tool which takes a go project as input and a
> FreeBSD package as output?
> 

This is an interesting idea. It's a bit of work though and you're be
re-implementing pkg in go and chasing any changes it made. And I'm not
sure how it would integrate with ports.

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

Re: lang/gcc48 fails to build [on HEAD]

[Steve Wills]

On 11/27/2015 08:42, Baptiste Daroussin wrote:
> On Fri, Nov 27, 2015 at 02:24:05PM +0100, Tijl Coosemans wrote:
>> On Fri, 27 Nov 2015 13:59:54 +0100 Baptiste Daroussin  
>> wrote:
>>> On Tue, Nov 10, 2015 at 07:23:40PM +0100, Rainer Hurling wrote:
 I think I found the problem.

 In my initial mail of this thread, I reported, that after upgrading
 Freebsd 11.0-CURRENT to r290538 (including locale and localedef updates)
 I am not able to build lang/gccXX any more. All I get are errors like
 that in usr/ports/lang/gccXX/work/build/gcc:

 
 In file included from .././../gcc-4.8.5/gcc/genflags.c:26:
 In file included from ./tm.h:16:
 ./options.h:4293:3: error: redefinition of enumerator 'OPT_C'
   OPT_C = 129,   /* -C */
   ^
 

 After more than 20 of them the build stops with
 fatal error: too many errors emitted, stopping now [-ferror-limit=]
 20 errors generated.


 This is with locale for Germany:
 LANG=de_DE.UTF-8
 LC_CTYPE="de_DE.UTF-8"
 LC_COLLATE="de_DE.UTF-8"
 LC_TIME="de_DE.UTF-8"
 LC_NUMERIC="de_DE.UTF-8"
 LC_MONETARY="de_DE.UTF-8"
 LC_MESSAGES="de_DE.UTF-8"
 LC_ALL=


 If I use 'LC_COLLATE="C"' for the build, the build works fine again:

 cd /usr/ports/lang/gcc48
 env LC_COLLATE="C" make
 ...


 So it seems, that something with the new 'locale' code in base of HEAD
 is not working as expected here? (At least for other locales than US?)

 I added bapt@, because he is the author introducing the new code into HEAD.

 Hope, my explanations are clear enough to get the problem. Please feel
 free to ask for more information, if needed.
>>>
>>> Your explanations are good, sorry for the delay for my reply I will look
>>> into it.
>>
>> I ran into this with lang/sdcc* which includes cpp from gcc.  At some
>> point the build runs an awk script (opt-gather.awk) that collects command
>> line options defined in *.opt files, sorts them and then puts them into
>> a C array.  The problem seems to be that FreeBSD awk takes collation into
>> account when sorting strings while GNU awk doesn't.  POSIX says that
>> FreeBSD is correct, so I was thinking of adding something like this to
>> bsd.port.mk:
>>
>> USE_LOCALE?= C
>> LANG=${USE_LOCALE}
>> LC_ALL=  ${USE_LOCALE}
>> .export LANG LC_ALL
>>
>> This gives a consistent locale environment for port builds.  Some ports
>> already set LANG or LC_ALL.  That would have to be reviewed and I haven't
>> had time for that yet.
> 
> yeah we should imho to that. The same issue appears with GNU tr which also
> do not take in account collation (IIRC) while ours do.

FWIW, I ran into this building devel/arm-none-eabi-gcc too. Setting
LC_ALL and LANG fixed it for me. Also, Mk/bsd.ruby.mk got something
similar for gem builds a while ago, though it uses en_US.UTF-8 for
LC_ALL and LC_CTYPE=UTF-8. As I recall, this was due to difference in
generated docs based on language. We may want to remove the bits from
Mk/bsd.ruby.mk if we add it globally. Also, I wonder what impacts this
will have beyond fixing builds, such as docs, plist differences or baked
in defaults, etc.

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

Re: FreeBSD Port: syncthing-discosrv-0.0.0.2015092201

[Steve Wills]

Hi,

Yeah, I will try to do that this weekend. Of course, I wanted to do it
last weekend, but was busy. Thanks for your patience. If you have a
patch, I'll take a look.

Steve

On 11/05/2015 15:16, Sean wrote:
> Hi swills
> 
> Now that syncthing v0.12.0 is out any change you can update the port?
> syncthing-discosrv-0.0.0.2015092201 port does not work.
>>From https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203987#c1
> 
> wraul 2015-10-23 16:35:55 UTC
> Two things have happened to Syncthing and discosrv.
> 
> 1. discosrv have changed to use an in memory database by default.
> This have deprecated the --db-dir command line argument and it should be 
> removed from the rc-script.
> It should also be possible to continue using a file backed database by 
> specifying a argument like -db-dsn="file://path/to/db"
> 
> 2. The protocol with which Syncthing and discosrv communicates have changed 
> to use HTTPS.
> This makes it necessary to specify a private key and a certificate using the 
> --key and --cert arguments when launching discosrv.
> 
> These two changes results in discosrv not starting using the current 
> rc-script.
> 
> The change in protocol also makes the version of Syncthing available in the 
> ports tree incompatible with the version of discosrv.
> Syncthing uses the new protocol from version 0.12 and forward.
> 
> 
> Thank you
> 
> -Sean Choquette
> [http://www.slcasa.com/base/Sigs/drawween.png]
> 
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Firefox + SeaMonkey (gecko browsers) instant crash on some web pages

[Steve Wills]

Hi,

On 10/13/2015 09:21, Miroslav Lachman wrote:
> 
> Hi Steve,
> 
> A "skia" fixed crashes on mapy.cz and seznam.cz but from this time I got
> random crashes of Firefox and Seamonkey (both with "skia"). Until this
> change Seamonkey was happily runnig for a few weeks (system uptime 20
> days). I have more than 5 crashes today.
> Is there a way to track this issue or some other way to fix mapy.cz and
> seznam.cz crashes without bringing this instability?

I guess we need a debug version of firefox built and a copy of the core
dump from the crash. I was going to do that but haven't made time.

In the mean time, you might consider having two profiles, one where you
use skia for mapy.cz and seznam.cz and the other one default. Not ideal,
but as a temporary workaround that lets you use both sites until the
issue is solved.

Since SeaMonkey hasn't been updated, I'm wonder if the issue existed in
the older version of Firefox too.

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

Re: Firefox + SeaMonkey (gecko browsers) instant crash on some web pages

[Steve Wills]

Hi,

On 10/09/2015 03:38, Miroslav Lachman wrote:
> Steve Wills wrote on 10/08/2015 21:55:
>> Just to test, try setting gfx.canvas.azure.backends and
>> gfx.content.azure.backends to skia in about:config and see if it still
>> crashes.
> 
> Hi Steve,
> 
> I changed both from cairo to skia. Firefox crashed again on www.mapy.cz
> but on next start www.mapy.cz and www.seznam.cz works normally. So this
> can be a workaround.
> 
> When I entered www.mapy.cz this messages were printed on console but FF
> didn't crash
> 

Yes, you have to restart for it to take effect. BTW, I think only
changing gfx.canvas.azure.backends is necessary,
gfx.content.azure.backends can remain at default setting.


>> firefox
> 
> (process:8936): GLib-CRITICAL **: g_slice_set_config: assertion
> 'sys_page_size == 0' failed
> Fontconfig warning: "local.conf", line 1093: saw number, expected matrix
> libGL error: Calling driver entry point failed
> libGL error: reverting to software direct rendering
> libGL error: failed to load driver: vboxvideo
> ATTENTION: default value of option force_s3tc_enable overridden by
> environment.

Yeah, GL stuff isn't going to get hardware acceleration in vbox, no
surprise there. Should be fine though, I think.

> Can I use "skia" or does it have some negative impact? (I don't know
> what these two settings mean)

The only negative impact could be slower performance in some cases. But
it does provide better performance in other cases, so it depends. And of
course, not crashing is a benefit. :)

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

Re: Firefox + SeaMonkey (gecko browsers) instant crash on some web pages

[Steve Wills]

Just to test, try setting gfx.canvas.azure.backends and
gfx.content.azure.backends to skia in about:config and see if it still
crashes.

Steve

On 10/08/2015 11:53, Steve Wills wrote:
> Hi,
> 
> On 10/08/2015 10:25, Miroslav Lachman wrote:
>> Walter Schwarzenfeld wrote on 10/07/2015 00:35:
>>> Firefox 41.0.1 is out, give it a try.
>>
>>
>>
>> I tried it in VirtualBox - same crash as with older versions.
>>
>> In real host I got this (started ff from command line)
>>
>>> firefox
>>
>> (process:77500): GLib-CRITICAL **: g_slice_set_config: assertion
>> 'sys_page_size == 0' failed
>> Assertion failed: (!scaled_font->cache_frozen), function
>> _cairo_scaled_glyph_page_destroy, file cairo-scaled-font.c, line 459.
>> Abort
>>
>>
>> In VirtualBox on FreeBSD 10.2 with Firefox 41
>>
>>> firefox
>>
>> (process:5471): GLib-CRITICAL **: g_slice_set_config: assertion
>> 'sys_page_size == 0' failed
>> Fontconfig warning: "local.conf", line 1093: saw number, expected matrix
>> libGL error: Calling driver entry point failed
>> libGL error: reverting to software direct rendering
>> libGL error: failed to load driver: vboxvideo
>> ATTENTION: default value of option force_s3tc_enable overridden by
>> environment.
>> Assertion failed: (!scaled_font->cache_frozen), function
>> _cairo_scaled_glyph_page_destroy, file cairo-scaled-font.c, line 459.
>> Redirecting call to abort() to mozalloc_abort
>>
>> Segmentation fault
>>
>>
>> First line with GLib-CRITICAL is shown on Firefox startup and is not
>> related to crash on www.mapy.cz
>>
>> The "cairo scaled" error is something I saw in the past with some other
>> software, like GIMP or Avidemux. GIMP and Avidemux are not able to even
>> start on my computer if I have Helvetica as system default font.
>> Firefox and Seamonkey works fine until I need to open www.seznam.cz,
>> www.mapy.cz and other websites from this company.
>>
>> I tried it on host with differen font (Arial) and Firefox crashed again.
>>
>>> firefox
>>
>> (process:79336): GLib-CRITICAL **: g_slice_set_config: assertion
>> 'sys_page_size == 0' failed
>> Assertion failed: (!scaled_font->cache_frozen), function
>> _cairo_scaled_glyph_page_destroy, file cairo-scaled-font.c, line 459.
>> Redirecting call to abort() to mozalloc_abort
>>
>>
>> ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv
>>
>> Assertion failed: (!scaled_font->cache_frozen), function
>> _cairo_scaled_glyph_page_destroy, file cairo-scaled-font.c, line 459.
>> Abort
>>
>> So the crash is not related to choosen default font.
>>
> 
> I was able to trigger the issue on www.seznam.cz only. I'll look into as
> much as I can.
> 
> Steve
> 
> ___
> freebsd-ge...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
> To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"
> 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Firefox + SeaMonkey (gecko browsers) instant crash on some web pages

[Steve Wills]

Hi,

On 10/08/2015 10:25, Miroslav Lachman wrote:
> Walter Schwarzenfeld wrote on 10/07/2015 00:35:
>> Firefox 41.0.1 is out, give it a try.
> 
> 
> 
> I tried it in VirtualBox - same crash as with older versions.
> 
> In real host I got this (started ff from command line)
> 
>> firefox
> 
> (process:77500): GLib-CRITICAL **: g_slice_set_config: assertion
> 'sys_page_size == 0' failed
> Assertion failed: (!scaled_font->cache_frozen), function
> _cairo_scaled_glyph_page_destroy, file cairo-scaled-font.c, line 459.
> Abort
> 
> 
> In VirtualBox on FreeBSD 10.2 with Firefox 41
> 
>> firefox
> 
> (process:5471): GLib-CRITICAL **: g_slice_set_config: assertion
> 'sys_page_size == 0' failed
> Fontconfig warning: "local.conf", line 1093: saw number, expected matrix
> libGL error: Calling driver entry point failed
> libGL error: reverting to software direct rendering
> libGL error: failed to load driver: vboxvideo
> ATTENTION: default value of option force_s3tc_enable overridden by
> environment.
> Assertion failed: (!scaled_font->cache_frozen), function
> _cairo_scaled_glyph_page_destroy, file cairo-scaled-font.c, line 459.
> Redirecting call to abort() to mozalloc_abort
> 
> Segmentation fault
> 
> 
> First line with GLib-CRITICAL is shown on Firefox startup and is not
> related to crash on www.mapy.cz
> 
> The "cairo scaled" error is something I saw in the past with some other
> software, like GIMP or Avidemux. GIMP and Avidemux are not able to even
> start on my computer if I have Helvetica as system default font.
> Firefox and Seamonkey works fine until I need to open www.seznam.cz,
> www.mapy.cz and other websites from this company.
> 
> I tried it on host with differen font (Arial) and Firefox crashed again.
> 
>> firefox
> 
> (process:79336): GLib-CRITICAL **: g_slice_set_config: assertion
> 'sys_page_size == 0' failed
> Assertion failed: (!scaled_font->cache_frozen), function
> _cairo_scaled_glyph_page_destroy, file cairo-scaled-font.c, line 459.
> Redirecting call to abort() to mozalloc_abort
> 
> 
> ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv
> 
> Assertion failed: (!scaled_font->cache_frozen), function
> _cairo_scaled_glyph_page_destroy, file cairo-scaled-font.c, line 459.
> Abort
> 
> So the crash is not related to choosen default font.
> 

I was able to trigger the issue on www.seznam.cz only. I'll look into as
much as I can.

Steve

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

Re: FreeBSD Port: ruby20-2.0.0.645,1 - reported as vulnerable while it isn't ?

[Steve Wills]

Hi,

Did you build your own ports where ruby 2.0 was default? I see the package name
here is ruby-2.0.0.645,1, not ruby20-2.0.0.645,1. The entries in vuxml look
like this:

 3326 ruby20
 3327 2.0.0.645,1

...

 3330 ruby
 3331 2.1.6,1

So I think maybe it's matching the second entry and then looking for a ruby
version 2.1.6,1 or newer. Not sure what the right solution is for this right
now.

Steve


On Sun, Jun 21, 2015 at 08:43:33AM +0200, Ing. Břetislav Kubesa wrote:
> Hi,
> 
> already for longer time while updating to 2.0.0.645,1 version, I'm 
> getting message that it's vulnerable, but I think it's not the case as 
> vulnerable are ruby20 < 2.0.0.645,1 (but it's not ruby20 <= 2.0.0.645,1).
> However I'm not sure where to report it for checking, so I hope it's the 
> right place here.
> 
> Thank you.
> 
> 
> --->  Upgrading 'ruby-2.0.0.643_1,1' to 'ruby-2.0.0.645,1' (lang/ruby20)
> --->  Building '/usr/ports/lang/ruby20'
> ===>  Cleaning for ruby-2.0.0.645,1
> ===>  ruby-2.0.0.645,1 has known vulnerabilities:
> ruby-2.0.0.645,1 is vulnerable:
> Ruby -- OpenSSL Hostname Verification Vulnerability
> CVE: CVE-2015-1855
> WWW: 
> http://vuxml.FreeBSD.org/freebsd/d4379f59-3e9b-49eb-933b-61de4d0b0fdb.html
> 
> Best regards,
> Bretislav Kubesa
> ___
> 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"


pgpq4JiPYBMMf.pgp
Description: PGP signature

Re: proper DOXYGEN option default value

[Steve Wills]

On Wed, Mar 04, 2015 at 02:41:48PM -0800, Don Lewis wrote:
> I maintain a number of ports that use doxygen to generate their
> documentation.  They all list DOXYGEN in OPTIONS_DEFAULT so that
> the packages will include documentation.
> 
> I recently received a PR for one of those ports that mentioned that most
> users don't require the documentation and pointed out that anyone
> building the port will find it is very painful because of the amount of
> time it takes to build doxygen and all of its dependencies (primarily
> all the TeX stuff).
> 
> It's been my experience that there is enough churn in the dependencies
> that the whole mess needs to get rebuilt fairly frequently.
> 
> As I see it, the pros and cons of listing DOXYGEN in OPTIONS_DEFAULT
> are:
>   Pros:
> * Users who need the documentation can use the binary packages if
>   they desire
> * This option gets regular exercise on the build cluster
>   Cons:
>   * A bit of extra load on the ports build cluster to install
> doxygen and its dependencies as a BUILD_DEPENDS for each
> supported OS version and architecture
>   * The packages are a bit larger
>   * A bit more space is consumed on the user's machine because
> documentation is installed, even if they don't need it
>   * Users building from ports have to build and install doxygen
> and it's dependencies unless they take measures to avoid it,
> either by disabling the option for each port or adding
> OPTIONS_UNSET=DOXYGEN to their /etc/make.conf to do this
> globally
> 
> The pros and cons of removing DOXYGEN from OPTIONS_DEFAULT:
>   Pros:
>  * Less load on the ports build cluster
>  * Smaller packages
>  * Less space consumed on most user machines
>  * Users building from ports who do not need the documentation don't
>pay the doxygen penalty without taking any special measures
>   Cons:
>  * Anyone who does need the documentation has to build from the
>port and pay the cost of building and installing doxygen and its
>dependencies.
>  * The DOXYGEN option would not get regular testing and could be
>subject to bit rot.
> 
> Ideally, the documentation could be built and packaged separately.  It
> could even be NO_ARCH.   Unfortunately, at this time this would require
> adding a bunch of new ports just for the documentation.
> 
> Since these ports only generate HTML documentation, it might be helpful
> to have a doxygen-lite port that has GRAPHVIZ and LATEX disabled, and
> use that as a BUILD_DEPENDS.  That introduces the problem of conflicts
> between doxygen and doxygen-lite if someone who builds from ports needs
> the full featured doxygen for other purposes.
> 
> Since we have neither of the above, should I leave my ports as-is, or
> should I disable DOXYGEN by default?

Personally I would tend to lean towards leaving DOXYGEN off by default,
especially if there is other accompanying documentation. This is the case for
lang/ruby* for example.

But beward that this may mean it is more likely that the DOXYGEN parts of the
plist may become outdated when the doxygen port is updated. So keep testing
that option.

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: rubygems not working with ruby 2.2?

[Steve Wills]

Hi,

Yep, I'm aware, there's an update to devel/ruby-gems pending, see:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197083

Steve

On Thu, Mar 05, 2015 at 09:25:43AM +, Koichiro IWAO wrote:
> Reproduced in clean environment.
> 
> I think devel/ruby-gems is too old and needs updating.
> ports version is 1.8.30 and the latest rubygems release is 2.4.6[1].
> 
> [1] https://github.com/rubygems/rubygems/releases
> 
> # confirm default ruby version is set to 2.2
> grep DEFAULT_VERSIONS /etc/make.conf
> DEFAULT_VERSIONS= ruby=2.2 perl5=5.20
> 
> # remove all pkgs
> pkg remove -fa
> 
> # update ports tree
> portsnap fetch update
> 
> # install ruby and some rubygem- ports
> make -C /usr/ports/lang/ruby22
> make -C /usr/ports/devel/rubygem-rake
> (snip)
> ===>   rubygem-rake-10.4.2 depends on file: /usr/local/bin/gem22 - found
> ===>   rubygem-rake-10.4.2 depends on file: /usr/local/bin/ruby22 - 
> found
> ===>  Configuring for rubygem-rake-10.4.2
> ===>  Building for rubygem-rake-10.4.2
> /usr/local/lib/ruby/site_ruby/2.2/rubygems/specification.rb:1960:in 
> `block (2 levels) in to_yaml': stack level too deep (SystemStackError)
>   from /usr/local/lib/ruby/2.2/psych/coder.rb:36:in `map'
>   from 
> /usr/local/lib/ruby/site_ruby/2.2/rubygems/specification.rb:1959:in 
> `block in to_yaml'
>   from /usr/local/lib/ruby/2.2/psych/deprecated.rb:19:in `call'
>   from /usr/local/lib/ruby/2.2/psych/deprecated.rb:19:in `block in 
> quick_emit'
>   from 
> /usr/local/lib/ruby/site_ruby/2.2/rubygems/specification.rb:1960:in 
> `block (2 levels) in to_yaml'
>   from /usr/local/lib/ruby/2.2/psych/coder.rb:36:in `map'
>   from 
> /usr/local/lib/ruby/site_ruby/2.2/rubygems/specification.rb:1959:in 
> `block in to_yaml'
>   from /usr/local/lib/ruby/2.2/psych/deprecated.rb:19:in `call'
>... 9619 levels...
>   from 
> /usr/local/lib/ruby/site_ruby/2.2/rubygems/command_manager.rb:147:in 
> `process_args'
>   from 
> /usr/local/lib/ruby/site_ruby/2.2/rubygems/command_manager.rb:117:in 
> `run'
>   from /usr/local/lib/ruby/site_ruby/2.2/rubygems/gem_runner.rb:65:in 
> `run'
>   from /usr/local/bin/gem22:30:in `'
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure 
> to
> the maintainer.
> *** Error code 1
> 
> -- 
> `whois vmeta.jp | nkf -w`
> meta 
> ___
> freebsd-r...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ruby
> To unsubscribe, send any mail to "freebsd-ruby-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"

ruby-gems update to 2.4.5

[Steve Wills]

Hi,

I hope to soon update devel/ruby-gems to the latest version, 2.4.5, after far
too long at the ancient 1.8.x. There is a review here:

https://reviews.freebsd.org/D1678

though only those with an @FreeBSD.org email address may currently sign up and
comment on the review. There's also a PR in bugzilla:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197083

for the exp-run. The diff can be found in either:

https://reviews.freebsd.org/D1678?download=true

or

https://bugs.freebsd.org/bugzilla/attachment.cgi?id=152148&action=diff&context=patch&collapsed=&headers=1&format=raw

I urge all users of ports Ruby to please download and test this locally. It's a
big change.

It's long overdue so waiting a bit longer if some issue is found isn't a
problem, but on the other hand I'm rather happy to finally have it all working
and I'd rather get it committed ASAP so that the many ports that need changing
to make it work don't end up needing further work and delaying it even more.

Thanks,
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: FreeBSD Port: ruby21-2.1.3_1,1

[Steve Wills]

On Sat, Nov 08, 2014 at 03:35:26PM +, Steve Wills wrote:
> On Fri, Nov 07, 2014 at 06:41:40PM -0700, Carol Deihl wrote:
> > Hello,
> > 
> > I just installed ruby21-2.1.3_1,1 with the DEBUG option *unset*,
> > and when ruby21 is invoked, it prints out:
> > 
> > WARNING: number of probes fixed does not match the number of defined probes 
> > (9 != 50, respectively)
> > WARNING: some probes might not fire or your program might crash
> > 
> > I haven't used dtrace yet and don't know much about it,
> > but I discovered that if I re-installed the port with DEBUG turned on 
> > (*set*),
> > then the warning messages aren't printed.
> > 
> > I'm guessing that the probes.d file in the ruby source arranges to install 
> > some probes
> > at runtime in some routines that don't get compiled into ruby if DEBUG is 
> > off.
> 
> What version of FreeBSD are you using? Because of a typo in the port, the
> dtrace stuff would only be enabled on 11-CURRENT, so I'm guessing 11-CURRENT?
> What rev? This should be fixed by r271413, I think.
> 

Oh wait, I was misremembering, you might be on a different revision. Perhaps
the dtrace option should just be disabled for anything that isn't CURRENT.

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: FreeBSD Port: ruby21-2.1.3_1,1

[Steve Wills]

On Fri, Nov 07, 2014 at 06:41:40PM -0700, Carol Deihl wrote:
> Hello,
> 
> I just installed ruby21-2.1.3_1,1 with the DEBUG option *unset*,
> and when ruby21 is invoked, it prints out:
> 
> WARNING: number of probes fixed does not match the number of defined probes 
> (9 != 50, respectively)
> WARNING: some probes might not fire or your program might crash
> 
> I haven't used dtrace yet and don't know much about it,
> but I discovered that if I re-installed the port with DEBUG turned on (*set*),
> then the warning messages aren't printed.
> 
> I'm guessing that the probes.d file in the ruby source arranges to install 
> some probes
> at runtime in some routines that don't get compiled into ruby if DEBUG is off.

What version of FreeBSD are you using? Because of a typo in the port, the
dtrace stuff would only be enabled on 11-CURRENT, so I'm guessing 11-CURRENT?
What rev? This should be fixed by r271413, I think.

> Is it appropriate to just tell you about this? Should I file a bug report
> someplace else?

Yeah, that's fine, but a bug report wouldn't hurt so it doesn't get lost, see:

http://bugs.freebsd.org/bugzilla/

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: Can't build ruby20 on -current: it doesn't honor WITHOUT_CDDL=yes

[Steve Wills]

On Tue, Nov 04, 2014 at 05:41:31AM +0300, Andrey Chernov wrote:
> On 30.10.2014 18:15, Steve Wills wrote:
> > The checks for OS version weren't meant to detect presence of dtrace, they 
> > were
> > meant to detect presence of dtrace with usable USDT. Unfortunately, 
> > presence of
> > /usr/sbin/dtrace doesn't necessarily mean USDT works. So, both checks need 
> > to
> > be there. I'll take a look when I can, but if someone else gets there first,
> > great.
> 
> Do you approve the patch attached?

Yeah, that looks fine.

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: Can't build ruby20 on -current: it doesn't honor WITHOUT_CDDL=yes

[Steve Wills]

On Thu, Oct 30, 2014 at 01:26:02PM +0300, Andrey Chernov wrote:
> On 30.10.2014 13:17, Baptiste Daroussin wrote:
> > On Thu, Oct 30, 2014 at 01:11:33PM +0300, Andrey Chernov wrote:
> >> Hi.
> >> I disable zfs and dtrace on my machine using WITHOUT_CDDL=yes in
> >> /etc/src.conf
> >> ryby20 port throw this error:
> >> ...
> >> checking for valgrind/memcheck.h... no
> >> checking for strip... strip
> >> configure: error: dtrace(1) is missing
> >> ===>  Script "configure" failed unexpectedly.
> >>
> >> I see you have sophisticated check depending on OS version for
> >> CONFIGURE_ARGS+=--enable-dtrace
> >> IMHO, it should be replaced to test dtrace binary presence instead.
> >>
> > 
> > To be previse the port should not care about WITHOUT_CDDL :) but it should
> > detect if the host has dtrace or note, probably a
> > .if exists(/usr/sbin/dtrace)
> > CONFIGURE_ARGS+= --enable-dtrace
> > .endif
> > 
> > Should do the trick (to be tested of course :)
> 
> Yes, the thing
> .if exists(/usr/sbin/dtrace)
> CONFIGURE_ARGS+=--enable-dtrace
> .else
> CONFIGURE_ARGS+=--disable-dtrace
> .endif
> works (at least for no dtrace case)

The checks for OS version weren't meant to detect presence of dtrace, they were
meant to detect presence of dtrace with usable USDT. Unfortunately, presence of
/usr/sbin/dtrace doesn't necessarily mean USDT works. So, both checks need to
be there. I'll take a look when I can, but if someone else gets there first,
great.

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: INDEX build breakage

[Steve Wills]

On Mon, Mar 24, 2014 at 06:28:50PM +, Portsnap buildbox wrote:
> "/usr/ports/Mk/Uses/compiler.mk", line 104: warning: "c++ -### /dev/null 
> 2>&1" returned non-zero status
[snip]
> "/usr/ports/Mk/Uses/compiler.mk", line 104: warning: "c++ -### /dev/null 
> 2>&1" returned non-zero status
> make_index: /usr/ports/devel/ruby-rbbr: no entry for 
> /usr/ports/x11-toolkits/ruby-gtk2
> 
> Committers on the hook (CCed):
> crees
> oliver
> pawel
> swills
> tj
> 

My bad, I thought rmport was going to check that for me. Should have known I
wasn't that lucky. Fixed now hopefully and sorry for the noise.

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: pidgin with pidgin-sipe plugin now aborts on connect

[Steve Wills]

There are some additional changes needed, see PR ports/186783. This version
passes poudriere testport.

Also, PR ports/183941 was submitted to update to 1.17.0, but had some issues
with KRB5 and wasn't committed. This version builds fine with KRB5 for me, so I
think 183941 can be closed.

Steve

On Fri, Feb 14, 2014 at 03:01:47PM -0700, Janky Jay, III wrote:
> Hi Ruslan,
> 
>   I most certainly will (providing that it actually works)! :) Once it's 
> verified, I'll submit the PR.
> 
> On 02/14/2014 02:21 PM, Ruslan Makhmatkhanov wrote:
> > Janky Jay, III wrote on 15.02.2014 01:16:
> >> Hello Greg,
> >>
> >>  Simply editing the Makefile and the distinfo file inside the
> >> net-im/pidgin-sipe directory worked fine for me. I did the following:
> >>
> >> 1) Edit Makefile
> >>a) Changed PORTVERSION from 1.13.1 to 1.18.0
> >>b) Removed the PORTREVISION line
> >>
> >> 2) After editing the Makefile, I ran
> >>a) make makesum (to update the distinfo file)
> >>b) make all install clean
> >>
> >>  Pidgin now connects without any issues using the Office
> >> Communicator protocol. I've also attached a patch for the port if you'd
> >> rather use that. If it works for you, I'll submit the patch to PR. Just
> >> let me know.
> >>
> >> Regards,
> >> Janky Jay, III
> >
> > Great! Would you please submit your patch to GNATS PR?
> >
> 
> ___
> 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: lang/ruby19: fails to build on 9.2-STABLE: don't know how to make OPENSSL_CFLAGS. Stop

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

Thanks,
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: Can't seem to build ruby19 or 18.

[Steve Wills]

On Mon, Jan 27, 2014 at 12:11:52PM -0600, Edwin L. Culp W. wrote:
> ===>  Building for ruby-1.9.3.484_1,1
> make: don't know how to make OPENSSL_CFLAGS. Stop
> *** [do-build] Error code 1
> 
> I just want to be sure that it isn't me, hopefully.

I'm unable to reproduce, and based on other responses and another thread, I
think this isn't something ruby specific. Perhaps you can share your make.conf?

Thanks,
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: how to install ruby18

[Steve Wills]

On Sat, Jan 04, 2014 at 03:45:12PM +0100, John Marino wrote:
> On 1/4/2014 15:38, Marco Beishuizen wrote:
> > On Sat, 4 Jan 2014, the wise John Marino wrote:
> > 
> > Portupgrade builds fine, but I have my locale set to UTF-8 and in that
> > case the pkgdb breaks and portupgrade no longer works:
> > 
> > ...
> > root@yokozuna:/home/marco# pkgdb -FfO
> > --->  Checking the package registry database
> > invalid byte sequence in UTF-8
> > ...
> > 
> > When the locale is set to the standard C the error changes to "invalid
> > byte sequence in US-ASCII".
> > 
> > I have this error for a very long time and after a lot of searching and
> > fiddling with the locale settings have no idea how to solve this.
> > 
> > Ruby18 worked fine so that would be the best option imo.
> 
> Ruby18 is gone forever, and unsupported, so that's not the best option.
> DragonFly had these same type errors with ruby19, until we redefined
> GEM_ENV in bsd.ruby.mk
> 
> -GEM_ENV?=LC_CTYPE=UTF-8
> +GEM_ENV+=LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
> 
> Maybe setting GEM_ENV in your make.conf and rebuilding all the ruby
> stuff would fix it for you too.  Shot in the dark.

I'm not sure this is the right solution. Most of those types of problems have
disappeared now that rdoc isn't a dependency. If you remove rubygem-rdoc, does
the problem go away?

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: Fwd: take a look at ports/182540 (vulnerabilities)

[Steve Wills]

Went ahead and committed, build tests are still running for me. If someone
could work on a VuXML entry, that would be great, I have to run for a while
right now.

Steve

On Tue, Oct 22, 2013 at 06:01:13AM -0500, Bryan Drewery wrote:
> 
> PR is assigned to you.
> 
>  Original Message 
> Subject: take a look at ports/182540 (vulnerabilities)
> Date: Tue, 22 Oct 2013 04:38:39 +0900
> From: Koichiro IWAO 
> To: po...@freebsd.org
> 
> Hello,
> 
> Would anyone please take a look at ports/182540?
> This update fixes buffer overruns and other vulnerabilities [1].
> 
> [1] https://github.com/FreeRDP/xrdp/commits/v0.6
> 
> Regards,
> 
> -- 
> `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"
> 
> 
> 


___
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: evolution-webcal - invalid DSO for symbol `g_thread_init' definition

[Steve Wills]

On Tue, Aug 06, 2013 at 09:40:37PM -0400, AN wrote:
> FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #78 r253966: Mon Aug  5 
> 14:42:05 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64
> 
> cc -DHAVE_CONFIG_H -I. -I.. -DGNOMELOCALEDIR=\""/usr/local/share/locale"\" 
> -I/usr/local/include/gtk-2.0 -I/usr/local/include/gio-unix-2.0/ 
> -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo 
> -I/usr/local/include/pixman-1 -D_THREAD_SAFE 
> -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libpng15 
> -I/usr/local/include/pango-1.0 -I/usr/local/include/freetype2 
> -I/usr/local/include/harfbuzz 
> -I/usr/local/include/evolution-data-server-2.32 
> -I/usr/local/include/gconf/2 -I/usr/local/include/orbit-2.0 -DORBIT2=1 
> -I/usr/local/include/libsoup-2.4 -pthread -I/usr/local/include/glib-2.0 
> -I/usr/local/include/libxml2 -I/usr/local/include-I/usr/local/include 
> -O2 -pipe -fno-strict-aliasing -MT evolution-webcal-notify.o -MD -MP -MF 
> .deps/evolution-webcal-notify.Tpo -c -o evolution-webcal-notify.o 
> evolution-webcal-notify.c
> evolution-webcal-main.c:83:9: warning: assigning to 'gchar *' (aka 'char 
> *') from 'const char *' discards qualifiers
>[-Wincompatible-pointer-types-discards-qualifiers]
>name = icalproperty_get_value_as_string (prop);
> ^ ~~~
> evolution-webcal-main.c:85:9: warning: assigning to 'gchar *' (aka 'char 
> *') from 'const char *' discards qualifiers
>[-Wincompatible-pointer-types-discards-qualifiers]
>desc = icalproperty_get_value_as_string (prop);
> ^ ~~~
> evolution-webcal-main.c:115:14: warning: 'soup_message_headers_get' is 
> deprecated [-Wdeprecated-declarations]
>  header = soup_message_headers_get (msg->response_headers, "Location");
>   ^
> /usr/local/include/libsoup-2.4/libsoup/soup-message-headers.h:40:21: note: 
> 'soup_message_headers_get' declared here
> const char *soup_message_headers_get  (SoupMessageHeaders 
> *hdrs,
>  ^
> evolution-webcal-main.c:255:3: warning: 'g_thread_init' is deprecated 
> [-Wdeprecated-declarations]
>g_thread_init (NULL);
>^
> /usr/local/include/glib-2.0/glib/deprecated/gthread.h:261:10: note: 
> 'g_thread_init' declared here
> void g_thread_init   (gpointer vtable);
>   ^
> 4 warnings generated.
> mv -f .deps/evolution-webcal-main.Tpo .deps/evolution-webcal-main.Po
> mv -f .deps/evolution-webcal-notify.Tpo .deps/evolution-webcal-notify.Po
> cc  -O2 -pipe -fno-strict-aliasing  -L/usr/local/lib -o evolution-webcal 
> evolution-webcal-main.o evolution-webcal-notify.o -lgtk-x11-2.0 
> -lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr 
> -lXcursor -lXcomposite -lXdamage -lXfixes -lX11 -latk-1.0 -lcairo 
> -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig 
> -lecal-1.2 -lical -licalss -licalvcal -pthread -ledataserver-1.2 -lxml2 
> -lgconf-2 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -L/usr/local/lib -lglib-2.0 
> -lintl
> /usr/bin/ld: R: invalid DSO for symbol `g_thread_init' definition
> /usr/local/lib/libgthread-2.0.so.0: could not read symbols: Bad value
> cc: error: linker command failed with exit code 1 (use -v to see 
> invocation)

Try the attached patch, also at:

http://meatwad.mouf.net/~swills/webcal.diff

Steve
Index: Makefile
===
--- Makefile	(revision 324412)
+++ Makefile	(working copy)
@@ -8,7 +8,7 @@
 
 PORTNAME=	evolution-webcal
 PORTVERSION=	2.32.0
-PORTREVISION=	2
+PORTREVISION=	3
 CATEGORIES=	www gnome
 MASTER_SITES=	GNOME
 DISTNAME=	${PKGNAMEPREFIX}${PORTNAME}-${PORTVERSION}
Index: files/patch-main.c
===
--- files/patch-main.c	(revision 0)
+++ files/patch-main.c	(working copy)
@@ -0,0 +1,11 @@
+--- src/evolution-webcal-main.c.orig	2013-08-09 02:33:10.761502738 +
 src/evolution-webcal-main.c	2013-08-09 02:33:18.402515485 +
+@@ -252,8 +252,6 @@
+   textdomain (GETTEXT_PACKAGE);
+ #endif
+ 
+-  g_thread_init (NULL);
+-
+   if (!gtk_init_with_args (&argc, &argv,
+ 			_("- Evolution webcal: URI Handler"),
+ 			options,

Property changes on: files/patch-main.c
___
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
___
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] devel/gitlab

[Steve Wills]

On Fri, Aug 02, 2013 at 01:13:49PM +0300, Ivan Klymenko wrote:
> Hello everyone!
> 
> Please help me in testing the SUBJ port and bringing it to the correct
> state. :)
> 
> https://redports.org/browser/fidaj/devel/gitlab
> 
> Submitted comments and the patches :).

I've been interested in having a port of this for a while, but there are some
problems with this port. I'll try to see what I can do to get it in shape to
commit.

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: FreeBSD Port: rubygem-ohai-6.16.0

[Steve Wills]

Thanks, I went ahead and filed a PR for it:

http://www.freebsd.org/cgi/query-pr.cgi?pr=180732

We're going to have to wait on a maintainer timeout I think.

Steve

On Sun, Jul 21, 2013 at 12:22:32PM -0700, Douglas Thrift wrote:
> Hello,
> 
> I have attached a patch for Ohai which fixes IP address detection when
> there is an interface with no addresses such as ipfw0. I have already
> submitted the patch upstream: https://tickets.opscode.com/browse/OHAI-492.
> 
> Thanks!
> -- 
> Douglas William Thrift
> 
> 

> --- ./lib/ohai/plugins/network.rb.orig2013-07-20 23:51:57.0 
> -0700
> +++ ./lib/ohai/plugins/network.rb 2013-07-20 23:52:07.0 -0700
> @@ -42,6 +42,7 @@
>ipaddresses = []
># ipaddresses going to hold #{family} ipaddresses and their scope
>Mash[network['interfaces']].each do |iface, iface_v|
> +next if iface_v.nil? or not iface_v.has_key? 'addresses'
>  iface_v['addresses'].each do |addr, addr_v|
>next if addr_v.nil? or not addr_v.has_key? "family" or 
> addr_v['family'] != family
>ipaddresses <<  {

> ___
> 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: Redmine rmagick dependencies

[Steve Wills]

On 07/12/13 19:47, Kozlov Sergey wrote:
> Hi all. I've already posted this on questions, but got no reply.

Sorry I didn't see your message.

> Recently the redmine port was updated to 2.3.1 and when i tried to
> install it I've noticed that it has two rmagick dependencies - 
> ruby-rmagick(optional) and rubygem-rmagick(non-optional). 
> ruby-rmagic and rubygem-rmagick ports have the same COMMENT and
> VERSION so i have some questions:
> 
> 1) What's the difference between ruby-rmagick and rubygem-rmagick?

The rubygem- one shows up in "gem list" and is detected as installed
by gem.

> 2) Why does redmine need rubygem-rmagick even if i turn rmagick
> option off (is it a bug)?
> 
> Before the port was updated I've installed redmine dependencies
> using bundler, and i had no rmagick at all while redmine working
> properly.

It's at least a bug that both are required, it may be a bug that
either is required, though I doubt it and it's a bug that the dep
doesn't go away when you turn it off, although the dep may not be
optional. I'll take a look at it and see if I can fix it, thanks for
letting us know.

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: INDEX build failed for 8.x

[Steve Wills]

Fixed, sorry about that.

On 07/02/13 09:08, Ports Index build wrote:
> INDEX build failed with errors:
> Generating INDEX-8 - please wait..clang: not found
>  Done.
> Warning: Duplicate INDEX entry: rubygem-bunny-0.6.0
> 
> Committers on the hook:
>  culot delphij girgen jgh jkim sbz swills 
> 
> Most recent SVN update was:
> Updating '.':
> Udatabases/pgbadger/Makefile
> Udatabases/pgbadger/distinfo
> Usecurity/vuxml/vuln.xml
> Udevel/p5-Config-INI/Makefile
> Udevel/p5-Config-INI/distinfo
> Udevel/p5-Config-INI/pkg-descr
> UU   devel/py-ptrace/pkg-plist
> UU   devel/py-ptrace/Makefile
> UU   devel/py-ptrace/distinfo
> Adevel/libvirt-glib
> Adevel/libvirt-glib/pkg-plist
> Adevel/libvirt-glib/Makefile
> Adevel/libvirt-glib/distinfo
> Adevel/libvirt-glib/pkg-descr
> Udevel/Makefile
> Uftp/curl/Makefile
> Aftp/curl/files/patch-CVE-2013-2174
> Updated to revision 322161.
> ___
> 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: CFT: [patch] making -jX builds the default

[Steve Wills]

On 06/30/13 16:40, Alexey Dokuchaev wrote:
> Hi there,
> 
> In attempt to catch (hopefully) last few remaining jobs-unsafe ports, and
> thus to make upcoming expruns fallouts easier to handle, I'm sending small
> patch I've been using locally for a while to get larger exposure.  Patch
> was sent to portmgr@ guys for review about a month earlier, it seems DTRT
> at the first glances. :-)
> 
> FORCE_MAKE_JOBS is removed because it is the default.  While here, I've
> moved empty(MAKE_JOBS_NUMBER) check higher, IMHO where it should belong,
> also saves a few lines.  Testing and feedback are welcome!  Let's finally
> flip the damn switch! ;-)

+1

I've been running with FORCE_MAKE_JOBS for a long time and rarely
encounter issues.

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: www/rubygem-passenger now requires bash?

[Steve Wills]

> I'm running FreeBSD/amd64 8-STABLE (r250276) and, yesterday, updated
> www/rubygem-passenger from 3.0.19 to 4.0.5 via portmaster.  Although the
> port upgraded without error, the resultant Passenger no longer works: it
> complains it can't find "bash" and Rails apps won't spawn.
>
> I don't have shells/bash installed, and didn't need to with version 3.0.19
> of the www/rubygem-passenger port.  The shells/bash port isn't listed as a
> runtime dependency for www/rubygem-passenger in its Makefile, either.
>
> If I install shells/bash and also put a symlink from /usr/bin/bash to
> /usr/local/bin/bash then Passenger will run once again.  I don't like this
> solution, though.  Does anyone know of a way of running the Passenger
> 4.0.5 port without needing bash?
>
> I've included at the end a snippet from httpd-error.log showing the
> behaviour of the new Passenger 4.0.5 prior to the workaround I put in
> place mentioned in the preceding paragraph.

I've submitted a patch for this, please see PR ports/179737

Any testing and feedback would be appreciated.

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: 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: www/rubygem-passenger now requires bash?

[Steve Wills]

> I'm running FreeBSD/amd64 8-STABLE (r250276) and, yesterday, updated
> www/rubygem-passenger from 3.0.19 to 4.0.5 via portmaster.  Although the
> port upgraded without error, the resultant Passenger no longer works: it
> complains it can't find "bash" and Rails apps won't spawn.
>
> I don't have shells/bash installed, and didn't need to with version 3.0.19
> of the www/rubygem-passenger port.  The shells/bash port isn't listed as a
> runtime dependency for www/rubygem-passenger in its Makefile, either.
>
> If I install shells/bash and also put a symlink from /usr/bin/bash to
> /usr/local/bin/bash then Passenger will run once again.  I don't like this
> solution, though.  Does anyone know of a way of running the Passenger
> 4.0.5 port without needing bash?
>
> I've included at the end a snippet from httpd-error.log showing the
> behaviour of the new Passenger 4.0.5 prior to the workaround I put in
> place mentioned in the preceding paragraph.

I think it only calls bash like that when it crashes, so that it can
generate a crash report of some kind and possibly submit it somewhere. As
far as the crash, I'm told it's a bug in our C++ stuff and that upgrading
to 9-STABLE should help, although I haven't had time to test that. If you
try that, please let us know how it goes.

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: Status of USE_GITHUB fetching

[Steve Wills]

On 06/07/13 22:32, Bryan Drewery wrote:
> On 6/6/2013 8:26 AM, Bryan Drewery wrote:
>> Ports using USE_GITHUB are currently broken. Github changed their
>> tar/compression algorithm which has resulted in mismatched checksums.
>>
>> I am working on changing our implementation and updating all affected
>> ports and should have the fix committed by this weekend, after enough
>> testing.
>>
>>
> 
> Github fixed the checksums issue.
> 
> You will see random 'size not known' warnings. These should be harmless.
> It's due to how they have implemented their download streaming.
> 

Are you saying this might happen once and be resolved or that it will be
ongoing and not resolvable?

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: fetch: expansion of correct source location in MASTER_SITES fails

[Steve Wills]

> Thank you for clearify this.
>
> Even if I use the SF macro and set FETCH_ARGS= to en ampty string (I
> suppose this will result in a "plain" fetch command without options)
> the result is as described intially.
>
> Applying the -v option to fetch then shows what happens and everything
> looks fine to me so far - except that the Makefile-Port-Fetch doesn't
> work. This is strange!

You should not override the FETCH_ARGS unless you really need to do so.
When using the SF macro, it shouldn't be necessary. Do you still see the
issue when not overriding the FETCH_ARGS? If so, please send a copy of
your port and the command and output received and expected.

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: fetch: expansion of correct source location in MASTER_SITES fails

[Steve Wills]

On 06/01/13 11:17, O. Hartmann wrote:
> 
> I'm preparing a port and I fail downloading the sources, although the
> base URL and the target tar ball are expanded correctly. But the fetch
> process then complains with this:
> 
> [...]
> ===>   pocl-0.8.0 depends on file: /usr/local/sbin/pkg - found
> => pocl-0.8rc1.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
> => Attempting to fetch
> http://sourceforge.net/projects/pocl/files/pocl-0.8rc1.tar.gz fetch:
> http://sourceforge.net/projects/pocl/files/pocl-0.8rc1.tar.gz: Moved
> Temporarily
> 
> If one the takes the error line named
> 
> fetch http://sourceforge.net/projects/pocl/files/pocl-0.8rc1.tar.gz
> 
> and issue it directly on the console, surprisingly the the fetch works!
> This is weird.
> 
> What is wrong here? Is this a bug in fetch?

Nothing is wrong here. The "=> Attempting..." line is not trying to tell
you what command it is running, but rather what it is doing. This result
is perfectly normal due to the default args that ports pass to fetch.
See bsd.port.mk:

   2214 FETCH_ARGS?=-AFpr

The fetch man page will explain these further.

For Sourceforge, there is a "SF" macro in bsd.sites.mk which you should
use so that users will try the various mirrors. Many ports use this, so
there are many examples to follow.

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: ruby 1.9 upgrade and puppet

[Steve Wills]

On 05/31/13 21:02, bw.mail.lists wrote:
> 
>>> 
>>> It would probably be best to kill puppet before the upgrade.
>> 
>> This is definitely the problem here.  I'm afraid you'll have to 
>> manually kill it here, since the old rc script has been
>> deinstalled. You'll only have to do it this once.
>> 
> 
> Not a problem (except for UPDATING), but since $command_interpreter
> is set to ruby19 in the new script, doesn't that mean that the same
> thing will happen on the next ruby update?

Yes, but it's pretty rare and I'm not sure how we could avoid it. I've
added a note to UPDATING reminding users to stop the software before
updating.

The other issues you had were caused by a bug in the facter port and
should be fixed now with sysutils/rubygem-facter 1.6.18_2. Please
update and let me know if you have any further issues.

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: ruby 1.9 upgrade and puppet

[Steve Wills]

> Moving to ruby 1.9 by following the instructions in UPDATING breaks
> puppet.
>
> When updating with portmaster, at install time it says 'could not load
> facter; cannot install' and exits. I had to manually run 'gem install
> facter', then puppet installed.

It's better to install via the port so that the package management knows
it's there. This could be causing the later problems.

> However, 'service puppetmaster status'
> was reporting puppet as not running even though it was, so I had to kill
> the running process before 'service puppetmaster start'. I assume this
> is related to $command_interpreter in the rc script being changed from
> ruby18 to ruby19? Although, /usr/local/bin/ruby and
> /usr/local/bin/ruby19 are identical, can't the script use plain ruby
> instead of ruby19?
>

It would probably be best to kill puppet before the upgrade.

> For poudriere, puppet failed, still facter:
>
> === >
> ===>  Installing for puppet-3.1.1_2
> ===>   Generating temporary packing list
> ===>  Checking if sysutils/puppet already installed
> ===> Creating users and/or groups.
> Creating group `puppet' with gid `814'.
> Creating user `puppet' with uid `814'.
> ftools not found.  Using FileUtils instead..
> Could not load facter; cannot install
> *** [do-install] Error code 255
>
> Stop in /usr/ports/sysutils/puppet.
> ===>  Cleaning for puppet-3.1.1_2
> build of /usr/ports/sysutils/puppet ended at Fri May 31 11:37:10 CEST 2013
>
> Rebuilding everything with 'poudriere bulk -c' worked fine. I'm aware
> that rebuilding everything isn't needed, but it didn't take that long.

I'm unable to reproduce any build issues.

> But then, when upgrading with pkg, again I had to 'gem install facter'
> manually and kill the running script before puppet would restart.

Could you send me a list of installed system packages and the output of
"gem list"?

Thanks,
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: ruby 1.9 upgrade and puppet

[Steve Wills]

> Moving to ruby 1.9 by following the instructions in UPDATING breaks
> puppet.
>

Sorry for the breakage, I'll take a look.

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: portupgrade broken after ruby upgrade

[Steve Wills]

> On Tue, 28 May 2013, the wise Bryan Drewery wrote:
>
>>> root@yokozuna:/usr/ports# portupgrade -a
>>> invalid byte sequence in UTF-8
>>> Command failed [exit code 1]: /usr/local/sbin/pkgdb -aFOQ
>>
>> Portupgrade does not handle major ruby upgrades well.
>>
>> I recommend rebuilding portupgrade and its databases:
>>
>> # make -C /usr/ports/ports-mgmt/portupgrade build deinstall install
>> clean
>> # rm -f /var/db/pkg/pkgdb.db
>> # rm -f /usr/ports/*.db
>> # pkgdb -fu
>> # portsdb -fu

Not sure this will help in your current stat, but for others who haven't
upgraded yet, the notes in UPDATING were incorrect and have been updated,
and after some testing I believe they should work better now. My apologies
for the mistake.

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"

[HEADSUP] default version of Ruby switched to 1.9

[Steve Wills]

Hi All,

Just a heads up, I've finally switched the default version of Ruby to 1.9.
There is a note in UPDATING that should help. Let us know if you have any
trouble.

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: INDEX build failed for 8.x

[Steve Wills]

My fault, fixed now, sorry about that.

Steve

On 05/27/13 00:05, Ports Index build wrote:
> INDEX build failed with errors:
> Generating INDEX-8 - please wait..clang: not found
>  Done.
> make_index: rubygem-dm-core-1.2.0: no entry for 
> /usr/ports/www/rubygem-addressable22
> 
> Committers on the hook:
>  ehaupt kuriyama swills 
> 
> Most recent SVN update was:
> Updating '.':
> Usecurity/vuxml/vuln.xml
> Unet/tramp/pkg-plist
> Unet/tramp/Makefile
> Unet/tramp/distinfo
> Unet/socat/Makefile
> Unet/socat/distinfo
> Uconverters/p5-Sereal/Makefile
> Uconverters/p5-Sereal/distinfo
> Uconverters/p5-Sereal-Decoder/Makefile
> Uconverters/p5-Sereal-Decoder/distinfo
> Uconverters/p5-Sereal-Encoder/Makefile
> Uconverters/p5-Sereal-Encoder/distinfo
> Awww/rubygem-addressable22
> Awww/rubygem-addressable22/Makefile
> Awww/rubygem-addressable22/distinfo
> Awww/rubygem-addressable22/pkg-descr
> UU   databases/rubygem-dm-core/Makefile
> Udatabases/p5-DBIx-QueryLog/Makefile
> Udatabases/p5-DBIx-QueryLog/distinfo
> Udevel/p5-File-ShareDir-ProjectDistDir/Makefile
> Udevel/p5-File-ShareDir-ProjectDistDir/distinfo
> Updated to revision 319143.
> ___
> 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: [texlive, FreeBSD 10.x-amd64] build error: _ThreadRuneLocale: TLS definition in /usr/lib/libc.so section .tbss mismatches non-TLS reference in gsftopk.o

[Steve Wills]

On 05/16/13 15:29, Hiroki Sato wrote:
> Boris Samorodov  wrote
>   in <51939aed.3060...@passap.ru>:
> 
> bs> Hi,
> bs>
> bs> I've got an error while building texlive-base at fresh CURRENT:
> bs> -
> bs> % uname -a
> bs> FreeBSD BB049.int.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #21 r250633:
> bs> Tue May 14 13:53:42 SAMT 2013
> bs> b...@bb049.int.wart.ru:/usr/obj/usr/src/sys/BB64X  amd64
> bs> -
> bs>
> bs> I have "TEX_DEFAULT=texlive" at the /etc/make.conf.
> bs>
> bs> Here is a tail of te log (full log 719 KB
> bs> ftp://ftp.wart.ru/pub/FreeBSD/errorlogs/texlive.make.log.txt ):
> 
>  Thank you for the report.  I am trying to reproduce this now.
> 

I had a similar issue with devel/kBuild recently. It may be due to
-Dlint getting passed to the build. See this rev:

http://svnweb.freebsd.org/base/head/sys/sys/cdefs.h?annotate=250623&pathrev=250623#l296

which defines _Thread_local as empty when lint is defined. This then
affects runetype.h:

http://svnweb.freebsd.org/base/head/include/runetype.h?annotate=232498&pathrev=250623#l92

I'm not sure if this is a bug in cdefs.h, runetype.h or things building
with -Dlint or none of the above. Comments would be appreciated.

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] add a config.site cache for the ports

[Steve Wills]

I'm sure your list probably includes this, but just in case,
databases/db42 broke with this for me.

Steve

>
> just a fyi this exp-run broke quiet a lot.
>
>
>
> On Mar 23, 2013, at 11:18 PM, Bryan Drewery  wrote:
>
>> On 3/18/2013 12:41 PM, Baptiste Daroussin wrote:
>>> Hi,
>>>
>>> The autotools allows us to have a config.site cache where we define our
>>> defaults
>>> values for a couple of things, and prevent the "slow" and possibly
>>> wrong
>>> autodetection.
>>>
>>> Here is a patch that makes use of it:
>>> http://people.freebsd.org/~bapt/autotools_config_site.diff
>>>
>>> As the libiconv/gettext update has shown the configure scripts can fall
>>> back on
>>> gnu version of commands first if it find it, and in case gettext is
>>> removed you
>>> can get trouble.
>>>
>>> In this config.site, I hardcoded a couple of FreeBSD binaries in order
>>> to always
>>> use them, but I let the toolchain being autodetected.
>>>
>>> I also added a couple of headers to avoid useless checks and more can
>>> be added
>>> in the futur.
>>>
>>> Any thought?
>>>
>>> regards,
>>> Bapt
>>>
>>
>> This will be great.
>>
>> I've added it to my jails for testing too.
>>
>> Bryan
>>
>>
>
> +-oOO--(_)--OOo-+
> With best Regards,
>Martin Wilke (miwi_(at)_FreeBSD.org)
>
> Mess with the Best, Die like the Rest
>
> ___
> 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: [CFT] New dialog for ports

[Steve Wills]

>
> I wonder if it is worth to let the question to install dialog4ports.
>
> I mean dialog4ports being mandatory you should just be installed directly
> doesn't it?
>
> anyone have an opinion about this?
>
> I will remove the question on 27/03 if I got more please do than please
> don't at
> that time.

The question does lead one to think it's optional. If it's not optional,
then there shouldn't be a prompt. I think it should be optional. IMHO, the
requirement being mandator violates POLA, as does the prompt. These are
questions that should have been answered before it was committed.

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] New dialog for ports

[Steve Wills]

On 03/14/13 09:55, Baptiste Daroussin wrote:
> Hi all,
> 
> Ilya A. Arkhipov wrote dialog4ports which has just been added into the ports
> tree ports-mgmt/dialog4ports, this is intended to be a replacement for 
> dialog(1)
> designed specifically for the options, in particular for optionsng.
> 
> It uses libdialog (recent version) and extend it with a new widget able to 
> deal
> with both normal and radio options in the same window.
> 
> dialog4ports will live forever in ports so that it can easily be updated and 
> get
> support for new features on all supported arches at the same time.
> 
> It bundles libdialog on FreeBSD versions that doesn't have a recent libdialog 
> in
> base (read 8.x)
> 
> dialog4ports also support a new feature: it has a help dialog to be able to
> print a human readable help text if possible.
> 
> Here is a patch to the ports tree that makes it use dialog4ports by default.
> What it does is:
> When make config is requested and dialog4ports is not installed yet the ports
> tree will install dialog4ports first.
> 
> New feature for maintainer, if a pkg-help file is found inside the port
> directory then dialog will show to the user a help file is available et 
> propose
> him to hint F1 or ^E to show the said help file
> 
> http://people.freebsd.org/~bapt/d4p.diff
> 
> Please test!

I didn't get a chance to test this before it was committed, but I'm
currently running into this:


% pwd
/usr/local/tinderbox/portstrees/FreeBSD/ports/www/apache22
% sudo make config
dialog4ports isn't installed, do you want to install it now? [Y/n] n
env: /usr/local/bin/dialog4ports: No such file or directory
===> Options unchanged
%

And I'm prompted every time. Is this how it's supposed to work?

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] add a config.site cache for the ports

[Steve Wills]

> On 18 Mar 2013 17:42, "Baptiste Daroussin"  wrote:
>>
>> Hi,
>>
>> The autotools allows us to have a config.site cache where we define our
> defaults
>> values for a couple of things, and prevent the "slow" and possibly wrong
>> autodetection.
>>
>> Here is a patch that makes use of it:
>> http://people.freebsd.org/~bapt/autotools_config_site.diff
>>
>> As the libiconv/gettext update has shown the configure scripts can fall
> back on
>> gnu version of commands first if it find it, and in case gettext is
> removed you
>> can get trouble.
>>
>> In this config.site, I hardcoded a couple of FreeBSD binaries in order
>> to
> always
>> use them, but I let the toolchain being autodetected.
>>
>> I also added a couple of headers to avoid useless checks and more can be
> added
>> in the futur.
>>
>> Any thought?
>
> This could save literally hours on package builds...
>
> Very exciting, thanks for this work!

Agreed, I like this a lot and will be testing it.

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: Port deprecation reason ``Does not work with Ruby 1.9'' -- what should I do?

[Steve Wills]

> On 3/11/2013 4:13 PM, Lev Serebryakov wrote:
>> Hello, Ports.
>>
>>   My  port  (devel/ruby-subversion) is marked for deletion in 2 months
>>  because `` Does not work with Ruby 1.9''. What should I do?
>>
>>To be honest, I know nothing about Ruby and this port is part of
>>  official subversion distribution. Only thing I could do is to check
>>  that it builds and pass "make tests".
>>
>>   Why port is marked for deletion? Is ruby 1.8 deprecated and removed?
>>  Why can't port be for ruby 1.8 only?
>
> I believe 1.8 is EOL in June.
>
> http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/
>
> I can't find anything more recent confirming this though.

Yep, that's correct as far as I know.

>>
>>   Only tyhing I could do right now -- ask upstream is ruby 1.9
>>  support planned for future releases, but I can not influence
>>  upstream to provide (or doesn't provide) such support and I cannot
>>  hack sources to make it support ruby 1.9 :(

Just out of curiosity, I did a search and found this:

http://subversion.tigris.org/issues/show_bug.cgi?id=4083

So perhaps it's fixable.

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"