Re: [HEADUP] FLAVORS landing.
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: Porters Handbook section 4.4
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.
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: [HEADUP] FLAVORS landing.
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
FreeBSD ports you maintain which are out of date
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.
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.
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.
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: gettng the port revision number associated with the pkg repo.
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.
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: [HEADUP] FLAVORS landing.
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.
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.
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.
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
Portmaster error
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? Paul Schmehl, Retired As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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
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: Portmaster error
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: [HEADUP] FLAVORS landing.
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: [HEADUP] FLAVORS landing.
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.
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: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD
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"
Codeblocks no longer compiles on -current
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: Codeblocks no longer compiles on -current
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"
Re: compler warnings in ports not supported in gcc 4.2.1 (stable/10)
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: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD
+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: [HEADUP] FLAVORS landing.
Am 27.09.17 um 22:57 schrieb Don Lewis: > 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. This assumes, that a matching version of the debug files is still available. Otherwise, you had to first install the latest version of the package and to reproduce the situation with that version. This may be seen as a feature (bug reports only for the version currently in ports), but may be impractical in many cases. The matching of versions of base package and sub-packages must be more strict than by version number, since trivial changes might be applied to a port without incrementing the PORTREVISION, but with impact on the binary, e.g. if the port is to built with some gcc version from ports and that gcc port has been updated, leading to different object files and debug symbols than a previous version of the port with identical version number. A "build number" could be added to each (sub-)package and only if this build number matches, a sub-package may be installed on top of an already installed base package. The build time/date could of course be used instead, if an identical value is used for all the corresponding files. 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"
