Re: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD

[Russell Haley]

+1
I threw some comments on the open issues.

On Wed, Sep 27, 2017 at 6:36 PM, Geoffrey Huntley  wrote:
> Tomas and Karel from MSFT have some updates for us, in short, the full-scale
> battle can start and volunteers are needed.
>
> - FreeBSD: implement System.Diagnostic.Process:
> https://github.com/dotnet/corefx/issues/24292
> - FreeBSD: System.Console is not working right:
> https://github.com/dotnet/corefx/issues/24259
>
>> I was finally able to run corefx tests on FreeBSD 11.0 (without outerloop
>> tests)
>> Total passed: 144208
>> Total failed: 2622
>> Total skipped 207
>>
>> I will update dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD with
>> instructions.
>>  I will file specific issues and tag them with with os-freebsd and
>> up-for-grab.
>>
>
> From https://github.com/dotnet/corefx/issues/1626#issuecomment-332668619
>
>
>
> On 8 September 2017 at 10:51, Russell Haley  wrote:
>>
>> Hi I just dropped a twitter to Karel (suddenly feel less smart) and
>> this was his response:
>>
>> "Yep, I was poking at a plan internally first. Got some hinys and will
>> reply tomorrow. Tomas even made some progress ."
>>
>> Sweet!
>>
>> Russ
>>
>> On Tue, Sep 5, 2017 at 12:24 PM, Russell Haley 
>> wrote:
>> > On Tue, Sep 5, 2017 at 11:52 AM, David Naylor 
>> > wrote:
>> >> On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote:
>> >>> See https://www.youtube.com/watch?v=NHllisWOCpU and
>> >>> https://twitter.com/GeoffreyHuntley/status/904227946084294656
>> >>
>> >> Hi Geoffrey
>> >>
>> >> It is great to hear there is more interest in finishing the port of
>> >> .NET Core
>> >> to FreeBSD (and, I hope, to have ports living in the Port's
>> >> Collection).
>> >>
>> >> Would it be possible for you to put me (and the mono@ mailing list) in
>> >> touch
>> >> with Karel and Tomas - I'm not on Twitter.
>> >>
>> >> I'll reply to this email (dropping ports@ and advocacy@) with more
>> >> technical
>> >> details.
>> >>
>> >> Regards
>> >>
>> >> David
>> >
>> > Just an FYI: I found Karel's email address and dropped him a private
>> > message for more information (I also don't use twitter). I wanted to
>> > wait for permission before publishing any information on the mono
>> > mailing list (including his email address etc).
>> >
>> > I had the DotNet CORE and CLR running on FreeBSD using the
>> > instructions posted way back when. I also asked about more information
>> > a few months back on the DotNet forums but I can't find the message.
>> > The response was that "nothing was happening at the time".
>> > http://forums.dotnetfoundation.org/
>> >
>> >
>> > Cheers,
>> >
>> > Russ
>
>
___
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: Codeblocks no longer compiles on -current

[Jan Beich]

Michael Butler  writes:

> --- sqvm.lo ---
> In file included from sqvm.cpp:5:
> In file included from /usr/include/c++/v1/math.h:310:
> /usr/include/c++/v1/limits:148:85: error: expected expression
> _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type min()
> _NOEXCEPT {return type();}
>
> ^
> ../../../../src/include/scripting/squirrel/sqobject.h:99:24: note:
> expanded from macro 'type'
> #define type(obj) ((obj)._type)
>^

Part libc++ 5.0 fallout[1] that landed a few months ago. Try moving
 one line up or comment out type() definition in "sqobject.h".

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219139

https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20170724/506669.html
___
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"

Codeblocks no longer compiles on -current

[Michael Butler]

Errors all seem to be similar, of the form ..

-- sqbaselib.lo ---
depbase=`echo sqbaselib.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; /bin/sh 
../../../../libtool  --tag=CXX--mode=compile c++ -DHAVE_CONFIG_H 
-I. -I../../../../src/include 
-I../../../../src/include/scripting/include 
-I../../../../src/include/scripting/squirrel -isystem /usr/local/include 
-ansi -DTIXML_USE_STL   -O2 -ffast-math -DCB_AUTOCONF -O2 -pipe 
-march=core2  -fstack-protector -isystem /usr/local/include 
-fno-strict-aliasing  -Wno-undefined-bool-conversion -isystem 
/usr/local/include -std=c++11  -fPIC -DPIC -fexceptions -MT sqbaselib.lo 
-MD -MP -MF $depbase.Tpo -c -o sqbaselib.lo sqbaselib.cpp && mv -f 
$depbase.Tpo $depbase.Plo

--- sqvm.lo ---
In file included from sqvm.cpp:5:
In file included from /usr/include/c++/v1/math.h:310:
/usr/include/c++/v1/limits:148:85: error: expected expression
_LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type min() 
_NOEXCEPT {return type();}


^
../../../../src/include/scripting/squirrel/sqobject.h:99:24: note: 
expanded from macro 'type'

#define type(obj) ((obj)._type)
   ^
In file included from sqvm.cpp:5:
In file included from /usr/include/c++/v1/math.h:310:
/usr/include/c++/v1/limits:148:61: error: no return statement in 
constexpr function
_LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type min() 
_NOEXCEPT {return type();}

^
/usr/include/c++/v1/limits:149:85: error: expected expression
_LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() 
_NOEXCEPT {return type();}


^
../../../../src/include/scripting/squirrel/sqobject.h:99:24: note: 
expanded from macro 'type'

#define type(obj) ((obj)._type)
   ^
In file included from sqvm.cpp:5:
In file included from /usr/include/c++/v1/math.h:310:
/usr/include/c++/v1/limits:149:61: error: no return statement in 
constexpr function
_LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() 
_NOEXCEPT {return type();}

___
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 Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD

[Geoffrey Huntley]

Tomas and Karel from MSFT have some updates for us, in short, the
full-scale battle can start and volunteers are needed.

- FreeBSD: implement System.Diagnostic.Process:
https://github.com/dotnet/corefx/issues/24292
- FreeBSD: System.Console is not working right:
https://github.com/dotnet/corefx/issues/24259

> I was finally able to run corefx tests on FreeBSD 11.0 (without outerloop
tests)
> Total passed: 144208
> Total failed: 2622
> Total skipped 207
>
> I will update dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD with
instructions.
>  I will file specific issues and tag them with with os-freebsd and
up-for-grab.
>

>From https://github.com/dotnet/corefx/issues/1626#issuecomment-332668619



On 8 September 2017 at 10:51, Russell Haley  wrote:

> Hi I just dropped a twitter to Karel (suddenly feel less smart) and
> this was his response:
>
> "Yep, I was poking at a plan internally first. Got some hinys and will
> reply tomorrow. Tomas even made some progress ."
>
> Sweet!
>
> Russ
>
> On Tue, Sep 5, 2017 at 12:24 PM, Russell Haley 
> wrote:
> > On Tue, Sep 5, 2017 at 11:52 AM, David Naylor 
> wrote:
> >> On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote:
> >>> See https://www.youtube.com/watch?v=NHllisWOCpU and
> >>> https://twitter.com/GeoffreyHuntley/status/904227946084294656
> >>
> >> Hi Geoffrey
> >>
> >> It is great to hear there is more interest in finishing the port of
> .NET Core
> >> to FreeBSD (and, I hope, to have ports living in the Port's Collection).
> >>
> >> Would it be possible for you to put me (and the mono@ mailing list) in
> touch
> >> with Karel and Tomas - I'm not on Twitter.
> >>
> >> I'll reply to this email (dropping ports@ and advocacy@) with more
> technical
> >> details.
> >>
> >> Regards
> >>
> >> David
> >
> > Just an FYI: I found Karel's email address and dropped him a private
> > message for more information (I also don't use twitter). I wanted to
> > wait for permission before publishing any information on the mono
> > mailing list (including his email address etc).
> >
> > I had the DotNet CORE and CLR running on FreeBSD using the
> > instructions posted way back when. I also asked about more information
> > a few months back on the DotNet forums but I can't find the message.
> > The response was that "nothing was happening at the time".
> > http://forums.dotnetfoundation.org/
> >
> >
> > Cheers,
> >
> > Russ
>
___
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.

[Don Lewis]

On 27 Sep, Julian Elischer wrote:
> 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.

The docs and runtime would fall into the subpackages category along with
things like debug symbols.

For example, if you want to build a runtime package for port X, and X
has a LIB_DEPENDS that points to Y, then you need to build a version of
Y that contains both the shared library and the include files so that
you can build X.  Since you don't want to install the include files for
Y when you install X, you would have to build another flavor of Y that
doesn't have the include files.  If you use subpackages, you would only
need to build Y once, that that would generate subpackages for the
runtime bits, the include files, the docs, and the debug files.  If you
use something like synth or poudriere for building X, it would install
the runtime and include file subpackages of Y when building X.  When you
want to "pkg install" the X runtime, pkg would only download and install
the Y runtime package.

If at some point you run into a bug and need the debug files, you can
pkg install the debug files for whatever packages that you need without
disturbing your already installed runtime files, and then you can later
deinstall the debug files when you are done with them without needing to
reinstall the runtime files.  The same thing applies to docs.

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

[Chris H]

On Wed, 27 Sep 2017 21:24:22 +0800 Julian Elischer  wrote

> 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.
If I choose licorice flavor. Do I still get to choose between
red, or black. If not, I'd like to request that black be the
one chosen.
IOW I see your point. I'm not really sure FLAVOR(S) are ready
to land, just yet.

Thanks for bringing this point up, Julian. :)

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


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

[Alexander Leidinger]

Quoting Stefan Esser  (from Wed, 27 Sep 2017 14:35:24 +0200):


Am 26.09.17 um 16:05 schrieb Mathieu Arnold:

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.

This has been a long awaiting feature, most of the work has been done by
bapt, bdrewery and antoine, I am just the one actually doing the
announce and commit and all.

All this information, and more to come are in the first link to our wiki
in the bottom block. A roadmap is in the second link.

To define a different flavors in a port, before any include, set:

FLAVORS=  flavor1 flavor2 [...]

The first flavor in the list will be the default.


One question regarding the naming of packages:

The default flavour should probably(?) lead to a package with the same
name as created without flavours.


This implies either an implicit default flavor-name, or stripping of  
the flavor-name in the package-name if it is the first listed flavor.


And if a flavor-ised port gets a different name, shouldn't we  
standardize on the name of the default-flavor (which makes it obsolete  
to list in FLAVORS then)?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpP8XU_Fw0hV.pgp
Description: Digitale PGP-Signatur

Re: Portmaster error

[Adam Vande More]

On Wed, Sep 27, 2017 at 10:22 AM, Paul Schmehl 
wrote:

> I'm running a 10.3-RELEASE instance. I ran portmaster -ad in screen
> yesterday to get all the ports up to date. Today I ran it again, to make
> sure everything was updated.
>
> When I did, I got this error:
>
> portmaster -ad
> ===>>> Gathering distinfo list for installed ports
>
> ===>>> Starting check of installed ports for available updates
> make: "/usr/ports/Mk/bsd.port.mk" line 1462: Cannot open
> /usr/ports/Mk/Uses/execinfo.mk
> make: Fatal errors encountered -- cannot continue
> ===>>> All ports are up to date
>
> Sure enough, execinfo.mk is missing.
>
> I ran portsnap fetch and update to see if that would fix it. It did not.
>
> I didn't find anything about this on the web or in /usr/ports/UDPATING. Is
> this something new? Is there something I can do to fix it other than wait?
>
>
>
A portsnap extract might workaround it.

-- 
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: Portmaster error

[DutchDaemon - FreeBSD Forums Administrator]

On 27-9-2017 17:22, Paul Schmehl wrote:
> I'm running a 10.3-RELEASE instance. I ran portmaster -ad in screen yesterday 
> to get all the ports up to date. Today I ran it again, to make sure 
> everything was updated. > > When I did, I got this error: > > portmaster -ad 
> > ===>>> Gathering
distinfo list for installed ports > > ===>>> Starting check of installed
ports for available updates > make: "/usr/ports/Mk/bsd.port.mk" line
1462: Cannot open /usr/ports/Mk/Uses/execinfo.mk > make: Fatal errors
encountered -- cannot continue > ===>>> All ports are up to date
I recommend you take a look at an earlier thread:

https://docs.freebsd.org/cgi/getmsg.cgi?fetch=24689+0+current/freebsd-ports

If all else fails, I advise you to:

rm /var/db/portsnap/tag
portsnap fetch extract




signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Mathieu Arnold]

Le 27/09/2017 à 15:24, Julian Elischer a écrit :
> 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?

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


  Flavors

One port is built multiple time with variations, each variation creating
a separate package.


  Sub Packages

Build the port once and create multiple packages.



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

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Guido Falsi]

On 09/27/2017 15:24, Julian Elischer wrote:
> 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?

While it's not well defined there's a simple euristics which can be applied:

Can two packages be obtained from a single build process of the ports?

yes -> subpackages

this applies when the produced binaries and other parts are the same
with and without a specific option. The only differentiating thing is if
specific files are included or not in the resulting package.

doc/nodoc usually falls in this category.


no -> flavour

this can happen because changing the options actually changes the
produced binaries and the libraries it links too, so I need to build the
port two times with different options.

x11/nox11 usually falls in this category.


There can be grey areas I bet...

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

[Stefan Esser]

Am 26.09.17 um 16:05 schrieb Mathieu Arnold:
> 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.
> 
> This has been a long awaiting feature, most of the work has been done by
> bapt, bdrewery and antoine, I am just the one actually doing the
> announce and commit and all.
> 
> All this information, and more to come are in the first link to our wiki
> in the bottom block. A roadmap is in the second link.
> 
> To define a different flavors in a port, before any include, set:
> 
> FLAVORS=  flavor1 flavor2 [...]
> 
> The first flavor in the list will be the default.

One question regarding the naming of packages:

The default flavour should probably(?) lead to a package with the same
name as created without flavours.

But any non-default flavour needs a distinct package name.

In the case of the Python ports, this will be the version prefix (py27-
vs. py36-).

But what is planned for the general case?

Will it be left to the port maintainer to add prefixes / postfixes to
package names that reflect the flavours by means of the options that
are enabled by some particular flavour?

Or will the flavour be automatically added to the package name, if
there would be name collisions, otherwise?

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"

Re: [HEADUP] FLAVORS landing.

[Stefan Esser]

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

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"

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.

[Guido Falsi]

On 09/27/2017 10:20, Matthew Seaman wrote:


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.


Same applies for php56 vs php70 vx php71 vs phpfutureversions.

Just stating this as a further example.

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

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

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

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

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


Port| Current version | New version
+-+
emulators/mame  | 0.166   | mame0190
+-+
emulators/mess  | 0.166   | mame0190
+-+


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

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

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

Re: [HEADUP] FLAVORS landing.

[Kirill Ponomarev via freebsd-ports]

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.


signature.asc
Description: PGP signature

Re: [HEADUP] FLAVORS landing.

[Matthew Seaman]

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"

Re: Porters Handbook section 4.4

[Stefan Esser]

Am 26.09.17 um 08:21 schrieb Kubilay Kocak:
> In section:
> 
> 4.4. Patching
> 
> - Add new section (at/numbered 4.4.2)
>   - Name: Automatic Patch Generation
> - Renumber sections (4.4.2 -> 4.4.3)
> 
> Text:
> 
> The ports framework provides a {{{makepatch}} target, which when run,
> automatically creates correctly named and formatted patch files in the
> correct location. The general process is as follows:
> 
> % cd 
> % make patch
> 
> Note: In the general case, {{{make patch}} is used (not just {{{make
> extract}}} to extract the DISTFILES), because ports that contain
> existing patches need to have the patches applied so that they are also
> generated (regenerated) in the last step.
> 
> ```
> % cd work/ (WRKSRC)
> ```
> 
> At this point, make the source changes in WRKSRC:
> 
> ```
> % cp  .orig

Do not perform this copy operation, IF the .orig file does already exist
(from the earlier "make patch" step).

I'd also use "cp -p" to preserve the original modification time, which
will be included in the patch ...

Else, your change will be against a patched file, without the patch that
lead to this state being conserved.

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"

Re: [HEADUP] FLAVORS landing.

[Tilman Keskinöz]

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.






signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[Matthew Seaman]

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

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

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"