Re: fetch is tarpitted by Texas Instruments and/or Akamai and can not download distfiles for TI-related ports.

[Julian Elischer]

On 4/5/20 11:11 AM, Julian Elischer wrote:

On 4/3/20 7:39 AM, Lev Serebryakov wrote:

On 03.04.2020 16:47, Kurt Jaeger wrote:


  I don't know, is it generic for Akamai or TI-specific.

  I think, somebody with official hat (FreeBSD Foundation 
speakperson?)

should contact TI and Akamai about this situation. Faking User-Agent
could be only temporary solution!

I've opened a case with ti.com, CS0177749.

I guess this will take some time to resolve. Someone from akamai
suggests that it might be some mis-selected option selected
for the CDN from akamai and that TI should get in touch with
the akamai support to get it sorted.

Let's see the efficiency of the free markets at work 8-)

  Thank you very much!



I've brought this up with a friend at akamai..

He's looking into it..


Ok I see it's fixed.. called him off.




Julian


___
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: fetch is tarpitted by Texas Instruments and/or Akamai and can not download distfiles for TI-related ports.

[Julian Elischer]

On 4/3/20 7:39 AM, Lev Serebryakov wrote:

On 03.04.2020 16:47, Kurt Jaeger wrote:


  I don't know, is it generic for Akamai or TI-specific.

  I think, somebody with official hat (FreeBSD Foundation speakperson?)
should contact TI and Akamai about this situation. Faking User-Agent
could be only temporary solution!

I've opened a case with ti.com, CS0177749.

I guess this will take some time to resolve. Someone from akamai
suggests that it might be some mis-selected option selected
for the CDN from akamai and that TI should get in touch with
the akamai support to get it sorted.

Let's see the efficiency of the free markets at work 8-)

  Thank you very much!



I've brought this up with a friend at akamai..

He's looking into it..

Julian


___
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: [HEADSUP] Removing DESTDIR support (aka chroot not staging)

[Julian Elischer]

On 10/2/19 11:47 AM, Baptiste Daroussin wrote:

Hello,

As far as I know, the chroot support in the ports tree, is not used by anyone
(and is broken in many areas) this is the feature called DESTDIR.

If anyone is using it, can you please raise your voice, in order to understand
your use case and see if we should juste remove the support for it, or fix it to
turn it into a usable sate?

Best regards,
Bapt


I can not check now but I may have used it int he build system at 
Panzura..


please check with Josh Paetzel who has access to the scripts.

___
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: has a framework change broken sysutils/google-compute-engine-oslogin?

[Julian Elischer]

On 13/8/18 9:16 pm, Helen Koike wrote:

Hi all,

On 08/08/2018 03:04 PM, Dmitri Goutnik wrote:

On 18-08-09 01:16:51, Julian Elischer wrote:

On 8/8/18 6:30 pm, Jan Beich wrote:

Julian Elischer  writes:


g++ -O2 -pipe -DPANZURA_DEV -DPZ_LONGNAMES -fstack-protector -isystem
/usr/local/include -fno-strict-aliasing -isystem /usr/local/include
-fPIC -c pam_module/pam_oslogin_login.cc -o
pam_module/pam_oslogin_login.o
g++ -fstack-protector -I/usr/local/include/json-c -o
google_authorized_keys authorized_keys/authorized_keys.cc
utils/oslogin_utils.cc -lcurl -ljson-c
g++ -fstack-protector -Wall -Wstrict-prototypes -fPIC -shared
-Wl,-soname,libnss_cache_oslogin.so.2 -o
libnss_cache_google-compute-engine-oslogin-1.3.0.so
libnss_cache_oslogin/nss_cache_oslogin.o
libnss_cache_oslogin/compat/getpwent_r.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory

- GCC 4.2.1 (patched) from base system is not a supported configuration
on i386/amd64/aarch64/armv6/armv7
- C*FLAGS aren't consistently respected, see
https://wiki.freebsd.org/WarnerLosh/UsrLocal#Include_paths
https://www.freebsd.org/doc/en/books/porters-handbook/dads-cflags.html

$ g++7 -v -xc++ -
[...]
ignoring nonexistent directory 
"/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.3.0/include-fixed"
ignoring nonexistent directory 
"/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.3.0/../../../../../x86_64-portbld-freebsd12.0/include"
#include "..." search starts here:
#include <...> search starts here:
   /usr/local/lib/gcc7/include/c++/
   /usr/local/lib/gcc7/include/c++//x86_64-portbld-freebsd12.0
   /usr/local/lib/gcc7/include/c++//backward
   /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.3.0/include
   /usr/local/include <-- HERE is why pkg-fallout@ is silent

Sorry you are out of my area of knowledge..
All I know is that the port no longer compiles under amd64.
though It did some months back.
How it selects the compiler to use I have no clue..
I got my pkg using make.conf but that is not a sustainable answer.


   /usr/include
End of search list.


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

Hi Julian,

As Jan said, port's Makefile is broken in a sense that not all of its binary
targets respect CXXFLAGS. I took a stab at unbreaking the build, see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230466

Sorry to take so long to reply. Thanks a lot for the patch.


BTW, it compiles fine on 112a and 104i with base clang, not sure why original
Makefile had USE_GCC.

Ok so thanks to everyone.  It's been educational.
Will the change in the bug be checked in?

Every few months I recompile all the packages we need at $JOB and each 
time the hope is that we can get all the way through,
tough there is nearly always one that falls over in some new way.. (we 
install a couple of hundred packages.
this time it was sysutils/google-compute-engine-oslogin (and a couple 
of others..)
Hopefully the fixes that go in this time will give me (false) hope of 
a clean run next time  :-)








Because of my lack of experience.


Ah but you did do the port, for which I thank you!.




I couldn't reproduce the error with USE_GCC though https://paste.ee/p/FXNiv
Maybe it is something in my environment (g++6 maybe).

Thank you all
Helen



___
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: has a framework change broken sysutils/google-compute-engine-oslogin?

[Julian Elischer]

On 8/8/18 6:30 pm, Jan Beich wrote:

Julian Elischer  writes:


g++ -O2 -pipe -DPANZURA_DEV -DPZ_LONGNAMES -fstack-protector -isystem
/usr/local/include -fno-strict-aliasing -isystem /usr/local/include
-fPIC -c pam_module/pam_oslogin_login.cc -o
pam_module/pam_oslogin_login.o
g++ -fstack-protector -I/usr/local/include/json-c -o
google_authorized_keys authorized_keys/authorized_keys.cc
utils/oslogin_utils.cc -lcurl -ljson-c
g++ -fstack-protector -Wall -Wstrict-prototypes -fPIC -shared
-Wl,-soname,libnss_cache_oslogin.so.2 -o
libnss_cache_google-compute-engine-oslogin-1.3.0.so
libnss_cache_oslogin/nss_cache_oslogin.o
libnss_cache_oslogin/compat/getpwent_r.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory

- GCC 4.2.1 (patched) from base system is not a supported configuration
   on i386/amd64/aarch64/armv6/armv7
- C*FLAGS aren't consistently respected, see
   https://wiki.freebsd.org/WarnerLosh/UsrLocal#Include_paths
   https://www.freebsd.org/doc/en/books/porters-handbook/dads-cflags.html

$ g++7 -v -xc++ -
[...]
ignoring nonexistent directory 
"/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.3.0/include-fixed"
ignoring nonexistent directory 
"/usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.3.0/../../../../../x86_64-portbld-freebsd12.0/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/local/lib/gcc7/include/c++/
  /usr/local/lib/gcc7/include/c++//x86_64-portbld-freebsd12.0
  /usr/local/lib/gcc7/include/c++//backward
  /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.3.0/include
  /usr/local/include <-- HERE is why pkg-fallout@ is silent

Sorry you are out of my area of knowledge..
All I know is that the port no longer compiles under amd64.
though It did some months back.
How it selects the compiler to use I have no clue..
I got my pkg using make.conf but that is not a sustainable answer.


  /usr/include
End of search list.



___
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: has a framework change broken sysutils/google-compute-engine-oslogin?

[Julian Elischer]

On 8/8/18 2:30 pm, Julian Elischer wrote:

On 8/8/18 1:59 pm, Fernando Apesteguía wrote:
On Wed, Aug 8, 2018 at 7:40 AM Julian Elischer  
wrote:

On 8/8/18 1:02 pm, Julian Elischer wrote:

It says it can not find the file curl/curl.h which IS PRESENT as
/usr/local/include/curl/curl.h

There are Makefile BROKEN annotations for this error in mips etc but
I'm seeing it now on amd64.

I would think that all ports should have /usr/local/include in their
Include list but maybe not?

is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin' 


g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c
-c utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory


I'm guessing there should be but who's responsibility is it to put
it there?

I got past it by adding (temporarily) the following to make.conf

for some faiign g++ commands
CFLAGS+-I /usr/local/include

and for others
LDFLAGS+=-L/usr/local/lib -I /usr/local/include

but that stinks

better suggestions welcome..

Is this what you are looking for?

USES=localbase

https://www.freebsd.org/doc/en/books/porters-handbook/uses-localbase.html 



nope..
g++  -fstack-protector -Wall -Wstrict-prototypes -fPIC -shared 
-Wl,-soname,libnss_cache_oslogin.so.2 -o 
libnss_cache_google-compute-engine-oslogin-1.3.0.so 
libnss_cache_oslogin/nss_cache_oslogin.o 
libnss_cache_oslogin/compat/getpwent_r.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory


seems that --system is being inconsistently applied

g++ -O2 -pipe -DPANZURA_DEV -DPZ_LONGNAMES -fstack-protector -isystem 
/usr/local/include -fno-strict-aliasing  -isystem /usr/local/include 
-fPIC -c pam_module/pam_oslogin_login.cc -o pam_module/pam_oslogin_login.o
g++  -fstack-protector -I/usr/local/include/json-c -o 
google_authorized_keys authorized_keys/authorized_keys.cc 
utils/oslogin_utils.cc -lcurl -ljson-c
g++  -fstack-protector -Wall -Wstrict-prototypes -fPIC -shared 
-Wl,-soname,libnss_cache_oslogin.so.2 -o 
libnss_cache_google-compute-engine-oslogin-1.3.0.so 
libnss_cache_oslogin/nss_cache_oslogin.o 
libnss_cache_oslogin/compat/getpwent_r.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory



(and where/how?)


Julian



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



___
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: has a framework change broken sysutils/google-compute-engine-oslogin?

[Julian Elischer]

On 8/8/18 1:59 pm, Fernando Apesteguía wrote:

On Wed, Aug 8, 2018 at 7:40 AM Julian Elischer  wrote:

On 8/8/18 1:02 pm, Julian Elischer wrote:

It says it can not find the file curl/curl.h which IS PRESENT as
/usr/local/include/curl/curl.h

There are Makefile BROKEN annotations for this error in mips etc but
I'm seeing it now on amd64.

I would think that all ports should have /usr/local/include in their
Include list but maybe not?

is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin'
g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c
-c utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory


I'm guessing there should be but who's responsibility is it to put
it there?

I got past it by adding (temporarily) the following to make.conf

for some faiign g++ commands
CFLAGS+-I /usr/local/include

and for others
LDFLAGS+=-L/usr/local/lib -I /usr/local/include

but that stinks

better suggestions welcome..

Is this what you are looking for?

USES=localbase

https://www.freebsd.org/doc/en/books/porters-handbook/uses-localbase.html


nope..
g++  -fstack-protector -Wall -Wstrict-prototypes -fPIC -shared 
-Wl,-soname,libnss_cache_oslogin.so.2 -o 
libnss_cache_google-compute-engine-oslogin-1.3.0.so 
libnss_cache_oslogin/nss_cache_oslogin.o 
libnss_cache_oslogin/compat/getpwent_r.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory



(and where/how?)


Julian



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



___
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: has a framework change broken sysutils/google-compute-engine-oslogin?

[Julian Elischer]

On 8/8/18 1:59 pm, Fernando Apesteguía wrote:

On Wed, Aug 8, 2018 at 7:40 AM Julian Elischer  wrote:

On 8/8/18 1:02 pm, Julian Elischer wrote:

It says it can not find the file curl/curl.h which IS PRESENT as
/usr/local/include/curl/curl.h

There are Makefile BROKEN annotations for this error in mips etc but
I'm seeing it now on amd64.

I would think that all ports should have /usr/local/include in their
Include list but maybe not?

is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin'
g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c
-c utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or
directory


I'm guessing there should be but who's responsibility is it to put
it there?

I got past it by adding (temporarily) the following to make.conf

for some faiign g++ commands
CFLAGS+-I /usr/local/include

and for others
LDFLAGS+=-L/usr/local/lib -I /usr/local/include

but that stinks

better suggestions welcome..

Is this what you are looking for?

USES=localbase

https://www.freebsd.org/doc/en/books/porters-handbook/uses-localbase.html


yeah that would help for  libs but not for the includes..  actually 
maybe it would't help because I'd still want /lib in the path.
the link you give says that LIBS would be replaced?  what does that 
actually mean?





(and where/how?)


Julian



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



___
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: has a framework change broken sysutils/google-compute-engine-oslogin?

[Julian Elischer]

On 8/8/18 1:02 pm, Julian Elischer wrote:
It says it can not find the file curl/curl.h which IS PRESENT as 
/usr/local/include/curl/curl.h


There are Makefile BROKEN annotations for this error in mips etc but 
I'm seeing it now on amd64.


I would think that all ports should have /usr/local/include in their 
Include list but maybe not?


is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory 
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin'
g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c 
-c utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory



I'm guessing there should be but who's responsibility is it to put 
it there?


I got past it by adding (temporarily) the following to make.conf

for some faiign g++ commands
CFLAGS+-I /usr/local/include

and for others
LDFLAGS+=-L/usr/local/lib -I /usr/local/include

but that stinks

better suggestions welcome..



(and where/how?)


Julian



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

has a framework change broken sysutils/google-compute-engine-oslogin?

[Julian Elischer]

It says it can not find the file curl/curl.h which IS PRESENT as 
/usr/local/include/curl/curl.h


There are Makefile BROKEN annotations for this error in mips etc but 
I'm seeing it now on amd64.


I would think that all ports should have /usr/local/include in their 
Include list but maybe not?


is this something that is supplied by the framework?


ports tree checked out from a week ago and today... same issue.


there is no /usr/local/include in the failing command line...

gmake[1]: Entering directory 
'/usr/ports/sysutils/google-compute-engine-oslogin/work/compute-image-packages-20180611/google_compute_engine_oslogin'
g++ -O2 -pipe  -fstack-protector  -fPIC -I/usr/local/include/json-c -c 
utils/oslogin_utils.cc -o utils/oslogin_utils.o
utils/oslogin_utils.cc:16:23: error: curl/curl.h: No such file or 
directory



I'm guessing there should be but who's responsibility is it to put it 
there?


(and where/how?)


Julian



___
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: Archives of last quarterly package builds?

[Julian Elischer]

On 3/8/18 11:17 am, Kurt Jaeger wrote:

Hi!


I've asked for this but the answer is
"no we don't do that..  and have no plans to".

What is the rationale?

I don't know, but as the setup of your own package builder box
is simple enough -- wouldn't that be an alternative for you ?
If the answer is always "don't use the quarterly packages but create 
your own, then why have them at all?"


Think about it.. Every three months we spend time adding bug fixes and 
stability fixes to a branch.
then just as it's getting good..    we delete all the pkgs.  It makes 
no sense at all.



___
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: Reproducibility packages

[Julian Elischer]

On 4/8/18 7:44 am, Yuet-nan Wong via freebsd-ports wrote:

Are FreeBSD ports supposed to change version numbers when a change is made?
Issue is reproducibility is void when packages have changed like suricata or 
the many changes to binutils. Some removing package content but version not 
changed. Need to diff Makefile is inefficient.
___
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"


yes and no.

When any change is made to a port (or any component of it) at least 
the last digit (after the '_') should be changed.


However if it has a dependency on another package, and THAT package 
changes it's version number, then the dependency information in the 
first package will reflect the new dependency, but the name of that 
package will not be changed.. so you could say it is imperfect in 
noting any external changes. I don't see a way around that at the 
current time.



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

Automake creation error.. generic or just me?

[Julian Elischer]

I'm not exactly sure where the error come from.. possibly the find, if 
stderr and stdout are not synchronous.


Has anyone else seen this?  or understand it?


===>  Building for automake-1.16.1
--- doc/aclocal.1 ---
--- doc/automake.1 ---
--- bin/automake ---

[...]ls pkg/All

/usr/bin/make  install-data-hook
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver'
 chmod +x 
'/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh'
find: 
/usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl: No 
such file or directory

> Compressing man pages (compress-man)
===>  Installing for automake-1.16.1
===>   Registering installation for automake-1.16.1 as automatic
*** Error code 70

[...]


___
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: Archives of last quarterly package builds?

[Julian Elischer]

On 22/7/18 5:59 am, grarpamp wrote:

Packages are delivered via a single quarterly label here

https://pkg.freebsd.org/FreeBSD:11:amd64/quarterly/

which corresponds to the latest quarterly branch label here

https://svnweb.freebsd.org/ports/branches/?sortby=date#dirlist


However, similar to how the tags here

https://svnweb.freebsd.org/ports/tags/?sortby=date#dirlist

are archived here

https://pkg.freebsd.org/FreeBSD:11:amd64/
as these
https://pkg.freebsd.org/FreeBSD:11:amd64/release_[n]


The last "ie: final" builds of each quarterly branch before they
roll over should also be moved off into their own archived
quarterly directories as


I've asked for this but the answer is "no we don't do that..  and have 
no plans to".
Which is a putty as it means you need to make your own snapshots if 
you want to have any reproducability.
It no linger matters to me as we now roll all our own packages from 
source (we have private OS changes

that make this a requirement), but it was a sore point for many years.




https://pkg.freebsd.org/FreeBSD:11:amd64/Q[n]

For example /quarterly/ should be repointed from 2018Q2
to 2018Q3, leaving 2018Q2 as a live "pkg" accessible archive.


Eventually all such archives could be moved to historical
archive server under typical release support expiry periods.


This would also serve critical purpose as an independant
original remote repository for validating local package / file
signatures against compromise, corruption, loss.


For example, does the last 2018Q2 (or older ones) still exist
anywhere for users to reference and use?

no.


___
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: anyone know how to shut these ports up?

[Julian Elischer]

On 30/5/18 12:38 am, Brooks Davis wrote:

On Sat, May 26, 2018 at 02:07:43PM +0800, Julian Elischer wrote:

several ports, when compiled output a MASS of stuff that looks like:

   No recipe for '../gnulib/m4/stdio_h.m4' and no prerequisites
actually changed.
   No need to remake target '../gnulib/m4/stdio_h.m4'.
   Considering target file '../gnulib/m4/stdlib_h.m4'.
  ?? Looking for an implicit rule for '../gnulib/m4/stdlib_h.m4'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/stdlib_h.m4,v'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/RCS/stdlib_h.m4,v'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/RCS/stdlib_h.m4'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/s.stdlib_h.m4'.
  ?? Trying pattern rule with stem 'stdlib_h.m4'.
  ?? Trying implicit prerequisite '../gnulib/m4/SCCS/s.stdlib_h.m4'.
  ?? No implicit rule found for '../gnulib/m4/stdlib_h.m4'.
  ?? Finished prerequisites of target file '../gnulib/m4/stdlib_h.m4'.
   No recipe for '../gnulib/m4/stdlib_h.m4' and no prerequisites
actually changed.
   No need to remake target '../gnulib/m4/stdlib_h.m4'.
   Considering target file '../gnulib/m4/stpcpy.m4'.
  ?? Looking for an implicit rule for '../gnulib/m4/stpcpy.m4'.

...?? except for about 20 minutes (my connection to the machine doing
the work is not that fast)

That is very weird output.  It looks like gmake is being called with -d
which certainly shouldn't be the case.


I suspect print/texinfo is one (it's kind of hard to tell exactly when
they go off to do dependencies..)

Does anyone know the secret to shutting up all this debug stuff?

It literally pumps out so much crap that the rest of he family gets
bumped off the internet connection..

If you must run interactive, run tmux or screen and switch virtual
terminals.  I find the latter to be really helpful when I've got a high
bandwidth-delay product connection (e.g.  Washington, USA to the UK).
I can get back to the prompt much faster after a build success/failure
then if I have to wait for everything to clear the pipe.
Unfortunately, running tmux, the data comes out of tmux so fast that I 
can not get a "switch windows" signal down to tmux.
in actuality the process has probably finushed, but I have quite a few 
minutes of solid data queued up between the Server and me in AUS.
for example, if I hit ^Z it eventually stops..  after that make has 
completed..  same thing with attempts to switch windows on tmux or screen.




-- Brooks



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

anyone know how to shut these ports up?

[Julian Elischer]

several ports, when compiled output a MASS of stuff that looks like:

 No recipe for '../gnulib/m4/stdio_h.m4' and no prerequisites 
actually changed.

 No need to remake target '../gnulib/m4/stdio_h.m4'.
 Considering target file '../gnulib/m4/stdlib_h.m4'.
  Looking for an implicit rule for '../gnulib/m4/stdlib_h.m4'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/stdlib_h.m4,v'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/RCS/stdlib_h.m4,v'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/RCS/stdlib_h.m4'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/s.stdlib_h.m4'.
  Trying pattern rule with stem 'stdlib_h.m4'.
  Trying implicit prerequisite '../gnulib/m4/SCCS/s.stdlib_h.m4'.
  No implicit rule found for '../gnulib/m4/stdlib_h.m4'.
  Finished prerequisites of target file '../gnulib/m4/stdlib_h.m4'.
 No recipe for '../gnulib/m4/stdlib_h.m4' and no prerequisites 
actually changed.

 No need to remake target '../gnulib/m4/stdlib_h.m4'.
 Considering target file '../gnulib/m4/stpcpy.m4'.
  Looking for an implicit rule for '../gnulib/m4/stpcpy.m4'.

...  except for about 20 minutes (my connection to the machine doing 
the work is not that fast)



I suspect print/texinfo is one (it's kind of hard to tell exactly when 
they go off to do dependencies..)


Does anyone know the secret to shutting up all this debug stuff?

It literally pumps out so much crap that the rest of he family gets 
bumped off the internet connection..


(including any other session I may have running)


___
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: Practice of "Sponsored by" in commit messages

[Julian Elischer]

On 15/5/18 7:40 am, John W. O'Brien wrote:

Hello FreeBSD Ports,

The Committer's Guide section on Commit Log Messages [0], doesn't cover
the use of the "Sponsored by" key word. As a non-committer contributor,
it only recently occurred to me to wonder what work that credit is
intended to represent, and whether some light definition would be
helpful to reduce ambiguity.

When a committer credits a sponsor of theirs, from which the contributor
received no sponsorship, the portrayal feels a little awkward. Does this
strike the list as a problem, and if so, how ought it be solved?

To make this concrete, allow me to illustrate the situation.

Alice, working on her own time, prepares and contributes a patch. Bob,
who works for Acme Corp, reviews and commits the patch on company time.
The commit message includes "Sponsored by: Acme Corp". Alice eagerly
awaits her check from Acme Corp. Should the commit message have read
"Sponsored by: Acme Corp (Bob)"?


Probably not for just a review, unless it was pretty in depth and took 
many hours.

However we want to give some sort of acknowledgement
to companies that do allow their work to be incorporated, and who allow
their employees to do some FreeBSD work as part of their duties.
It also makes their name familiar to the readers of the commit emails
and often results in others seeking work there etc.
 "Sponsored by:"  generally means "some (maybe small) part of this 
work was developed
by someone being paid". It does not specify how much, and it is 
generally left to the committer
to decide if it was meaningful.   In some cases it is deliberately NOT 
entered despite
the developer being paid. (e.g. when a company is in stealth mode, or 
when some political

issue is relevant and people don't want to draw attention).



This could be extensible to multiple sponsorships. If, instead, Alice
prepares the patch having received a grant to do so from Best Sys Dev,
the commit message could state "Sponsored by: Acme Corp (Bob), Best Sys
Dev (Alice)".

[0]
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#commit-log-message

PS: I realize that this issue transcends ports, but it's not clear where
I should send this instead, and this list seems like it would have a
reasonably high concentration of people with a stake in the discussion.



___
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: request for a new port + package

[Julian Elischer]

On 7/5/18 7:03 am, Mateusz Piotrowski wrote:

On Fri, 20 Apr 2018 04:22:32 +0800
Julian Elischer  wrote:


On 9/4/18 7:15 pm, Eugene Grosbein wrote:

On 09.04.2018 14:16, Mayuresh Kathe wrote:


how do i place a request for a new port + package?
the sources for my requested tool are available at
http://www.t3x.org/files/zenlisp.zip and the author of that tool has
granted permission to move it from the existing "public domain"
license to any "bsdl" license.

The package is created automatically once new port is created and
added to FreeBSD Ports collection. You can create and submit new
port yourself, just read
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/

It seems to me that the description of what to do to make a port
is somewhat recursive by which I mean you need to understand
what it says before you read it. if you don't already know the jargon,
it is all Greek. (Apologies to any Greeks on the list).
I think it would be a pretty cool project to write a tool that asks
lots of questions and then eventually spits out a port Makefile.
it could allow the user to browse to places and then analyse the
links used etc.
I think the port writer's handbook is a bit intimidating to new ports
submitters.

You might be interested in this: https://reviews.freebsd.org/D12921

Cheers :)

MP

great.. when I read it before it was hard to read but 
http://envirobotics.ca/portershb/tools-introduction.html


makes it readable.


___
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: request for a new port + package

[Julian Elischer]

On 9/4/18 7:15 pm, Eugene Grosbein wrote:

On 09.04.2018 14:16, Mayuresh Kathe wrote:


how do i place a request for a new port + package?
the sources for my requested tool are available at
http://www.t3x.org/files/zenlisp.zip and the author of that tool has
granted permission to move it from the existing "public domain" license
to any "bsdl" license.

The package is created automatically once new port is created and added
to FreeBSD Ports collection. You can create and submit new port yourself,
just read https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/


It seems to me that the description of what to do to make a port
is somewhat recursive by which I mean you need to understand
what it says before you read it. if you don't already know the jargon,
it is all Greek. (Apologies to any Greeks on the list).
I think it would be a pretty cool project to write a tool that asks
lots of questions and then eventually spits out a port Makefile.
it could allow the user to browse to places and then analyse the
links used etc.
I think the port writer's handbook is a bit intimidating to new ports 
submitters.






___
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: reccomendation for a building architecture schematic diagram editor ?

[Julian Elischer]

On 16/4/18 4:32 pm, Kurt Jaeger wrote:

Hi!


Only port I can think of is xfig, which I've used for other things
https://svnweb.freebsd.org/ports/head/graphics/xfig/
but wondering if something else more appropriate exists ?

If I did drawings in the past, I used xfig. graphics/dia is also
usable. Then there's kdiagram, but I never used it.


one of the oldest drawing tools ever, tgif ...

I find it way better than some newer, fancier packages.


___
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: 6100 subdirectories in /usr/ports/devel!

[Julian Elischer]

On 29/12/17 5:16 am, Bob Willcox wrote:

On Fri, Dec 29, 2017 at 03:54:28AM +0700, Eugene Grosbein wrote:

29.12.2017 3:36, Bob Willcox wrote:


Does anyone else feel that having 6100 subdirectories (939 are for py-* stuff)
is a bit excessive?

It is. But py-* stuff has second place only:

$ ls /usr/ports/devel | sed 's/-.*//' | sort | uniq -c | sort -rn | head
1908 p5
  964 py
  600 rubygem
  280 hs
  176 pear
   57 R
   56 pecl
   48 elixir
   47 geany
   43 erlang

In fact, ports/devel is first but not only category having similar problem with 
p5-* stuff:

$ cd /usr/ports
$ find . -type d -mindepth 1 -maxdepth 1 | while read category; do printf "%15s 
" ${category#./}; ls $category | sed 's/-.*//' | sort | uniq -c | sort -rn | head 
-1; done | sort -k 2,2 -rn | head -15
   devel 1908 p5
 www  807 p5
textproc  617 p5
 net  327 p5
   databases  259 p5
security  258 p5
math  146 p5
mail  145 p5
graphics  100 p5
 editors   98 libreoffice
sysutils   75 rubygem
  converters   72 p5
misc   63 p5
net-mgmt   56 p5
x11-toolkits   49 p5


Yeah, I happened to notice the py-* stuff due to some problems I have been
having with synth. I did notice the large number of p5-* subdirs but didn't
count them.  :)

Certainly seems to be out of control...

the py and p5 stuff is a symptom of another problem, which is that we 
are only second level for those files...


the correct behaviour in my point of view is for our packages/ports 
system to delegate to pypi or similar for python and to CPAN for perl.


maybe with the ability to add some patches on the way through.. There 
is just too much going on there for us to follow properly.



___
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: 6100 subdirectories in /usr/ports/devel!

[Julian Elischer]

On 29/12/17 4:36 am, Bob Willcox wrote:

Does anyone else feel that having 6100 subdirectories (939 are for py-* stuff)
is a bit excessive? I hadn't really looked at the number of subdirectories
there in quite a long time and was shocked to see how meny there are now.


yeah we really could do with a re-org..

like the languages (hungarian, japanese etc, not C, Perl ) shoudl be 
two levels down and we could do with a whole multi level setup.


(why are we limited to just one level of directories?)


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

java pt failure

[Julian Elischer]

Hello ports people,

When I was compiling the openjdb8 port I got the following errors. 
This is on -current from a couple of weeks ago with a ports tree from 
459153



Compiling ../generated/adfiles/ad_x86_64_format.cpp
In file included from :391:
In file included from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/precompiled/precompiled.hpp:29:
In file included from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/asm/assembler.hpp:28:
In file included from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/asm/codeBuffer.hpp:28:
In file included from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/code/oopRecorder.hpp:28:
In file included from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/memory/universe.hpp:29:
In file included from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/utilities/array.hpp:29:
In file included from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/memory/allocation.inline.hpp:28:
In file included from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21: 
error: unknown token in expression

  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
    ^
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:48:24: 
note: expanded from macro 'LOCK_IF_MP'

#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "
   ^
:1:30: note: instantiated into assembly here
    cmp $0, %edx; je 1f; lock; 1: cmpxchgl %ecx,(%rdi)
    ^


does anyone know if this has been generally seen and if so was it 
fixed? (should I try move forwards?)


the whole project compile takes me over a day so moving up is not to 
be taken lightly if it won't fix it.


Julian

___
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: Of LSOF

[Julian Elischer]

On 27/12/17 7:14 am, Dave Horsfall wrote:

aneurin# freebsd-version
10.4-RELEASE-p5
aneurin# which lsof
/usr/local/sbin/lsof
aneurin# lsof > /dev/null
lsof: WARNING: compiled for FreeBSD release 10.3-RELEASE-p22; this 
is 10.4-RELEASE-p3.

aneurin# pkg upgrade lsof
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.
aneurin#

Building it from ports updated it (as I probably did before), but 
should not the binary have been updated?  Or are binaries not 
available for all ports (I guess)?


there is no per release active branch for pkgs, just one for the whole 
branch.


Because we keep binary compatibility we compile for the oldest 
supported branch. Maybe we should change the test to be less specific, 
but lsof breaks a lot of rules so maybe it matters more than in other 
programs.



___
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: Flavor part of package origin?

[Julian Elischer]

On 11/12/17 9:38 pm, Mathieu Arnold wrote:

Le 11/12/2017 à 10:12, Stefan Esser a écrit :

$ pkg info -o '*setuptools*'
py27-setuptools-36.5.0 devel/py-setuptools@py27
py36-setuptools-36.5.0 devel/py-setuptools@py36


I really do not like the look of this. The origin always has been a
directory name, with this change, it would become some abstract thing.
don't concentrate on the syntax, but the idea.. It SHOULD somehow be 
represented in the origin I think..

or the origin becomes useless.






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

somone able to make a simple fix to net/ftp?

[Julian Elischer]

change 445013 added the following patch. unfortunatly it need to to be 
only applied if we are in 11 or 12.


Two possibilities:

1/ add a term to only act if __FreeBSD_version < 110

or

2/ don't apply the patch under 10x.

not sure which is easier.


Julian


1 
 
	--- lft_lib.h.orig 2017-07-04 09:02:47 UTC
2 
 
	+++ lft_lib.h
3 
 
	@@ -277,7 +277,7 @@ typedef struct _incomicmpicmp
4 
 
	#define EVT_INCOMING_ICMP_ICMP 75
5 
 
	#define EVT_RCVD_ICMP_ICMP 76
6 
 
	
7 
 
	-#if defined(BSD_IP_STACK) && !defined(OPENBSD)
8 
 
	+#if defined(BSD_IP_STACK) && !defined(OPENBSD) && !defined(__FreeBSD__)
9 
 
	#define SCREWED_IP_LEN
10 
 
	#endif


___
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: gcc6 port just 'stopping'. ZZZZZZZzzzzz

[Julian Elischer]

On 29/11/17 1:38 am, Julian Elischer wrote:

anyone have a reason for this? (or seen it before)
don't worry.. I deleted the work dir and redid it by hand and all was 
fine.





ports tree rev 451075

===>   gcc6-6.4.0_2 depends on file: /usr/local/bin/as - found
===>   gcc6-6.4.0_2 depends on executable: gmake - found
===>   gcc6-6.4.0_2 depends on package: libiconv>=1.14_11 - found
===>   gcc6-6.4.0_2 depends on file: /usr/local/bin/as - found
===>   gcc6-6.4.0_2 depends on package: perl5>=5.24<5.25 - found
/usr/bin/env  dp_RAWDEPENDS="libgmp.so:math/gmp 
libmpfr.so:math/mpfr  libmpc.so:math/mpc" dp_DEPTYPE="LIB_DEPENDS"  
dp_DEPENDS_TARGET="install" dp_DEPENDS_PRECLEAN=""  
dp_DEPENDS_CLEAN=""  dp_DEPENDS_ARGS="" dp_USE_PACKAGE_DEPENDS=""  
dp_USE_PACKAGE_DEPENDS_ONLY="" 
dp_PKG_ADD="/usr/local/sbin/pkg-static add" 
dp_PKG_INFO="/usr/local/sbin/pkg-static info -g" 
dp_WRKDIR="/usr/ports/lang/gcc6/work" dp_PKGNAME="gcc6-6.4.0_2" 
dp_STRICT_DEPENDS="" dp_LOCALBASE="/usr/local"  dp_LIB_DIRS="/lib 
/usr/lib /usr/local/lib"  dp_SH="/bin/sh" 
dp_SCRIPTSDIR="/usr/ports/Mk/Scripts"  PORTSDIR="/usr/ports" 
dp_MAKE="/usr/bin/make"  /bin/sh /usr/ports/Mk/Scripts/do-depends.sh
===>   gcc6-6.4.0_2 depends on shared library: libgmp.so - found 
(/usr/local/lib/libgmp.so)
===>   gcc6-6.4.0_2 depends on shared library: libmpfr.so - found 
(/usr/local/lib/libmpfr.so)
===>   gcc6-6.4.0_2 depends on shared library: libmpc.so - found 
(/usr/local/lib/libmpc.so)echo "===>  Configuring for gcc6-6.4.0_2"

===>  Configuring for gcc6-6.4.0_2
cd /usr/ports/lang/gcc6/work/gcc-6.4.0 ; contrib/gcc_update --touch

[ several hours pass ]

^C

gcc is getting compiled as a prerequisite of gdb 8.0.1



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

gcc6 port just 'stopping'. ZZZZZZZzzzzz

[Julian Elischer]

anyone have a reason for this? (or seen it before)


ports tree rev 451075

===>   gcc6-6.4.0_2 depends on file: /usr/local/bin/as - found
===>   gcc6-6.4.0_2 depends on executable: gmake - found
===>   gcc6-6.4.0_2 depends on package: libiconv>=1.14_11 - found
===>   gcc6-6.4.0_2 depends on file: /usr/local/bin/as - found
===>   gcc6-6.4.0_2 depends on package: perl5>=5.24<5.25 - found
/usr/bin/env  dp_RAWDEPENDS="libgmp.so:math/gmp libmpfr.so:math/mpfr  
libmpc.so:math/mpc" dp_DEPTYPE="LIB_DEPENDS"  
dp_DEPENDS_TARGET="install" dp_DEPENDS_PRECLEAN=""  
dp_DEPENDS_CLEAN=""  dp_DEPENDS_ARGS="" dp_USE_PACKAGE_DEPENDS=""  
dp_USE_PACKAGE_DEPENDS_ONLY="" dp_PKG_ADD="/usr/local/sbin/pkg-static 
add" dp_PKG_INFO="/usr/local/sbin/pkg-static info -g" 
dp_WRKDIR="/usr/ports/lang/gcc6/work" dp_PKGNAME="gcc6-6.4.0_2"  
dp_STRICT_DEPENDS="" dp_LOCALBASE="/usr/local"  dp_LIB_DIRS="/lib 
/usr/lib /usr/local/lib"  dp_SH="/bin/sh" 
dp_SCRIPTSDIR="/usr/ports/Mk/Scripts"  PORTSDIR="/usr/ports" 
dp_MAKE="/usr/bin/make"  /bin/sh /usr/ports/Mk/Scripts/do-depends.sh
===>   gcc6-6.4.0_2 depends on shared library: libgmp.so - found 
(/usr/local/lib/libgmp.so)
===>   gcc6-6.4.0_2 depends on shared library: libmpfr.so - found 
(/usr/local/lib/libmpfr.so)
===>   gcc6-6.4.0_2 depends on shared library: libmpc.so - found 
(/usr/local/lib/libmpc.so)echo "===>  Configuring for gcc6-6.4.0_2"

===>  Configuring for gcc6-6.4.0_2
cd /usr/ports/lang/gcc6/work/gcc-6.4.0 ; contrib/gcc_update --touch

[ several hours pass ]

^C

gcc is getting compiled as a prerequisite of gdb 8.0.1



___
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: can I get a 'mentor' who can guide me on the topic of python module ports?

[Julian Elischer]

On 28/11/17 11:09 pm, Chris H wrote:

On Tue, 28 Nov 2017 07:29:10 +0100 "Kurt Jaeger"  said


Hi!

> >> I have a requirement from $JOB to install some software (the 
python

> >> based Azure SDK actually) [...]
> > I suggest you put your initial version up somewhere and
> > then start ask questions here.
> >
> > It might be faster if many people submit hints than if
> > only one person gives you hints 8-}
> So far I don't know enough to put up anything.

Ok, then there are two steps for the start:

1) Where is the distfile ? Because the first step would be to
create a ports Makefile that downloads that distfile.

Is it this ?

https://go.microsoft.com/fwlink/?LinkId=253472&clcid=0x409

2) Then, one has to dig into

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html 



to get to a initial Makefile.

For this step: Install ports-mgmt/porttools and use

port create

Extra homework: Think about a nice name 8-}


Not to discount anything Kurt as already suggested
But I'd just like to throw in a couple of things that come to mind.
You can think of this as a short learning curve, or the highway to 
hell.

You decide.

1) With a brand new port; I have often found it makes it quicker to 
find a
already existing port that closely resembles the one I'm attempting 
to create,

and either gut it, or simply replace the parts required.

2) Given it's the Python Azure SDK. I'd probably go with the 
following location:

https://github.com/Azure/azure-sdk-for-python
The opening page nearly creates the port for you. :)


well it may for you but for me it's all a learning curve where I need 
to discover the significance of every little thing.


thanks though..


HTH


every bit helps



--Chris



--
p...@opsec.eu    +49 171 3101372 3 
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"

can I get a 'mentor' who can guide me on the topic of python module ports?

[Julian Elischer]

I have a requirement from $JOB to install some software (the python 
based Azure SDK actually) and I'd like to see if I can beat it into 
the form of a port so that others can solve this issue as well.  My 
problem is that I don't know enough about how ports deal with python,  
nor for that matter how python (via pip) handles it's own modules.
If there is someone on this mailing list who has the time and patience 
to help me by answering stupid questions as I come up with them, and 
really understands the ports/python  interaction, I'd love to hear 
from you.


thanks

Julian

___
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: vim language bindings

[Julian Elischer]

On 14/10/17 12:21 am, Adam Weinberger wrote:

Hello,

I'm trying to get a feel for how many people utilize utilize vim's language 
bindings. Note that this does NOT include syntax highlighting, indenting, or 
anything related to editing language-specific files. This is calling external 
scripting languages and interactive debugging within vim.

Right now, vim installs Lua, Perl, Python, Ruby, and TCL for everybody, and I'm 
not sure whether anybody actually intentionally uses Lua or TCL anymore. Python 
hooks are definitely staying, but if you use any other language bindings, 
please reply and tell me which ones.

Thanks!

# Adam



One hopes vim-lite does not install those, right?

___
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: anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

[Julian Elischer]

On 4/10/17 12:56 am, Ian Lepore wrote:

On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote:

Our 10.4 system is using gcc (for now).

when we compile the devel/binutils port, we get a failure with a
bunch
of these errors:


`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section
`.rodata' of aarch64.o: defined in discarded section
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__
N_110Stub_tableILi64ELb1EEE]'
of aarch64.o
`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section
`.rodata' of aarch64.o: defined in discarded section
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__
N_110Stub_tableILi64ELb0EEE]'
of aarch64.o


I managed to defeat these one before but I forget how.

possibly the answer is to use clang/clang++ for this item but I
tried
defining CC and CXX  to clang/clang++ in the Makefile but that
didn't
seem to help

there's probably a USE_CLANG option or something that I haven't seen.

We ran into the same thing recently at $work.  The root cause for us
involved having same-named classes in anonymous namespaces in different
compilation units.  The classes made reference to something that was
declared extern "C", bringing into play some rules about how C things
in anon namespaces really refer to the same global C object outside of
any namespace.  Then link-time optimization led to discarding the
object from one compilation unit, and that somehow resulted in
discarding the referenced extern "C" thing completely, even though it
was still referenced from the non-discarded instance of an object from
a different compilation unit.  Phew.

The same code has no problems with clang on freebsd 11, just with gcc
on 10.3.

So, for us the fix was a bit heavy-handed: we just renamed one of the
classes involved in the problem so that there were no longer any same-
named classes in anon namespaces in separate compilation units.
  Probably not a good option for you.  A fix involving compile options
might result in not discarding unreferenced segments at all, and with
templated code that might result in huge binaries.

Mixing clang-compiled and gcc-compiled c++ may give you grief with
exceptions and other things (it would on ARM on 10.x, but maybe not on
x86 arches).

-- Ian



thanks

the issue comes up in the binutils port which is a dependency of gdb.

I don't think we actually need to install the binutils port on our 
appliance, (and we only install gdb to generate backtraces on debug 
reports)


I just added CC=clang and CXX=clang++ in the makefile that called it 
and the problem seemed to go away.



All i wanted to do is get gdb compiled and I end up with gcc6, llvm 
and binutils (plus a whole lot more) as a bonus (plus an extra 30 
minutes of compile time)




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

anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

[Julian Elischer]

Our 10.4 system is using gcc (for now).

when we compile the devel/binutils port, we get a failure with a bunch 
of these errors:



`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section 
`.rodata' of aarch64.o: defined in discarded section 
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE]' 
of aarch64.o
`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section 
`.rodata' of aarch64.o: defined in discarded section 
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE]' 
of aarch64.o



I managed to defeat these one before but I forget how.

possibly the answer is to use clang/clang++ for this item but I tried 
defining CC and CXX  to clang/clang++ in the Makefile but that didn't 
seem to help


there's probably a USE_CLANG option or something that I haven't seen.


___
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: [maybe spam] New 2017Q4 branch

[Julian Elischer]

On 3/10/17 3:01 am, René Ladan wrote:
can we please have a way of finding out the revision at which the 
latest HEAD branch compile was done at?

(and for that matter the latest recompile on the quarterly branch).



Hi,

The 2017Q4 branch has been created. It means that the next update on the
quarterly packages will be on the 2017Q4 branch.

A lot of things happened in the last three months:
- pkg 1.10.1
- New USES: (none)
- Removed USES: execinfo twisted
- New keywords: (none)
- Removed keywords: (none)
- Default version of GCC switched to 6
- Firefox 56.0
- Firefox-esr 52.4.0
- Chromium 61.0.3163.100
- Ruby 2.2.8, 2.3.5, 2.4.1
- gcc 6.4.0
- ghc 8.0.2
- devel/cmake-modules merged into devel/cmake
- devel/cargo merged into lang/rust, as Cargo is now provided with Rust

Next quarterly package builds will start on Tuesday October 3th, at 1:00
PM and
should be available on your closest mirrors few days later.

For those stat nerds out there, here's what happened during the last 3
months on head:
Number of commits: 5876
Number of committers: 175
Most active committers:
1542  sunpoet
  261  amdmi3
  215  jbeich
  180  swills
  153  olgeni
  148  dbaio
  144  ultima
  126  antoine
  120  jrm
  104  mat
Diffstat: 16612 files changed, 245701 insertions(+), 152531 deletions(-)

and on the 2017Q3 branch:
Number of commits: 345
Number of committers: 54
Most active committers:
   59  feld
   51  jbeich
   40  tz
   18  sunpoet
   17  cpm
   13  koobs
   11  riggs
8  ultima
8  junovitch
8  joneum
Diffstat: 955 files changed, 13462 insertions(+), 16764 deletions(-)

Regards,
René Ladan



___
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: gettng the port revision number associated with the pkg repo. [Please?)

[Julian Elischer]

On 3/10/17 12:25 am, Simon Wright wrote:

On 02/10/2017 22:19, Julian Elischer wrote:

On 28/9/17 9:25 pm, Lowell Gilbert wrote:

Julian Elischer  writes:


On 26/9/17 10:07 pm, Lowell Gilbert wrote:

Julian Elischer  writes:

SO imagine that I needed to be ab;e to reproduce the pkg repo 
as of a
articular day, is there anywhere one can look to see the svn 
revision

number that corresponds to teh current pkg files.


I would like to take a snapshot at a particular revision.. but 
how do

I find out what the revision was when the build was kicked off?
If you want to do that after the fact, I'm not sure how you'd 
specify
when you want the information for. But if you do it when you 
kick off

the build (or if you haven't changed the tree since), svnversion(1)
will tell you.


I mean for the official pkg repo..

is there a file somewhere that says "these packages are as of 
r443234"?

Sorry that I misunderstood your intent.

I am fairly sure that what you want exists somewhere, but I can't 
find

it at the moment.


Unfortunately neither can I.


Hi Julian, Lowell

I need this information so that I can start my poudriere builds with 
my quite small list of ports with non-standard options from the same 
revision as the pkg system. I use a somewhat modified version of 
this script:


https://gist.github.com/reedacartwright/8622973baf89b263a6d7

Thanks to Reed for creating and maintaining this.

can we just find out who runs the poudriere instances and ask them to 
just append the svn revision number somewhere? or maybe even the 
poudriere commands  used..


*somewhere*?


___
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: gettng the port revision number associated with the pkg repo.

[Julian Elischer]

On 28/9/17 9:25 pm, Lowell Gilbert wrote:

Julian Elischer  writes:


On 26/9/17 10:07 pm, Lowell Gilbert wrote:

Julian Elischer  writes:


SO imagine that I needed to be ab;e to reproduce the pkg repo as of a
articular day, is there anywhere one can look to see the svn revision
number that corresponds to teh current pkg files.


I would like to take a snapshot at a particular revision.. but how do
I find out what the revision was when the build was kicked off?

If you want to do that after the fact, I'm not sure how you'd specify
when you want the information for. But if you do it when you kick off
the build (or if you haven't changed the tree since), svnversion(1)
will tell you.


I mean for the official pkg repo..

is there a file somewhere that says "these packages are as of r443234"?

Sorry that I misunderstood your intent.

I am fairly sure that what you want exists somewhere, but I can't find
it at the moment.


Unfortunately neither can I.


___
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: compler warnings in ports not supported in gcc 4.2.1 (stable/10)

[Julian Elischer]

On 24/9/17 5:58 am, Dimitry Andric wrote:

On 23 Sep 2017, at 23:42, Julian Elischer  wrote:

Trying to compile the emulators/open-vm-tools-nox11 port

but I end up dying with:

libtool: compile:  cc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"10.1.5\" 
"-DPACKAGE_STRING=\"open-vm-tools 10.1.5\"" -DPACKAGE_BUGREPORT=\"open-vm-tools-de...@lists.sourceforge.net\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"open-vm-tools\" -DVERSION=\"10.1.5\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DX_DISPLAY_MISSING=1 
-DHAVE_DLOPEN=1 -DNO_PROCPS=1 -DNO_DNET=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 
-DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DNO_XSM=1 -DNO_XCOMPOSITE=1 -DNO_MULTIMON=1 -I. 
-I/usr/ports/emulators/open-vm-tools-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include 
-I/usr/ports/emulators/open-vm-tools-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include -Wno-deprecated-declarations -isystem /usr/local/include -DUSING_AUTOCONF=1 
-DOPEN_VM_TOOLS -DNO_ICU -DVMX86_TOOLS -O2 -pipe -DPANZURA_DEV -DPZ_FBSD_10 -isystem /usr/local/include -fno-strict-aliasing -Wall -Werror -Wno-unused-function 
-Wno-address-of-packed-member -Wno-unknown-warning-option -Wno-unused -MT nicinfo_xdr.lo -MD -MP -MF .deps/nicinfo_xdr.Tpo -c nicinfo_xdr.c  -fPIC -DPIC -o .libs/nicinfo_xdr.o
cc1: error: unrecognized command line option "-Wno-address-of-packed-member"
cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
*** [nicinfo_xdr.lo] Error code 1


the system in question is compiled with gcc


is there a supported way of making the port not set those flags on each cc1 
command?

This appears to have been broken by r444773.  Try replacing
emulators/open-vm-tools/files/patch-configure.ac with the attached file.

-Dimitry

Dimitry, could you commit your fix.?  I confirm it corrects the problem.



___
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: [HEADUP] FLAVORS landing.

[Julian Elischer]

On 27/9/17 8:17 pm, Stefan Esser wrote:

Am 27.09.17 um 13:52 schrieb Julian Elischer:

On 27/9/17 4:20 pm, Matthew Seaman wrote:

Before this gets too far down the road I would like to suggest that we
quickly formalise some nomenclature
or we will have 200 different ideas as to how to do the same thing;

I would like to propose the following possible "examples of official"
flavours:
-nodocs ..  nearly every port has a DOCS option..  a way to
automatically turn it off globally and generate said pkgs would be good.
-minimal ..  smallest possible feature set.. probably used just to
satisfy some stupid dependency.
-kitchensink    ..  speaks for itself .. options lit up like a christmas
tree
-runtime    ..  no .a files, include files, development
documentation or sources ..
     might only contain a single libxx.so.N file, or a
single binary executable.

No, these are no good examples for flavours, as I understand them ...

why not?

that's part of the problem here. It's not really defined..
sub packages?  flavours?  what's the difference?
It's not defined and a dozen examples would go a long way to help.
I know what I want..  that's to be able to populate my appliance 
without all the stuff I don't need.
I also have a different requirement for my application build 
environment.  There I need all the includes etc.

How I get there is still a mystery.



These are possible typical sub-package categories, or rather you could
remove the DOCS from the base port, but offer a sub-package for them.


I'd rather think that NO-X11 might become a typical flavour, or the
dependency on a particular crypto library (e.g. openssl vs. libressl).


Regards, STefan
___
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: gettng the port revision number associated with the pkg repo.

[Julian Elischer]

On 26/9/17 10:07 pm, Lowell Gilbert wrote:

Julian Elischer  writes:


SO imagine that I needed to be ab;e to reproduce the pkg repo as of a
articular day, is there anywhere one can look to see the svn revision
number that corresponds to teh current pkg files.


I would like to take a snapshot at a particular revision.. but how do
I find out what the revision was when the build was kicked off?

If you want to do that after the fact, I'm not sure how you'd specify
when you want the information for. But if you do it when you kick off
the build (or if you haven't changed the tree since), svnversion(1)
will tell you.


I mean for the official pkg repo..

is there a file somewhere that says "these packages are as of r443234"?


___
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: [HEADUP] FLAVORS landing.

[Julian Elischer]

On 27/9/17 4:48 pm, Kirill Ponomarev via freebsd-ports wrote:

On 09/27, Tilman Keskinöz wrote:


On 2017-09-27 08:29, Matthew Seaman wrote:

On 27/09/2017 07:11, Julian Elischer wrote:

Is there a document/paper on what this is and what it's limits are etc?

https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
https://wiki.freebsd.org/Ports/FlavorsMigration


These pages don't contain any information what this is, how it differs
from/interacts with the OPTIONS framework and why I would want to
convert a port to FLAVORS.

I'd like to ask portmgr team to provide this information as well as
their vision for future correlations between OPTIONS, FLAVORS and
slave ports.

K.


I second this request.

more clarity in direction is needed.


___
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: [HEADUP] FLAVORS landing.

[Julian Elischer]

On 27/9/17 4:20 pm, Matthew Seaman wrote:

Before this gets too far down the road I would like to suggest that we 
quickly formalise some nomenclature

or we will have 200 different ideas as to how to do the same thing;

I would like to propose the following possible "examples of official" 
flavours:
-nodocs ..  nearly every port has a DOCS option..  a way to 
automatically turn it off globally and generate said pkgs would be good.
-minimal ..  smallest possible feature set.. probably used just to 
satisfy some stupid dependency.
-kitchensink    ..  speaks for itself .. options lit up like a 
christmas tree
-runtime    ..  no .a files, include files, development 
documentation or sources ..
    might only contain a single libxx.so.N file, or a 
single binary executable.


Other suggestions welcome. These were just suggestions. I await your 
suggestions with interest.


I would certainly like the 'runtime' version as that would allow me to 
create packages for, and populate appliances.


A ports developer would be encouraged to supply as many of the 
official flavours as make sense.

Poudrierre could be taught to generate only "minimal" packages etc.





On 27/09/2017 08:09, Tilman Keskinöz wrote:


On 2017-09-27 08:29, Matthew Seaman wrote:

On 27/09/2017 07:11, Julian Elischer wrote:

Is there a document/paper on what this is and what it's limits are etc?

https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
https://wiki.freebsd.org/Ports/FlavorsMigration


These pages don't contain any information what this is, how it differs
from/interacts with the OPTIONS framework and why I would want to
convert a port to FLAVORS.

Well, you can think of FLAVORS as essentially a group of different
pre-sets for OPTIONS or DEFAULT_VALUE settings, so you can build several
different instances of the same port with different configurations
easily.  It has the biggest benefit for people either using the default
pkg repositories or who are building their own via poudriere or similar.

Currently the idea is to work on the python ports in the tree so we'd
have both python-2.7 and python-3.6 versions built and available in the
repos.  That's just the initial target to debug and bed-in the FLAVORS
stuff.

This will all need to interact with two other changes due to hit the
tree in the not too distant future:

sub-packages --- so from one WRKSRC you can generate several
different packages.  eg. separate packages for doc or examples, a shlibs
package, a devel package with eg. static libraries and headers, a debug
package with separate files for the debugging symbols, as well as the
main package with the principal binaries and so forth.  So, for php,
it's going to make a big change.  Instead of extracting the entire PHP
sources and building each PHP module as a separate job, all of the PHP
modules for a particular version of PHP could be built at once, and the
results just assigned to different packages.

   variable-dependencies --- this should remove one of the biggest
frustrations with the packaging system at the moment, where dependences
are very strict and pkg(8) will insist on installing exactly the version
of any dependencies a package was compiled against.  Frequently this is
unnecessary, as the same package should work fine with eg. a later
version of a dependency, or with an alternate implementation (eg. mysql
vs mariadb).

Overall, it means the repositories will end up containing more packages,
but these will generally be smaller and allow finer grained control of
what gets installed on your system.

The downside at the moment is that tools like portmaster are pretty much
tied to the idea that there is a 1-to-1 relationship between ports and
packages, which this definitively breaks.

Cheers,

Matthew

___
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: [HEADUP] FLAVORS landing.

[Julian Elischer]

Is there a document/paper on what this is and what it's limits are etc?

On 26/9/17 10:05 pm, Mathieu Arnold wrote:

Hi,

**Do not commit FLAVORS to any ports, a hook will prevent it, that being
said, do try it and test what can be done.**

To test this feature in poudriere, you need
poudriere-devel-3.1.99.20170621 or later.


[...]
___
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"

gettng the port revision number associated with the pkg repo.

[Julian Elischer]

SO imagine that I needed to be ab;e to reproduce the pkg repo as of a 
articular day, is there anywhere one can look to see the svn revision 
number that corresponds to teh current pkg files.



I would like to take a snapshot at a particular revision.. but how do 
I find out what the revision was when the build was kicked off?



___
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: EXTRA_PATCHES considered harmful?

[Julian Elischer]

On 24/9/17 6:37 am, Adam Weinberger wrote:

On 23 Sep, 2017, at 15:39, Julian Elischer  wrote:

currently if you set EXTRA_PATCHES and the port you are making decides to build 
a second port as a dependency, EXTRA_PATCHES is passed to the second port which 
them obiously fails to patch it.

e.g.  cd /usr/ports/emulators/open-vm-tools-nox11; Make 
EXTRA_PATCHES=/foo/bar/patch1

will fail when it tries to apply the patch files to each dependency.

AM I doing something wrong here?

Hi Julian,

I think EXTRA_PATCH_TREE is a better option for what you're looking for. You 
put patches in there in a tree that gets essentially overlaid on the ports tree.

EXTRA_PATCH_TREE=/usr/patches
Then put your patch1 in /usr/patches/emulators/open-vm-tools-nox11

# Adam


You are correct and I am moving to that.. In fact I submitted the idea 
of EXTRA_PATCH_TREE, though it was reimplemented during a rewrite.

(but the comments saying what it is are still mine).
___
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: compler warnings in ports not supported in gcc 4.2.1 (stable/10)

[Julian Elischer]

On 24/9/17 5:58 am, Dimitry Andric wrote:

On 23 Sep 2017, at 23:42, Julian Elischer  wrote:

Trying to compile the emulators/open-vm-tools-nox11 port

but I end up dying with:

libtool: compile:  cc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"10.1.5\" 
"-DPACKAGE_STRING=\"open-vm-tools 10.1.5\"" -DPACKAGE_BUGREPORT=\"open-vm-tools-de...@lists.sourceforge.net\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"open-vm-tools\" -DVERSION=\"10.1.5\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DX_DISPLAY_MISSING=1 
-DHAVE_DLOPEN=1 -DNO_PROCPS=1 -DNO_DNET=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 
-DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DNO_XSM=1 -DNO_XCOMPOSITE=1 -DNO_MULTIMON=1 -I. 
-I/usr/ports/emulators/open-vm-tools-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include -I/usr/ports/emulators/open-vm-too

ls-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include 
-Wno-deprecated-declarations -isystem /usr/local/include -DUSING_AUTOCONF=1 
-DOPEN_VM_TOOLS -DNO_ICU -DVMX86_TOOLS -O2 -pipe -DPANZURA_DEV -DPZ_FBSD_10 
-isystem /usr/local/include -fno-strict-aliasing -Wall -Werror 
-Wno-unused-function -Wno-address-of-packed-member -Wno-unknown-warning-option 
-Wno-unused -MT nicinfo_xdr.lo -MD -MP -MF .deps/nicinfo_xdr.Tpo -c 
nicinfo_xdr.c  -fPIC -DPIC -o .libs/nicinfo_xdr.o

cc1: error: unrecognized command line option "-Wno-address-of-packed-member"
cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
*** [nicinfo_xdr.lo] Error code 1


the system in question is compiled with gcc


is there a supported way of making the port not set those flags on each cc1 
command?

This appears to have been broken by r444773.  Try replacing
emulators/open-vm-tools/files/patch-configure.ac with the attached file.


works!
please commit..




-Dimitry




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

compler warnings in ports not supported in gcc 4.2.1 (stable/10)

[Julian Elischer]

Trying to compile the emulators/open-vm-tools-nox11 port

but I end up dying with:

libtool: compile:  cc -DPACKAGE_NAME=\"open-vm-tools\" 
-DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"10.1.5\" 
"-DPACKAGE_STRING=\"open-vm-tools 10.1.5\"" 
-DPACKAGE_BUGREPORT=\"open-vm-tools-de...@lists.sourceforge.net\" 
-DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"10.1.5\" 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
-DX_DISPLAY_MISSING=1 -DHAVE_DLOPEN=1 -DNO_PROCPS=1 -DNO_DNET=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_WCHAR_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TYPES_H=1 
-DHAVE_SYS_USER_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 
-DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DNO_XSM=1 
-DNO_XCOMPOSITE=1 -DNO_MULTIMON=1 -I. 
-I/usr/ports/emulators/open-vm-tools-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include 
-I/usr/ports/emulators/open-vm-tools-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include 
-Wno-deprecated-declarations -isystem /usr/local/include 
-DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -DNO_ICU -DVMX86_TOOLS -O2 -pipe 
-DPANZURA_DEV -DPZ_FBSD_10 -isystem /usr/local/include 
-fno-strict-aliasing -Wall -Werror -Wno-unused-function 
-Wno-address-of-packed-member -Wno-unknown-warning-option -Wno-unused 
-MT nicinfo_xdr.lo -MD -MP -MF .deps/nicinfo_xdr.Tpo -c nicinfo_xdr.c  
-fPIC -DPIC -o .libs/nicinfo_xdr.o
cc1: error: unrecognized command line option 
"-Wno-address-of-packed-member"

cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
*** [nicinfo_xdr.lo] Error code 1


the system in question is compiled with gcc


is there a supported way of making the port not set those flags on 
each cc1 command?


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

EXTRA_PATCHES considered harmful?

[Julian Elischer]

currently if you set EXTRA_PATCHES and the port you are making decides 
to build a second port as a dependency, EXTRA_PATCHES is passed to the 
second port which them obiously fails to patch it.


e.g.  cd /usr/ports/emulators/open-vm-tools-nox11; Make 
EXTRA_PATCHES=/foo/bar/patch1


will fail when it tries to apply the patch files to each dependency.

AM I doing something wrong here?

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

how to set ALL ports to automatically unset DOCS

[Julian Elischer]

Iwish to compile several hundred ports on a regular basis.

I  however want to not install docs or examples.

is there a single place I can do that? or do I need to do a 'make 
config' for every port?



also:

if a port specifies something like JAVA=1.7+

how can I make it decide to select 1.8 to build?


Julian



___
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 make www/npm pick www/node4 and www/node6 instead of www/node?

[Julian Elischer]

On 16/9/17 9:40 pm, Sunpoet Po-Chuan Hsieh wrote:

On Sun, Sep 10, 2017 at 4:25 AM, Marcin Cieslak  wrote:


Hello,

in the past (before r414303[1])
[1] https://svnweb.freebsd.org/ports/head/www/npm/Makefile?view=
log&pathrev=414303

npm had a couple of OPTIONS to select which node engine should be used.

Now this is all gone and replaced with

RUN_DEPENDS=node>=0.8.0:www/node


I am trying to build node-sass binaries for FreeBSD (I used to publish
them in the past)
and that requires running poudriere against multiple engines.

The following attempt to cheat does not help:

  poudriere bulk -j node4_10_3_i386 -p exp www/node4
textproc/node-sass

(textproc/node-sass is my custom port https://github.com/saper/ports
-exp/tree/master/textproc/node-sass)

since poudriere starts to build www/node4 and www/node in parallel.


Would that help if the npm dependency were changed to

RUN_DEPENDS=node:www/node

so that only existing executable is needed? How could I tell poudriere to
pick node4 first?

I used to maintain a private copy of the npm port with lots of OPTIONS and
this is a PITA.



I have separate poudriere jails for all architectures I have decided to
support:

$ poudriere jail -ln | grep ^node
node4_10_3_amd64
node4_10_3_i386
node6_10_3_amd64
node6_10_3_i386
node8_10_3_amd64
node8_10_3_i386

In the past those had OPTIONS set to pick a proper engine as a www/npm
dependency.


How to do it cleanly now?

Marcin


Hello,

I could add options for older node versions.
You could use these options to select different node versions for your
poudriere builds.

On the other hand, I'm planning a change for npm port.
It includes:
- Add slave ports of npm (e.g. npm-node4, npm-node6) for older node
versions.
- Remove www/npm{2,3,4}.

With this change, npm packages of different node version could be built by
FreeBSD cluster.

I'm looking forward to bhughes@'s comment.

Regards,
sunpoet

we use the npm 3 port at work with node 6
hopefully we will able to upgrade soon but please dont take them away yet.


___
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: Samba4 needs switch to turn off messages

[Julian Elischer]

On 21/8/17 4:13 am, scratch65...@att.net wrote:

Whenever there is more than 1 Samba server running in the same
netbios space, they INCESSANTLY put out the same worthless
message every 5 minutes exactly, filling up disc space or
disrupting whatever's happening on the console.

The message always has the same form:

"query name response:  Multiple [n] reponses received on subnet
[this ip address] for name [netbios group name].  This response
was from [other ip address]."

This has been a problem for years, but  so far nobody seems to
know how to stop the damned things.  Log levels appear to have no
effect on them.

The server needs to have a switch to turn off such messages!

Preferably as a patch, distributed  s o o n.

I'm just before lodging a bug report, because anyone trying to
construe that message as a feature would be likely to spend time
in hospital by reason of having herniated their imagination.


I don't know the answer, but I suspect that the Samba forums would be 
the place to ask rather than the FreeBSD forums.



__
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: State of FUSE on FreeBSD

[Julian Elischer]

On 3/8/17 7:38 pm, Nikolaus Rath wrote:

Hello,

I am the upstream maintainer of libfuse. I'd like to refresh / improve
the FreeBSD support in libfuse. My goal is for libfuse not to require
any FreeBSD specific patches.


Hi, great to hear from you!
 at $JOB we use libfuse and We have always worried that we don't really
have anyone in FreeBSD that really has fuse as a priority.

Rick Maclem has looked at it a little, as have a few people (see the 
commit logs)

but generally as long as it more or less works, people tend to steer
clear of it.

For us libfuse "just worked" so we haven't touched it.
We had to touch the kernel part of fuse a little so remove some overly 
restrictive
permission checks, and fix some issues to do with page boundaries 
(from memory)

but nothing in the library.


After taking a look at
https://github.com/freebsd/freebsd/tree/master/sbin/mount_fusefs,
https://svn.freebsd.org/ports/head/sysutils/fusefs-libs/, and
https://github.com/libfuse/libfuse/issues/173, it seems to me that:

- A lot of upstream code that was actually intended to support FreeBSD
   is actually patched out when libfuse is installed via ports.

- The mount.fusefs and fusermount binaries are not installed from
   libfuse at all, and are instead provided by a "sysutils/fusefs-libs"
   package(?)
that may be possible, We just mount by doing calls to the library in 
our code

so I haven't looked at it.

- Some additional patches are necessary to get libfuse to work.


Is that correct so far, or am I looking at the wrong place?


If so, my tentative plan would be to:
  
- Not build fusermount and mount.fusefs on FreeBSD at all. This would

   allow getting rid of mount_bsd.c (and the corresponding patch)
   completely.

I don't think I've ever seen them used.
   
- Integrate the helper.c patch upstream using #ifdefs


- As far as I can tell, the mount_util.[ch] patch is a no-op that should
   be dropped anyway.


Personally, I don't use FreeBSD and I don't have an easy way to test on
FreeBSD either. So I would appreciate any input.

got vmware or Xen or virtualBox or HyperV?

we provide a bunch of virtual images.




Best,
-Nikolaus



___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 11:47 pm, Grzegorz Junka wrote:


On 23/06/2017 03:58, Julian Elischer wrote:

On 23/6/17 6:36 am, Miroslav Lachman wrote:

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:

On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net 
wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the 
state where everything works and has no bugs. (and cannot be, 
because upstreams have bugs) Even if it compiles and installs it 
does not mean that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean 
others are dilettantes.


The usage of the word dilettante can have negative connotations but 
he is in essential facts correct.


I have spent 30 years on BSD systems in industry, and we almost 
NEVER want the latest and greatest (except at project start time).

What we want is:
  A "recent" starting point for our next project/upgrade to start from
and an ongoing version of that, which will get critical fixes only 
for at LEAST 2 years, probably 5.

The key here is the *_*critical fixes only*_* part.

We do NOT want:
A new version of perl, python, ssh, shell openssl (*), apache, 
named, etc. etc.
The less changes the better.  Basically if it doesn't have a CVE 
number or it isn't actually completely broken,

then don't upgrade it in that branch.
We'll fix it ourselves if we need it bad enough (and feed back 
changes if we know it would be taken).


(*) From my experience, the best way to cope with openssl is to 
have everything link with
the system openssl and issue security upgrades to the base OS that 
upgrades that when there is a need.

(this may change, but it's been my experience so far).

The recent starting point doesn't even need to be 100.00% working.
What we will do here is mirror it and from the mirror, put it into 
our own source control branch/tree where we will add our own 
changes to fix/tailor what we need.
We will then keep merging in fixes from upstream. which usually 
will not collide with our private changes/fixes.

From that we generate our required packages.
From our perspective, a yearly branch (6 months would be 'ideal' 
but 12 would work) that gets only *critical *fixes would be wonderful.
Remember that from the time when a product major release is planned 
to when it comes out is usually 6 to 12 months lead time.
So when it hits the customer's racks,  the packages were usually 
generated somewhere mid-cycle and are already 6 months old.
We will not be replacing them on the customer premises machine 
until they elect to do/purchase an upgrade / patch release.
which may be in a year or two. Certainly for a minor update it is 
rarely less than 6 months.
It'd have to be a heartbleed scale security issue to get customers 
to do an upgrade earlier.


Can't you just create the branch yourself? It's open source. You 
just clone it and can keep it in Github for free. Then you can apply 
security patches to just the applications you need yourself. If it's 
too difficult you can hire people to apply just specific patches. 
With Github pull requests it's deadly easy. I am sure that if you 
asked maintainers to do the patching for a financial incentive they 
would mind doing it.
I actually explained it..  We do not have the people who understand 
all those ports.
if there is a port hat gets a fix, one assumes there is a maintainer 
who at least understands that port a bit.

I would feel more comfortable if they made the fix.
Having said that I do think tat we do need to pony up some cash at 
some stage.. and many others should too

if we want to have something like this. I've said this elsewhere.



Grzegorz
___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 4:38 pm, Vlad K. wrote:

On 2017-06-23 10:26, demelier.da...@gmail.com wrote:


Release branches won't have many maintenance except individual bug
fixes when security advisories are found. No backport, no updates.


Nothing prevents the maintainers from doing exactly that right now. 
But you see, there are two kinds of ports in the tree:


1) ports where upstream maintains a concept of LTS
2) ports that mix bug, security fixes and new features in even 
point.point releases


For some (all?) major production software like Apache, nginx, PHP, 
PostgreSQL, MySQL (I think?), Postfix, Dovecot2, etc... #1 applies. 
So for serious production servers this should be easy to maintain as 
the upstream is doing that in the first place.


The problem is then with ports of type #2. And there's lots of them.

Gentoo portage can easily maintain "stable" ports because portage 
doesn't have a single Makefile, it has multiple .ebuild files so 
multiple versions are available under ONE port name, and bumping the 
version while keeping previous ones available is literally just a 
matter of making a copy of the latest .ebuild and fixing the version 
in it like we do with PORTVERSION.
This is why I think our Makefile should be split up into two parts. 
One of which has the interface to the rest of the ports and one of 
which specifies what to download and things that are specific to a 
given version.


then hopefully you could update the second without changing the first.
 Harder to do than say, I know, but I have faced htat challenge soo 
often, in fact i have it right now.
I need  a new azure-agent, in a 10.3 world, where I can not update any 
other packages/ports.





On FreeBSD that's impossible and often ports are separated and 
version baked into the port name. Like www/node from the original 
post of this thread.


But again, that's all doable without having to introduce new 
infrastructure. The ports tree as is can be maintained like this and 
quarterly repos would NOT be required. All it's needed is for 
maintainers to keep a stable version and a latest version. There's 
already plenty of ports done like that, otoh postfix and 
postfix-current, nginx and nginx-devel, etc...


Because the BIGGEST problem in maintaining separate "stable" or LTS 
branches is BACKPORTING fixes for ports in the #2 category, ie. 
those that mix new features with fixes, so you have to CHERRY PICK 
only the fix and BACKPORT it to your "stable" branch. And that's 
even more work often introducing NEW bugs.


BTW, the problem of the original post could've been avoided if the 
user only read UPDATING which clearly stated that www/node becomes 7 
and previous node (6) becomes www/node6.  (20161207) entry.







___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 1:23 pm, Kurt Jaeger wrote:

Hi!


There's a blog post from one of the folks that explains the
idea behind that 'fast update' mode of operations, and yes,
he's doing real work.
http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/

That is ONE kind of installation.

Well, there's the thinking that in the not-to-far future, everything
is connected, and you'll need to be able to update at any time
because of whatever security/threat that IT ecosystem throws at you.


It DOES NOT WORK when th most you can upgrade a customer system is
once a year or once every two years.

The 'other side' of the debate thinks: Well, if they think this
is the way to do it, they have a problem and need to change
their procedures.

The viewpoint is: That system can start debating with the next
worm/trojan coming along, but that won't help. The assumption
is: everything is connected/on the internet, and not even
voluntarily.

Think connected cars, IoT etc.


I will add that such users would help their own case by fixing such
issues and feeding the changes back to their branches upstream,
thus helping maintain the branch. Maybe we could have a system of
"corporate sponsors" for these branches.

Given the state of fundraising in open source, I doubt that this
will be viable.

My personal experience is that if it were put in the form of an annual s
subscription, most mid sized corporate finance offices wouldn't blink 
at $20k
if they thought it was an important part of their product.  (that's 
the key)

Some wouldn't blink at 50K.  ("the software is free but we need to
help pay for people to do real work to keep it safe, it'll save us (some
fraction of) a full time person").

The problem is that such a set of sponsored branches does not exist so
knowing who'd sign up and who would't is just guesswork, and the companies
have made "alternative arrangements"  whether that means somewhat forgoing
the ports tree (e.g Vicor) or building an infrastructure around ports
head ( e.g. Panzura), or having some other snapshotting system ( e.g 
Ironport/Cisco)



___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 12:39 pm, Mark Linimon wrote:

On Fri, Jun 23, 2017 at 11:58:14AM +0800, Julian Elischer wrote:

What we want is:
A "recent" starting point for our next project/upgrade to start from
and an ongoing version of that, which will get critical fixes only for
at LEAST 2 years, probably 5.
The key here is the *_*critical fixes only*_* part.

And how much is that worth to you and/or your company?

glad you asked.

If we had such a setup it would probably be worth a good part of a 
person's salary.


Since we have had to do without it, we have workarounds in place that 
took a lot of work to make.
But we are now running a  parallel system where we are taking 
snapshots of head and using them.
The downside is that we don't have the resources to follow all the 
Security issues so we are forced
to do cross-revision upgrades sometimes where for example all the 
packages we install were
compiled from a tree that approximates 10.3 ports, but the openssl 
package is from a source tree
that is much newer.  We enjoy this about as much as having our 
corporate wisdom teeth pulled out

but it's forced on us.
In the near future we will be taking a new snapshot for the next 
release. What branch and revision
of the ports tree wil be snapshotted is still not decided, If there 
were a suitable first-half-2017
stable branch we'd take that for sure, then we'd follow it, merging 
changes in, and probably feeding

fixes back.

Since there are no "security patch only" branches, What we will 
probably end up doing is
snapshotting head and crossing our fingers hoping that we notice any 
relevant
vulnerabilities and have the time to work out a fix. Of course If 
there is no easy patch, we
may have to do single-package upgrades, which is usually only painless 
for  a short time

after the snapshot, because the Makefile infrastructure keeps changing.



I mean, honestly.  You constantly criticize the volunteers for not doing
what you need.  Well _need_, to me, implies the existence of some kind
of incentive.  I can state to you, flatly, that "a feeling of a job well
done" isn't _sufficient incentive_ to do professional-level QA.  There's
a reason people get _paid to do it_: it's hard, long, tedious, unrewarding
work, and it never ends.

Clearly, relying on _volunteers_ to do professional-level QA isn't working
out for you.

Thus, IMVVHO, at this point, to get what you _need_, you need to get out
your checkbook and provide a _financial_ incentive.  In my experience,
with the volunteers that we have, we can barely keep things afloat as
it is.  It's sufficiently hard to recruit people, and burnout is high
-- especially given the grief we take.

(I won't even start on how even "critical fixes" can drag in the need
to update dependencies, which then conflict with each other, and so on
and so forth, and thus even "critical fixes" aren't trivial.)

Summary: you are providing negative incentive to the ports crew, with
no upside for them, and you can't understand why it doesn't work.

tl;dr: you want us to be RedHat but with no paid employees.

mcl



___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 7:28 am, Grzegorz Junka wrote:


On 22/06/2017 15:50, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:


On 2017/06/22 15:03, scratch65...@att.net wrote:

Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not 
exert

much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied.

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?



Not sure how you use your tools or in which industry you work. Take 
front-end development for example.


here lies the crux of the problem.
FreeBSD is often not a front-end software module.
It is often used to provision off-line (from a 
management/administrative perspective) systems.

Front end or personal systems can be upgraded day by day.
Real products such as routers, proxies, gateways, accounting systems, 
firewalls etc. can NOT be upgraded every day.

you are lucky if the customer allows you to do it once a year.

Chrome is releasing a new version every couple of days. Sure, I 
don't upgrade every release, but when I am developing a website, I 
want to test using the same version that my customers are using, 
which is the latest, since Chrome on Windows updates itself 
automatically. The same with new versions of Firefox. Often new 
versions of browsers require new versions of libraries to support 
new features (CSS/JavaScript). That requires new versions of 
compiler and transpilers. They may, in turn, require an updated 
version of node or npm.


Take server-side development as another example. Erlang is releasing 
a new version of OTP every couple of weeks. Sure, I don't need a new 
version when supporting an old application, but I may need one when 
starting a new application. Especially that many libraries that I am 
going to use won't support Erlang older than a specific version.


A similar story with C++ development, where the standard is being 
constantly developed and compilers are adding these features every 
release. Again, you may not need these new features, but a library 
that you need to use may require the new version.


 No matter how long you are going to maintain a specific version of 
ports with locked down versions of applications, there will surely 
come a time when you will need to upgrade. And for every user that 
time will be different. The current model is in my opinion the most 
common denominator - we can't maintain multiple branches with past 
versions so lets try to properly maintain one with current versions.


Grzegorz
___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 2:57 am, Dave Hayes wrote:

On 06/22/2017 11:43, demelier.da...@gmail.com wrote:

Let me use my example of www/node back. I have built the port www/node
in poudriere using this origin (so no version). At the time I've built
it it was a 6.x version. When I upgraded my machine, www/node has
switched to 7.x version and since this software follows semantic
versioning, every application using the 6.x branch may or may not work
anymore.


I completely agree that an annoying consequence of what the 
volunteers are doing with the ports tree. These unwelcome surprises 
are the bulk of my non-automated work in creating package repositories.


Frankly, I also wish this kind of thing would stop. Ultimately my 
wishes are irrelevant for reasons far far beyond the scope of this 
thread.



Now, I'm in a state where if I pull the ports tree, I must check if
www/node6 still exists or I must not upgrade.

With releases branches I will be sure that:

  1. www/node will *always* be at a 6.x version;
  2. www/node will still be supported for the version of the FreeBSD
system.


That sounds reasonable...yet others will likely expect www/node to 
always be the latest version. Perhaps these others might complain 
that it is not the latest version and it would be reasonable to have 
node always be at the latest version.
then at install they should set their packages to follow head, and 
ignore the branches.


Would you agree that release branches would be unnecessary if 
somehow you could select the version of node that the ports tree 
builds via some (as yet unspecified) mechanism?



___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 10:39 am, Kurt Jaeger wrote:

Hi!


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.

There's a blog post from one of the folks that explains the
idea behind that 'fast update' mode of operations, and yes,
he's doing real work.

http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/


That is ONE kind of installation.

It only works if you are talking about a software module that is 
either dynamically delivered (think web apps that are downloaded every 
time they are run) or at lear often redelivered. (say, a personal 
system that gets automatic upgrades, a-la slack on OS-X (they seem to 
have  anew version every week or two)
It DOES NOT WORK when th most you can upgrade a customer system is 
once a year or once every two years.


That kind of installation basically "follows head". It doesn't need 
ANY branches. So quarterly branches are of no use to them either.
They are a minority of all commercial users, and a completely non 
existent part of appliance manufacturers,

(because you can't do it that way unless you only have 2 customers (*)).

 * and even then, the customers may only allow you to upgrade every 
so often. For example Bank of America only allow their FreeBSD 
machines to be upgraded after a several month testing and burn-in 
period on a parallel test system with real data and dummy users, and 
that can obviously only happen on a yearly scale as it costs a lot to 
do. (ask Devin about the details..it's been a while since I worked on 
their stuff but I know it's still similar).


To be useful any branch must:
1/ not make unneeded changes, but DO include all/most CRITICAL changes.
2/ stay around and be buildable for at least 3 years, preferably 5.

Note that a company can take care of point 2 themselves to some extent 
by mirroring etc.
but they probably don't have the expertise to handle all if the 
critical (security) patches part of the picture.


I will add that such users would help their own case by fixing such 
issues and feeding the changes back to their branches upstream,
thus helping maintain the branch. Maybe we could have a system of 
"corporate sponsors" for these branches.





___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 6:36 am, Miroslav Lachman wrote:

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state 
where everything works and has no bugs. (and cannot be, because 
upstreams have bugs) Even if it compiles and installs it does not 
mean that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean 
others are dilettantes.


The usage of the word dilettante can have negative connotations but he 
is in essential facts correct.


I have spent 30 years on BSD systems in industry, and we almost NEVER 
want the latest and greatest (except at project start time).

What we want is:
  A "recent" starting point for our next project/upgrade to start from
and an ongoing version of that, which will get critical fixes only for 
at LEAST 2 years, probably 5.

The key here is the *_*critical fixes only*_* part.

We do NOT want:
A new version of perl, python, ssh, shell openssl (*), apache, 
named, etc. etc.
The less changes the better.  Basically if it doesn't have a CVE 
number or it isn't actually completely broken,

then don't upgrade it in that branch.
We'll fix it ourselves if we need it bad enough (and feed back 
changes if we know it would be taken).


(*) From my experience, the best way to cope with openssl is to have 
everything link with
the system openssl and issue security upgrades to the base OS that 
upgrades that when there is a need.

(this may change, but it's been my experience so far).

The recent starting point doesn't even need to be 100.00% working.
What we will do here is mirror it and from the mirror, put it into our 
own source control branch/tree where we will add our own changes to 
fix/tailor what we need.
We will then keep merging in fixes from upstream. which usually will 
not collide with our private changes/fixes.

From that we generate our required packages.
From our perspective, a yearly branch (6 months would be 'ideal' but 
12 would work) that gets only *critical *fixes would be wonderful.
Remember that from the time when a product major release is planned to 
when it comes out is usually 6 to 12 months lead time.
So when it hits the customer's racks,  the packages were usually 
generated somewhere mid-cycle and are already 6 months old.
We will not be replacing them on the customer premises machine until 
they elect to do/purchase an upgrade / patch release.
which may be in a year or two. Certainly for a minor update it is 
rarely less than 6 months.
It'd have to be a heartbleed scale security issue to get customers to 
do an upgrade earlier.







Miroslav Lachman
___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 22/6/17 11:50 pm, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:


On 2017/06/22 15:03, scratch65...@att.net wrote:

Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not exert
much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied.

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?

So where's the point in everyone going mad trying to keep up a
quarterly release schedule that serves more as an annoyance than
benefit to your customer base?  (Do you read the Asterix comics?
The one where Asterix and Obelix go to Switzerland is
particularly apropos here, I think:  the owner of the inn awakens
the guests every hour so that they can turn over the hourglass
mounted over their bed.  What benefit do the guests derive from
that?  None, of course, but it helps the owner feel in control of
things.  But the guests are, reasonably, quite upset by the loss
of sleep due to his obsessiveness.)



  2) Even if we could scrape up enough people to support however many
branches you are proposing, remember they are all volunteers.  It's hard
enough getting people to maintain the existing quarterly branches as it
is, and those are relatively short lived so that most merges from head
are pretty trivial.  People really aren't going to want to do
essentially repetitive merges to branches where everything else is up to
X years older than head.  Which would make it both tedious and
frequently difficult to do.

Again I'm really not following your logic.   There are 2 versions
of the base system now in play:  10.3 and 11.0.  There are 2 more
being developed: 10.4 and 11.1.   10.2 has already been trashed,
thus forcing us to upgrade to 10.3 whether we wanted to or not,
which in many cases, mine among them, was a "not".  I'm sure the
same thing will happen with 10.4 and 11.1 and plenty folk will be
just as annoyed as we were with 10.2


I've had this conversation with ports several times, But the requirements
of  'business' is not their interest.  In fact i was told several times,
"Don't use our quarterly packages, make your own with poudriere".
(which makes one wonder "What is the purpose of he quarterlies?)

My suggestion is to ignore the existence of the quarterly snapshots as
they are neither stable (they change every 3 months out from under 
you) nor snapshots,
(they a re updated randomly a bit at a time. This just doesn't work 
for what business needs.
So the only alternative is to have a SVN mirror, and take your own 
snapshots, and keep your eye

on the security notices.



Let's say you guys don't try to follow that schedule.  You do a
ports release for (let's say) 10.0 and then 11.0, but not for the
other point releases in between.  So if someone feels the deep
need for 10.1, or 10.2, or 10.3 (or 11.n mutatis mutandis),
they'll run 10.0 (or 11.0)  ports under it.   It's done all the
time in industry.   If you treat each ports release as a DVD
--immutable once shipped--, or as a PROM, where changes can be
made but it's a pain in the dupa so you only do it for the
emergency case, it seems to me that the pressure has gone down by
a factor of  3 or so.  So where's the problem in that?

's mise le meas
___
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: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 22/6/17 10:16 pm, Baptiste Daroussin wrote:

On Thu, Jun 22, 2017 at 10:03:33AM -0400, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:


As usual with such proposal, where do you find the manpower to handle the number
of branches required (the quarterly branches are already hard to maintain, it is
only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?

We only have 1 quarterly branch at the time :)

The model with one branch per release will bring it to way more with a
maintenance window way larger (actually it is 3 month making the quarterly
relatively easy to maintain)
Yeah but the quarterly branches are relatively useless because they a 
not sync'd to anything and mean nothing special to anyone.
As soon as you sync to one, it's deleted and replaced by a completely 
different one meaning you have to replace *EVERYTHING*,

so one might as well just use head. it's actually easier.




Best regards,
Bapt



___
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: [Help] Linux low level data structures < - > FreeBSD low level data structures

[Julian Elischer]

On 4/6/17 7:07 pm, blubee blubeeme wrote:

Hello

Is there anyone on either of these lists that have experience with both
linux low level data structures and their equivalents on FreeBSD?

For instance the linux header file:


which includes the header file:


Then looking at that file:







You are going to have to be a lot more specific about this.
I have worked in several places where they use s shim layer to make 
Linux basic services work on freeBSD.

usually  a mix of functions, macros and inlines.
However you need to narrow down your questions a bit as the POSSIBLE 
scope of your question is too large for anyone to attempt an answer.


Remember that both systems are POSIX inspired so outside the kernel 
there are many more simlarities than one might be led to expect,

 but you need to be way more specific.
It's even possible to write kernel code to run on both, but it is 
usually domain specific.





I'll be doing a lot of work trying to find these FreeBSD equivalent of
these types of files to port some code.

Does anyone here have experience with something like this? Is there any
other projects that maps these low level data structures from
Linux <-> FreeBSD, etc?

Best,
Owen
___
freebsd-curr...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-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: How should we name node-js ports ?

[Julian Elischer]

On 14/5/17 8:16 pm, Rodrigo Osorio wrote:

Hi,

I have a bunch of nodejs ports to add, most of them as dependencies,
and I wonder if we can find a naming standard like adding  'node' or
'node-js' prefix in the name ; I personally prefer 'node'.

As a result a port who install the node package xxx will be named 
'node-xxx'


Does it sounds good to you ?

Thanks for your time,


this brings up the whole question of whether we should package these 
things ourselves anyhow.
python and perl  have their own schemes (pip et al.)  and with npm 
(and others) node is no exception.
it seems that to chase these packages down manually is a never ending 
task.
maybe the way we should handle it is to have a generic  "handover to 
external package manager" feature,
so that we somehow let npm (or whatever) do it ting but then take the 
output result an put it into our database.


At $JOB we have the issue of many many node modules for our new gen UI 
and it causes us a great headache.




-- rodrigo


___
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: pkg and packages

[Julian Elischer]

On 7/5/17 5:14 am, Kevin Oberman wrote:

On Fri, May 5, 2017 at 3:11 PM, Sebastian Schwarz 
wrote:


On 2017-05-04, scratch65...@att.net wrote:

I can't imagine what code could possibly be in thunar and
samba that the xfce desktop would need, (...)

Thunar is used to display the icons on the XFCE desktop.  It
depends on gvfs, which is used for accessing remote file systems
and the trash inside Thunar.  gvfs in turn depends on samba44 in
order to access CIFS/SMB shares.

Strictly speaking some of these features might be optional.  But
as far I know pkg currently doesn't have a concept of optional
dependencies.  So it's an all or nothing decision, when building
the packages.


This is the case. If you want to stick with packages, at least until some
new packaging features are available, your best bet is to install
ports-mgmt/synth. Then you can use it to add a private repository of all
ports that you want built with non-standard options. Then have synth create
a custom Thunar package that you can then use to avoid samba (44 or 46) or,
if supported, build Thunar against the samba version of your choosing.

synth(8) has excellent documentation on how to configure and use it. I
recommend it for the type of issue you are running into. (N.B. synth is
written in ADA and, for that reason, I don't recommend building synth from
source as that requires a major installation of the ADA compiler.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

you can do the same with poudriere, by telling it to keep a set of 
pre-canned configureations.


see:

  PORT_DBDIRDirectory where the results of configuring 
OPTIONS are
   stored.  Defaults to /var/db/ports.  Each port 
where
   OPTIONS have been configured will have a 
uniquely named

   sub-directory, containing a single file options.


___
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: Is pkg quarterly really needed?

[Julian Elischer]

On 20/4/17 5:18 pm, Mathieu Arnold wrote:

Le 20/04/2017 à 11:15, Mathieu Arnold a écrit :

Le 20/04/2017 à 10:49, Torfinn Ingolfsen a écrit :

On Thu, Apr 20, 2017 at 8:00 AM, Kurt Jaeger  wrote:

Hi!


On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer  wrote:

quarterly however is broken because the pkg mirors discard it all at the
time of update.

Do they have to?
Why couldn't pkg mirrors keep say, the four latest quarterly sets
all the time?

Because the URL for the latest quarterly is one stable URL.

Obviously this has to be changed. As I wrote:
"No extra work involved once the setup is configured and tested".
So yes, there is some work needed, but it would be a one-time job.

If anyone has any real arguments as to why the FreeBSD project can't
do it this way, let's hear them.
HTH

I am not exactly sure what you are asking for, to keep the previous, not
updated, quarterly package repositories ? say, in latest-1 latest-2
latest-3... ?

So, that should be quarterly-1, quarterly-2..., not latest :-)

2017-Q1, 2017-Q2, 2017-Q3   etc.




What purpose would that serve ? I mean, they would not be updated.




___
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: Is pkg quarterly really needed?

[Julian Elischer]

On 20/4/17 5:15 pm, Mathieu Arnold wrote:

Le 20/04/2017 à 10:49, Torfinn Ingolfsen a écrit :

On Thu, Apr 20, 2017 at 8:00 AM, Kurt Jaeger  wrote:

Hi!


On Thu, Apr 20, 2017 at 1:30 AM, Julian Elischer  wrote:

quarterly however is broken because the pkg mirors discard it all at the
time of update.

Do they have to?
Why couldn't pkg mirrors keep say, the four latest quarterly sets
all the time?

Because the URL for the latest quarterly is one stable URL.

Obviously this has to be changed. As I wrote:
"No extra work involved once the setup is configured and tested".
So yes, there is some work needed, but it would be a one-time job.

If anyone has any real arguments as to why the FreeBSD project can't
do it this way, let's hear them.
HTH


I am not exactly sure what you are asking for, to keep the previous, not
updated, quarterly package repositories ? say, in latest-1 latest-2
latest-3... ?


What purpose would that serve ? I mean, they would not be updated.


exactly! that's what is often needed...  something that is not updated..
having spent 20 years embedding FreeBSD into products I can tell you 
that the commercial reality is a requirement for FROZEN (or near to 
it) contents. not contents changing all the time. ports/pkgs that need 
to be updated for security reasons are the exception, not the rule. 
And since handling a security issue usually required extra paperwork 
anyhow, they are usually handled in a different workflow.


here's a workflow I'd find less annoying.. or something similar:

quarterly snapshot into .../quarterly/$DATE/initial/All/
   this never changes again. it is a snapshot of the head set of 
patches at that time. no recomipiles needed.

an additional directory: .../quarterly/$DATE/updating/All...
all files in 'updating' start out as symlinks to 
../../initial/All/$filename and are replaced if the files get updated.

   ( or if name changes.. maybe we get a choice of two)
For the people who want to leap from quarterly to quarterly we have a
symlink from "quarterly/Latest" to $DATE/updating/ and  from 
quarterly/Initial to $DATE/initial


Each quarter  a new set is created with new dates, and the symlinks 
are recreated.
also create in each real directory, a file that contains the (possibly 
relative) URL so we know what to point our pkg.cfg at if we don't want 
to follow the rolling version.


how long you leave the old ones there is up to you, but someone 
mirroring might decide to leave them for ever if they had the space.

but at least leave them for a whole quarter...










___
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: Is pkg quarterly really needed?

[Julian Elischer]

On 20/4/17 6:29 am, Dewayne Geraghty wrote:

Scratch65535, I think your best solution is to use latest and upgrade when
you need to.  Unlike Freddie's comment re only desktop users using latest.
I ONLY upgrade my local svn of ports when there's a vulnerability or
significant (for users) functional improvement of a port.

It is a labour intensive exercise, monitoring CVE's for all
externally-facing applications.

Its a nice idea having a snapshot of ports, from the perspective of
consistency, but that model doesnt suite our risk appetite on multiple
levels; and in our view back-porting fixes to a quarterly snapshot - a good
idea from a security perspective it is a really bad idea from a
consistency/administrative/audit perspective.


We mirror the ports tree (and base) into p4 and also as svn, and use 
this to check out the head branch to whatever release we need.
Our scripts are capable of checking out a particular port at a 
(slightly) different rev to the default rev used for the rest, as 
sometimes we find we need a slightly newer rev of one port or 
another.  This sometimes doesn't work if there are framework changes 
that affect the port but mostly we find that it's ok if you just want 
to bump a port up a small amount to catch a bugfix,or take it back a 
bit to avoid a regression. We also do sparse checkouts of the ports 
tree ot save time, but that's another issue..


We therefore have all out pkgs (which we store with each release) at 
the same level of source tree so they all match.




How the ports infrastructure can meet many conflicting objectives is
something that we (the consumers of the ports service) must decide for our
circumstance.  The use-the-latest paradigm suits individuals that manage
their individual machine, but when you manage multiple clients' servers,
the requirements are different (try meeting a SAS70-II/SAE16-SOC2, ISO27001
SOA, NIST 800-53r5, etc)

On a non-audit level, Microsoft might hold to monthly updates/fixes ("patch
Tuesday") but bad guys don't.
Regards, Dewayne.
___
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: Is pkg quarterly really needed?

[Julian Elischer]

On 20/4/17 4:37 am, scratch65...@att.net wrote:

[Default] On Tue, 18 Apr 2017 15:57:02 +0100, krad
 wrote:


quarterly does seem very cautious, maybe a monthly might be a good
alternative.

I have to STRONGLY disagree.

Right now, pkg isn't smart enough not to use version-skewed bits.
Which means that, for those of us trying to use freebsd and the
ports/pkgs as *tools* wherewith to do other work, we have to run
pkg upgrade -fy every cursëd quarter, not just when the minor
number changes.  With crappy access to the inet (something true
of most of the USA and Canada outside Really Big Cities) that
costs half a day or more.

If it were every month, I'd with unconsolable regret abandon
freebsd for linux (ptui!).  (Right now, it's quite hard to resist
the paranoid suspicion that maybe this crazy, anti-real-user
behavior is a subtle way to kill freebsd altogether by driving
away the non-hobbyists.)

I have to agree with you. It is most frustrating
The only way to sanity is to totally ignore the quarterly releases, 
and if you have changes, use poudriere to build what you need yourself 
once a month or whatever, or if you don't have changes, take snapshots 
of the entire pkg tree every now and then. (we do both for different 
reasons).. My snapshot is kept out on an amazon machine we have, as 
it's purpose is to "freeze in time" the head branch of the pkg tree. 
This means we can come back in a week and get  a new pkg that we now 
need and know it is compatible with the other ones we have. I don't 
have to download the entire collection through my crappy link. just 
the ones I need.
The trouble is that the people doing ports and pkg management really 
don't really have production systems in mind and rarely really 
understand the requirements of such. (reproducible builds from 
scratch, and the ability to append to an existing  frozen-in-time 
release (for debug or bug-fix reasons). They ESPECIALLY don't 
understand the requirement to have access to old sets of packages, so 
you need to do it yourself.

___
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: Is pkg quarterly really needed?

[Julian Elischer]

On 19/4/17 12:13 am, Freddie Cash wrote:

On Tue, Apr 18, 2017 at 7:57 AM, krad  wrote:


quarterly does seem very cautious, maybe a monthly might be a good
alternative. I can understand people being hesitant about latest though. I
guess these are not the people who ask though. Maybe the real answer though
is to have a specific repo for that port for the bleeding edge people  much
like launchpad on ubuntu. It might get complicated though for big
dependency trees though.


​latest/ is good for desktop users who only care about running the very
latest versions of everything.

quarterly/ is good for server users who want to make sure that installing a
new piece of software won't require an upgrade of all the currently
installed software (repo hasn't changed since the last install).  And for
desktop users who prefer to use their computers for doing work instead of
spending all their time chasing after the "latest" flashy bling bling.  :)

quarterly/ also gets security fixes back-ported into it (on a
per-maintainer basis so it's not 100% coverage yet), so you can stay secure
without chasing new software versions.

IOW, don't change the infrastructure, it's working nicely.  Just educate
the users.  :D


quarterly however is broken because the pkg mirors discard it all at the time 
of update.
meaning you can not come back later to get one you forgot..
and sometimes you can get half way through, and everything breaks becuase you 
happened to select  teh wrong date to do your work.





On 18 April 2017 at 14:54, qjail1  wrote:


I maintain a port and I have users complaining that the pkg system takes
many months before the updated version of my port shows up in the pkg
system.

My response is I tell them to change a line in their

/etc/pkg/FreeBSD.conf

file
from url: "pkg+http://pkg.Freebsd.org/${ABI}/quarterly";,
to   url: "pkg+http://pkg.Freebsd.org/${ABI}/latest";,

The old pkg system never had this quarterly update cycle and I see no
reason to have it now when its so easy to over ride the default.

Why not just change the default to "latest" and save on all the overhead
of the quarterly cycle?
___
freebsd-questi...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe
@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"






___
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: manpath change for ports ?

[Julian Elischer]

On 8/3/17 11:39 pm, Dag-Erling Smørgrav wrote:

Baptiste Daroussin  writes:

I would like to propose a change in the localbase hier for ports

I think we should add /usr/local/share/man in the manpath along with
at first and maybe instead of in long term.

2) plus info -> share/info as suggested by jbeich

3) plus libdata/pkgconfig -> lib/pkgconfig

These three items will ensure that "./configure --prefix=/usr/local &&
make install" will do the right thing out of the box - by changing our
definition of "the right thing" to match what the GNU autotools have
been doing for at least 15 years.

4) Remove the hardcoded library path in lang/gcc*

This makes it possible to work on software that includes both libraries
and programs while an earlier copy of the same software is already
installed.  With the current state of gcc, the programs you are working
on will be linked against the version of the library that's already
installed instead of the version you just compiled, and there is nothing

unless you use --sysroot=...

you can do to prevent it.  You won't notice anything if all you ever do
is "make && make install", because the new library will replace the old,
but if you try to run your program directly from the build tree, it will
use the wrong library.  This can be incredibly frustrating if you're not
aware of it - imagine you're trying to fix a bug in that library and no
matter what you do, your regression test keeps failing...

DES



___
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: ports and dependency hell

[Julian Elischer]

On 9/2/17 11:02 pm, Steve Wills wrote:

Hi Julian,

On 02/07/2017 13:03, Julian Elischer wrote:
[...]
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?
the specification of what you are getting is intermixed too much with 
the makefile components that

interact with the .mk files.

In a slightly theoretical world you would have two files..
one says "MAJOR=2 ; MINOR=2" (or similar) , and specifies the 
checksums etc
and the other gives options and dependencies (which don't usually 
change as fast as you think) but uses all the

complicted USES stuff for example.
so you couth PROBABLY get a range of module versions to compile with 
the same base makefile as long as it matches the .mk

files.





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.

but that is not reproducible in source control



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.

Commercial products are Hardly EVER rolling releases.
they lurch from point of stability to point of stability, with large 
amounts of testing between releases.

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.

pkg would have to do it looking in the pkg index.




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 generally be maintained as sets, rather than individual
packages, IMHO.

See "required by different teams" in the first email.




The way to get around the problem above CAN be (not always) to install
foo.1.2.1 first and THEN install the package you actually want, and pkg
will accept it. The problem comes when pkg needs to install a dependency
itself. Then it becomes "super picky", when there is actually a range of
package revisions that would do. Instead of letting pkg install what it
needs, we need to manually set up scripts to install the dependencies.
so that all the work done by pkg is wasted.


Please think about these two issues..

You can always use 'pkg lock

please fix the pkg downloads system

[Julian Elischer]

please work on having the "Latest" image in a directory that has the 
cvs revision number in its name


and make the current names just be links to there.

I ONCE AGAIN (for the third time) got half of one release (432891) and 
half of another (433120) because the newest snapshot of the pkgs was 
replaced half way through my process of downloading a large set of 
packages.  Then a couple of days later I managed to get all the files 
of 433274, but by the time I got to downloading the metadata it was 
changed to the next snapshot (433341), making my mirror pointless. 
(unless there is a script I can run to regenerate the metadata from 
the actual files. (I'm guessing there is).


Please consider keeping two copies, at any time. this measn that 
someonewho starts copying the latest set has at least a couple of days 
to get it.


So FreeBSD http://pkg.freebsd.org/FreeBSD:10:amd64/latest/ would be a 
link to the latest but someone who followed the link 20 minutes 
earlier and was copying files would keep getting a consistent set.


the actual backing set would be called

something like:

FreeBSD-pkg/head/r433274/FreeBSD:10:amd64/All

and the next would be:

FreeBSD-pkg/head/r433341/FreeBSD:10:amd64/All

then

FreeBSD-pkg/head/r433529/FreeBSD:10:amd64/All

etc. (real snapshot numbers)

but
http://pkg.freebsd.org/FreeBSD:10:amd64/latest/ would always point to 
the latest one.


this would ensure that I don't keep getting HALF A RELEASE!

___
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: (Relevant?) article on package mgmt at lwn.net

[Julian Elischer]

On 5/2/17 7:18 pm, Kurt Jaeger wrote:

Hi!

There's an article on package mgmt, also referencing the
topic of language-specific package mgmt, at lwn.net:

Package managers all the way down
https://lwn.net/Articles/712318/


very relevant


FreeBSD ports/pkg issues are taking close to 50% of my time these days,

and we are just using 400 or so packages.


___
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: ports and dependency hell

[Julian Elischer]

On 8/2/17 3:17 am, Grzegorz Junka wrote:


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

(...)

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.




Hi Julian,
I may not fully understand how it works but what prevents you from 
getting sources for the version you want and typing make in them, 
exactly the way you do it in Linux? It should pick up the versions 
of dependencies currently installed in the system and compile for 
them. Is it only when you want to use the ports infrastructure that 
poses a problem?


Nothing stops me from doing that. It's just that means that the ports 
infrastructure is useless and a complete waste of time right?

I'm no ready to admit that, however I may just be in denial.

also, downsides to doing that include:

* not getting any FreeBSD related fixes (many packages don't work well 
on FreeBSD without patches)

* not being able to play nice with software installed by packages
* having a hard time installing FreeBSD specific software that is 
delivered by ports and pkg as it's primary means of delivery.
* having to manually chase package revisions. In areas where I have no 
expertise.


upsides include the ability to use autotools etc as they are designed 
to be used and pkgconf to knit everything together without worring 
about version problems. (downside is using autotools :-)  )


So there is a price to pay each way..

I'm discouraged to not hear back from any of the ports 'committee'.





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

ports and dependency hell

[Julian Elischer]

This is a serious post  on a serious issue that ports framework people 
seem unaware of.


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


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

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.


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


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.


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


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.


The way to get around the problem above CAN be (not always) to install 
foo.1.2.1 first and THEN install the package you actually want, and 
pkg will accept it. The problem comes when pkg needs to install a 
dependency itself. Then it becomes "super picky", when there is 
actually a range of package revisions that would do. Instead of 
letting pkg install what it needs, we need to manually set up scripts 
to install the dependencies. so that all the work done by pkg is wasted.



Please think about these two issues..


Julian




___
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: unable to build java in poudriere

[Julian Elischer]

On 26/1/17 7:32 am, Ultima wrote:
I just finished building openjdk8 with a fresh repo and it built 
just fine.


poudriere bulk -p git -j 103amd64 java/openjdk8
ref: 
https://poudriere.ultimasbox.com/build.html?mastername=103amd64-git&build=2017-01-25_14h51m15s


yeah but not so for me..  remember openjdk8 compiles just fine for me 
too. but only after openjdb7 is available.

did yours compile jdk7?




A google search on the error suggests that it is most likely related 
to some form of memory issue.


If you follow this post from a few years ago, it could lead you to 
the same conclusion. More or less it seemed to be a problem with 
java determining incorrect memory values which was causing that 
error. Could be completely wrong but it is worth looking into.


https://lists.freebsd.org/pipermail/freebsd-java/2013-December/010441.html

Explicit setting maximum memory starts the vm, but being that this 
is a port building, I'm not really sure what to suggest. I guess you 
could try add an arg on the Makefile setting max memory, but I'm not 
sure how much memory it requires to build. I know building openjdk 
does need quite a bit. Another solution, likely less desired is 
using another system to build it or using the FreeBSD repo to 
download it. Sorry if this isn't helpful. Someone else may have a 
better solution.


Good luck,
Ultima

On Wed, Jan 25, 2017 at 5:48 AM, Julian Elischer <mailto:jul...@freebsd.org>> wrote:


    On 25/1/17 6:30 pm, Julian Elischer wrote:

On 25/1/17 10:36 am, Ultima wrote:

Sorry Julian but your details are kind of vague. Are you
on head? I'm not sure when my last build for openjdk7 or
8 were but I have them built in my repo. Is there enough
memory on the system building it? or is it limited? that
is usually the culprit for the openjdk ports.

I ask if you were on head because I know java was broken
for sometime in January but was fixed, or at least
r312388 is working.

Sorry, one item missing..  compile is on FreeBSD 10.3

Poudriere is populated with the head ports tree as of
yesterday, but I had hte same problem a few weeks ago.
the list of packages includes openjdk8
it would probably have the same issue if openjdk8 was the
ONLY port to make, because jdk8 wants jdk7 to jdb7 won't build.
Should poudriere or ports give a warning "you need to
install package X before we can do this compile"?


I will add that bootstrap-openjdk-r351880_1.txz  is already
finished and available.
I'm guessing that openjdk7 should be using that, but isn't for
some reason.

in fact is it possible that 8 should be using that to bootstrap
itself up as well instead of using 7?

I'm not experienced with java, I just need to get it into the
machine image at $JOB for others to use.






On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer
mailto:jul...@freebsd.org>
<mailto:jul...@freebsd.org <mailto:jul...@freebsd.org>>>
wrote:

from he log file:  (see below)

This dies almost immediately.
Do we need to prime the build with an older java?
(e.g. the
bootstrap pkg)?
If so why does  poudriere not do this?
I actually want jdk8 but iti insists on building 7
first, which
fails.
Since I don't care about 7 I can prime the pump by
downloading a
7 pkg but should all this be automatic somehow?

Log:







# Entering langtools for target(s) all   #




(cd  ./langtools/make && \
  gmake
   
JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk


JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk/make/common/shared
EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01
JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01
PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111
JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1
JDK_MINOR_VERSION=7
JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1
PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=
PAX_COMMAND=/usr/sbin/paxmark.sh PAX_COMMAND_ARGS="-vm"
ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1

Re: unable to build java in poudriere

[Julian Elischer]

On 25/1/17 6:30 pm, Julian Elischer wrote:

On 25/1/17 10:36 am, Ultima wrote:
Sorry Julian but your details are kind of vague. Are you on head? 
I'm not sure when my last build for openjdk7 or 8 were but I have 
them built in my repo. Is there enough memory on the system 
building it? or is it limited? that is usually the culprit for the 
openjdk ports.


I ask if you were on head because I know java was broken for 
sometime in January but was fixed, or at least r312388 is working.

Sorry, one item missing..  compile is on FreeBSD 10.3

Poudriere is populated with the head ports tree as of yesterday, but 
I had hte same problem a few weeks ago.

the list of packages includes openjdk8
it would probably have the same issue if openjdk8 was the ONLY port 
to make, because jdk8 wants jdk7 to jdb7 won't build.
Should poudriere or ports give a warning "you need to install 
package X before we can do this compile"?


I will add that bootstrap-openjdk-r351880_1.txz  is already finished 
and available.
I'm guessing that openjdk7 should be using that, but isn't for some 
reason.


in fact is it possible that 8 should be using that to bootstrap itself 
up as well instead of using 7?


I'm not experienced with java, I just need to get it into the machine 
image at $JOB for others to use.









On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer 
mailto:jul...@freebsd.org>> wrote:


from he log file:  (see below)

This dies almost immediately.
Do we need to prime the build with an older java? (e.g. the
bootstrap pkg)?
If so why does  poudriere not do this?
I actually want jdk8 but iti insists on building 7 first, which
fails.
Since I don't care about 7 I can prime the pump by downloading a
7 pkg but should all this be automatic somehow?

Log:

 

 


# Entering langtools for target(s) all#
 



(cd  ./langtools/make && \
  gmake
JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk
JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk/make/common/shared
EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01
JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01
PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111
JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7
JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1
PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=
PAX_COMMAND=/usr/sbin/paxmark.sh PAX_COMMAND_ARGS="-vm"
ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1
ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7"
ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools
ALT_BOOTDIR=/usr/local/bootstrap-openjdk all)
gmake[3]: Entering directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
JAVA_HOME=/usr/local/bootstrap-openjdk
ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
-diagnostics >
/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log
; \
  JAVA_HOME=/usr/local/bootstrap-openjdk
ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
-version >>
/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log
Could not create the Java virtual machine.
Could not create the Java virtual machine.
gmake[3]: *** [Makefile:196:
/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log]
Error 1
gmake[3]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
gmake[2]: *** [make/langtools-rules.gmk:39: langtools-build] 
Error 2

gmake[2]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'
gmake[1]: *** [Makefile:251: build_product_image] Error 2
gmake[1]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'
*** Error code 1


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




___

Re: unable to build java in poudriere

[Julian Elischer]

On 25/1/17 10:36 am, Ultima wrote:
Sorry Julian but your details are kind of vague. Are you on head? 
I'm not sure when my last build for openjdk7 or 8 were but I have 
them built in my repo. Is there enough memory on the system building 
it? or is it limited? that is usually the culprit for the openjdk 
ports.


I ask if you were on head because I know java was broken for 
sometime in January but was fixed, or at least r312388 is working.

Sorry, one item missing..  compile is on FreeBSD 10.3

Poudriere is populated with the head ports tree as of yesterday, but I 
had hte same problem a few weeks ago.

the list of packages includes openjdk8
it would probably have the same issue if openjdk8 was the ONLY port to 
make, because jdk8 wants jdk7 to jdb7 won't build.
Should poudriere or ports give a warning "you need to install package 
X before we can do this compile"?






On Tue, Jan 24, 2017 at 8:56 PM, Julian Elischer <mailto:jul...@freebsd.org>> wrote:


from he log file:  (see below)

This dies almost immediately.
Do we need to prime the build with an older java? (e.g. the
bootstrap pkg)?
If so why does  poudriere not do this?
I actually want jdk8 but iti insists on building 7 first, which
fails.
Since I don't care about 7 I can prime the pump by downloading a
7 pkg but should all this be automatic somehow?

Log:



# Entering langtools for target(s) all#


(cd  ./langtools/make && \
  gmake
JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk

JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk/make/common/shared
EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7
TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01
JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01
PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111
JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7
JDK_MICRO_VERSION=0_111 PREVIOUS_MAJOR_VERSION=1
PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=
PAX_COMMAND=/usr/sbin/paxmark.sh PAX_COMMAND_ARGS="-vm"
ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1
ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7"

ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools
ALT_BOOTDIR=/usr/local/bootstrap-openjdk all)
gmake[3]: Entering directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
JAVA_HOME=/usr/local/bootstrap-openjdk

ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
-diagnostics >

/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log
; \
  JAVA_HOME=/usr/local/bootstrap-openjdk

ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp'
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant
-version >>

/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log
Could not create the Java virtual machine.
Could not create the Java virtual machine.
gmake[3]: *** [Makefile:196:

/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log]
Error 1
gmake[3]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
gmake[2]: *** [make/langtools-rules.gmk:39: langtools-build] Error 2
gmake[2]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'
gmake[1]: *** [Makefile:251: build_product_image] Error 2
gmake[1]: Leaving directory
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'
*** Error code 1


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

unable to build java in poudriere

[Julian Elischer]

from he log file:  (see below)

This dies almost immediately.
Do we need to prime the build with an older java? (e.g. the bootstrap 
pkg)?

If so why does  poudriere not do this?
I actually want jdk8 but iti insists on building 7 first, which fails.
Since I don't care about 7 I can prime the pump by downloading a 7 pkg 
but should all this be automatic somehow?


Log:



# Entering langtools for target(s) all #


(cd  ./langtools/make && \
  gmake JDK_TOPDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk 
JDK_MAKE_SHARED_DIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/jdk/make/common/shared 
EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 
TARGET_CLASS_VERSION=7 MILESTONE=fcs BUILD_NUMBER=b01 
JDK_BUILD_NUMBER=b01 FULL_VERSION=1.7.0_111-b01 
PREVIOUS_JDK_VERSION=1.6. JDK_VERSION=1.7.0_111 JDK_MKTG_VERSION=7 
JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0_111 
PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 
PREVIOUS_MICRO_VERSION= PAX_COMMAND=/usr/sbin/paxmark.sh 
PAX_COMMAND_ARGS="-vm" ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=1 
ANT_HOME="/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7" 
ALT_OUTPUTDIR=/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools 
ALT_BOOTDIR=/usr/local/bootstrap-openjdk all)
gmake[3]: Entering directory 
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'
JAVA_HOME=/usr/local/bootstrap-openjdk 
ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp' 
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant 
-diagnostics > 
/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log 
; \
  JAVA_HOME=/usr/local/bootstrap-openjdk 
ANT_OPTS=-Djava.io.tmpdir='/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-tmp' 
/wrkdirs/usr/ports/java/openjdk7/work/apache-ant-1.9.7/bin/ant 
-version >> 
/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log

Could not create the Java virtual machine.
Could not create the Java virtual machine.
gmake[3]: *** [Makefile:196: 
/wrkdirs/usr/ports/java/openjdk7/work/openjdk/build/bsd-amd64/langtools/build/ant-diagnostics.log] 
Error 1
gmake[3]: Leaving directory 
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk/langtools/make'

gmake[2]: *** [make/langtools-rules.gmk:39: langtools-build] Error 2
gmake[2]: Leaving directory 
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'

gmake[1]: *** [Makefile:251: build_product_image] Error 2
gmake[1]: Leaving directory 
'/wrkdirs/usr/ports/java/openjdk7/work/openjdk'

*** Error code 1


___
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: [CFT] emulators/open-vm-tools{,-nox11} update to 10.1.0

[Julian Elischer]

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:

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

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.



___
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: [CFT] emulators/open-vm-tools{,-nox11} update to 10.1.0

[Julian Elischer]

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?

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



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

jdk7 broken in some way?

[Julian Elischer]

last night  I had poudriere try build jdk8 but that required jdk7 
which didn't build.


I think itwanted jdk6 or maybe bootstrap-openjdk.

whatever it needed (it said it couldn't make a java vm) it didn't do it.


I thought poudriere would set up everything needed.. Is there anything 
special needed to compile the jdk?



I got my jdk8 by dropping a jdk7 package into the packages area. but 
such manual intervention shouldn't be needed...



___
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: devel/llvm39: runaway_process

[Julian Elischer]

On 19/01/2017 5:49 AM, Craig Leres wrote:
My poudriere build servers have been unable to build devel/llvm39 
ever since some ports changed from llvm37 (January 17th?) The error 
is runaway_process and this happens during the package phase. It 
looks like pkg-static spins for one hour at which point poudriere 
gives up on it. Yesterday I raised max_execution_time for package on 
one build server to 2 hours which did not help.  My three servers 
are all at 10.3-RELEASE-p16 and I'm attempting to build packages for 
the same version.

 llvm-39 took arond 45 minutes more than 37 on my machine.

I'm still able to build llvm37 ok. Since it takes ~2 hours for the 
failure to occur I'm hoping for ideas on how to diagnose this.


Craig
___
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: poudriere: devel/llvm39: runaway_process

[Julian Elischer]

On 19/01/2017 5:49 AM, Craig Leres wrote:
My poudriere build servers have been unable to build devel/llvm39 
ever since some ports changed from llvm37 (January 17th?) The error 
is runaway_process and this happens during the package phase. It 
looks like pkg-static spins for one hour at which point poudriere 
gives up on it. Yesterday I raised max_execution_time for package on 
one build server to 2 hours which did not help.  My three servers 
are all at 10.3-RELEASE-p16 and I'm attempting to build packages for 
the same version.


I'm still able to build llvm37 ok. Since it takes ~2 hours for the 
failure to occur I'm hoping for ideas on how to diagnose this.


mine build both yesterday for some reason
(both succeeded)



Craig
___
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: recent change to vim defaults?

[Julian Elischer]

On 19/01/2017 11:18 AM, Julian Elischer wrote:

On 19/01/2017 1:37 AM, Adam Weinberger wrote:
On 18 Jan, 2017, at 10:35, Julian Elischer  
wrote:


On 17/01/2017 1:23 AM, Adam Weinberger wrote:
On 16 Jan, 2017, at 9:25, Baptiste Daroussin  
wrote:


On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
I noticed that suddenly vim is grabbing mouse movements, which 
makes life

really hard.

Was there a specific revision that brought in this change, and 
can it be

removed?
This change appeared in one of the last patchset of vim 7.4 and 
was one of the

"features" of the vim 8.0 release.

I do agree this is just totally painful :(

Best regards,
Bapt
One of the things that I inherited with the Vim port was the 
DEFAULT_VIMRC option (which installs 
/usr/ports/editors/vim/files/vimrc), and I haven't touched it.


I have moused disabled in all my boxes so I have no idea about 
bad mouse behaviour in Vim. If there is a bad default that is 
causing grief, let's just fix it in that default vimrc.


I'm not really understanding what the unexpected behaviour is so 
I can't make an intelligent recommendation myself, but I'll go 
with whatever you folks suggest.


# Adam

I'm in iterm on my mac.
I ssh to a freebsd machine
I use vim on a file.
I used to be able to use the mouse on my mac to copy a few lines 
into the cut buffer.. slide-shift-click etc..
now suddenly if I try highlight some code in vim to copy it vim 
drags stuff around, scrolls up and down, deletes stuff and 
generally makes a mess.

if click, instead of starting a copy zone it grabs some of the text.

basically it makes hte mouse useless.
I can;t copy and paste from a file I'm ediitng. I end up having to 
exit vim and do it in vi.
There have been a number of recommendations in this thread for you, 
Julian, including "set mouse=a" and "set mouse=v". Test some of 
them out and let me know what works for you.


actually I never saw one about mouse=a however I did see and try 
mouse=v which didn't work for me.


I have now tried mouse=a and am happy to say that that does what I 
need.

thanks!


actually no, 'set mouse='
seems to be what I want.. not sure why I thought =a worked:




# Adam




___
freebsd-curr...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
"freebsd-current-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: recent change to vim defaults?

[Julian Elischer]

On 19/01/2017 1:37 AM, Adam Weinberger wrote:

On 18 Jan, 2017, at 10:35, Julian Elischer  wrote:

On 17/01/2017 1:23 AM, Adam Weinberger wrote:

On 16 Jan, 2017, at 9:25, Baptiste Daroussin  wrote:

On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:

I noticed that suddenly vim is grabbing mouse movements, which makes life
really hard.

Was there a specific revision that brought in this change, and can it be
removed?

This change appeared in one of the last patchset of vim 7.4 and was one of the
"features" of the vim 8.0 release.

I do agree this is just totally painful :(

Best regards,
Bapt

One of the things that I inherited with the Vim port was the DEFAULT_VIMRC 
option (which installs /usr/ports/editors/vim/files/vimrc), and I haven't 
touched it.

I have moused disabled in all my boxes so I have no idea about bad mouse 
behaviour in Vim. If there is a bad default that is causing grief, let's just 
fix it in that default vimrc.

I'm not really understanding what the unexpected behaviour is so I can't make 
an intelligent recommendation myself, but I'll go with whatever you folks 
suggest.

# Adam

I'm in iterm on my mac.
I ssh to a freebsd machine
I use vim on a file.
I used to be able to use the mouse on my mac to copy a few lines into the cut 
buffer.. slide-shift-click etc..
now suddenly if I try highlight some code in vim to copy it vim drags stuff 
around, scrolls up and down, deletes stuff and generally makes a mess.
if click, instead of starting a copy zone it grabs some of the text.

basically it makes hte mouse useless.
I can;t copy and paste from a file I'm ediitng. I end up having to exit vim and 
do it in vi.

There have been a number of recommendations in this thread for you, Julian, including "set 
mouse=a" and "set mouse=v". Test some of them out and let me know what works for you.


actually I never saw one about mouse=a however I did see and try 
mouse=v which didn't work for me.


I have now tried mouse=a and am happy to say that that does what I need.
thanks!



# Adam




___
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: standard settings for ports.

[Julian Elischer]

On 19/01/2017 1:28 AM, Trond Endrestøl wrote:

On Thu, 19 Jan 2017 01:25+0800, Julian Elischer wrote:


pointers appreciated...

Try something like this in /etc/make.conf:

DEFAULT_VERSIONS=apache=2.4 bdb=6 firebird=2.5 gcc=4.9 ghostscript=9 lua=5.2 
mysql=5.7 perl5=5.22 php=5.6 pgsql=9.5 python=2.7 python2=2.7 python3=3.5 
ruby=2.2 ssl=openssl tcltk=8.6


that's good but where is it documented?

thanks anyway!


___
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: recent change to vim defaults?

[Julian Elischer]

On 18/01/2017 5:03 PM, Raimund Sacherer wrote:

I have to put mouse=v to get the behavior I am used to.

Best


doesn't really work for me.

vim is still taking mouse events


___
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: recent change to vim defaults?

[Julian Elischer]

On 17/01/2017 1:23 AM, Adam Weinberger wrote:

On 16 Jan, 2017, at 9:25, Baptiste Daroussin  wrote:

On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:

I noticed that suddenly vim is grabbing mouse movements, which makes life
really hard.

Was there a specific revision that brought in this change, and can it be
removed?

This change appeared in one of the last patchset of vim 7.4 and was one of the
"features" of the vim 8.0 release.

I do agree this is just totally painful :(

Best regards,
Bapt

One of the things that I inherited with the Vim port was the DEFAULT_VIMRC 
option (which installs /usr/ports/editors/vim/files/vimrc), and I haven't 
touched it.

I have moused disabled in all my boxes so I have no idea about bad mouse 
behaviour in Vim. If there is a bad default that is causing grief, let's just 
fix it in that default vimrc.

I'm not really understanding what the unexpected behaviour is so I can't make 
an intelligent recommendation myself, but I'll go with whatever you folks 
suggest.

# Adam

I'm in iterm on my mac.
I ssh to a freebsd machine
I use vim on a file.
I used to be able to use the mouse on my mac to copy a few lines into 
the cut buffer..  slide-shift-click etc..
now suddenly if I try highlight some code in vim to copy it vim drags 
stuff around, scrolls up and down, deletes stuff and generally makes a 
mess.

if click, instead of starting a copy zone it grabs some of the text.

basically it makes hte mouse useless.
I can;t copy and paste from a file I'm ediitng. I end up having to 
exit vim and do it in vi.







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

standard settings for ports.

[Julian Elischer]

I know there are some standard setting one can set..


make ports shows 8 but I know there are many more.


like what version of perl you want to use throughout your system

or whether you want to use openssl from ports or system or what 
version of python..


or whether to use some version of gcc or ...


Is there a list somewhere as to where all these are found?

for example setting NO-X11-yes (or someting like that)


things I'd like to turn off include

DOCS, EXAMPLES, MAN, X11,

Also I'd like to specify that I'd like everything to try use python 2.7

and jdk8

can I set the USES stuff from the command line?(no?)


pointers appreciated...


Julian




___
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: recent change to vim defaults?

[Julian Elischer]

On 17/01/2017 12:07 AM, ohauer wrote:

I suspect you mean the /usr/local/etc/vim/vimrc and gvimrc files.
That was the first place I've tried to overwrite it, but without 
luck (even with set mouse=) but it works in ~/.vimrc


what to put IN the file?


--
olli
--
send with broken GMX mailer client, sorry for tofu and html scrap
On 15/01/2017, 22:48 Benjamin Kaduk  wrote:

On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
> I noticed that suddenly vim is grabbing mouse movements, which
makes
> life really hard.
>
> Was there a specific revision that brought in this change, and
can it
> be removed?

I remember seeing something go by during an upgrade somewhat
recently
about there now being a defaults file that gets used when a user
does
not specify a .vimrc. Unfortunately, I don't remember whether I saw
that notice on a FreeBSD machine or a Debian one, and haven't
been able
to find the notice I remember through searching some likely places.

Just to check: do you have a .vimrc file in place already?


not yet.
when I work out what to put into it I will make it.



-Ben
___
freebsd-curr...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-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: pending PRs [ports] -[lightsquid],[pftop]

[Julian Elischer]

On 16/01/2017 3:01 PM, Franco Fichtner wrote:

Hi,

Please have a look at either one of:

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


you should say what the patches are abut so the right people know to 
look at them



Thanks,
Franco
___
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: Aw: recent change to vim defaults?

[Julian Elischer]

On 16/01/2017 4:04 AM, Carsten Kunze wrote:

Julian Elischer  wrote:


I noticed that suddenly vim is grabbing mouse movements, which makes
life really hard.

Was there a specific revision that brought in this change, and can it
be removed?

Of course this behavior can be disabled as suggested by others--or you give it a try.  
IMHO using the mouse in vim has many advantages.  To temporarily disable the mouse you 
can press the SHIFT key.  As long as SHIFT is pressed vim ignores the mouse.  So you may 
use copy/paste with left and middle mouse buttons as before or you now use the mouse to 
position the cursor or select text--very useful IMHO (I actually have "set 
mouse=a" in .vimrc... ;)
Since i use a mac I cut and paste using blob-c and blob-v. 
Unfortunatley shift-blob-xxx  doesn't work and is interpretted as a 
different command by the mac.


my sessions are  [OSX]=>[iTerm]=>[ssh]=>[screen]=>[vim]
so I'm quite surprised my mouse movements are getting as far as vim.
but if I hold shift..  I can't cut and paste in the OSX layer any more.




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

recent change to vim defaults?

[Julian Elischer]

I noticed that suddenly vim is grabbing mouse movements, which makes 
life really hard.


Was there a specific revision that brought in this change, and can it 
be removed?


___
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: suggested patch for bsd.ports.mk

[Julian Elischer]

On 4/01/2017 4:05 AM, Kurt Jaeger wrote:

Hi!


I got several "yes please" from members of the public,
but no actionable response from members of the ports group
So I am asking again.

I'd also like to have this patch.

If I look at the PR, mat is already working to integrate it.


yes though I've no estimate of when we could see it.

If it is going to take too long I'd like to put in my version and have 
it replaced when Mat works out his version.


Mat?

___
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: openldap-client vs openldap-sasl-client

[Julian Elischer]

On 5/01/2017 6:44 PM, Julian Elischer wrote:

On 5/01/2017 6:30 PM, Jan Bramkamp wrote:

On 04/01/2017 18:32, Andriy Gapon wrote:


Do you I understand correctly that it is impossible now to install 
both samba44

and libreoffice using the official FreeBSD package repository?
Or samba44 and KDE?

If yes, then that sucks...


similar happened recently with the two jpeg libraries.
They can't be installed at the same time but some packages wanted 
one and some the other.




Yes and yes it sucks. The "solution" is to build your own repo and 
set the right flags to always use the same LDAP client port. With 
binary packages and the speed of modern x86_64 systems I for one no 
longer see removing SASL support from OpenLDAP as useful enough to 
justify the complexity. Are there any reasons other than saved 
build time to disable this dependency (e.g. a bad security track 
record/process, different licenses)?

___
no, I think the "solution" is to think of an architectural way around 
this.

One thought:
 maybe we can have a 'virtual dependency"  that more than one package 
can satisfy?
 the USES stuff seems to be heading in that direction.  Maybe someone 
who knows more about it can tell us more about it?


I'd also like to see packages have more htan one way to install, to 
give the same effect as the linux -devel and regular packages.

pkg install --runtime vs  pkg install --devel
 (and I'd like to see a --minimal,  no docs, examples etc.)
Each would have their own depednencies as well, probably building up 
from minimal->runtime->devel






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

using ports for things they were never meant to do

[Julian Elischer]

So this seems to be  a speciality of mine.

I often find that I need a ports tree at rev X except for some port 
foo/bar that needs to be at some different rev (Y) to pick up  a 
fix/change needed by the application. Now there is no reason that I 
can't just edit the distinfo file and the Makefile and replace X with 
Y, and that nearly always works if X and Y are not too different. I'd 
prefer however to be able to upgrade the Makefile to the right level, 
but that then hits the problem that he Makefile is using an API with 
the rest of the ports system, that is rapidly changing. SO you have 
much more chance of your build failing because of Makefile changes 
than due to incompatibilities in the distfiles.


My personal way of handing that would be to break the pkg rev out to a 
separate file with nothing but PORTVERSION and PORTREVISION in it so 
that the version of the distfile being fetched is divorced from the 
ports API.  Then in my tree I update distinfo and the new Portrev and 
leave the Makefile alone.


Does anyone else have a better way to slide a particular port back or 
ahead compared to the rest of the tree?





___
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: openldap-client vs openldap-sasl-client

[Julian Elischer]

On 5/01/2017 6:30 PM, Jan Bramkamp wrote:

On 04/01/2017 18:32, Andriy Gapon wrote:


Do you I understand correctly that it is impossible now to install 
both samba44

and libreoffice using the official FreeBSD package repository?
Or samba44 and KDE?

If yes, then that sucks...


similar happened recently with the two jpeg libraries.
They can't be installed at the same time but some packages wanted one 
and some the other.




Yes and yes it sucks. The "solution" is to build your own repo and 
set the right flags to always use the same LDAP client port. With 
binary packages and the speed of modern x86_64 systems I for one no 
longer see removing SASL support from OpenLDAP as useful enough to 
justify the complexity. Are there any reasons other than saved build 
time to disable this dependency (e.g. a bad security track 
record/process, different licenses)?

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

unable to reproduce previous pkg builds

[Julian Elischer]

d'gay all.

I've been stuggling for  a few days trying to get a pkg of 
sysutils/tracker (1.6+) that I can apply to a 10.3 system.


The version in the 10.3 pkg collection is 1.4 but the version in head 
at exactly the same time is 1.6.1.


Most of the packages on our machine are generated from the head branch 
at rev 411747 which is where the head was when 10.3 was released.


Luckily this revision number also gives me the version I need. It 
could also be taken from the 2016Q2 branch, but neither of those two 
compile.


Or rather they never get to compile because poudriere trips up over 
other failures earlier.



I have to presume that thes pkgs were actually compiled in hte past 
(in fact I KNOW some were becausewe wer eable to install one earlier 
in testing.


My qustion is "if we are compiling on a standard 10,3 system under 
poedriere using head checked out (manually) to 4117474, or  with 
-Bbranches/2016Q2
 Am I right in expecting that as these probably compiled at the time, 
one should expect them to compile now.



the eventual command run is

sudo poudriere bulk -j freebsd_10-3x64 -p svn2016Q2  -f 
/usr/local/etc/poudriere.d/port-list


or
sudo poudriere bulk -j freebsd_10-3x64 -p head-411747  -f 
/usr/local/etc/poudriere.d/port-list


where svn2016Q2 is controlled entirely by poudrier and head-411747 is 
checked out (from svn) manually at 411747


_*[00:10:47] >> [01][00:00:24] Finished build of 
misc/shared-mime-info: Failed: build*_


_*[00:13:11] >> [01][00:00:14] Finished build of textproc/gtk-doc: 
Failed: build*_


_*[00:13:49] >> [02][00:00:08] Finished build of devel/xdg-utils: 
Failed: build

*_

_*
*_Is there someone more familiar with poudriere and ports who can 
duplicate the failure and let me know if it is pilot error?


these must have compiled some time...

the surprising thing for me is that tracker, a package I had never 
heard of until recently forces a compile of 230 other packages!


(hense the likelihood that one will fail).

I also have tried head at 425747.. same issue.

I must be doing something wrong...




___
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: suggested patch for bsd.ports.mk

[Julian Elischer]

On 3/01/2017 6:44 PM, Vlad K. wrote:

On 2017-01-03 11:31, Julian Elischer wrote:

Sometime ago I proposed the following change.

I got several "yes please" from members of the public,
but no actionable response from members of the ports group
So I am asking again.



I haven't checked the code in detail for correctness, but 
conceptually this is nice. I wanted to propose something like this 
last year, inspired by Gentoo's ability to just drop a patch in a 
directory in /etc which would be picked up automatically by portage.


However, I was convinced that it's unnecessary work because any 
custom patches can be added directly to the /files/ directory of the 
port and if using svn'd ports tree, it's easy to track and even push 
upstream.


But seeing that someone else now thinks this is good too, I'd like 
to cast my vote again for this. Yes, it's easy to do it with svn, 
but with something like this it should be possible to add an ability 
for Poudriere (and Synth?) to track multiple patches for multiple 
sets without the need to "pollute" the ports tree. Why? A/B testing, 
different arches - different patches, etc


So here: YES PLEASE.

Julian, did you put it up for comments on reviews.freebsd.org?

no I did not. I'm not sure how I would do that
clicking on the 'diff' button on the bug attachment gives  a nice view 
of the patch.








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