Re: pkg: explain PUBKEY
On 07/10/2013 21:37, Anton Shterenlikht wrote: The pkg.conf(5) man page only says: PUBKEY: string Specifies the location to the public RSA key used for signing the repository database. The default value for this file is /etc/ssl/pkg.conf I'm not clear which side creates this file: the server which builds the packages? Or the client that gets the packages from the server? Or something else altogether? This is an optional function. You can just leave the entry blank if you don't need to sign the packages. Otherwise, you can create an RSA keypair using the instructions shown in Glen's blog, and copy the pub key onto all your client machines. https://glenbarber.us/2012/06/11/Maintaining-Your-Own-pkgng-Repository.html I note that there are changes to the digital signing code coming with pkg-1.2 to support package signatures for 10.x Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk signature.asc Description: OpenPGP digital signature
[QAT] r329763: 1x leftovers, 3x success
- Fix location of reswrap after update of FOX-1.4 Reported by:QAT - Build ID: 20131008071200-51528 Job owner: g...@freebsd.org Buildtime: 7 minutes Enddate: Tue, 08 Oct 2013 07:19:04 GMT Revision: r329763 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=329763 - Port:audio/rezound 0.12.3.b_18 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~g...@freebsd.org/20131008071200-51528-204636/rezound-0.12.3.b_18.log Buildgroup: 9.1-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~g...@freebsd.org/20131008071200-51528-204637/rezound-0.12.3.b_18.log Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~g...@freebsd.org/20131008071200-51528-204638/rezound-0.12.3.b_18.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~g...@freebsd.org/20131008071200-51528-204639/rezound-0.12.3.b_18.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131008071200-51528 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] Staging, packaging and more
2013/10/7 Bryan Drewery br...@shatow.net: On 10/6/2013 9:16 PM, Dewayne Geraghty wrote: -Original Message- From: owner-freebsd-po...@freebsd.org [mailto:owner-freebsd-po...@freebsd.org] On Behalf Of Ulrich Spörlein Sent: Sunday, 6 October 2013 11:20 PM To: Bryan Drewery Cc: po...@freebsd.org; Baptiste Daroussin; Fernando Apesteguía Subject: Re: [HEADSUP] Staging, packaging and more Importance: Low 2013/10/4 Bryan Drewery br...@shatow.net: On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote: On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote: On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote: Please no devel packages. Seconded. What's wrong with devel packages? It complicates things for developers and custom software on FreeBSD. The typical situation that I see on most Linux platforms is a lot of confusion by people, why their custom software XYZ does not properly build - the most common answer: they forgot to install a tremendous amount of dev packages, containing headers, build tools and whatnot. On FreeBSD, you can rely on the fact that if you installed e.g. libGL, you can start building your own GL applications without the need to install several libGL-dev, libX11-dev, ... packages first. This is something, which I personally see as a big plus of the FreeBSD ports system and which makes FreeBSD attractive as a development platform. On the other ends, that makes the package fat for embedded systems, that also makes some arbitrary runtime conflicts between packages (because they both provide the same symlink on the .so, while we could live with 2 version at runtime), that leads to tons of potential issue while building locally, and that makes having sometime insane issues with dependency tracking. Why having .a, .la, .h etc in production servers? It could greatly reduce PBI size, etc. Personnaly I do have no strong opinion in one or another direction. Should we be nicer with developers? with end users? with embedded world? That is the question to face to decide if -devel packages is where we want to go or not. If we chose to go down that path, at least we should chose a different name as we've used the -devel suffix for many years for developmental versions. I must agree that it is one of the things high on my list of things that irritate me with several Linux distributions but I can see the point for for embedded systems as well. But can't we have both? Create three packages, a default full package and split packages of -bin, -lib, and even -doc. My first though twas to make the full package a meta-package that would install the split packages in the background, but that would probably be confusing for users at the end of the day, so rather just have it be a real package. I do like that idea very much, and it is easily doable with stage :) +1 to splitting packages for embedded usage. -1 for the split, as it will not fix anybody's problem. On regular machines, disk space is cheap and having to install more packages is just annoying to users. Think of the time wasted that people are told to apt-get libfoo-dev before they can build anything from github, or similar. Are you suggesting we should just auto install all of ports then? The hassle of installing required dependencies for something outside of the normal system is going to happen either way. If you actually *are* space constricted on your tiny embedded machine, what the fuck are you doing with the sqlite database and all the metadata about ports/packages anyway? Just rm /usr/include and /usr/share/doc, /usr/share/man, etc. when building your disk image. But you are doing that already anyway, so this solves no actual problem for you. My two cents Uli Concur with Uli, sans expletive. Subpackages has no harm to anyone. The idea that too many packages hurts me is bad. It's 1 more entry in 'pkg info'. The overall savings in BW/Space is good for everyone. It makes upgrades faster for non-developer users who don't need headers. A lot of ports already track DOCS/EXAMPLES. Subpackages are just an extension/refactoring of that effort. I have the same opinion on stripping docs/examples as I have for stripping headers, so that argument doesn't count :) As for just one more package, I still remember the X11 - Xorg split where your typical system suddenly went from 150 ports to 350 ports installed and every ports/pkg tool slowed down to a crawl. Please understand that more packages triggers some bad memories for some people here. There are plenty of ideas and ways to make this user friendly by automatically installing/depending on the subpackages, as they effectively are today with DOCS/EXAMPLES options. If you don't care about /var/db/pkg or sqlite then its easier to remove the unnecessary files after the build process and repackage the packages (tar --exclude), leaving the clients'
Re: FreeBSD mplayer port update?
On 8 October 2013 02:10, Ronald F. Guilmette r...@tristatelogic.com wrote: Could someone (anyone) explain to me why the FreeBSD port of mplayer has not been updated at all since March 8th of this year? Yes. That is because I am preparing roughly 2 major updates per year, preferably shortly after a FreeBSD release. The other changes to the port are to maintain compatibility and fix whatever problems users may have. To pre-empt the inevitable question: Yes, there will be a new version before the end of October. Do you miss a specific feature in the current port or why do you press for an update? Best regards Riggs ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] Staging, packaging and more
Pascal Schmid pas...@lechindianer.de schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/06/2013 07:21 PM, Bernhard Fröhlich wrote: On Sun, Oct 6, 2013 at 2:20 PM, Ulrich Spörlein u...@freebsd.org wrote: 2013/10/4 Bryan Drewery br...@shatow.net: On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote: On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote: On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote: Please no devel packages. Seconded. What's wrong with devel packages? It complicates things for developers and custom software on FreeBSD. The typical situation that I see on most Linux platforms is a lot of confusion by people, why their custom software XYZ does not properly build - the most common answer: they forgot to install a tremendous amount of dev packages, containing headers, build tools and whatnot. On FreeBSD, you can rely on the fact that if you installed e.g. libGL, you can start building your own GL applications without the need to install several libGL-dev, libX11-dev, ... packages first. This is something, which I personally see as a big plus of the FreeBSD ports system and which makes FreeBSD attractive as a development platform. On the other ends, that makes the package fat for embedded systems, that also makes some arbitrary runtime conflicts between packages (because they both provide the same symlink on the .so, while we could live with 2 version at runtime), that leads to tons of potential issue while building locally, and that makes having sometime insane issues with dependency tracking. Why having .a, .la, .h etc in production servers? It could greatly reduce PBI size, etc. Personnaly I do have no strong opinion in one or another direction. Should we be nicer with developers? with end users? with embedded world? That is the question to face to decide if -devel packages is where we want to go or not. If we chose to go down that path, at least we should chose a different name as we've used the -devel suffix for many years for developmental versions. I must agree that it is one of the things high on my list of things that irritate me with several Linux distributions but I can see the point for for embedded systems as well. But can't we have both? Create three packages, a default full package and split packages of -bin, -lib, and even -doc. My first though twas to make the full package a meta-package that would install the split packages in the background, but that would probably be confusing for users at the end of the day, so rather just have it be a real package. I do like that idea very much, and it is easily doable with stage :) +1 to splitting packages for embedded usage. -1 for the split, as it will not fix anybody's problem. On regular machines, disk space is cheap and having to install more packages is just annoying to users. Think of the time wasted that people are told to apt-get libfoo-dev before they can build anything from github, or similar. If you actually *are* space constricted on your tiny embedded machine, what the fuck are you doing with the sqlite database and all the metadata about ports/packages anyway? Just rm /usr/include and /usr/share/doc, /usr/share/man, etc. when building your disk image. But you are doing that already anyway, so this solves no actual problem for you. My two cents Uli I also don't see why we need to optimize our packages for an embedded environment that is usually very customized. Wouldn't it make more sense to provide some proper port / packaging options/flags that help to optimize size of the packages without touching header files? People could use that flags and poudriere to build their packages together with all their other compiler flags and cpu optimisations. +1 As far as I can see Daniel Nebdal's approach (WITH_DEV_FILES flag, and defaulting to yes) sounds promising. +1 This doesn't change things in the standard case and follows existing patterns, so I like it, too. Mathias Pascal -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSUZ9hAAoJEAWefonBOgAfDlUP/3117hVdZ6WhrygIGnctSb49 V+i0SggAFxXuvFFYlkjexrWFpjMPN2H7vBtR9DVbLNwqb4En+mVj/LVY1ejS9TAQ gj/nKlK6HNdVQWQD8qLfzFUAzWwnSBco/rIOiGkOrHuvFSUCTV5gPehoJ+Vg8Qnz dyUp5SByePNpY1MGMTJZh9gKWJFtTe8DcanDBCVL65rZf/eOVPyiMwlQK+Fy2AQj OQgJxhkWJzvl5V9THsMGiSCzJ+9EMoC620F9WEs3MvO0Ky2zIercFJ2bDaks6CXn arNTsqTT1zI0sZNGNQMrnxYtQPgV3oCEAggj4ZOG0FkhmBkxWNOPUyahBUE/V8ds tvLvugzVzqeaIJWg3IKDNEfGGh0ZnAMhUakUHyJPDhuCLgb498uwElesmgaSvlky eotS4cWGVp2lquuf/xPRRl82K4ciozZi3mttRmrfoznK69p1HJbepCn9maIhFkii WqLTjKVkeZ778is8mw8dom/Qb8OEj+XR6Vetq7cLg4Is//zieKzSvMWm7QrW1dAI zohAjP+lMP5d3TEmeVqvSZhQ9ticzqGGaW4U7zxxRZ0Y/zxkBwe3cIBEpjTpnW9p /a0DJ3JodVBo79N2JheIqweCK9RPn8rOK5HxujnWcJ3jbQAgCxOdLd9iyN6IxOjI 3pHI9pO++Am9ReFvL/Uy =qm+q -END PGP SIGNATURE-
[QAT] r329765: 2x ignored: does not run on i386, while you are running i386, 1x leftovers, 1x success
- Update to 0.13 - While I'm here, support STAGEDIR Changes:http://search.cpan.org/dist/Math-Int128/Changes PR: ports/182808 Submitted by: Kurt Jaeger fbsd-po...@opsec.eu (maintainer) - Build ID: 20131008074600-24466 Job owner: sunp...@freebsd.org Buildtime: 13 minutes Enddate: Tue, 08 Oct 2013 07:58:52 GMT Revision: r329765 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=329765 - Port:math/p5-Math-Int128 0.13 Buildgroup: 9.1-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~sunp...@freebsd.org/20131008074600-24466-204644/p5-Math-Int128-0.13.log Buildgroup: 9.1-QAT/i386 Buildstatus: IGNORED: DOES NOT RUN ON I386, WHILE YOU ARE RUNNING I386 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~sunp...@freebsd.org/20131008074600-24466-204646/p5-Math-Int128-0.13.log Buildgroup: 8.4-QAT/i386 Buildstatus: IGNORED: DOES NOT RUN ON I386, WHILE YOU ARE RUNNING I386 -- Buildarchive URL: https://qat.redports.org/buildarchive/20131008074600-24466 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] Staging, packaging and more
+1 Jov blog: http:amutu.com/blog http://amutu.com/blog 2013/10/8 Mathias Picker mathias.pic...@virtual-earth.de Pascal Schmid pas...@lechindianer.de schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/06/2013 07:21 PM, Bernhard Fröhlich wrote: On Sun, Oct 6, 2013 at 2:20 PM, Ulrich Spörlein u...@freebsd.org wrote: 2013/10/4 Bryan Drewery br...@shatow.net: On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote: On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote: On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote: Please no devel packages. Seconded. What's wrong with devel packages? It complicates things for developers and custom software on FreeBSD. The typical situation that I see on most Linux platforms is a lot of confusion by people, why their custom software XYZ does not properly build - the most common answer: they forgot to install a tremendous amount of dev packages, containing headers, build tools and whatnot. On FreeBSD, you can rely on the fact that if you installed e.g. libGL, you can start building your own GL applications without the need to install several libGL-dev, libX11-dev, ... packages first. This is something, which I personally see as a big plus of the FreeBSD ports system and which makes FreeBSD attractive as a development platform. On the other ends, that makes the package fat for embedded systems, that also makes some arbitrary runtime conflicts between packages (because they both provide the same symlink on the .so, while we could live with 2 version at runtime), that leads to tons of potential issue while building locally, and that makes having sometime insane issues with dependency tracking. Why having .a, .la, .h etc in production servers? It could greatly reduce PBI size, etc. Personnaly I do have no strong opinion in one or another direction. Should we be nicer with developers? with end users? with embedded world? That is the question to face to decide if -devel packages is where we want to go or not. If we chose to go down that path, at least we should chose a different name as we've used the -devel suffix for many years for developmental versions. I must agree that it is one of the things high on my list of things that irritate me with several Linux distributions but I can see the point for for embedded systems as well. But can't we have both? Create three packages, a default full package and split packages of -bin, -lib, and even -doc. My first though twas to make the full package a meta-package that would install the split packages in the background, but that would probably be confusing for users at the end of the day, so rather just have it be a real package. I do like that idea very much, and it is easily doable with stage :) +1 to splitting packages for embedded usage. -1 for the split, as it will not fix anybody's problem. On regular machines, disk space is cheap and having to install more packages is just annoying to users. Think of the time wasted that people are told to apt-get libfoo-dev before they can build anything from github, or similar. If you actually *are* space constricted on your tiny embedded machine, what the fuck are you doing with the sqlite database and all the metadata about ports/packages anyway? Just rm /usr/include and /usr/share/doc, /usr/share/man, etc. when building your disk image. But you are doing that already anyway, so this solves no actual problem for you. My two cents Uli I also don't see why we need to optimize our packages for an embedded environment that is usually very customized. Wouldn't it make more sense to provide some proper port / packaging options/flags that help to optimize size of the packages without touching header files? People could use that flags and poudriere to build their packages together with all their other compiler flags and cpu optimisations. +1 As far as I can see Daniel Nebdal's approach (WITH_DEV_FILES flag, and defaulting to yes) sounds promising. +1 This doesn't change things in the standard case and follows existing patterns, so I like it, too. Mathias Pascal -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSUZ9hAAoJEAWefonBOgAfDlUP/3117hVdZ6WhrygIGnctSb49 V+i0SggAFxXuvFFYlkjexrWFpjMPN2H7vBtR9DVbLNwqb4En+mVj/LVY1ejS9TAQ gj/nKlK6HNdVQWQD8qLfzFUAzWwnSBco/rIOiGkOrHuvFSUCTV5gPehoJ+Vg8Qnz dyUp5SByePNpY1MGMTJZh9gKWJFtTe8DcanDBCVL65rZf/eOVPyiMwlQK+Fy2AQj OQgJxhkWJzvl5V9THsMGiSCzJ+9EMoC620F9WEs3MvO0Ky2zIercFJ2bDaks6CXn arNTsqTT1zI0sZNGNQMrnxYtQPgV3oCEAggj4ZOG0FkhmBkxWNOPUyahBUE/V8ds tvLvugzVzqeaIJWg3IKDNEfGGh0ZnAMhUakUHyJPDhuCLgb498uwElesmgaSvlky eotS4cWGVp2lquuf/xPRRl82K4ciozZi3mttRmrfoznK69p1HJbepCn9maIhFkii
Re: [HEADSUP] Staging, packaging and more
On Sun, Oct 06, 2013 at 02:20:21PM +0200, Ulrich Spörlein wrote: 2013/10/4 Bryan Drewery br...@shatow.net: On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote: On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote: On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote: Please no devel packages. Seconded. What's wrong with devel packages? It complicates things for developers and custom software on FreeBSD. The typical situation that I see on most Linux platforms is a lot of confusion by people, why their custom software XYZ does not properly build - the most common answer: they forgot to install a tremendous amount of dev packages, containing headers, build tools and whatnot. On FreeBSD, you can rely on the fact that if you installed e.g. libGL, you can start building your own GL applications without the need to install several libGL-dev, libX11-dev, ... packages first. This is something, which I personally see as a big plus of the FreeBSD ports system and which makes FreeBSD attractive as a development platform. On the other ends, that makes the package fat for embedded systems, that also makes some arbitrary runtime conflicts between packages (because they both provide the same symlink on the .so, while we could live with 2 version at runtime), that leads to tons of potential issue while building locally, and that makes having sometime insane issues with dependency tracking. Why having .a, .la, .h etc in production servers? It could greatly reduce PBI size, etc. Personnaly I do have no strong opinion in one or another direction. Should we be nicer with developers? with end users? with embedded world? That is the question to face to decide if -devel packages is where we want to go or not. If we chose to go down that path, at least we should chose a different name as we've used the -devel suffix for many years for developmental versions. I must agree that it is one of the things high on my list of things that irritate me with several Linux distributions but I can see the point for for embedded systems as well. But can't we have both? Create three packages, a default full package and split packages of -bin, -lib, and even -doc. My first though twas to make the full package a meta-package that would install the split packages in the background, but that would probably be confusing for users at the end of the day, so rather just have it be a real package. I do like that idea very much, and it is easily doable with stage :) +1 to splitting packages for embedded usage. -1 for the split, as it will not fix anybody's problem. On regular machines, disk space is cheap and having to install more packages is just annoying to users. Think of the time wasted that people are told to apt-get libfoo-dev before they can build anything from github, or similar. If you actually *are* space constricted on your tiny embedded machine, what the fuck are you doing with the sqlite database and all the metadata about ports/packages anyway? Just rm /usr/include and /usr/share/doc, /usr/share/man, etc. when building your disk image. But you are doing that already anyway, so this solves no actual problem for you. My two cents Uli You are totally misunderstanding the goal of sub packages. Right now people are asking for nox11, noportdocs, noportexamples, etc and all sort of knob, when building resulting in a nightmare for the package system, a given package might or might not have a file depending on the knob, this is totally insane. Here is a list of things the sub package solves (among full other things): - Stupid conflicts like libjpeg and libjpeg-turbo, that conflicts because they have the same dev files, meaning that people cannot end up with packages bringing both libraries where there are no technical restrictions about it. a more accurate examples is probably all the databases clients like pgsql or mysql etc. - Allow to not split in tons of different ports things like qt and php. - Not providing .h, .a, .la, etc files also makes it more complicated for someone to build something on a production server. Why the hell does a production would need a compiler and anything related to build? except making it easier for an attacked to build and run its own software easily that has no meaning imho. - Allow to bring cross compilation in the ports tree without too much headache. To get cross compilation working the more atomic the packages are the simpler it is. As we need for some build to have both native and target packages for example gettext: all the bin/* should be native one and are needed while building, whereas we need target version of libintl. Same goes for libxstl and
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 +-+ sysutils/whowatch | 1.4 | 1.8.5 +-+ www/xist| 3.25| 5.2.2 +-+ 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 If wish to stop receiving portscout reminders, please contact portsc...@freebsd.org Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] Staging, packaging and more
On Tue, Oct 8, 2013 at 11:47 AM, Baptiste Daroussin b...@freebsd.org wrote: Concerning the fact that you need a couple of new packages to be able to actually build something out github or whatever, this is a developer problem and doing pkg install gtk2-dev is not complicated at all. While installing gtk2-dev is not hard indeed, finding the name of package, which you need (gtk2-dev in your example) may be much harder. Just an example: Ubuntu has a package for curl (commandline utility): http://packages.ubuntu.com/precise/curl curl (commandline utility) is a thin wrapper around libcurl, libcurl is registered as a dependency. No problems yet, just go through hypelink. http://packages.ubuntu.com/precise/libcurl3 Now, can you say me, what package should I install for obtain headers, .pc, debug symbols and other developer-related stuff for that libcurl? Not some libcurl, but that specific libcurl, which was fetched as dependency of the curl (commandline utility)? It just a fear. My fear. Fear that possibility to create packages/subpackages may lead to creating them randomly, and these randomly created packages/subpackages may lead to the same problems as demonstrated above. And, seems, I'm not alone in that. -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] Staging, packaging and more
On Tue, Oct 08, 2013 at 12:38:22PM +0300, Andrew W. Nosenko wrote: On Tue, Oct 8, 2013 at 11:47 AM, Baptiste Daroussin b...@freebsd.org wrote: Concerning the fact that you need a couple of new packages to be able to actually build something out github or whatever, this is a developer problem and doing pkg install gtk2-dev is not complicated at all. While installing gtk2-dev is not hard indeed, finding the name of package, which you need (gtk2-dev in your example) may be much harder. Just an example: Ubuntu has a package for curl (commandline utility): http://packages.ubuntu.com/precise/curl curl (commandline utility) is a thin wrapper around libcurl, libcurl is registered as a dependency. No problems yet, just go through hypelink. http://packages.ubuntu.com/precise/libcurl3 Now, can you say me, what package should I install for obtain headers, .pc, debug symbols and other developer-related stuff for that libcurl? Not some libcurl, but that specific libcurl, which was fetched as dependency of the curl (commandline utility)? It just a fear. My fear. Fear that possibility to create packages/subpackages may lead to creating them randomly, and these randomly created packages/subpackages may lead to the same problems as demonstrated above. And, seems, I'm not alone in that. Who spoke about reproducing what debian does? So because some people are doing things the wrong way now, we should not try to do it the right way? Sure if we one day decide to go to sepate packages we should go along with a policy about naming the packages. For example in that case we would probably have: curl-bin curl-libs curl-dev No policy has been written yet, and as I said earlier we have no yet ready for that :) regards, Bapt pgpRgoy697m88.pgp Description: PGP signature
Re: [HEADSUP] Staging, packaging and more
On 2013-Oct-08, 10:47, Baptiste Daroussin wrote: [snip] - Lots of people complained about pkg-config being a run dep. But if we are consistent every single port bring .pc files should then run depend on pkg-config because .pc files are useless without pkg-config. This is nonsense. So every port installing a .h should run-depend on a compiler? The port installing the .pc is most likely not the one that's going to use it. Their consumers should (probably build-) depend on pkgconf. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgp3a9kLZ4jdZ.pgp Description: PGP signature
[QAT] r329770: 2x leftovers, 2x success
Upgrade to version 1.570. - Build ID: 20131008105200-18905 Job owner: olg...@freebsd.org Buildtime: 7 minutes Enddate: Tue, 08 Oct 2013 10:59:16 GMT Revision: r329770 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=329770 - Port:sysutils/usermin 1.570 Buildgroup: 9.1-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~olg...@freebsd.org/20131008105200-18905-204656/usermin-1.570.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~olg...@freebsd.org/20131008105200-18905-204657/usermin-1.570.log Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~olg...@freebsd.org/20131008105200-18905-204658/usermin-1.570.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~olg...@freebsd.org/20131008105200-18905-204659/usermin-1.570.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131008105200-18905 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
trouble with poudriere and recent ports tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, after updating my ports tree to a more recent version (svn revision: 329714), I'm no longer able to build most of my ports with poudriere, as I was before (some weeks ago). IMHO there are two major issuses: 1) the STAGE environment isn't yet fully implemented, as some ports seem to need NO_STAGE=yes in make.conf: e.g. devel/libSM, ports-mgmt/poudriere and others. poudriere reports a successful build for these, but the packages do not exist after bulk run. So after updating /usr/local/etc/poudriere.d/make.conf with the NO_STAGE line, I successfully built some ports (e.g. poudriere-3.0.9). 2) the new method of handling manpages does only partly work for me. There are some ports left, which fail at step package (see list). As m4 and perl are among these, there are more than 1200 ports skipped during bulk run. For now, I'm lost. Am I missing something? Is there someone, who is able to give any hints? I'd really like to update my local packages. This is with stable/8: FreeBSD dsssrvt4.incore 8.4-STABLE FreeBSD 8.4-STABLE #4 r253040: Mon Aug 12 14:59:20 CEST 2013 root@dsssrvt4.incore:/usr/obj/usr/src/sys/SERVER64 amd64 List of failed ports: = multimedia/libdv libdv-1.0.0_4 package === Building package for libdv-1.0.0_4 tar: man/man1/dubdv.1.gz: Cannot stat: No such file or directory tar: man/man1/dvconnect.1.gz: Cannot stat: No such file or directory tar: man/man1/encodedv.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 devel/m4 m4-1.4.17,1 package === Building package for m4-1.4.17,1 tar: man/man1/gm4.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 graphics/webp webp-0.3.1_1 package === Building package for webp-0.3.1_1 tar: man/man1/cwebp.1.gz: Cannot stat: No such file or directory tar: man/man1/dwebp.1.gz: Cannot stat: No such file or directory tar: man/man1/gif2webp.1.gz: Cannot stat: No such file or directory tar: man/man1/webpmux.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 sysutils/fusefs-libs fusefs-libs-2.9.3_1 package === Building package for fusefs-libs-2.9.3_1 tar: man/man1/fusermount.1.gz: Cannot stat: No such file or directory tar: man/man1/ulockmgr_server.1.gz: Cannot stat: No such file or directory tar: man/man8/mount.fuse.8.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 graphics/ocrad ocrad-0.22 package === Building package for ocrad-0.22 tar: man/man1/ocrad.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 lang/perl5.14 perl-5.14.4_1 package === Building package for perl-5.14.4_1 tar: man/man1/a2p.1.gz: Cannot stat: No such file or directory tar: man/man1/c2ph.1.gz: Cannot stat: No such file or directory tar: man/man1/config_data.1.gz: Cannot stat: No such file or directory ... (long list) tar: man/man1/xsubpp.1.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/AnyDBM_File.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/App::Cpan.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/App::Prove.3.gz: Cannot stat: No such file or directory ... (another long list) tar: lib/perl5/5.14/perl/man/man3/vmsish.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/warnings.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/warnings::register.3.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 security/clamav clamav-0.98_1 package === Building package for clamav-0.98_1 tar: man/man1/clambc.1.gz: Cannot stat: No such file or directory tar: man/man1/clamconf.1.gz: Cannot stat: No such file or directory tar: man/man1/clamdscan.1.gz: Cannot stat: No such file or directory tar: man/man1/clamdtop.1.gz: Cannot stat: No such file or directory tar: man/man1/clamscan.1.gz: Cannot stat: No such file or directory tar: man/man1/freshclam.1.gz: Cannot stat: No such file or directory tar: man/man1/sigtool.1.gz: Cannot stat: No such file or directory tar: man/man5/clamav-milter.conf.5.gz: Cannot stat: No such file or directory tar: man/man5/clamd.conf.5.gz: Cannot stat: No such file or directory tar: man/man5/freshclam.conf.5.gz: Cannot stat: No such file or directory tar: man/man8/clamav-milter.8.gz: Cannot stat: No such file or directory tar: man/man8/clamd.8.gz: Cannot stat: No such file or directory tar: Error
[QAT] r329769: 2x leftovers, 2x success
Upgrade to version 1.660. - Build ID: 20131008105200-64898 Job owner: olg...@freebsd.org Buildtime: 16 minutes Enddate: Tue, 08 Oct 2013 11:08:15 GMT Revision: r329769 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=329769 - Port:sysutils/webmin 1.660 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~olg...@freebsd.org/20131008105200-64898-204652/webmin-1.660.log Buildgroup: 9.1-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~olg...@freebsd.org/20131008105200-64898-204653/webmin-1.660.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~olg...@freebsd.org/20131008105200-64898-204654/webmin-1.660.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~olg...@freebsd.org/20131008105200-64898-204655/webmin-1.660.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131008105200-64898 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: trouble with poudriere and recent ports tree
On 10/8/2013 12:51, Alfred Bartsch wrote: Hi all, after updating my ports tree to a more recent version (svn revision: 329714), I'm no longer able to build most of my ports with poudriere, as I was before (some weeks ago). For now, I'm lost. Am I missing something? Is there someone, who is able to give any hints? Did you update poudriere to the latest version 3.0.9 before attempting these builds? John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] Staging, packaging and more
2013/10/8 Baptiste Daroussin b...@freebsd.org: On Sun, Oct 06, 2013 at 02:20:21PM +0200, Ulrich Spörlein wrote: 2013/10/4 Bryan Drewery br...@shatow.net: On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote: On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote: On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote: Please no devel packages. Seconded. What's wrong with devel packages? It complicates things for developers and custom software on FreeBSD. The typical situation that I see on most Linux platforms is a lot of confusion by people, why their custom software XYZ does not properly build - the most common answer: they forgot to install a tremendous amount of dev packages, containing headers, build tools and whatnot. On FreeBSD, you can rely on the fact that if you installed e.g. libGL, you can start building your own GL applications without the need to install several libGL-dev, libX11-dev, ... packages first. This is something, which I personally see as a big plus of the FreeBSD ports system and which makes FreeBSD attractive as a development platform. On the other ends, that makes the package fat for embedded systems, that also makes some arbitrary runtime conflicts between packages (because they both provide the same symlink on the .so, while we could live with 2 version at runtime), that leads to tons of potential issue while building locally, and that makes having sometime insane issues with dependency tracking. Why having .a, .la, .h etc in production servers? It could greatly reduce PBI size, etc. Personnaly I do have no strong opinion in one or another direction. Should we be nicer with developers? with end users? with embedded world? That is the question to face to decide if -devel packages is where we want to go or not. If we chose to go down that path, at least we should chose a different name as we've used the -devel suffix for many years for developmental versions. I must agree that it is one of the things high on my list of things that irritate me with several Linux distributions but I can see the point for for embedded systems as well. But can't we have both? Create three packages, a default full package and split packages of -bin, -lib, and even -doc. My first though twas to make the full package a meta-package that would install the split packages in the background, but that would probably be confusing for users at the end of the day, so rather just have it be a real package. I do like that idea very much, and it is easily doable with stage :) +1 to splitting packages for embedded usage. -1 for the split, as it will not fix anybody's problem. On regular machines, disk space is cheap and having to install more packages is just annoying to users. Think of the time wasted that people are told to apt-get libfoo-dev before they can build anything from github, or similar. If you actually *are* space constricted on your tiny embedded machine, what the fuck are you doing with the sqlite database and all the metadata about ports/packages anyway? Just rm /usr/include and /usr/share/doc, /usr/share/man, etc. when building your disk image. But you are doing that already anyway, so this solves no actual problem for you. My two cents Uli You are totally misunderstanding the goal of sub packages. Right now people are asking for nox11, noportdocs, noportexamples, etc and all sort of knob, when building resulting in a nightmare for the package system, a given package might or might not have a file depending on the knob, this is totally insane. Yes it is, and I fully understand that part and have been advocating for one package that has everything, but might only extract 80% depending on OPTIONS, for some time now. I just don't want us to have 20.000 ports now, and then 40.000 ports because we split things into user/dev ports/packages. I'm totally cool with having a tweaked package here and there to fix several annoyances as you've outlined below. Seriously, make it happen! A user should not care, if not installing headers for package X solves a conflict, do it! But please don't make it a default to not install headers because 3% of the FreeBSD system builders might find it useful. It looks like a lot of the arguments are because there's a different understanding of what a -dev package is, and of course everyone just knows what they are in linux-land, and they suck. That's why you see some pushback on this list. Here is a list of things the sub package solves (among full other things): - Stupid conflicts like libjpeg and libjpeg-turbo, that conflicts because they have the same dev files, meaning that people cannot end up with packages bringing
Re: trouble with poudriere and recent ports tree
On 10/8/2013 5:51 AM, Alfred Bartsch wrote: Hi all, after updating my ports tree to a more recent version (svn revision: 329714), I'm no longer able to build most of my ports with poudriere, as I was before (some weeks ago). IMHO there are two major issuses: 1) the STAGE environment isn't yet fully implemented, as some ports seem to need NO_STAGE=yes in make.conf: e.g. devel/libSM, ports-mgmt/poudriere and others. poudriere reports a successful build for these, but the packages do not exist after bulk run. This is not a problem. They are marked NO_STAGE to run compatibility code until they are converted. So after updating /usr/local/etc/poudriere.d/make.conf with the NO_STAGE line, I successfully built some ports (e.g. poudriere-3.0.9). NO_STAGE is not a user variable. Do NOT put it in your make.conf. This will break a lot. 2) the new method of handling manpages does only partly work for me. There are some ports left, which fail at step package (see list). As m4 and perl are among these, there are more than 1200 ports skipped during bulk run. For now, I'm lost. Am I missing something? Is there someone, who is able to give any hints? I'd really like to update my local packages. This is with stable/8: FreeBSD dsssrvt4.incore 8.4-STABLE FreeBSD 8.4-STABLE #4 r253040: Mon Aug 12 14:59:20 CEST 2013 root@dsssrvt4.incore:/usr/obj/usr/src/sys/SERVER64 amd64 List of failed ports: = multimedia/libdv libdv-1.0.0_4 package === Building package for libdv-1.0.0_4 tar: man/man1/dubdv.1.gz: Cannot stat: No such file or directory tar: man/man1/dvconnect.1.gz: Cannot stat: No such file or directory tar: man/man1/encodedv.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 devel/m4 m4-1.4.17,1 package === Building package for m4-1.4.17,1 tar: man/man1/gm4.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 graphics/webp webp-0.3.1_1 package === Building package for webp-0.3.1_1 tar: man/man1/cwebp.1.gz: Cannot stat: No such file or directory tar: man/man1/dwebp.1.gz: Cannot stat: No such file or directory tar: man/man1/gif2webp.1.gz: Cannot stat: No such file or directory tar: man/man1/webpmux.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 sysutils/fusefs-libs fusefs-libs-2.9.3_1 package === Building package for fusefs-libs-2.9.3_1 tar: man/man1/fusermount.1.gz: Cannot stat: No such file or directory tar: man/man1/ulockmgr_server.1.gz: Cannot stat: No such file or directory tar: man/man8/mount.fuse.8.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 graphics/ocrad ocrad-0.22 package === Building package for ocrad-0.22 tar: man/man1/ocrad.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 lang/perl5.14 perl-5.14.4_1 package === Building package for perl-5.14.4_1 tar: man/man1/a2p.1.gz: Cannot stat: No such file or directory tar: man/man1/c2ph.1.gz: Cannot stat: No such file or directory tar: man/man1/config_data.1.gz: Cannot stat: No such file or directory ... (long list) tar: man/man1/xsubpp.1.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/AnyDBM_File.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/App::Cpan.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/App::Prove.3.gz: Cannot stat: No such file or directory ... (another long list) tar: lib/perl5/5.14/perl/man/man3/vmsish.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/warnings.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/warnings::register.3.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 security/clamav clamav-0.98_1 package === Building package for clamav-0.98_1 tar: man/man1/clambc.1.gz: Cannot stat: No such file or directory tar: man/man1/clamconf.1.gz: Cannot stat: No such file or directory tar: man/man1/clamdscan.1.gz: Cannot stat: No such file or directory tar: man/man1/clamdtop.1.gz: Cannot stat: No such file or directory tar: man/man1/clamscan.1.gz: Cannot stat: No such file or directory tar: man/man1/freshclam.1.gz: Cannot stat: No such file or directory tar: man/man1/sigtool.1.gz: Cannot stat: No such file or directory tar: man/man5/clamav-milter.conf.5.gz: Cannot stat: No such file or
[QAT] r329773: 3x leftovers, 1x success
databases/gtksql: Fix leftovers Ever since this port was updated to verson 0.4.5, it has suffered from leftover files caused by installing two sets of PORTDOCS. The custom version added in the post-install target is accounted for, but the distfiles's makefile also has a target that installs the same files plus two others in a non-standard location. The fix is to disable the distfile's install target and keep the one in post-install. - Build ID: 20131008111600-38958 Job owner: mar...@freebsd.org Buildtime: 12 minutes Enddate: Tue, 08 Oct 2013 11:27:52 GMT Revision: r329773 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=329773 - Port:databases/gtksql 0.4.5 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mar...@freebsd.org/20131008111600-38958-204668/gtksql-0.4.5.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mar...@freebsd.org/20131008111600-38958-204669/gtksql-0.4.5.log Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~mar...@freebsd.org/20131008111600-38958-204670/gtksql-0.4.5.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mar...@freebsd.org/20131008111600-38958-204671/gtksql-0.4.5.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131008111600-38958 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] Staging, packaging and more
On Tue, Oct 08, 2013 at 01:21:40PM +0200, Ulrich Spörlein wrote: 2013/10/8 Baptiste Daroussin b...@freebsd.org: On Sun, Oct 06, 2013 at 02:20:21PM +0200, Ulrich Spörlein wrote: 2013/10/4 Bryan Drewery br...@shatow.net: On Fri, Oct 04, 2013 at 09:01:58AM +0200, Baptiste Daroussin wrote: On Fri, Oct 04, 2013 at 08:57:53AM +0200, Erwin Lansing wrote: On Fri, Oct 04, 2013 at 08:32:59AM +0200, Baptiste Daroussin wrote: Please no devel packages. Seconded. What's wrong with devel packages? It complicates things for developers and custom software on FreeBSD. The typical situation that I see on most Linux platforms is a lot of confusion by people, why their custom software XYZ does not properly build - the most common answer: they forgot to install a tremendous amount of dev packages, containing headers, build tools and whatnot. On FreeBSD, you can rely on the fact that if you installed e.g. libGL, you can start building your own GL applications without the need to install several libGL-dev, libX11-dev, ... packages first. This is something, which I personally see as a big plus of the FreeBSD ports system and which makes FreeBSD attractive as a development platform. On the other ends, that makes the package fat for embedded systems, that also makes some arbitrary runtime conflicts between packages (because they both provide the same symlink on the .so, while we could live with 2 version at runtime), that leads to tons of potential issue while building locally, and that makes having sometime insane issues with dependency tracking. Why having .a, .la, .h etc in production servers? It could greatly reduce PBI size, etc. Personnaly I do have no strong opinion in one or another direction. Should we be nicer with developers? with end users? with embedded world? That is the question to face to decide if -devel packages is where we want to go or not. If we chose to go down that path, at least we should chose a different name as we've used the -devel suffix for many years for developmental versions. I must agree that it is one of the things high on my list of things that irritate me with several Linux distributions but I can see the point for for embedded systems as well. But can't we have both? Create three packages, a default full package and split packages of -bin, -lib, and even -doc. My first though twas to make the full package a meta-package that would install the split packages in the background, but that would probably be confusing for users at the end of the day, so rather just have it be a real package. I do like that idea very much, and it is easily doable with stage :) +1 to splitting packages for embedded usage. -1 for the split, as it will not fix anybody's problem. On regular machines, disk space is cheap and having to install more packages is just annoying to users. Think of the time wasted that people are told to apt-get libfoo-dev before they can build anything from github, or similar. If you actually *are* space constricted on your tiny embedded machine, what the fuck are you doing with the sqlite database and all the metadata about ports/packages anyway? Just rm /usr/include and /usr/share/doc, /usr/share/man, etc. when building your disk image. But you are doing that already anyway, so this solves no actual problem for you. My two cents Uli You are totally misunderstanding the goal of sub packages. Right now people are asking for nox11, noportdocs, noportexamples, etc and all sort of knob, when building resulting in a nightmare for the package system, a given package might or might not have a file depending on the knob, this is totally insane. Yes it is, and I fully understand that part and have been advocating for one package that has everything, but might only extract 80% depending on OPTIONS, for some time now. I just don't want us to have 20.000 ports now, and then 40.000 ports because we split things into user/dev ports/packages. I'm totally cool with having a tweaked package here and there to fix several annoyances as you've outlined below. Seriously, make it happen! A user should not care, if not installing headers for package X solves a conflict, do it! But please don't make it a default to not install headers because 3% of the FreeBSD system builders might find it useful. It looks like a lot of the arguments are because there's a different understanding of what a -dev package is, and of course everyone just knows what they are in linux-land, and they suck. That's why you see some pushback on this list. Here is a list of things the sub package
Re: trouble with poudriere and recent ports tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.10.2013 13:19, schrieb John Marino: On 10/8/2013 12:51, Alfred Bartsch wrote: Hi all, after updating my ports tree to a more recent version (svn revision: 329714), I'm no longer able to build most of my ports with poudriere, as I was before (some weeks ago). For now, I'm lost. Am I missing something? Is there someone, who is able to give any hints? Did you update poudriere to the latest version 3.0.9 before attempting these builds? Thank you for your quick answer. Yes, I did. I had to put NO_STAGE=yes into poudriere's make.conf to successfully build poudriere-3.0.9 with poudriere-3.0.5. BTW.: I don't use pkgng up to now. John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org - -- Mit freundlichem Gruß Alfred Bartsch Data-Service GmbH Beethovenstr. 2A 23617 Stockelsdorf fon: +49 451 490010 fax: +49 451 4900126 Amtsgericht Lübeck, HRB 318 BS Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlJT8j0ACgkQ5QGe2JdVf3g16wCgufuD+yWLW56CwqizTabg9FjV QloAoKC/lgoFgFfrvEQsoigH945r4Pl4 =2VU4 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: trouble with poudriere and recent ports tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.10.2013 13:23, schrieb Bryan Drewery: On 10/8/2013 5:51 AM, Alfred Bartsch wrote: Hi all, after updating my ports tree to a more recent version (svn revision: 329714), I'm no longer able to build most of my ports with poudriere, as I was before (some weeks ago). IMHO there are two major issuses: 1) the STAGE environment isn't yet fully implemented, as some ports seem to need NO_STAGE=yes in make.conf: e.g. devel/libSM, ports-mgmt/poudriere and others. poudriere reports a successful build for these, but the packages do not exist after bulk run. This is not a problem. They are marked NO_STAGE to run compatibility code until they are converted. Thank you for your fast answer. AFAICS there are some ports left which are NOT marked NO_STAGE, but can only be built (at least) with poudriere if NO_STAGE is set. So after updating /usr/local/etc/poudriere.d/make.conf with the NO_STAGE line, I successfully built some ports (e.g. poudriere-3.0.9). NO_STAGE is not a user variable. Do NOT put it in your make.conf. This will break a lot. Then I need some advice, how to actually build ports-mgmt/poudriere or devel/libSM (and some more) without this entry in /usr/local/etc/poudriere.d/make.conf. Does this NO_STAGE entry break the build of my failed ports list? 2) the new method of handling manpages does only partly work for me. There are some ports left, which fail at step package (see list). As m4 and perl are among these, there are more than 1200 ports skipped during bulk run. For now, I'm lost. Am I missing something? Is there someone, who is able to give any hints? I'd really like to update my local packages. This is with stable/8: FreeBSD dsssrvt4.incore 8.4-STABLE FreeBSD 8.4-STABLE #4 r253040: Mon Aug 12 14:59:20 CEST 2013 root@dsssrvt4.incore:/usr/obj/usr/src/sys/SERVER64 amd64 List of failed ports: = multimedia/libdv libdv-1.0.0_4 package === Building package for libdv-1.0.0_4 tar: man/man1/dubdv.1.gz: Cannot stat: No such file or directory tar: man/man1/dvconnect.1.gz: Cannot stat: No such file or directory tar: man/man1/encodedv.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 devel/m4 m4-1.4.17,1 package === Building package for m4-1.4.17,1 tar: man/man1/gm4.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 graphics/webp webp-0.3.1_1 package === Building package for webp-0.3.1_1 tar: man/man1/cwebp.1.gz: Cannot stat: No such file or directory tar: man/man1/dwebp.1.gz: Cannot stat: No such file or directory tar: man/man1/gif2webp.1.gz: Cannot stat: No such file or directory tar: man/man1/webpmux.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 sysutils/fusefs-libs fusefs-libs-2.9.3_1 package === Building package for fusefs-libs-2.9.3_1 tar: man/man1/fusermount.1.gz: Cannot stat: No such file or directory tar: man/man1/ulockmgr_server.1.gz: Cannot stat: No such file or directory tar: man/man8/mount.fuse.8.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 graphics/ocrad ocrad-0.22 package === Building package for ocrad-0.22 tar: man/man1/ocrad.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 lang/perl5.14 perl-5.14.4_1 package === Building package for perl-5.14.4_1 tar: man/man1/a2p.1.gz: Cannot stat: No such file or directory tar: man/man1/c2ph.1.gz: Cannot stat: No such file or directory tar: man/man1/config_data.1.gz: Cannot stat: No such file or directory ... (long list) tar: man/man1/xsubpp.1.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/AnyDBM_File.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/App::Cpan.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/App::Prove.3.gz: Cannot stat: No such file or directory ... (another long list) tar: lib/perl5/5.14/perl/man/man3/vmsish.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/warnings.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/warnings::register.3.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 security/clamav clamav-0.98_1 package === Building package for clamav-0.98_1 tar: man/man1/clambc.1.gz: Cannot stat: No such file or
Re: trouble with poudriere and recent ports tree
On 10/8/2013 14:14, Alfred Bartsch wrote: Am 08.10.2013 13:23, schrieb Bryan Drewery: NO_STAGE is not a user variable. Do NOT put it in your make.conf. This will break a lot. Then I need some advice, how to actually build ports-mgmt/poudriere or devel/libSM (and some more) without this entry in /usr/local/etc/poudriere.d/make.conf. Build poudriere straight from /usr/ports and install it. If you need to build poudriere inside poudriere after that, you can. Does this NO_STAGE entry break the build of my failed ports list? NO_STAGE is not a user variable, so why discuss it further? Just remove it. Regards, John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: trouble with poudriere and recent ports tree
On 10/8/2013 7:14 AM, Alfred Bartsch wrote: Am 08.10.2013 13:23, schrieb Bryan Drewery: On 10/8/2013 5:51 AM, Alfred Bartsch wrote: Hi all, after updating my ports tree to a more recent version (svn revision: 329714), I'm no longer able to build most of my ports with poudriere, as I was before (some weeks ago). IMHO there are two major issuses: 1) the STAGE environment isn't yet fully implemented, as some ports seem to need NO_STAGE=yes in make.conf: e.g. devel/libSM, ports-mgmt/poudriere and others. poudriere reports a successful build for these, but the packages do not exist after bulk run. This is not a problem. They are marked NO_STAGE to run compatibility code until they are converted. Thank you for your fast answer. AFAICS there are some ports left which are NOT marked NO_STAGE, but can only be built (at least) with poudriere if NO_STAGE is set. So after updating /usr/local/etc/poudriere.d/make.conf with the NO_STAGE line, I successfully built some ports (e.g. poudriere-3.0.9). NO_STAGE is not a user variable. Do NOT put it in your make.conf. This will break a lot. Then I need some advice, how to actually build ports-mgmt/poudriere or ports-mgmt/poudriere builds fine for me. Can you show the entire build log and your make.conf? devel/libSM (and some more) without this entry in /usr/local/etc/poudriere.d/make.conf. Does this NO_STAGE entry break the build of my failed ports list? 2) the new method of handling manpages does only partly work for me. There are some ports left, which fail at step package (see list). As m4 and perl are among these, there are more than 1200 ports skipped during bulk run. For now, I'm lost. Am I missing something? Is there someone, who is able to give any hints? I'd really like to update my local packages. This is with stable/8: FreeBSD dsssrvt4.incore 8.4-STABLE FreeBSD 8.4-STABLE #4 r253040: Mon Aug 12 14:59:20 CEST 2013 root@dsssrvt4.incore:/usr/obj/usr/src/sys/SERVER64 amd64 List of failed ports: = multimedia/libdv libdv-1.0.0_4 package === Building package for libdv-1.0.0_4 tar: man/man1/dubdv.1.gz: Cannot stat: No such file or directory tar: man/man1/dvconnect.1.gz: Cannot stat: No such file or directory tar: man/man1/encodedv.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 devel/m4 m4-1.4.17,1 package === Building package for m4-1.4.17,1 tar: man/man1/gm4.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 graphics/webp webp-0.3.1_1 package === Building package for webp-0.3.1_1 tar: man/man1/cwebp.1.gz: Cannot stat: No such file or directory tar: man/man1/dwebp.1.gz: Cannot stat: No such file or directory tar: man/man1/gif2webp.1.gz: Cannot stat: No such file or directory tar: man/man1/webpmux.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 sysutils/fusefs-libs fusefs-libs-2.9.3_1 package === Building package for fusefs-libs-2.9.3_1 tar: man/man1/fusermount.1.gz: Cannot stat: No such file or directory tar: man/man1/ulockmgr_server.1.gz: Cannot stat: No such file or directory tar: man/man8/mount.fuse.8.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 graphics/ocrad ocrad-0.22 package === Building package for ocrad-0.22 tar: man/man1/ocrad.1.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 lang/perl5.14 perl-5.14.4_1 package === Building package for perl-5.14.4_1 tar: man/man1/a2p.1.gz: Cannot stat: No such file or directory tar: man/man1/c2ph.1.gz: Cannot stat: No such file or directory tar: man/man1/config_data.1.gz: Cannot stat: No such file or directory ... (long list) tar: man/man1/xsubpp.1.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/AnyDBM_File.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/App::Cpan.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/App::Prove.3.gz: Cannot stat: No such file or directory ... (another long list) tar: lib/perl5/5.14/perl/man/man3/vmsish.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/warnings.3.gz: Cannot stat: No such file or directory tar: lib/perl5/5.14/perl/man/man3/warnings::register.3.gz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 security/clamav clamav-0.98_1 package
port missing dep.!
Hello, The port sysutils / linux-afaapps-2.7_4 is missing a dependency, namely devel / linux-f10-ncurses-base-5.6. The port itself only installs a single binary (afacli) and it simply won't run without the linux ncurses. Thank you. K.C.S. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: trouble with poudriere and recent ports tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 08.10.2013 14:48, schrieb Bryan Drewery:
On 10/8/2013 7:14 AM, Alfred Bartsch wrote:
Am 08.10.2013 13:23, schrieb Bryan Drewery:
On 10/8/2013 5:51 AM, Alfred Bartsch wrote:
Hi all, after updating my ports tree to a more recent
version (svn revision: 329714), I'm no longer able to build
most of my ports with poudriere, as I was before (some weeks
ago).
IMHO there are two major issuses: 1) the STAGE environment
isn't yet fully implemented, as some ports seem to need
NO_STAGE=yes in make.conf: e.g. devel/libSM,
ports-mgmt/poudriere and others. poudriere reports a
successful build for these, but the packages do not exist
after bulk run.
This is not a problem. They are marked NO_STAGE to run
compatibility code until they are converted.
Thank you for your fast answer.
AFAICS there are some ports left which are NOT marked NO_STAGE,
but can only be built (at least) with poudriere if NO_STAGE is
set.
So after updating /usr/local/etc/poudriere.d/make.conf with
the NO_STAGE line, I successfully built some ports (e.g.
poudriere-3.0.9).
NO_STAGE is not a user variable. Do NOT put it in your
make.conf. This will break a lot.
Then I need some advice, how to actually build
ports-mgmt/poudriere or
ports-mgmt/poudriere builds fine for me. Can you show the entire
build log and your make.conf?
Here you are:
==
Building ports-mgmt/poudriere
build started at Fri Oct 4 16:45:06 CEST 2013
port directory: /usr/ports/ports-mgmt/poudriere
building for: FreeBSD j8sp64-PT1-job-01 8.4-STABLE FreeBSD 8.4-STABLE
amd64
maintained by: b...@freebsd.org
Makefile ident: $FreeBSD: head/ports-mgmt/poudriere/Makefile
328933 2013-10-01 11:44:31Z bdrewery $
Poudriere version: 3.0.5
- ---Begin Environment---
OSVERSION=804500
UNAME_v=FreeBSD 8.4-STABLE
UNAME_r=8.4-STABLE
FTP_PASSIVE_MODE=YES
BLOCKSIZE=K
MAIL=/var/mail/root
PACKAGE_BUILDING=yes
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=poudriere-3.0.9
USER=root
SKIPSANITY=0
HOME=/root
FORCE_PACKAGE=yes
PKG_DELETE=pkg_delete
PKG_ADD=pkg_add
PKG_EXT=tbz
PKGNG=0
STATUS=1
MASTERMNT=/home/poudriere/data/build/j8sp64-PT1/ref
TRYBROKEN=yes
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
tpid=37204
LOCALBASE=/usr/local
NBPARALLEL=1
MASTERNAME=j8sp64-PT1
PWD=/home/poudriere
POUDRIERE_VERSION=3.0.5
- ---End Environment---
- ---Begin OPTIONS List---
=== The following configuration options are available for
poudriere-3.0.9:
ZSH=off: Install programmable completions for zsh
=== Use 'make config' to modify these settings
- ---End OPTIONS List---
- --CONFIGURE_ARGS--
- --End CONFIGURE_ARGS--
- --CONFIGURE_ENV--
TMPDIR=/tmp TMPDIR=/tmp SHELL=/bin/sh CONFIG_SHELL=/bin/sh
- --End CONFIGURE_ENV--
- --MAKE_ENV--
TMPDIR=/tmp TMPDIR=/tmp SHELL=/bin/sh NO_LINT=YES
PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR=/usr/lib CC=cc
CFLAGS=-O2 -pipe -fno-strict-aliasing CPP=cpp CPPFLAGS=
LDFLAGS= CXX=c++ CXXFLAGS=-O2 -pipe -fno-strict-aliasing
MANPREFIX=/usr/local BSD_INSTALL_PROGRAM=install -s -o root -g
wheel -m 555 BSD_INSTALL_LIB=install -s -o root -g wheel -m 444
BSD_INSTALL_SCRIPT=install -o root -g wheel -m 555
BSD_INSTALL_DATA=install -o root -g wheel -m 444
BSD_INSTALL_MAN=install -o root -g wheel -m 444
- --End MAKE_ENV--
- --SUB_LIST--
PREFIX=/usr/local
LOCALBASE=/usr/local
DATADIR=/usr/local/share/poudriere
DOCSDIR=/usr/local/share/doc/poudriere
EXAMPLESDIR=/usr/local/share/examples/poudriere
WWWDIR=/usr/local/www/poudriere
ETCDIR=/usr/local/etc/poudriere
- --End SUB_LIST--
- ---Begin make.conf---
USE_PACKAGE_DEPENDS=yes
BATCH=yes
WRKDIRPREFIX=/wrkdirs
PACKAGES=/packages
DISTDIR=/distfiles
/usr/local/etc/poudriere.d/make.conf
#
# - POUDRIERE.D/make.conf - #
#
# ab hier nur noch Einstellungen für Ports
# START Ports -
.if ${.CURDIR:M*/ports/*} !${.CURDIR:M*/work/*}
PACKAGE_BUILDING=1
BATCH=yes
PORTSDIR?= /usr/ports
# docproj
WITHOUT_CJK=yes
# ghostscript, a2ps, ...
A4=yes
PAPERSIZE=a4
# all ports with openssl
WITH_OPENSSL_BASE=yes
WITHOUT_GNUTLS=yes
# all ports with odbc support
WITH_IODBC=yes
# some versions
WITH_BDB_VER= 48
DEFAULT_MYSQL_VER= 53m
APACHE_VERSION= 22
APACHE_PORT=www/apache22
JAVA_VENDOR=openjdk
OVERRIDE_LINUX_NONBASE_PORTS= f10
SAMBA_PORT= samba36
# kdevelop (kde3)
.if ${.CURDIR} == ${PORTSDIR}/devel/kdevelop
WITH_OPTIONAL_DEPENDS=yes
.endif
#php53
.if ${.CURDIR} == ${PORTSDIR}/lang/php53
PREFIX=/usr/local/php53
.endif
.if ${.CURDIR} == ${PORTSDIR}/devel/php53-gettext
PREFIX=/usr/local/php53
PHPBASE=/usr/local/php53
.endif
.if ${.CURDIR} == ${PORTSDIR}/security/php53-hash
PREFIX=/usr/local/php53
PHPBASE=/usr/local/php53
.endif
.if ${.CURDIR} == ${PORTSDIR}/converters/php53-mbstring
PREFIX=/usr/local/php53
Re: port missing dep.!
Le 08/10/2013 14:51, K.C. Smith a écrit : The port sysutils / linux-afaapps-2.7_4 is missing a dependency, namely devel / linux-f10-ncurses-base-5.6. Please fill a PR. The subject of the mail isn't helpful. -- Florent Peterschmitt | Please: flor...@peterschmitt.fr| * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) signature.asc Description: OpenPGP digital signature
Re: trouble with poudriere and recent ports tree
On 10/8/2013 8:00 AM, Alfred Bartsch wrote: Am 08.10.2013 14:48, schrieb Bryan Drewery: On 10/8/2013 7:14 AM, Alfred Bartsch wrote: Am 08.10.2013 13:23, schrieb Bryan Drewery: On 10/8/2013 5:51 AM, Alfred Bartsch wrote: Hi all, after updating my ports tree to a more recent version (svn revision: 329714), I'm no longer able to build most of my ports with poudriere, as I was before (some weeks ago). IMHO there are two major issuses: 1) the STAGE environment isn't yet fully implemented, as some ports seem to need NO_STAGE=yes in make.conf: e.g. devel/libSM, ports-mgmt/poudriere and others. poudriere reports a successful build for these, but the packages do not exist after bulk run. This is not a problem. They are marked NO_STAGE to run compatibility code until they are converted. Thank you for your fast answer. AFAICS there are some ports left which are NOT marked NO_STAGE, but can only be built (at least) with poudriere if NO_STAGE is set. So after updating /usr/local/etc/poudriere.d/make.conf with the NO_STAGE line, I successfully built some ports (e.g. poudriere-3.0.9). NO_STAGE is not a user variable. Do NOT put it in your make.conf. This will break a lot. Then I need some advice, how to actually build ports-mgmt/poudriere or ports-mgmt/poudriere builds fine for me. Can you show the entire build log and your make.conf? Here you are: [snip] POUDRIERE_VERSION=3.0.5 You should probably just update poudriere from your host ports tree directly. At least 3.0.6 is required for staging support. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Undelivered Mail: ho...@freebsd.org
I attempted to contact the maintainer of the
deskutils/horde-groupware port, ho...@freebsd.org, but I received
the following notification:
From: mailer-dae...@mx2.freebsd.org (Mail Delivery System)
To: carmel...@hotmail.com
Subject: Undelivered Mail Returned to Sender
Date: Tue, 8 Oct 2013 12:58:48 + (UTC)
This is the mail system at host mx2.freebsd.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
ho...@freebsdnorth.com: Host or domain name not found. Name service error for
name=freebsdnorth.com type=: Host found but no data record of requested
type
From: Carmel carmel...@hotmail.com
To: ho...@freebsd.org
{truncated by me}
Has anyone else experienced this problem? Is there a change in the
maintainers address that is not reflected in the port?
--
Carmel ✌
carmel...@hotmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: trouble with poudriere and recent ports tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.10.2013 15:05, schrieb Bryan Drewery: On 10/8/2013 8:00 AM, Alfred Bartsch wrote: Am 08.10.2013 14:48, schrieb Bryan Drewery: On 10/8/2013 7:14 AM, Alfred Bartsch wrote: Am 08.10.2013 13:23, schrieb Bryan Drewery: On 10/8/2013 5:51 AM, Alfred Bartsch wrote: Hi all, after updating my ports tree to a more recent version (svn revision: 329714), I'm no longer able to build most of my ports with poudriere, as I was before (some weeks ago). IMHO there are two major issuses: 1) the STAGE environment isn't yet fully implemented, as some ports seem to need NO_STAGE=yes in make.conf: e.g. devel/libSM, ports-mgmt/poudriere and others. poudriere reports a successful build for these, but the packages do not exist after bulk run. This is not a problem. They are marked NO_STAGE to run compatibility code until they are converted. Thank you for your fast answer. AFAICS there are some ports left which are NOT marked NO_STAGE, but can only be built (at least) with poudriere if NO_STAGE is set. So after updating /usr/local/etc/poudriere.d/make.conf with the NO_STAGE line, I successfully built some ports (e.g. poudriere-3.0.9). NO_STAGE is not a user variable. Do NOT put it in your make.conf. This will break a lot. Then I need some advice, how to actually build ports-mgmt/poudriere or ports-mgmt/poudriere builds fine for me. Can you show the entire build log and your make.conf? Here you are: [snip] POUDRIERE_VERSION=3.0.5 You should probably just update poudriere from your host ports tree directly. At least 3.0.6 is required for staging support. Understood. I managed this update by setting NO_STAGE. My wrong conclusion was, that this would help with other ports too. Meanwhile I removed this entry from make.conf and I'm looking forward to the results of my next poudriere bulk run. At least m4 and perl are successfully built again. Thanks. - -- Regards Alfred Bartsch Data-Service GmbH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlJUBs4ACgkQ5QGe2JdVf3gMWACfSa7z2Hnl5n7FyuBUjrUFRQ+4 HVMAn1asxo2W8FDE4kdmuHP16ZV46xmV =2jOh -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
this poudriere thing... it's all right
A success story: - installed ports-mgmt/poudriere-devel on ia64 10.0-CURRENT #4 r255488 - followed poudriere(8) man page, together with http://www.neant.ro/2013/03/building-a-package-repository-for-freebsd-with-poudriere-and-pkgng/ https://wiki.freebsd.org/PkgPrimer - set up poudriere ia64 jail and a separate ports tree at r329660 - built ~200 packages - signed the packages: https://glenbarber.us/2012/06/11/Maintaining-Your-Own-pkgng-Repository.html - set up nginx to serve packages - updated packages on 2 hosts via pkg update/upgrade Many thanks to all who helped and replied to my many questions. Remaining issues/questions: - is it possible to show the svn revision of the ports tree via poudriere ports? This would be useful. - it seems -v option to poudriere ports does nothing: # poudriere ports -l PORTSTREEMETHOD PATH default svn+https /pdr/ports/ # poudriere ports -l -v PORTSTREEMETHOD PATH default svn+https /pdr/ports/ # - is there a standard way to clean up old logs: $ du -sh /pdr/data/logs/bulk/ia64-default/* 12M/pdr/data/logs/bulk/ia64-default/2013-10-06_21h47m07s 14M/pdr/data/logs/bulk/ia64-default/2013-10-07_08h57m57s 592k/pdr/data/logs/bulk/ia64-default/2013-10-07_21h58m03s 524k/pdr/data/logs/bulk/ia64-default/2013-10-07_22h19m56s 504k/pdr/data/logs/bulk/ia64-default/2013-10-07_22h57m42s 524k/pdr/data/logs/bulk/ia64-default/2013-10-07_23h00m03s 524k/pdr/data/logs/bulk/ia64-default/2013-10-08_09h14m14s 524k/pdr/data/logs/bulk/ia64-default/2013-10-08_09h17m49s 8M/pdr/data/logs/bulk/ia64-default/2013-10-08_09h20m56s $ - to get authenticated sendmail I have to have these lines in /etc/make.conf: SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 Do I understand correctly that these lines only affect buildworld on the target box, and have nothing to do with the poudriere build of security/cyrus-sasl2? Or do I need to add these lines to /usr/local/etc/poudriere.d/make.conf? - Do I need to add WITH_SSP_PORTS=yes to /usr/local/etc/poudriere.d/make.conf? Thanks again Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Need some help debugging c++ code for 10.0
On Tue, 08 Oct 2013 00:12:45 +1030 Shane Ambler wrote: Hi there, I am the port maintainer for opencolorio, openimageio and openshadinglanguage. These build and run on 9.2 with clang 3.3 but I have an issue on 10.0. I don't have much programming experience and even less with c++ which all 3 use. After ocio and oiio are installed building osl generates oslc (the osl script compiler) and then runs it to pre-compile the included scripts. This step fails on 10.0 I am fairly sure that the issue is within the ustring class - full code can be viewed at github.com/OpenImageIO/oiio with src/include/ustring.h having some info about the class. The following is from src/libutil/ustring.cpp for ustrings constructor #if defined(__GNUC__) // We don't want the internal 'string str' to redundantly store the // chars, along with our own allocation. So we use our knowledge of // the internal structure of gcc strings to make it point to our chars! // Note that we've carefully structured the TableRep fields so they // mimic a GCC basic_string::_Rep. // // It turns out that the first field of a gcc std::string is a // pointer to the characters within the basic_string::_Rep. We // merely redirect that pointer, though for std::string to function // properly, the chars must be preceeded immediately in memory by // the rest of basic_string::_Rep, consisting of length, capacity // and refcount fields. And we have designed our TableRep to do // just that! So now we redirect the std::string's pointer to our // own characters and its mocked-up _Rep. // // See /usr/include/c++/VERSION/bits/basic_string.h for the details // of gcc's std::string implementation. *(const char **)str = c_str(); DASSERT (str.c_str() == c_str()); #else // Not gcc -- just assign the internal string. This will result in // double allocation for the chars. If you care about that, do // something special for your platform, much like we did for gcc // above. (Windows users, I'm talking to you.) str = s; #endif When the osl build starts to precompile the bundled osl scripts oslc triggers the DASSERT (which is line 137) shown above. If I adjust the #if (and the matching destructor) so the non-gcc fallback is used, osl still fails just without the assert message. There's a third __GNUC__ case in that header. Unlike the first two it's ifNdef though so you need to change it into something like: #if !defined(__GNUC__) || defined(_LIBCPP_VERSION) signature.asc Description: PGP signature
Re: Undelivered Mail: ho...@freebsd.org
On 10/8/2013 15:21, Carmel wrote: I attempted to contact the maintainer of the deskutils/horde-groupware port, ho...@freebsd.org, but I received the following notification: ho...@freebsdnorth.com: Host or domain name not found. Name service error for name=freebsdnorth.com type=: Host found but no data record of requested type Has anyone else experienced this problem? Is there a change in the maintainers address that is not reflected in the port? Yes, I experienced this months ago. The address horde@ points to has been bogus, it's not a new thing. And yes, something should probably be done. John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
poudriere cluster error: contention?
I'm building science/paraview in poudriere with -J 4. paraview pulls in quite a few ports, many of which are included in KDE/qt-everywhere-opensource-src-4.8.4.tar.gz. In my case devel/qmake4 build fails with: pax: File /usr/ports/distfiles/KDE/qt-everywhere-opensource-src-4.8.4.tar.gz was modified during copy to /pdr/data/build/ia64-default/ref/../01/portdistfiles/KDE/qt-everywhere-opensource-src-4.8.4.tar.gz The full log: http://eis.bris.ac.uk/~mexas/poudriere/bulk/ia64-default/2013-10-08_14h41m14s/logs/errors/qt4-qmake-4.8.4_1.log Is it possible that several builders compete for access to KDE/qt-everywhere-opensource-src-4.8.4.tar.gz ? Is it possible that this would lead to the above error? Thanks Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: trouble with poudriere and recent ports tree
Date: Tue, 08 Oct 2013 15:00:19 +0200 From: Alfred Bartsch bart...@dssgmbh.de To: Bryan Drewery bdrew...@freebsd.org Subject: Re: trouble with poudriere and recent ports tree Cc: po...@freebsd.org === Building package for poudriere-3.0.9 Creating package /wrkdirs/usr/ports/ports-mgmt/poudriere/work/poudriere-3.0.9.tbz Registering depends:. Registering conflicts: poudriere-devel. Seems you are trying to install both poudriere and poudriere-devel. Probably they conflict. Try to use just one. Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: trouble with poudriere and recent ports tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.10.2013 16:24, schrieb Anton Shterenlikht: Date: Tue, 08 Oct 2013 15:00:19 +0200 From: Alfred Bartsch bart...@dssgmbh.de To: Bryan Drewery bdrew...@freebsd.org Subject: Re: trouble with poudriere and recent ports tree Cc: po...@freebsd.org === Building package for poudriere-3.0.9 Creating package /wrkdirs/usr/ports/ports-mgmt/poudriere/work/poudriere-3.0.9.tbz Registering depends:. Registering conflicts: poudriere-devel. Seems you are trying to install both poudriere and poudriere-devel. Probably they conflict. Try to use just one. No, the conflicts line does not indicate an installation issue IMHO, it seems to be a comment/hint from Makefile. poudriere-devel has never been installed into my environment. Thanks. Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org - -- Regards Alfred Bartsch Data-Service GmbH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlJUIi0ACgkQ5QGe2JdVf3hmYQCgvqpVbtTzE0UcWtMuRR0qMrh3 oAIAoK1jJ501w5z/iLmje7dJDX0PA5Vk =GDfe -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: this poudriere thing... it's all right
On Tue, Oct 8, 2013 at 8:56 AM, Anton Shterenlikht me...@bris.ac.uk wrote: - to get authenticated sendmail I have to have these lines in /etc/make.conf: SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 Do I understand correctly that these lines only affect buildworld on the target box, and have nothing to do with the poudriere build of security/cyrus-sasl2? Or do I need to add these lines to /usr/local/etc/poudriere.d/make.conf? These variables only affect the build of sendmail when you buildworld. They are not needed when building ports with poudriere. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: building seamonkey - possible clang bug
On 08.10.13 03:41, Tom Uffner wrote: clang: error: unable to execute command: Killed: 9 clang: error: clang frontend command failed due to signal (use -v to see invocation) You were out of swap space, that's why the compiler was killed. real memory = 268435456 (256 MB) avail memory = 248418304 (236 MB) This is not nearly enough, I don't recall what how much a non debug build needs right now, but i think it was close to 2-3GB. You could add more swap, but that's not going to make it any faster :) Florian signature.asc Description: OpenPGP digital signature
building seamonkey - possible clang bug
On Tue Oct 8 15:57:07 UTC 2013, Florian Smeets wrote: You were out of swap space, that's why the compiler was killed. real memory = 268435456 (256 MB) avail memory = 248418304 (236 MB) This is not nearly enough, I don't recall what how much a non debug build needs right now, but i think it was close to 2-3GB. You could add more swap, but that's not going to make it any faster :) Thanks. I realize this. in my message I mentioned that the failure mode was running out of memory. and that I added swap. What I failed to include was that (including swap) i had 3/4 G of VM the 1st time, and a bit over 2 G on the 2nd try. Is 2GB still not enough to compile ns_core.c, or is something else wrong? If possible I would prefer not to invest another week or more to find out that insufficient swap space wasn't the problem after all. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r329794: 1x leftovers, 2x depend (ignored: requires freebsd 9.0 or later in sysutils/pcbsd-utils), 1x depend (plist in sysutils/pcbsd-utils)
- Update to 1381240866 - Build ID: 20131008150600-1101 Job owner: kmo...@freebsd.org Buildtime: 3 hours Enddate: Tue, 08 Oct 2013 17:54:40 GMT Revision: r329794 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=329794 - Port:sysutils/pcbsd-utils-qt4 1381240866 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~kmo...@freebsd.org/20131008150600-1101-204776/pcbsd-utils-qt4-1381240866.log Buildgroup: 9.1-QAT/i386 Buildstatus: DEPEND (PLIST IN SYSUTILS/PCBSD-UTILS) Log: https://qat.redports.org//~kmo...@freebsd.org/20131008150600-1101-204777/pcbsd-utils-1381240866.log Buildgroup: 8.4-QAT/amd64 Buildstatus: DEPEND (IGNORED: REQUIRES FREEBSD 9.0 OR LATER IN SYSUTILS/PCBSD-UTILS) Buildgroup: 8.4-QAT/i386 Buildstatus: DEPEND (IGNORED: REQUIRES FREEBSD 9.0 OR LATER IN SYSUTILS/PCBSD-UTILS) -- Buildarchive URL: https://qat.redports.org/buildarchive/20131008150600-1101 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r329793: 1x leftovers, 1x plist, 2x ignored: requires freebsd 9.0 or later
- Update to 1381240866 - Fix building without GCC - Build ID: 20131008150400-32134 Job owner: kmo...@freebsd.org Buildtime: 3 hours Enddate: Tue, 08 Oct 2013 18:03:29 GMT Revision: r329793 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=329793 - Port:sysutils/pcbsd-utils 1381240866 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~kmo...@freebsd.org/20131008150400-32134-204772/pcbsd-utils-1381240866.log Buildgroup: 9.1-QAT/i386 Buildstatus: PLIST Log: https://qat.redports.org//~kmo...@freebsd.org/20131008150400-32134-204773/pcbsd-utils-1381240866.log Buildgroup: 8.4-QAT/amd64 Buildstatus: IGNORED: REQUIRES FREEBSD 9.0 OR LATER Buildgroup: 8.4-QAT/i386 Buildstatus: IGNORED: REQUIRES FREEBSD 9.0 OR LATER -- Buildarchive URL: https://qat.redports.org/buildarchive/20131008150400-32134 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[patch] audio/mumble: urgent unbreak
Hello folks, Sorry to ask you a second time for a maintainer timeout but it's critical because audio/mumble is unusable currently because of a CELT detection failure. Two patches were sent over PR, one from me [1] and one from Natacha Porté. [2] Both are working, I think her is a bit better as it won't break if the standalone celt library install the same name. Please commit the one you find the best but as soon as possible because you just *can't* speak / hear anything, which is pretty useless on a VoIP application :-). Regards, [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182215 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/181102 -- Demelier David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r329816: 4x leftovers
Convert to staging. - Build ID: 20131008180600-60449 Job owner: ead...@freebsd.org Buildtime: 9 minutes Enddate: Tue, 08 Oct 2013 18:14:40 GMT Revision: r329816 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=329816 - Port:math/p5-Math-Round 0.06 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131008180600-60449-204868/p5-Math-Round-0.06.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131008180600-60449-204869/p5-Math-Round-0.06.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131008180600-60449-204870/p5-Math-Round-0.06.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~ead...@freebsd.org/20131008180600-60449-204871/p5-Math-Round-0.06.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131008180600-60449 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD mplayer port update?
In message CAFU734xXW2A3k_Db1RAhdpDoUeupx6G1fM-q1tu78Jb6=y2...@mail.gmail.com , you wrote: On 8 October 2013 02:10, Ronald F. Guilmette r...@tristatelogic.com wrote: Could someone (anyone) explain to me why the FreeBSD port of mplayer has not been updated at all since March 8th of this year? Yes. That is because I am preparing roughly 2 major updates per year, preferably shortly after a FreeBSD release. The other changes to the port are to maintain compatibility and fix whatever problems users may have. To pre-empt the inevitable question: Yes, there will be a new version before the end of October. Do you miss a specific feature in the current port or why do you press for an update? The answer to your question is just this: On very rare occasions, I come upon a video that does not seem to play correctly (using mplayer). When this happens, it may be the fault of the video itself, or perhaps of mplayer. If I knew that my mplayer had been updated recently, then I would tend more to suspect the video file of being corrupted. And also, of course, even when videos play correctly I do often wonder whether or not I am getting the full benefits of my hardware. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r329820: 4x leftovers
- Fix build with clang [1] - Convert USE_GMAKE to USES - Drop BINUTILVERSION variable - Add stage support PR: ports/182538 Submitted by: Peter Johnson johnson.pe...@gmail.com (maintainer) [1] Approved by:wg/culot (mentors, implicit) - Build ID: 20131008184000-10272 Job owner: dan...@freebsd.org Buildtime: 10 minutes Enddate: Tue, 08 Oct 2013 18:49:59 GMT Revision: r329820 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=329820 - Port:devel/djgpp-binutils 2.17 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~dan...@freebsd.org/20131008184000-10272-204884/djgpp-binutils-2.17.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~dan...@freebsd.org/20131008184000-10272-204885/djgpp-binutils-2.17.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~dan...@freebsd.org/20131008184000-10272-204886/djgpp-binutils-2.17.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~dan...@freebsd.org/20131008184000-10272-204887/djgpp-binutils-2.17.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131008184000-10272 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [patch] audio/mumble: urgent unbreak
On Tue, Oct 8, 2013, at 13:05, David Demelier wrote: Hello folks, Sorry to ask you a second time for a maintainer timeout but it's critical because audio/mumble is unusable currently because of a CELT detection failure. Two patches were sent over PR, one from me [1] and one from Natacha Porté. [2] Both are working, I think her is a bit better as it won't break if the standalone celt library install the same name. Please commit the one you find the best but as soon as possible because you just *can't* speak / hear anything, which is pretty useless on a VoIP application :-). Natacha's solution is the right way because there may be a conflict with the celt ports in the future. In fact, it used to be done this way as there was a conflict in the past. I'm not sure how/why this broke but I'll take this PR and get this sorted. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re : Re: [patch] audio/mumble: urgent unbreak
Thank you very much! :-) -- David Demelier Mark Felder f...@freebsd.org a écrit : On Tue, Oct 8, 2013, at 13:05, David Demelier wrote: Hello folks, Sorry to ask you a second time for a maintainer timeout but it's critical because audio/mumble is unusable currently because of a CELT detection failure. Two patches were sent over PR, one from me [1] and one from Natacha Porté. [2] Both are working, I think her is a bit better as it won't break if the standalone celt library install the same name. Please commit the one you find the best but as soon as possible because you just *can't* speak / hear anything, which is pretty useless on a VoIP application :-). Natacha's solution is the right way because there may be a conflict with the celt ports in the future. In fact, it used to be done this way as there was a conflict in the past. I'm not sure how/why this broke but I'll take this PR and get this sorted. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
INDEX build failed for 8.x
INDEX build failed with errors: Generating INDEX-8 - please wait../home/indexbuild/tindex/ports/Mk/bsd.port.mk, line 1511: Could not find /home/indexbuild/tindex/ports/Mk/Uses/compiler.mk make: fatal errors encountered -- cannot continue === archivers/rvm failed *** [describe.archivers] Error code 1 *** [/home/indexbuild/tindex/ports/INDEX-8] Error code 1 Stop in /home/indexbuild/tindex/ports. *** [index] Error code 1 Stop in /home/indexbuild/tindex/ports. 1 error Committers on the hook: antoine bapt cs danilo delphij eadler pawel theraven wg Most recent SVN update was: Updating '.': Agames/solarus Agames/solarus/Makefile Agames/solarus/distinfo Agames/solarus/pkg-descr Ugames/Makefile Ubiology/biococoa/pkg-plist Ubiology/biococoa/Makefile Ubiology/biococoa/distinfo Utextproc/libextractor/Makefile Uscience/Makefile Ascience/fisicalab Ascience/fisicalab/pkg-plist Ascience/fisicalab/Makefile Ascience/fisicalab/distinfo Ascience/fisicalab/pkg-descr Uarchivers/pxz/Makefile Uarchivers/rvm/Makefile Uastro/gpstk/Makefile Umultimedia/ffmpeg/Makefile Amultimedia/ffmpeg/files/patch-doc-protocols.texi Umultimedia/Makefile Umultimedia/avbin/Makefile Amultimedia/ffmpeg0 Amultimedia/ffmpeg0/pkg-plist Amultimedia/ffmpeg0/Makefile Amultimedia/ffmpeg0/distinfo Amultimedia/ffmpeg0/pkg-descr Amultimedia/ffmpeg0/files Amultimedia/ffmpeg0/files/patch-libavformat-udp.c Amultimedia/ffmpeg0/files/patch-libavdevice-bktr.c Amultimedia/ffmpeg0/files/patch-libavfilter-Makefile Amultimedia/ffmpeg0/files/patch-libavfilter-vf_libopencv.c Amultimedia/ffmpeg0/files/patch-doc-protocols.texi Amultimedia/ffmpeg0/files/patch-configure Amultimedia/ffmpeg0/files/patch-libavdevice-oss_audio.c Amultimedia/ffmpeg0/files/patch-libavcodec-Makefile Amultimedia/ffmpeg0/files/patch-libavcodec-libgsm.c Amultimedia/ffmpeg0/files/patch-libavutil-common.h Amultimedia/ffmpeg0/files/ffserver0.in Ux11-wm/wmconfig/pkg-plist Ux11-wm/wmconfig/Makefile Ux11-wm/wmconfig/distinfo Udevel/djgpp-binutils/pkg-plist Udevel/djgpp-binutils/Makefile Usecurity/py-gnupg/Makefile Usecurity/py-gnupg/distinfo Udeskutils/gworkspace/Makefile Udeskutils/gworkspace/distinfo Udeskutils/gworkspace/pkg-plist Udeskutils/gworkspace-gwmetadata/Makefile Udeskutils/gworkspace-gwmetadata/distinfo Udeskutils/gworkspace-gwmetadata/pkg-plist UCHANGES UUPDATING Umath/p5-Math-Round/pkg-plist Umath/p5-Math-Round/Makefile Umail/addresses-goodies/Makefile Umail/addresses-goodies/distinfo Umail/claws-mail-vcalendar/Makefile Updated to revision 329836. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD mplayer port update?
On 08/10/2013 18:18, Ronald F. Guilmette wrote: If I knew that my mplayer had been updated recently, then I would tend more to suspect the video file of being corrupted. Have you tried another player? -- Florent Peterschmitt | Please: flor...@peterschmitt.fr| * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) signature.asc Description: OpenPGP digital signature
Re: building seamonkey - possible clang bug
On Oct 8, 2013, at 19:11, Tom Uffner t...@uffner.com wrote: On Tue Oct 8 15:57:07 UTC 2013, Florian Smeets wrote: You were out of swap space, that's why the compiler was killed. real memory = 268435456 (256 MB) avail memory = 248418304 (236 MB) This is not nearly enough, I don't recall what how much a non debug build needs right now, but i think it was close to 2-3GB. You could add more swap, but that's not going to make it any faster :) Thanks. I realize this. in my message I mentioned that the failure mode was running out of memory. and that I added swap. What I failed to include was that (including swap) i had 3/4 G of VM the 1st time, and a bit over 2 G on the 2nd try. Is 2GB still not enough to compile ns_core.c, or is something else wrong? No, this is a clang bug. With your .c file I can reproduce the problem: it looks like clang's optimizer gets into an endless loop, or something similar, and it eats up memory until it dies. Since it turns out recent trunk versions do not exhibit this behavior, I will attempt to figure out exactly where it was fixed. :-) Meanwhile, as a workaround, you can lower the optimization level from -O3 to -O2, that should allow the build to continue. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Undelivered Mail: ho...@freebsd.org
On Tue, 2013-10-08 at 16:05:29 +0200, John Marino wrote: On 10/8/2013 15:21, Carmel wrote: I attempted to contact the maintainer of the deskutils/horde-groupware port, ho...@freebsd.org, but I received the following notification: ho...@freebsdnorth.com: Host or domain name not found. Name service error for name=freebsdnorth.com type=: Host found but no data record of requested type Has anyone else experienced this problem? Is there a change in the maintainers address that is not reflected in the port? Yes, I experienced this months ago. The address horde@ points to has been bogus, it's not a new thing. And yes, something should probably be done. Did you, by chance, report this to postmas...@freebsd.org? We'll look into it. -- Sahil Tandon pgptDpMUNgrfO.pgp Description: PGP signature
Re: PostgreSQL server bus error with uuid-ossp extension
Hello Bill, On Mon, 7 Oct 2013 14:34:28 -0400 Bill Moran wmo...@potentialtech.com wrote: On Mon, 7 Oct 2013 11:20:23 +0800 Christopher Hall christopherhall@gmail.com wrote: Hello Bill, On Fri, 4 Oct 2013 08:34:35 -0400 Bill Moran wmo...@potentialtech.com wrote: On Fri, 4 Oct 2013 15:44:51 +0800 Christopher Hall christopherhall@gmail.com wrote: When running PostgreSQL with the uuid-ossp extension the server fails with signal 10 (bus error). http://pgfoundry.org/projects/uuid-freebsd/ Thanks for the information. I would sooner stay with the existing module so as to be compatible with Linux. Currently I am trying out a patch to misc/uuid-ossp so I can just compile the postgres-contrib unmodified. uuid-freebsd is intended to be compatable. What are you finding incompatable? Although I would be appreciative if you could get that patch working. Sorry for delay, I wanted to try my patch on another machine. I does appear to work on that machine. To preserve the patch I filed it as a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=182846 Rather than attach it to an old PR which was mainly talking about changing libc, but nothing seems to have happen with that one. (It was: PR-121745 from 2008) The reason I did not use the other uuid module was that it simply was not in the postgresql-contrib and would require a new port, and it seemed simpler to fix an existing port rather than introduce new code. -- Bill Moran wmo...@potentialtech.com -- Best regards. Christopher Hall ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
INDEX now builds successfully on 8.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
