Re: 6.3 subversion package

2018-04-04 Thread Daniel Jakots
On Wed, 4 Apr 2018 13:28:44 -0400, sven falempin
 wrote:

> If they build.

I've broken a couple of times ports and I can assure broken ports are
noticed quickly. Maybe you should consider fixing your system.



Re: 6.3 subversion package

2018-04-04 Thread sven falempin
On Wed, Apr 4, 2018 at 11:16 AM, Stefan Sperling  wrote:
> On Wed, Apr 04, 2018 at 10:10:20AM -0400, sven falempin wrote:
>> On Wed, Apr 4, 2018 at 4:23 AM, Stuart Henderson  
>> wrote:
>> > Is there any particular reason for building from source anyway?
>>
>> Thank you for the pointers,
>> i wanted to have a lighter version , and
>> it is probably not a silly idea because someone already did it
>> but before building with Flavors, i just wanted to build the basic package.
>
> I don't see why compiling the subversion port would be useful.
>
> The subversion port only has PSEUDO_FLAVORS, which means you can compile
> just the core 'subversion' package with less build dependencies installed
> if you want, and avoid also compiling the py-subversion, ruby-subversion,
> etc.  sub-packages.
> This can be useful on a -current OpenBSD system in case packages and base
> system sets on the mirrors are out of sync with respect to base system
> libraries, and you need subversion on your -current system "right now".
>
> But there is no advantage to compiling this port on a -release system.
> As long as you don't install additional packages like py-subversion or
> ruby-subversion, the behaviour and content of the core 'subversion' package
> on official mirrors and the one you've compiled is effectively identical.
>
> (There is one exception: The 'maintainer_mode' flavor enables additional
> debugging output, but it doesn't sound like that's what you want.)

I used the FLAVOR option using the Makefile info :

FLAVOR?=
.if ${FLAVOR:Mno_bindings}
FLAVOR += no_perl no_python no_ruby

to get my package doing FLAVOR='no_perl no_python no_ruby' make package

Ports are great because you can patch stuff quickly in case of trouble.
If they build.

AFAIK the no_bindings option is new, and thanks for whoever did it.

Another example:

I am adding the DAV module of nginx and passenger is not building.
I just removed passenger as i do not need it.

Index: Makefile
===
RCS file: /cvs/ports/www/nginx/Makefile,v
retrieving revision 1.120
diff -u -p -r1.120 Makefile
--- Makefile1 Mar 2018 15:58:19 -   1.120
+++ Makefile4 Apr 2018 17:22:16 -
@@ -12,7 +12,6 @@ COMMENT-naxsi=nginx web application fi
 COMMENT-lua=   nginx lua scripting module
 COMMENT-headers_more=  nginx module for setting/adding/clearing headers
 COMMENT-perl=  nginx perl scripting module
-COMMENT-passenger= nginx passenger (ruby/python/nodejs) integration module

 VERSION=   1.12.2
 DISTNAME=  nginx-${VERSION}
@@ -28,7 +27,6 @@ PKGNAME-naxsi=nginx-naxsi-${VERSION}
 PKGNAME-lua=   nginx-lua-${VERSION}
 PKGNAME-headers_more=  nginx-headers-more-${VERSION}
 PKGNAME-perl=  nginx-perl-${VERSION}
-PKGNAME-passenger= nginx-passenger-${VERSION}

 MASTER_SITES=  https://nginx.org/download/
 MASTER_SITES0= https://github.com/simpl/ngx_devel_kit/archive/
@@ -51,7 +49,7 @@ MAINTAINER=   Robert Nagy 

Re: 6.3 subversion package

2018-04-04 Thread Stefan Sperling
On Wed, Apr 04, 2018 at 10:10:20AM -0400, sven falempin wrote:
> On Wed, Apr 4, 2018 at 4:23 AM, Stuart Henderson  wrote:
> > Is there any particular reason for building from source anyway?
> 
> Thank you for the pointers,
> i wanted to have a lighter version , and
> it is probably not a silly idea because someone already did it
> but before building with Flavors, i just wanted to build the basic package.

I don't see why compiling the subversion port would be useful.

The subversion port only has PSEUDO_FLAVORS, which means you can compile
just the core 'subversion' package with less build dependencies installed
if you want, and avoid also compiling the py-subversion, ruby-subversion,
etc.  sub-packages.
This can be useful on a -current OpenBSD system in case packages and base
system sets on the mirrors are out of sync with respect to base system
libraries, and you need subversion on your -current system "right now".

But there is no advantage to compiling this port on a -release system.
As long as you don't install additional packages like py-subversion or
ruby-subversion, the behaviour and content of the core 'subversion' package
on official mirrors and the one you've compiled is effectively identical.

(There is one exception: The 'maintainer_mode' flavor enables additional
debugging output, but it doesn't sound like that's what you want.)



Re: 6.3 subversion package

2018-04-04 Thread sven falempin
On Wed, Apr 4, 2018 at 4:23 AM, Stuart Henderson  wrote:
> On 2018/04/04 09:18, Marc Espie wrote:
>>
>> First, your subject is misleading, you're talking about the port,
>> not the package.
>> On Tue, Apr 03, 2018 at 10:31:47PM -0400, sven falempin wrote:
>> > Fresh out of the box.
>>
>>
>> Builds here.
>
> I've never had problems with this in bulk builds. I think it's a
> bit more likely there is something present locally causing a problem
> than an issue with the port.
>
>> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_client_h.swg:196:
>> > Error: Couldn't find 'proxy.py'.
>> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_client_h.swg:197:
>> > Error: Couldn't find 'proxy.py'.
>> > Unable to open file subversion/bindings/swig/python/svn_client.c: Too
>> > many open files
>> > *** Error 1 in /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7
>> > (./build-outputs.mk:286
>> > 'subversion/bindings/swig/python/svn_client.c')
>> > *** Error 1 in . (Makefile:224 'post-build')
>> >
>> > Given the large amount of  _Couldn't find 'proxy.py'_
>> > i guess allowing more fd would be a terrible idea.
>> >
>> > the problem starts with :
>>
>> It probably starts earlier. This looks like a hidden dependency to me.
>>
>> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_version.h:148:
>> > Warning 302: Identifier 'svn_version_t' redefined (ignored),
>> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_types_h.swg:47:
>> > Warning 302: previous definition of 'svn_version_t'.
>> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_props.h:504:
>> > Warning 305: Bad constant value (ignored).
>> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_props.h:652:
>> > Warning 305: Bad constant value (ignored).
>> >
>> > I update to -rOPENBSD_6_3 after uncompressing, reproduced
>>
>> You probably have stuff installed that isn't properly configured out
>> properly. with --disable or something.
>>
>> (python ? swig ? I don't know).
>>
>>
>> You didn't actually provide relevant info (the stuff scrolling by in the
>> configure part), so I don't have stuff to diff...
>>
>> I could look, but I'm lazy and this is actually an incomplete report.
>>
>
> Full build log please, but first make sure you don't have old versions
> of things lying around.
>
> Is there any particular reason for building from source anyway?
>

Thank you for the pointers,
i wanted to have a lighter version , and
it is probably not a silly idea because someone already did it
but before building with Flavors, i just wanted to build the basic package.

Nothing was installed prior to that, but the dhclient that filter answers.

It does not matter much as the build i want ('no_perl no_python no_ruby')
is building fine.

I can try to reproduce and send you the .config file and or configure
output ( which as some warning
about deprecated option btw )

I may have a few more modification coming in ( but nothing that is
related to basic ports  ).

Best

pkg_info :

apache-httpd-2.4.29p0 apache HTTP server
apache-httpd-common-2.4.29 /var/www files for Apache HTTPd
apr-1.6.3p0 Apache Portable Runtime
apr-util-1.6.1  companion library to APR
autoconf-2.13p4 automatically configure source code on many Un*x platforms
autoconf-2.64p1 automatically configure source code on many Un*x platforms
autoconf-2.67p1 automatically configure source code on many Un*x platforms
autoconf-2.68p1 automatically configure source code on many Un*x platforms
autoconf-2.69p2 automatically configure source code on many Un*x platforms
automake-1.15.1 GNU Standards-compliant Makefile generator
bash-4.4.19 GNU Bourne Again Shell
bison-3.0.4p0   GNU parser generator
bzip2-1.0.6p8   block-sorting file compressor, unencumbered
cairo-1.14.12   vector graphics library
cyrus-sasl-2.1.26p25 RFC  SASL (Simple Authentication and Security Layer)
db-4.6.21p5v0   Berkeley DB package, revision 4
dbus-1.12.6v0   message bus system
docbook-4.5p1   technical documentation XML/SGML definitions
docbook-dsssl-1.79  modular DSSSL stylesheets for the DocBook DTD
docbook-xsl-1.68.1p5 docbook XSL modular stylesheet
gdbm-1.14.1 GNU dbm
gettext-0.19.8.1p1  GNU gettext runtime libraries and programs
gettext-tools-0.19.8.1 GNU gettext development and translation tools
glib2-2.54.3p1  general-purpose utility library
gmake-4.2.1 GNU make
gmp-6.1.2p1 library for arbitrary precision arithmetic
gnugetopt-1.1.6p0   GNU getopt(1) utility
gobject-introspection-1.54.1p0 GObject Introspection
guile-1.8.8p5   GNU's Ubiquitous Intelligent Language for Extension
help2man-1.47.5 generates simple manual pages from program output
intel-firmware-20180312v0 firmware binary images for intel(4) driver
intltool-0.51.0p1   

Re: 6.3 subversion package

2018-04-04 Thread Stuart Henderson
On 2018/04/04 09:18, Marc Espie wrote:
> 
> First, your subject is misleading, you're talking about the port,
> not the package.
> On Tue, Apr 03, 2018 at 10:31:47PM -0400, sven falempin wrote:
> > Fresh out of the box.
> 
> 
> Builds here.

I've never had problems with this in bulk builds. I think it's a
bit more likely there is something present locally causing a problem
than an issue with the port.

> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_client_h.swg:196:
> > Error: Couldn't find 'proxy.py'.
> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_client_h.swg:197:
> > Error: Couldn't find 'proxy.py'.
> > Unable to open file subversion/bindings/swig/python/svn_client.c: Too
> > many open files
> > *** Error 1 in /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7
> > (./build-outputs.mk:286
> > 'subversion/bindings/swig/python/svn_client.c')
> > *** Error 1 in . (Makefile:224 'post-build')
> > 
> > Given the large amount of  _Couldn't find 'proxy.py'_
> > i guess allowing more fd would be a terrible idea.
> > 
> > the problem starts with :
> 
> It probably starts earlier. This looks like a hidden dependency to me.
> 
> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_version.h:148:
> > Warning 302: Identifier 'svn_version_t' redefined (ignored),
> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_types_h.swg:47:
> > Warning 302: previous definition of 'svn_version_t'.
> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_props.h:504:
> > Warning 305: Bad constant value (ignored).
> > /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_props.h:652:
> > Warning 305: Bad constant value (ignored).
> > 
> > I update to -rOPENBSD_6_3 after uncompressing, reproduced
> 
> You probably have stuff installed that isn't properly configured out
> properly. with --disable or something.
> 
> (python ? swig ? I don't know).
> 
> 
> You didn't actually provide relevant info (the stuff scrolling by in the
> configure part), so I don't have stuff to diff...
> 
> I could look, but I'm lazy and this is actually an incomplete report.
> 

Full build log please, but first make sure you don't have old versions
of things lying around.

Is there any particular reason for building from source anyway?



Re: 6.3 subversion package

2018-04-04 Thread Marc Espie

First, your subject is misleading, you're talking about the port,
not the package.
On Tue, Apr 03, 2018 at 10:31:47PM -0400, sven falempin wrote:
> Fresh out of the box.


Builds here.
> /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_client_h.swg:196:
> Error: Couldn't find 'proxy.py'.
> /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_client_h.swg:197:
> Error: Couldn't find 'proxy.py'.
> Unable to open file subversion/bindings/swig/python/svn_client.c: Too
> many open files
> *** Error 1 in /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7
> (./build-outputs.mk:286
> 'subversion/bindings/swig/python/svn_client.c')
> *** Error 1 in . (Makefile:224 'post-build')
> 
> Given the large amount of  _Couldn't find 'proxy.py'_
> i guess allowing more fd would be a terrible idea.
> 
> the problem starts with :

It probably starts earlier. This looks like a hidden dependency to me.

> /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_version.h:148:
> Warning 302: Identifier 'svn_version_t' redefined (ignored),
> /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_types_h.swg:47:
> Warning 302: previous definition of 'svn_version_t'.
> /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_props.h:504:
> Warning 305: Bad constant value (ignored).
> /usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_props.h:652:
> Warning 305: Bad constant value (ignored).
> 
> I update to -rOPENBSD_6_3 after uncompressing, reproduced

You probably have stuff installed that isn't properly configured out
properly. with --disable or something.

(python ? swig ? I don't know).


You didn't actually provide relevant info (the stuff scrolling by in the
configure part), so I don't have stuff to diff...

I could look, but I'm lazy and this is actually an incomplete report.