help make port for opencoarrays

[Anton Shterenlikht]

Please help/advise

https://github.com/sourceryinstitute/opencoarrays

It requires mpich built with at least gcc5.3,
more specifically mpif90 built with gcc5.3 or gcc6.
net/mpich has FORTRAN_USES=fortran, which I understand
triggers lang/gcc.

Is it a good idea (or at all possible) to add
an option to net/mpich to choose a particular
gcc version?

Any other advice?

Thanks

Anton
___
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"

Can someone take a look at these PRs?

[Tobias Kortkamp]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206846 (x11/rofi,
issue confirmed and patch approved by maintainer)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206488 (java/jd-gui,
new port)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206515 (www/dillo2,
maintainer timeout)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207236 (security/afl,
update)

Thanks :)
___
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: Installing multi-version ports with portmaster

[Walter Schwarzenfeld]

DEFAULT_VERSIONS=python=2.7 python2=2.7 python3=3.5

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

Installing multi-version ports with portmaster

[Christian Ullrich]

Hello,

how can I use portmaster to install multiple versions of a port, such as 
databases/py-psycopg2?


My default Python version is set to 3.5, but I need psycopg2 for both 
versions. When I have py35-psycopg2 installed and do


portmaster -m PYTHON_VERSION=python2.7 databases/py-psycopg2

, it replaces the 3.5 version with the 2.7 one, and vice versa. Running 
"make PYTHON_VERSION=python2.7 install" in the port directory works, but 
isn't there a way to make portmaster keep the other port?


Thanks,

--
Christian

___
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 user/group in /usr/ports/UIDs and /usr/ports/GIDs

[Douglas Thrift]

On 2/17/2016 12:25 AM, Matthias Fechner wrote:
> Am 16.02.2016 um 20:23 schrieb Douglas Thrift:
>> While your arguments for user isolation make sense, they really only
>> make sense if you were to be using gitolite or gitosis at the same time
>> as gogs which I imagine would not be that common. I am not opposed to
>> you having a gogs user on your system, but I think that the default user
>> defined by the port should reflect a reasonable default for most people,
>> and that user is git not gogs, even the gogs documentation directs you
>> to use the git user.
> 
> the default git user will not work, it has its homedir in /usr/local/git
> but gogs expect it on /var/db/gogs/home.
> I know, here is a second user generated but if I look on the pros and
> cons I think using a dedicated gogs user is here more secure (for
> security and also for the upgrade path in the future).
> 
> 
> Gruß
> Matthias
> 

The home directory should be configurable, that should not be a problem.
I set up Gogs manually from source on my system and have a git user
whose home directory is actually /home/git and I don't have any problems.

I don't think this is going to really make sense for most people, the
default is to have Git urls of the form g...@example.com:user/repo.git
not g...@example.com:user/repo.git. I really don't see that there is a
huge security issue unless someone is trying to run Gogs at the same
time as Gitolite or Gitosis where they would probably just end up
changing what users things run as. Also, I don't see what upgrading has
to do with anything.

I think that it would be a huge mistake to have a user other than git as
the default for this port. Users can configure their systems as they see
fit, but I think the port should ship a reasonable default and that
reasonable default should not have any POLA violations.

-- 
Douglas William Thrift

___
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: www/nghttp2 build failure

[Beeblebrox via freebsd-ports]

Thanks for this. It's good to know that I'm not the only one running into the 
error.

> I looked at this a little when I ran into it earlier; the configure
> script only looks for initgroups() in grp.h (where it isn't) rather
> than unistd.h (where it is), so it doesn't find it, and dumps in a
> local definition.  But the place it's used DOES pull in unistd.h, so
> it gets the conflict.  A configure (.in maybe, since the port does
> autoreconf) patch would be called for, I presume.

Regards.
-- 
FreeBSD_amd64_11-Current_RadeonKMS
Please CC my email when responding, mail from list is not delivered.
___
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: www/nghttp2 build failure

[Matthew D. Fuller]

On Wed, Feb 17, 2016 at 05:45:38PM +0200 I heard the voice of
Beeblebrox via freebsd-ports, and lo! it spake thus:
>
> Latest version (nghttp2-1.7.1) fails to build.

I looked at this a little when I ran into it earlier; the configure
script only looks for initgroups() in grp.h (where it isn't) rather
than unistd.h (where it is), so it doesn't find it, and dumps in a
local definition.  But the place it's used DOES pull in unistd.h, so
it gets the conflict.  A configure (.in maybe, since the port does
autoreconf) patch would be called for, I presume.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: www/nghttp2 build failure

[Walter Schwarzenfeld]

There is a patch fixed it, needs only maintainer approval

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207222
___
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"

www/nghttp2 build failure

[Beeblebrox via freebsd-ports]

Latest version (nghttp2-1.7.1) fails to build. Usually I don't post such 
things, but this failure causes "build-skipped" for a whole number of 
downstream ports. Tail of poudriere log:

gmake[4]: Leaving directory 
'/wrkdirs/usr/ports/www/nghttp2/work/nghttp2-1.7.1/src/includes'
gmake[4]: Entering directory 
'/wrkdirs/usr/ports/www/nghttp2/work/nghttp2-1.7.1/src'
  CXX  libnghttpx_a-util.o
  CXX  libnghttpx_a-http2.o
  CC   libnghttpx_a-timegm.o
  CXX  libnghttpx_a-app_helper.o
  CXX  libnghttpx_a-ssl.o
  CXX  libnghttpx_a-shrpx_config.o
In file included from shrpx_config.cc:42:
/usr/include/unistd.h:511:6: error: declaration of 'initgroups' has a different 
language linkage
int  initgroups(const char *, gid_t);
 ^
./shrpx.h:48:12: note: previous definition is here
inline int initgroups(const char *user, gid_t group) { return 0; }
   ^
1 error generated.
Makefile:1542: recipe for target 'libnghttpx_a-shrpx_config.o' failed
gmake[4]: *** [libnghttpx_a-shrpx_config.o] Error 1
gmake[4]: Leaving directory 
'/wrkdirs/usr/ports/www/nghttp2/work/nghttp2-1.7.1/src'
Makefile:2380: recipe for target 'all-recursive' failed
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory 
'/wrkdirs/usr/ports/www/nghttp2/work/nghttp2-1.7.1/src'
Makefile:554: recipe for target 'all-recursive' failed
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory '/wrkdirs/usr/ports/www/nghttp2/work/nghttp2-1.7.1'
Makefile:463: recipe for target 'all' failed
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory '/wrkdirs/usr/ports/www/nghttp2/work/nghttp2-1.7.1'
*** Error code 1
Stop.
make: stopped in /usr/ports/www/nghttp2


-- 
FreeBSD_amd64_11-Current_RadeonKMS
Please CC my email when responding, mail from list is not delivered.
___
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: Looking committer for PR

[Lowell Gilbert]

Fernando Apesteguía  writes:

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

For what it's worth, this seems to be a trivial version upgrade.
___
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: PHP7 issue [was PHP7 + Synth issue]

[Jim Ohlstein]

Hello,

On 2/17/16 8:59 AM, John Marino wrote:

On 2/17/2016 2:44 PM, Martin Wilke wrote:

Hi,

The long term solution will be switching to mysqli or pdo_mysql which is
provided by php70 (and php55/56), I am working right now on cleaning up
the pecl ports, after that I'll go and check which port can switch already.


php56-pdo_mysql has php56-mysql as a dependency.

# pkg info -d php56-pdo_mysql
php56-pdo_mysql-5.6.18:
php56-5.6.18
php56-mysql-5.6.18
php56-pdo-5.6.18

This is not the case with php70-pdo_mysql.

I have come across at least one port where you see the following in the 
Makefile:


MYSQL_USE=  MYSQL=client PHP=mysql,pdo_mysql

where:

MYSQL_USE=  MYSQL=client PHP=pdo_mysql

would suffice for PHP 5.6 and would not break PHP 7.0, assuming the 
correct extension is phpXx-pdo_mysql.






The problem with that approach is that his tree is broken now.
His choice is don't build at all or don't use php 7.0.

I think it's something that needs attention now unless the intent is to
say, "don't use php7 yet, it is not ready for prime time" (which is
possible)


This is clearly not a Synth issue. Synth did its job correctly.

PHP 7.0 is early and anyone who uses it in production uses it at their 
own peril. It's not the default PHP version, people have to actually 
opt-in to build PHP-based ports with it. As such, they need to have 
their eyes wide open.


Sorting this all out will take awhile with over 100 pecl extensions 
alone and many more than that ports dependent on PHP. The only way to 
figure it out is to leave it in ports so people can test it against 
their apps. Again, anyone who uses it in production without testing is 
asking for trouble.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain

___
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: PHP7 + Synth issue

[John Marino]

Matt wrote:
> I'll search bugzilla to see if there are any bug reports for this and if 
> not I'll raise one then.
> 
> I know php70 is very new so I was expecting problems. Synth is pretty 
> new as well though so I thought I would let people know in case they 
> were not aware of this type of breakage.

I haven't confirmed it, but I expect that poudriere would have choked
the same way when it scans comms/atslog or any similarly affected port.
So synth is new for sure, but the result is expected and correct I think.

John
___
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: PHP7 + Synth issue

[Matt Smith]

On Feb 17 15:05, Kurt Jaeger wrote:

Hi!


> The long term solution will be switching to mysqli or pdo_mysql which is
> provided by php70 (and php55/56), I am working right now on cleaning up
> the pecl ports, after that I'll go and check which port can switch already.



The problem with that approach is that his tree is broken now.
His choice is don't build at all or don't use php 7.0.

I think it's something that needs attention now unless the intent is to
say, "don't use php7 yet, it is not ready for prime time" (which is
possible)


The PHP eco-system is so huge that one can say that even php56 is
not yet ready for prime time 8-)

So: Everyone knows that php70 has open issues, miwi and others are
tracking them down, and if users/testers submit problem reports via
bugzilla, it helps enormously.

It will settle the next few weeks.



I'll search bugzilla to see if there are any bug reports for this and if 
not I'll raise one then.


I know php70 is very new so I was expecting problems. Synth is pretty 
new as well though so I thought I would let people know in case they 
were not aware of this type of breakage.


Thanks,

--
Matt
___
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: PHP7 + Synth issue

[Kurt Jaeger]

Hi!

> > The long term solution will be switching to mysqli or pdo_mysql which is
> > provided by php70 (and php55/56), I am working right now on cleaning up
> > the pecl ports, after that I'll go and check which port can switch already. 

> The problem with that approach is that his tree is broken now.
> His choice is don't build at all or don't use php 7.0.
> 
> I think it's something that needs attention now unless the intent is to
> say, "don't use php7 yet, it is not ready for prime time" (which is
> possible)

The PHP eco-system is so huge that one can say that even php56 is
not yet ready for prime time 8-)

So: Everyone knows that php70 has open issues, miwi and others are
tracking them down, and if users/testers submit problem reports via
bugzilla, it helps enormously.

It will settle the next few weeks.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: PHP7 + Synth issue

[John Marino]

On 2/17/2016 2:44 PM, Martin Wilke wrote:
> Hi,
> 
> The long term solution will be switching to mysqli or pdo_mysql which is
> provided by php70 (and php55/56), I am working right now on cleaning up
> the pecl ports, after that I'll go and check which port can switch already. 
> 

The problem with that approach is that his tree is broken now.
His choice is don't build at all or don't use php 7.0.

I think it's something that needs attention now unless the intent is to
say, "don't use php7 yet, it is not ready for prime time" (which is
possible)
___
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: PHP7 + Synth issue

[Martin Wilke]

Hi,

The long term solution will be switching to mysqli or pdo_mysql which is
provided by php70 (and php55/56), I am working right now on cleaning up the
pecl ports, after that I'll go and check which port can switch already.

- Martin

On Wed, Feb 17, 2016 at 9:27 PM, John Marino  wrote:

> On 2/17/2016 2:24 PM, Matt Smith wrote:
> > The problem is that it isn't just that port. I've also seen it on
> > databases/mysqldumper for example. It's going to affect all ports which
> > have USE_PHP=mysql within them of which I suspect there are quite a
> > lot.  It might be impractical to do what you suggest with them all and
> > I'm wondering if miwi as the maintainer of PHP7 has any thoughts of an
> > official way of solving it.
>
> Yes, I agree with you in that case.
> The USE_PHP=mysql needs to handle the case of php 7.0.
>
> is mysqli inbuilt to php7?  or does it require a different dependency so
> USE_PHP=mysql needs to switch depending on the php version?
>
> in any case, synth is involved only because it cause it first I guess.
>
> John
>



-- 
+-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
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: synth documentation

[Dave Horsfall]

On Sat, 13 Feb 2016, Kevin Oberman wrote:

> What do you mean, "Computers don't have switch registers any more"?

Real computers also have blinkenlights, and the more the better.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
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: PHP7 + Synth issue

[John Marino]

On 2/17/2016 2:24 PM, Matt Smith wrote:
> The problem is that it isn't just that port. I've also seen it on
> databases/mysqldumper for example. It's going to affect all ports which
> have USE_PHP=mysql within them of which I suspect there are quite a
> lot.  It might be impractical to do what you suggest with them all and
> I'm wondering if miwi as the maintainer of PHP7 has any thoughts of an
> official way of solving it.

Yes, I agree with you in that case.
The USE_PHP=mysql needs to handle the case of php 7.0.

is mysqli inbuilt to php7?  or does it require a different dependency so
USE_PHP=mysql needs to switch depending on the php version?

in any case, synth is involved only because it cause it first I guess.

John
___
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: PHP7 + Synth issue

[Matt Smith]

On Feb 17 14:16, John Marino wrote:


It seems like a problem with comms/atslog to me.
You can work around it now by removing MYSQL as a default option for
that port (either modifying the port itself or adding something in
-make.conf to change it)

atslog is not maintained.  Another option is hiding the option if
php>=7.  Probably the easiest thing to do is turn off the option by
default though.



The problem is that it isn't just that port. I've also seen it on 
databases/mysqldumper for example. It's going to affect all ports which 
have USE_PHP=mysql within them of which I suspect there are quite a lot.  
It might be impractical to do what you suggest with them all and I'm 
wondering if miwi as the maintainer of PHP7 has any thoughts of an 
official way of solving it.


--
Matt
___
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: PHP7 + Synth issue

[John Marino]

On 2/17/2016 2:10 PM, Matt Smith wrote:
> Hi guys, I'm using the ports-mgmt/synth package builder to build my
> packages.  I just tried to build all of the packages for PHP7 from the
> new ports and came across an issue. If I set php=7.0 in DEFAULT_VERSIONS
> in the LiveSystem-make.conf (make.conf) then Synth bails out and refuses
> to build the repository. It does this:
> 
> Scanning entire ports tree.
> progress: 5.93%
> culprit: comms/atslog
> Scan aborted because dependency could not be located.
> databases/php70-mysql (required dependency of comms/atslog) does not exist.
> 
> It looks like it scans the port tree, come across a port that has
> USE_PHP=mysql in it and then bails because the port
> databases/php70-mysql does not exist. Obviously because mysql was
> removed from PHP7 in favour of mysqli.
> 
> Is this a problem with the ports infrastructure or should I just not
> declare php=7.0 in the DEFAULT_VERSIONS? If I do this then it builds
> fine, but I guess that might cause other issues elsewhere.

It seems like a problem with comms/atslog to me.
You can work around it now by removing MYSQL as a default option for
that port (either modifying the port itself or adding something in
-make.conf to change it)

atslog is not maintained.  Another option is hiding the option if
php>=7.  Probably the easiest thing to do is turn off the option by
default though.



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

PHP7 + Synth issue

[Matt Smith]

Hi guys, I'm using the ports-mgmt/synth package builder to build my 
packages.  I just tried to build all of the packages for PHP7 from the 
new ports and came across an issue. If I set php=7.0 in DEFAULT_VERSIONS 
in the LiveSystem-make.conf (make.conf) then Synth bails out and refuses 
to build the repository. It does this:


Scanning entire ports tree.
progress: 5.93%
culprit: comms/atslog
Scan aborted because dependency could not be located.
databases/php70-mysql (required dependency of comms/atslog) does not 
exist.


It looks like it scans the port tree, come across a port that has 
USE_PHP=mysql in it and then bails because the port 
databases/php70-mysql does not exist. Obviously because mysql was 
removed from PHP7 in favour of mysqli.


Is this a problem with the ports infrastructure or should I just not 
declare php=7.0 in the DEFAULT_VERSIONS? If I do this then it builds 
fine, but I guess that might cause other issues elsewhere.


--
Matt
___
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: unexpected package dependency

[Andriy Gapon]

On 17/02/2016 11:28, Perry Hutchison wrote:
> I had not expected to find gcc listed (in packagesite.yaml) as a
> dependency of the sysutils/cpuburn package.  I can understand a
> _port_ needing gcc (at build time), but does the cpuburn _package_
> actually require gcc at _runtime_?
> 

I don't believe so.  AFAIR, it builds static binaries.

-- 
Andriy Gapon
___
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"

unexpected package dependency

[Perry Hutchison]

I had not expected to find gcc listed (in packagesite.yaml) as a
dependency of the sysutils/cpuburn package.  I can understand a
_port_ needing gcc (at build time), but does the cpuburn _package_
actually require gcc at _runtime_?
___
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 you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
net-mgmt/weathermap | 1.1.1   | 20.0.0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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

Re: Looking for commiter: dns/dnstracer: Build fails on 10.2-RELEASE-p2 amd64

[Łukasz Wąsikowski]

W dniu 2016-02-17 o 05:41, Kurt Jaeger pisze:

>> I'm looking for a commiter for this PR (working patch is included):
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202824
> 
> Done.

Thank you.

-- 
best regards,
Lukasz Wasikowski
___
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: Makefile for devel/tcllibc causes error in cache-init

[Matthew Seaman]

On 17/02/2016 03:14, Doug Barton wrote:
> Matthew,
> 
> When running cache-init for some time now I get this error:
> 
> cache-init:devel/tcllibc (tcllibc-1.18_1) Error. RUN_DEPENDS
> /var/ports/devel/tcllib -- dependency is not a port
> cache-init: /usr/ports/devel/tcllibc Error.  Can't parse make output
> 
> Interestingly I don't get that same error when I run 'make describe', so
> I'm not quite sure what's happening.

Hmmm... I really should change that output.  When cache-init says:

   Processing make describe output for path "/usr/ports":

it is actually lying through its teeth.  It hasn't run 'make describe'
per-se for many, many years.  Instead it uses 'make -V var1 -V var2
' to extract the values of numerous variables which provides
equivalent information, and a bit more.

> hope this helps,
> 
> Doug
> 

I can't reproduce this with cache-init on my system.  Do you have any
non-standard OPTIONS or make.conf settings that could affect this port?
(I couldn't see any obvious OPTION knobs that might cause problems, but
I didn't really look very hard.)  Any local modifications to your ports
tree?

The only slightly odd looking thing was this RUN_DEPENDS line in
devel/tcllibc:

RUN_DEPENDS=${PREFIX}/lib/tcllib/pkgIndex.tcl:${MASTERDIR}  #
PREFIX, not LOCALBASE

Can you show me what this returns?:

make -C /var/ports/devel/tcllibc -V RUN_DEPENDS -V MASTERDIR

(I assume from your output above you have PORTSDIR=/var/ports ?)

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: New user/group in /usr/ports/UIDs and /usr/ports/GIDs

[Matthias Fechner]

Am 16.02.2016 um 20:23 schrieb Douglas Thrift:

While your arguments for user isolation make sense, they really only
make sense if you were to be using gitolite or gitosis at the same time
as gogs which I imagine would not be that common. I am not opposed to
you having a gogs user on your system, but I think that the default user
defined by the port should reflect a reasonable default for most people,
and that user is git not gogs, even the gogs documentation directs you
to use the git user.


the default git user will not work, it has its homedir in /usr/local/git 
but gogs expect it on /var/db/gogs/home.
I know, here is a second user generated but if I look on the pros and 
cons I think using a dedicated gogs user is here more secure (for 
security and also for the upgrade path in the future).



Gruß
Matthias

--

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
___
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"