Re: 118sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory
On Thu, 12 Mar 2015 05:49:19 -0700 (PDT) Anton Shterenlikht me...@bris.ac.uk wrote From da...@catwhisker.org Thu Mar 12 12:44:43 2015 What does output of kldstat | grep linux look like? Expected: g1-251(11.0-C)[1] kldstat |grep linux 23 0xc17a4000 74c90linux.ko g1-251(11.0-C)[2]=20 But if it's not loaded, I suspect that might be a valid reason for the OID to fail to be recognized # kldstat Id Refs AddressSize Name 19 0x8020 e33630 kernel 21 0x81034000 e10350 nvidia.ko 31 0x81e45000 2ba58bwn_v4_ucode.ko # kldload linux kldload: can't load linux: module already loaded or in kernel # I have in the kernel config file: options COMPAT_43 options COMPAT_LINUX32 options LINPROCFS options LINSYSFS Perhaps I also need to add options COMPAT_LINUX ? By virtue of the fact that kldstat(8) returns nvidia. You can be assured that linux has already been loaded, or rather, that linux is already available. Which suggests to me that it is already part of your kernel. dmesg(8) (/var.run/dmesg.boot) might well reveal that, for you. Perhaps even in /var/log/messages. --Chris 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 ___ 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: 118sysctl: unknown oid 'sysctl compat.linux.osrelease' at line 11: No such file or directory
On Thu, 12 Mar 2015 08:20:27 -0700 (PDT) Anton Shterenlikht me...@bris.ac.uk wrote From bsd-li...@bsdforge.com Thu Mar 12 15:16:15 2015 From da...@catwhisker.org Thu Mar 12 12:44:43 2015 What does output of kldstat | grep linux look like? Expected: g1-251(11.0-C)[1] kldstat |grep linux 23 0xc17a4000 74c90linux.ko g1-251(11.0-C)[2]=20 But if it's not loaded, I suspect that might be a valid reason for the OID to fail to be recognized # kldstat Id Refs AddressSize Name 19 0x8020 e33630 kernel 21 0x81034000 e10350 nvidia.ko 31 0x81e45000 2ba58bwn_v4_ucode.ko # kldload linux kldload: can't load linux: module already loaded or in kernel # I have in the kernel config file: options COMPAT_43 options COMPAT_LINUX32 options LINPROCFS options LINSYSFS Perhaps I also need to add options COMPAT_LINUX ? By virtue of the fact that kldstat(8) returns nvidia. You can be assured that linux has already been loaded, or rather, that linux is already available. Which suggests to me that it is already part of your kernel. dmesg(8) (/var.run/dmesg.boot) might well reveal that, for you. Perhaps even in /var/log/messages. $ grep -i linux /var/run/dmesg.boot $ What does this tell me? [in your case] apparently, nothing. I have chosen not to include linux in my kernels, for convenience reasons. Should I need to update linux, or something goes wrong using the linux ABI. I can simply unload it, and deal with it accordingly. FWIW I know from experience that the nvidia blob will refuse to load, if the linux ABI is not present/available. So it's safe to assume, that in your case , the linux ABI 1) is available 2) must have come from within your kernel I'm sure it's possible to query various aspects of linux available. maybe by/through /proc or /compat/linux/proc and surely by other means. But I have made no effort to do so in the past. So I couldn't be of much help, there. All the best. Thanks Anton --Chris -- ___ 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: pkgng deviates from defaults?
On Mon, 09 Mar 2015 13:23:11 +0100 Carsten Jensen to...@tomse.dk wrote On 03/08/2015 02:41 PM, Baptiste Daroussin wrote: On Sun, Mar 08, 2015 at 01:46:28PM +0100, Carsten Jensen wrote: It seems that pkgng deviates from installing the defaults. one of the culprits seems to be phpMyAdmin, as trying to upgrade this only it wants php56 deleting phpMyAdmin just shows I have other packages needing php56 in my system. is this a bug? and how can I prevent upgrading to the non-default php56? The default settings are a ports tree setting not a pkg setting. for now the ports are hardcoding the required version into the packages, this is a legacy of the old system, noone has yet been working on this. so beside building your own packages with poudriere (which will define the default you want) righ now there is no way to avoid that. The php case but not only php will require small changes in pkg(8) to activate smart dependencies: depend on a1=2.10 and also adding provides/requires (this is not very hard to be added in pkg.) and it should also require heavy changes on the port side! As far as I know noone has been working on those changes in the port side. the pkg(8) changes are mostly pending for real use cases in the port side. Meaning both should be coordinated. Best regards, Bapt Sorry I don't think I was clear. Some applications wants php5 and some applications wants php56 when upgrading using pkg-ng. Using pkg-ng one cannot upgrade i.e. both phpMyAdmin and an other web based application due to this conflict. So while the upgrade happens to upgrade to php56 it also removes the other web application, as it only wants php5. Most of the applications on the server is maintained by pkg-ng, and it conflicts itself. Basically there are now 2 default php versions used by pkg-ng meaning, _I_ am not trying to upgrade to php56, pkg-ng does but it also tries to upgrade php5. I can't find any hardcode to php56 in the Makefile of databases/phpmyadmin I don't know if this is expressed better, I hope so atleast. You might be able to avoid the issue you're having, by using: DEFAULT_VERSIONS+=php=5.5 in your make.conf(5) (/etc/make.conf) file. Check to see if you already have a DEFAULT_VERSIONS line there. If not simply add DEFAULT_VERSIONS+=php=5.5 you your make.conf file. If the line already exists, it is a space separated list. So simply append it to the list thusly DEFAULT_VERSIONS+=mysql=5.5 php=5.5 assuming that the entry mysql=5.5 was already listed. HTH --Chris Cheers Carsten ___ 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
Re: pkgng deviates from defaults?
On Mon, 9 Mar 2015 15:07:39 + Mike Clarke jmc-freeb...@milibyte.co.uk wrote On Mon, 09 Mar 2015 07:04:30 -0700 Chris H bsd-li...@bsdforge.com wrote: You might be able to avoid the issue you're having, by using: DEFAULT_VERSIONS+=php=5.5 in your make.conf(5) (/etc/make.conf) file. As far as I know this won't have any effect on pkg. Bummer. Sorry to hear that. Seems like there *should* be a way in pkg(8) to honor DEFAULT_VERSIONS not that there is a way now. But that there *should* be a way, in the (near?) future. :-) Thanks for the heads up, Mike. --Chris If the OP wishes to use pkg then the only option is to switch to using php5.6. This will involve uninstalling all the php5.5 packages and reinstalling default php5.6 versions. I went through this process recently and described the steps involved in questions@ https://lists.freebsd.org/pipermail/freebsd-questions/2015-March/264525.html -- Mike Clarke ___ 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
Re: Approving a patch
On Wed, 04 Mar 2015 21:23:23 +1100 Kubilay Kocak ko...@freebsd.org wrote On 4/03/2015 9:05 PM, Kubilay Kocak wrote: On 4/03/2015 9:00 PM, Doug Hardie wrote: On 3 March 2015, at 22:45, Kubilay Kocak ko...@freebsd.org wrote: Canonically and preferred: Set maintainer-approval flag to + *on the attachment/patch*. The maintainer-feedback flag is at the issue/bug scope, not the attachment/patch scope. This of course requires the maintainer-approval flag was set to ? with your email as the value first. Currently this is not automatic, but *should be* if there is an attachment of type: patch in the issue. I'll create an issue for that now for bugmeister@ to look into addressing. Only in cases where maintainer-approval is *not* already set to?, is using the maintainer-feedback flag + comment flow OK. Setting maintainer-feedback is ambiguous, and is used to prove 'acknowledgement' of an issue or question. This is especially the case when there are multiple version of patches, or patches from multiple contributors. In future it will be used to derive maintainer timeouts to kick issues along, and open them up for someone else to make a decision on. tldr; Set the maintainer-approval flag to + Thanks to all who replied. I found and set the maintainer-feedback flag at the issue/bug scope. I couldn’t find any similar flag at the attachment/patch scope. Nothing there was really applicable. Which issue? Doug, Ignore that, I found it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198224 I've set the maintainer-approval flag to + for you. Note: this is what I meant in my on-list reply by: This of course requires the maintainer-approval flag was set to ? with your email as the value first. In your issues case, the flag hadn't been set yet. I've created a new issue on this exact point, so as to make setting the maintainer-approval flag automatic. You can follow it here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198271 Along those lines; would it make any sense to convert the current [select] into a [radio]? I must admit, it took me awhile to *conclusively* determine what best applied, and when/where. It all just seemed a bit more difficult to ascertain, than need be. Using a [radio] would allow for a more concise (intuitive?) description. Just a thought. --Chris -- Regards, Kubilay Kocak Bugmeister ___ 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
Re: Poudriere testport failure but manual jailed build success
On Tue, 3 Mar 2015 23:37:30 +0100 Marin Bernard ma...@olivarim.com wrote Hi, I've been banging my head for several days on what follows and I've come to the point where I have to get some help. Here's the point. I'm trying to port LizardFS (a distributed file system for Unix/Linux) on FreeBSD and I built a port candidate I would like to submit. But first I needed to be sure everything was OK, so I ran some tests. As of now: - The port builds fine on FreeBSD 10.1-RELEASE amd64 host. - portlint does not report any issue (on the same host as above) - port test (from porttools) happily validates the port (on the same host as above) - BUT poudriere fails to build the port. I'm using poudriere 3.1.1 on FreeBSD 11-Current, and failure occurs within a FreeBSD 10.1-RELEASE amd64 jail. What basically happens is that the build process runs fine until it reaches man page generation. There, a2x throws an error because xlstproc returns with return code 5 (= error in the stylesheet), whereas it shouldn't. What kills me here is that if I enter the jail after the failure and try to build the port manually, everything builds fine! You'll find poudriere log at the end of this message. Any reason you couldn't simply lower the risk of failure based on tools you have no control over; by simply creating a valid man page to begin with? In other words; if the man is already properly formatted groff/troff/mandoc (take your pick). You wouldn't ever need to worry again. :) Just a thought, and hope it helps. --Chris .. ___ 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
Re: Generating port changes easily
On Sat, 28 Feb 2015 18:34:40 +1100 Kubilay Kocak ko...@freebsd.org wrote On 28/02/2015 3:35 AM, Patrick Powell wrote: I have made some modifications to a port - couple of lines in the Makefile, and an updated pkg-plist. Once upon a time I was shown a script (run_this_script?) to help with updating a port. 1. Copy the original files in the port to XXX.orig (or something) For example cp Makefile Makefile.orig 2. Make your changes For example: vi Makefile 3. Now run this script which will generate a DIFF file which can be posted: run_this_script ... /tmp/changes.shar ? run_this_script ... /tmp/diffs ? 4. Post the generated file to bugzilla with an update request. Ummm... is there such a 'run_this_script' or am I indulging in wishful thinking? If the changes you make are in the ports files, porttools has a 'port diff' command (which uses a reference ports tree to create diffs against. You can use /usr/ports as that reference, and in fact I believe that is the default. You can then just port diff path-to-patch-file.diff, ready for attachment into a new bugzilla issue. If the patch is against WRKSRC source code, you can a) cp WRKSRC/file WRKSRC/file.orig b) edit file c) make makepatch (from the port dir) makepatch recursively searches WRKSRC for *.orig files, and automatically creates correctly named patch-foo patch files in /files for you. Hope that helps koobs' reply got me to thinking. So I did a little searching around in ports/Tools/scripts and found, I think, exactly what you were referring/hoping for; update-patches Give it a look. It's intended to work almost exactly as you described. HTH --Chris -- koobs ___ 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
Re: Generating port changes easily
On Fri, 27 Feb 2015 08:35:19 -0800 Patrick Powell papow...@astart.com wrote I have made some modifications to a port - couple of lines in the Makefile, and an updated pkg-plist. Once upon a time I was shown a script (run_this_script?) to help with updating a port. 1. Copy the original files in the port to XXX.orig (or something) For example cp Makefile Makefile.orig 2. Make your changes For example: vi Makefile 3. Now run this script which will generate a DIFF file which can be posted: run_this_script ... /tmp/changes.shar ? run_this_script ... /tmp/diffs ? 4. Post the generated file to bugzilla with an update request. Ummm... is there such a 'run_this_script' or am I indulging in wishful thinking? svn(1) is your friend; #check out the currently kisted version of your port: $ svn co --depth empty svn://svn.freebsd.org/ports/head 2015-02-27 $ svn up --set-depth empty 2015-02-27/port-category $ svn up 2015-02-27/port-category/your-port-name # make your modifications to your port, then... $ cd 2015-02-27/you-port-name $ svn diff 2015-02-27.diff NOTE: if you add, or delete files in the port, you will also need to issue the appropriate command to svn(1) (delete/add) prior to creating the diff. But the real answers lie within the svn man pages. :) Also have a look at diff(1), and patch (1), diff -u -N newfile.orig newfile patch-pathname-newfile and https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ for even greater depth to these topics. :) HTH --Chris -- Patrick Powell Astart Technologies papow...@astart.com1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting 858-874-6543 FAX 858-751-2435 Web: www.astart.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 ___ 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
Is Gnome3 *officially* supported?
I ask, because I installed x11/gnome3-lite, which also provided gnome-shell. But looking to best utilize it in FreeBSD led me the the FreeBSD Gnome page (https://www.freebsd.org/gnome/) which only speaks of Gnome2. A trip to the FreeBSD wiki only left me with Gnome2 info, as well. Are there any FreeBSD Gnome3 desktop resources? Or is Gnome3 still not *officially* supported, and I'm just a lab rat/guinea pig for Gnome3 on FreeBSD? Thank you for all your time, and consideration. --Chris -- ___ 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: Looking for a commiter
On Tue, 24 Feb 2015 22:07:26 +0100 Matthieu Volat ma...@alkumuna.eu wrote Hi, I asked for a enchancement to print/gutenprint-base to which the maintainer agreed, but now need a good soul with commit bit: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196321 I'd also like that if somebody with an interest in image processing ports would be nice enough to have a look at a graphic/lensfun update I posted more than two month without any reply: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196182 I'm not feeling this is the right way to bump issues, is there any way I don't know of in the bugzilla to draw attention? Maybe this is what you'd like? https://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html#pr-followup HTH. Best wishes. --Chris Thanks in advance -- Matthieu Volat ma...@alkumuna.eu ___ 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: freemat installation
On Fri, 20 Feb 2015 09:55:21 -0400 Pedro Almeidas pedroalmeida...@hotmail.com wrote Hello FreeBSD support. I'm writting you to have any information about FreeMat installation in PCBSD 9.0. In fact, i recently begin to use PCBSD, but i've a lot of problems to understand all. Recently, i downloaded Freemat from http://sourceforge.net/projects/freemat/files/ them i donwnloaded -tar.gz- file extension. But, i don't know how to use this pack, install and run then in pcbsd. I didn't found information in youtube.com, so, i'm writting you to know if you can inform me about steps to install it. Best Regards. The following resources should help you choose a solution that best suits your ultimate goal. :) https://www.freebsd.org/cgi/man.cgi?ports https://www.freebsd.org/cgi/man.cgi?pkg http://www.freshports.org/math/freemat/ and maybe https://www.freebsd.org/cgi/man.cgi?tar ;) Best wishes. --Chris ___ 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
Re: how to make a port of ex-FreeBSD code...
On Tue, 10 Feb 2015 15:31:54 -0800 John-Mark Gurney j...@funkthat.com wrote Chris H wrote this message on Tue, Feb 10, 2015 at 15:08 -0800: On Tue, 10 Feb 2015 14:21:28 -0800 John-Mark Gurney j...@funkthat.com wrote Hello, I'm going to be removing bdes (and possibly enigma) from FreeBSD and making a port of it... What is the best way to do this? Should I fetch this from git/svn? Make a new archive of this? But if I create a new archive, how to distribut it (keeping it in my home dir is not an option, as I don't plan on maintaining it)? Is there an example of other code that was retired to the ports tree? The only example that I can think of was fortune(6); specifically; the naughty fortunes that were censored. Last I heard, someone indicated they had ported it into ports tree. A port was made, but it was nevery committed (or if it was, I sure can't find it), so that isn't a good example.. Ahh. I remember a fairly lively discussion on @stable. Followed by an announcement with a PR listed. So I assumed it was eventually committed. Sorry. --Chris -- John-Mark GurneyVoice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. --Chris -- ___ 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: how to make a port of ex-FreeBSD code...
On Tue, 10 Feb 2015 14:21:28 -0800 John-Mark Gurney j...@funkthat.com wrote Hello, I'm going to be removing bdes (and possibly enigma) from FreeBSD and making a port of it... What is the best way to do this? Should I fetch this from git/svn? Make a new archive of this? But if I create a new archive, how to distribut it (keeping it in my home dir is not an option, as I don't plan on maintaining it)? Is there an example of other code that was retired to the ports tree? The only example that I can think of was fortune(6); specifically; the naughty fortunes that were censored. Last I heard, someone indicated they had ported it into ports tree. HTH --Chris Thanks. -- John-Mark GurneyVoice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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
Re: Is pkg-install the best solution?
On Mon, 09 Feb 2015 07:30:47 +0100 olli hauer oha...@gmx.de wrote
On 2015-02-09 03:05, Chris H wrote:
Greetings,
I'm working with a port that [conditionally] requires
creating/setting a UID GID. Following is my approach
for a pkg-install. But would simply setting them as
USERS=
GROUPS=
in Makefile be a better approach?
pkg-install:
#!/bin/sh
PATH=/bin:/usr/sbin
if [ -z ${WRAP_USER} ]; then
WRAP_USER=myapp
fi
case $2 in
PRE-INSTALL)
UID=181
GID=${UID}
if [ ! -d ${MYAPP_DIR} ]; then
mkdir -p ${MYAPP_DIR}
fi
if pw user show ${WRAP_USER} 2/dev/null; then
echo You already have a user \${WRAP_USER}\, so I will use it.
if pw usermod ${WRAP_USER} -d ${MYAPP_DIR}
then
echo Changed home directory of \${WRAP_USER}\ to
\${MYAPP_DIR}\ else
${MYAPP_DIR}\ failed...
snip ...
Hi Chris,
go with USERS,GROUPS in Makefile and if the user/group does not already exist
in ports/UIDs, ports/GIDs request one together with the new port.
Using pkg-install to create users/groups is deprecated.
Perfect. Good to know.
Thank you, olli!
Greatly appreciated. :)
--Chris
--
Regards,
olli
___
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
Is pkg-install the best solution?
Greetings,
I'm working with a port that [conditionally] requires
creating/setting a UID GID. Following is my approach
for a pkg-install. But would simply setting them as
USERS=
GROUPS=
in Makefile be a better approach?
pkg-install:
#!/bin/sh
PATH=/bin:/usr/sbin
if [ -z ${WRAP_USER} ]; then
WRAP_USER=myapp
fi
case $2 in
PRE-INSTALL)
UID=181
GID=${UID}
if [ ! -d ${MYAPP_DIR} ]; then
mkdir -p ${MYAPP_DIR}
fi
if pw user show ${WRAP_USER} 2/dev/null; then
echo You already have a user \${WRAP_USER}\, so I will use
it.
if pw usermod ${WRAP_USER} -d ${MYAPP_DIR}
then
echo Changed home directory of \${WRAP_USER}\ to
\${MYAPP_DIR}\
else
${MYAPP_DIR}\ failed...
exit 1
fi
else
if pw useradd ${WRAP_USER} -u ${UID} \
-d ${MYAPP_DIR} -s /sbin/nologin -c MyApp Daemon
then
echo Added user \${WRAP_USER}\.
else
echo Adding user \${WRAP_USER}\ failed...
exit 1
fi
fi
;;
esac
--Chris
--
___
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: testing the value of ${CXX} in ports Makefile
On Thu, 29 Jan 2015 22:46:32 -0800 (PST) Don Lewis truck...@freebsd.org wrote
On 29 Jan, Chris H wrote:
On Thu, 29 Jan 2015 19:43:38 -0800 (PST) Don Lewis truck...@freebsd.org
wrote
I need to test the value of ${CXX} in the Makefile for a port and am
getting unexpected results. Here is a simplified version of the
Makefile:
PORTNAME=junk
PORTVERSION=0.0.0
CATEGORIES=devel
DISTFILES=
MAINTAINER=truck...@freebsd.org
COMMENT=junk
USE_GCC=4.9+
.include bsd.port.pre.mk
post-patch:
echo CXX=${CXX}
.if ${CXX} == g++49
echo detected g++49
.else
echo did not detect g++49
.endif
.include bsd.port.post.mk
If I run make patch, this is what I get:
# make patch
=== junk-0.0.0 depends on file: /usr/local/sbin/pkg - found
=== Fetching all distfiles required by junk-0.0.0 for building
=== Extracting for junk-0.0.0
=== Patching for junk-0.0.0
echo CXX=g++49
CXX=g++49
echo did not detect g++49
did not detect g++49
If I run make -dA patch and look at the debug output, I observe
bsd.gcc.mk getting processed after the .if is evaluated. When the .if
is processed, the value of ${CXX} is still c++. It sort of looks like
bsd.gcc.mk isn't getting included until bsd.port.post.mk and we are
relying on lazy expansion to get the correct value of ${CXX} for the
actions.
It sort of looks like I'll have to do something like:
post-patch:
[ ${CXX} = g++49 ] echo detected g++49
but that just seems goofy.
I'm not attempting to come off as any sot of expert. But it
seems like you're going the long way around. Couldn't you
just as easily REQUIRE, or perhaps even better; simply reverse
the logic;
if ${CXX} != g++49
@VOMIT
endif
It'd be shorter, and still assures the results you require,
no? Just a thought.
gcc46, gcc47, gcc48, and probably gcc5 (haven't tested that one yet) all
work. gcc49 requires a source patch. I just want to be able to set
USE_GCC=yes and not have the port break when the default version of gcc
gets changed to 4.9.
The way that the ports infrastructure is written, it looks like I can't
do the test with a Makefile .if / .endif. It looks like I have to do it
in the shell code in actions for the target.
Instead of using [ condition ] do something, I could also write it as
if [ ${CXX} = g++49 ]; then apply the patch; fi
Ahh. Sure. It's also shorter than the only alternative I can conceive
if ${CXX} = g++48 || if ${CXX} = g++50
@${PATCHME}
endif
--Chris
--
___
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: testing the value of ${CXX} in ports Makefile
On Fri, 30 Jan 2015 06:30:10 -0800 Chris H bsd-li...@bsdforge.com wrote
On Thu, 29 Jan 2015 22:46:32 -0800 (PST) Don Lewis truck...@freebsd.org
wrote
On 29 Jan, Chris H wrote:
On Thu, 29 Jan 2015 19:43:38 -0800 (PST) Don Lewis truck...@freebsd.org
wrote
I need to test the value of ${CXX} in the Makefile for a port and am
getting unexpected results. Here is a simplified version of the
Makefile:
PORTNAME=junk
PORTVERSION=0.0.0
CATEGORIES=devel
DISTFILES=
MAINTAINER=truck...@freebsd.org
COMMENT=junk
USE_GCC=4.9+
.include bsd.port.pre.mk
post-patch:
echo CXX=${CXX}
.if ${CXX} == g++49
echo detected g++49
.else
echo did not detect g++49
.endif
.include bsd.port.post.mk
If I run make patch, this is what I get:
# make patch
=== junk-0.0.0 depends on file: /usr/local/sbin/pkg - found
=== Fetching all distfiles required by junk-0.0.0 for building
=== Extracting for junk-0.0.0
=== Patching for junk-0.0.0
echo CXX=g++49
CXX=g++49
echo did not detect g++49
did not detect g++49
If I run make -dA patch and look at the debug output, I observe
bsd.gcc.mk getting processed after the .if is evaluated. When the .if
is processed, the value of ${CXX} is still c++. It sort of looks like
bsd.gcc.mk isn't getting included until bsd.port.post.mk and we are
relying on lazy expansion to get the correct value of ${CXX} for the
actions.
It sort of looks like I'll have to do something like:
post-patch:
[ ${CXX} = g++49 ] echo detected g++49
but that just seems goofy.
I'm not attempting to come off as any sot of expert. But it
seems like you're going the long way around. Couldn't you
just as easily REQUIRE, or perhaps even better; simply reverse
the logic;
if ${CXX} != g++49
@VOMIT
endif
It'd be shorter, and still assures the results you require,
no? Just a thought.
gcc46, gcc47, gcc48, and probably gcc5 (haven't tested that one yet) all
work. gcc49 requires a source patch. I just want to be able to set
USE_GCC=yes and not have the port break when the default version of gcc
gets changed to 4.9.
The way that the ports infrastructure is written, it looks like I can't
do the test with a Makefile .if / .endif. It looks like I have to do it
in the shell code in actions for the target.
Instead of using [ condition ] do something, I could also write it as
if [ ${CXX} = g++49 ]; then apply the patch; fi
Ahh. Sure. It's also shorter than the only alternative I can conceive
if ${CXX} = g++48 || if ${CXX} = g++50
Ahem... That *should* have read
if ${CXX} = g++48 || ${CXX} = g++50
Sorry for the noise. In the future, I'll try to refrain from
sending email until *after* my first cup of coffee. :(
@${PATCHME}
endif
--Chris
--
___
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
Re: testing the value of ${CXX} in ports Makefile
On Thu, 29 Jan 2015 19:43:38 -0800 (PST) Don Lewis truck...@freebsd.org wrote
I need to test the value of ${CXX} in the Makefile for a port and am
getting unexpected results. Here is a simplified version of the
Makefile:
PORTNAME=junk
PORTVERSION=0.0.0
CATEGORIES=devel
DISTFILES=
MAINTAINER=truck...@freebsd.org
COMMENT=junk
USE_GCC=4.9+
.include bsd.port.pre.mk
post-patch:
echo CXX=${CXX}
.if ${CXX} == g++49
echo detected g++49
.else
echo did not detect g++49
.endif
.include bsd.port.post.mk
If I run make patch, this is what I get:
# make patch
=== junk-0.0.0 depends on file: /usr/local/sbin/pkg - found
=== Fetching all distfiles required by junk-0.0.0 for building
=== Extracting for junk-0.0.0
=== Patching for junk-0.0.0
echo CXX=g++49
CXX=g++49
echo did not detect g++49
did not detect g++49
If I run make -dA patch and look at the debug output, I observe
bsd.gcc.mk getting processed after the .if is evaluated. When the .if
is processed, the value of ${CXX} is still c++. It sort of looks like
bsd.gcc.mk isn't getting included until bsd.port.post.mk and we are
relying on lazy expansion to get the correct value of ${CXX} for the
actions.
It sort of looks like I'll have to do something like:
post-patch:
[ ${CXX} = g++49 ] echo detected g++49
but that just seems goofy.
I'm not attempting to come off as any sot of expert. But it
seems like you're going the long way around. Couldn't you
just as easily REQUIRE, or perhaps even better; simply reverse
the logic;
if ${CXX} != g++49
@VOMIT
endif
It'd be shorter, and still assures the results you require,
no? Just a thought.
--Chris
___
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
Re: powerdns meta packages?
On Wed, 28 Jan 2015 11:17:20 + Joe Holden li...@rewt.org.uk wrote
On 12/01/2015 16:53, Chris H wrote:
On Mon, 12 Jan 2015 16:42:45 + Joe Holden li...@rewt.org.uk wrote
On 12/01/2015 16:05, Chris H wrote:
On Mon, 12 Jan 2015 15:10:12 + Joe Holden li...@rewt.org.uk wrote
Hi guys,
What is the process for adding/submitting meta packages for ports for
example powerdns that have multiple backend options and the default
isn't suitable, or failing that have the ability to install powerdns
with default backend but allow the installation of others?
Currently the port defaults to postgres, in this case I'd like sqlite
backend for some servers (slaves), at the moment I'm just building that
manually but it does mean I can't just do 'pkg upgrade'
As I understand it, you want to create a custom meta-port.
You might do well to have a look at some of the other meta-ports
available, for the best way to accomplish it for your needs;
x11/xorg
x11/xorg-minimal
x11/xorg-apps
lang/php5-extensions
are some that come to mind.
Best wishes.
This is what I'd normally do but I was hoping with the new pkg stuff we
could have some sort of virtual packages but this will do I guess!
Will need to read up on package building now - seems a bit silly to have
my own repo just for -mysql, -sqlite type packages though
Well, I thought you might want to make the (meta)port, and submit it.
Then other like-minded people could also benefit from your
contribution. :) If you submit it as a port, the pkg(8) business takes
care of itself.
So, I made an attempt on my poudriere box, package builds -
powerdns-backend-sqlite3, just includes the .so and the schema in plist
however pkg says it conflicts. My interpretation from the handbook is
that the % option stuff in plist is only used if that option is
selected, so I can't see why powerdns (without any backends) and my
slave port would conflict... I used mysql server/client ports as a base:
Makefile :-
PORTNAME= powerdns
PKGNAMESUFFIX= -backend-sqlite3
COMMENT=PowerDNS sqlite3 backend
MASTERDIR= ${.CURDIR}/../powerdns
PKGMESSAGE= mustnotexist
PLIST= ${.CURDIR}/pkg-plist
OPTIONS_SET= SQLITE3
.include ${MASTERDIR}/Makefile
pkg-plist :-
%%LUA_LIBDIR%%/pdns/%%LUA_LIBDIR%%gsqlite3backend.so
%%PORTDOCSDOCSDIR%%/dnssec-3.x_to_3.4.0_schema.sqlite3.sql
%%PORTDOCSDOCSDIR%%/nodnssec-3.x_to_3.4.0_schema.sqlite3.sql
%%PORTDOCSDOCSDIR%%/schema.sqlite3.sql
#
I also made powerdns port not have PGSQL set by default.
Is there something obvious I'm doing wrong?
Off the top of my pointy head; I'm going to guess it's wanting
to install PowerBSD, but it's already installed?
Because you haven't already said so; the following may help
shed some light:
in /etc/make.conf:
DEVELOPER=yes
When testing your port
make -DBATCH check-plist
portlint(1) is your friend - ports-mgmt/portlint
HTH
Cheers
All the best.
--Chris
Cheers
--Chris
Cheers,
J
--Chris
--
___
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: xrdesktop ported to Gtk2
On Tue, 27 Jan 2015 11:09:21 +0100 Peter pe...@flytrace.com wrote Hello, I've ported xrdesktop to Gtk2 and fixed some small bugs. The software was tested during some months in everyday use, there is no problem. You can push it to ports tree with the same name or as xrdesktop2 (to save the old one). Best regards, Peter TKATCHENKO I'll take it. Thanks for all your work, Peter. --Chris ___ 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] Upcoming change in dependency registration
On Thu, 22 Jan 2015 16:49:47 -0600 Bryan Drewery bdrew...@freebsd.org wrote On 1/22/2015 2:24 PM, Chris H wrote: On Thu, 22 Jan 2015 19:09:13 +0100 Baptiste Daroussin b...@freebsd.org wrote Hi all Some changes are coming to the ports, the diff is rather simple, but the change of behaviour is worse notifying all maintainers: Currently and since very long the dependency registration in the ports tree is based on the origin of the packages. which makes it unfriendly with FLAVORS and Subpackages. The ports tree has been changed in the branch https://svnweb.freebsd.org/ports/projects/rework-dependency-registration/ .. This change is being exp-run and will be committed as soon as it is stable enough Best regards, Bapt Hi Bapt. Will this be OR'ed? In other words; will this create compatibility issues for anyone using ports without this change? While I develop on 11-CURRENT. I wonder about developers that aren't, or haven't yet incorporated this new change? (granted, developers *should* always be running *fairly* current revision(s)). I guess I'm just wondering if ports, and those still using them, that don't *yet* incorporate this change, will still continue to work as intended/expected (at least for awhile). I'm still reading the proposed changes. :) Thanks. --Chris For the most part, ports written after this change can be used without this change. The py-27 py-33 multiple installations stuff maybe not. This required action here is to fix dependencies depending on *generated files* rather than *plist files*. This is a proper fix even without this change. So the ports will still work without this change. The bigger picture changes, such as sub-packages, flavors and flexible dependencies, are not here yet. Those changes will most definitely not be forward-compat once they go in. Ports written after those won't work with older framework. We're not quite there yet though. Looking forward to this! :) And in general, the ports tree is a single snapshot. It's only supported to build a port using the exact Mk/ it was checked-in as. At my work we violate this frequently though. It's on us/you to deal with this if you choose to go off book. Understood. Thanks for clearing things up, Bryan! -- Regards, Bryan Drewery --Chris -- ___ 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] Upcoming change in dependency registration
On Thu, 22 Jan 2015 16:51:11 -0600 Bryan Drewery bdrew...@freebsd.org wrote On 1/22/2015 4:49 PM, Bryan Drewery wrote: And in general, the ports tree is a single snapshot. It's only supported to build a port using the exact Mk/ it was checked-in as. For the record, I don't like this at all. It's one of my biggest gripes about the ports framework. +1 That's a separate discussion though. I'll be looking forward to that discussion. :) -- Regards, Bryan Drewery --Chris -- ___ 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] Upcoming change in dependency registration
On Thu, 22 Jan 2015 19:09:13 +0100 Baptiste Daroussin b...@freebsd.org wrote Hi all Some changes are coming to the ports, the diff is rather simple, but the change of behaviour is worse notifying all maintainers: Currently and since very long the dependency registration in the ports tree is based on the origin of the packages. which makes it unfriendly with FLAVORS and Subpackages. The ports tree has been changed in the branch https://svnweb.freebsd.org/ports/projects/rework-dependency-registration/ so now it basically do the same kind of mechanism which is done during the .. Last side effect it also prepare the way to be able to depend on provides and depend correctly on smart dep aka perl5=5.18.2_35.20 This change is being exp-run and will be committed as soon as it is stable enough Best regards, Bapt Hi Bapt. Will this be OR'ed? In other words; will this create compatibility issues for anyone using ports without this change? While I develop on 11-CURRENT. I wonder about developers that aren't, or haven't yet incorporated this new change? (granted, developers *should* always be running *fairly* current revision(s)). I guess I'm just wondering if ports, and those still using them, that don't *yet* incorporate this change, will still continue to work as intended/expected (at least for awhile). I'm still reading the proposed changes. :) Thanks. --Chris ___ 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: www/dansguardian revival?
On Thu, 15 Jan 2015 08:42:21 -0800 Nick Rogers ncrog...@gmail.com wrote
On Sun, Nov 2, 2014 at 1:00 PM, Chris H bsd-li...@bsdforge.com wrote:
On Fri, 31 Oct 2014 16:55:47 -0700 Nick Rogers ncrog...@gmail.com wrote
On Tue, Oct 21, 2014 at 6:29 PM, Chris H bsd-li...@bsdforge.com wrote:
On Tue, 21 Oct 2014 09:39:30 +0200 Marko Cupać marko.cu...@mimar.rs
wrote
On Mon, 20 Oct 2014 17:47:19 -0700
Chris H bsd-li...@bsdforge.com wrote:
Unless theirs any objection. I'll take it. I'll open a pr(1)
with a shar(1) ready, in about an hour.
--Chris
Nice to hear that dansguardian will be back in ports. I also used it
for years in combination with www/squid33 without problem. I was
compiling it from ports, and the trick was to compile squid33 first,
and dansguardian only after, as dansguardian would only check
existence
of /use/local/bin/squid, and if it was already there, no matter which
version, it would happily compile, install and work.
Right. But there's ${STAGE} to deal with, as well. I may
make sqid34 the DEPENDS (I'm still testing).
I'm also working with the -devel version, and will likely
convert it to the (un)devel version, as there is less user
overhead involved -- RESTRICTED/COPYRIGHT/LICENSE/{...}
Should be able to post a complete version, sometime
tomorrow.
Hey Chris. Any luck getting your new dansguardian port to work? I can't
find a PR for it. Just wondering if theres anything I can do to help test
or if it would be worth my while to just submit a PR with the last-known
www/dansguardian for the time being. Thanks.
-Nick
Sorry for the delay, and thank you for your generous offer, Nick.
There were some issues with www/squid(34), and decided to wait
to see if they would be addressed soonish. I see that there was
a [partial] resolution just submitted. I'll see if they made it
into the ports tree. If so, I'll see where things are with
regard to their (e|a)ffect on www/dansguardian. If there's still
issues, I'll take you up on your generous offer. :)
Any luck with the squid issues and getting a new www/dansguardian going?
I'm still having success with www/squid and the old www/dansguardian,
albeit www/squid version needs to be bumped to the latest.
Sorry for the delay, Nick.
There's been a great deal of activity in the squid* department over
the past couple months. I wanted to wait for the dust to settle
before continuing; lest I be required to re-release every couple
weeks to work with any new changes. On the up-side, things seem
to have settled down. So I'll suck down a copy of HEAD, and renew
my efforts to get this back in, over the next couple days.
Again, sorry for the delay. Hope you understand. :)
--Chris
FWIW I run my dev box on 11 (CURRENT).
Thanks, again.
--Chris
--Chris
--
Marko Cupać
https://www.mimar.rs
___
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
___
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
___
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
--Chris
---
___
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: sysutils/bbcp: Anyone interesting in helping upgrade this port?
On Thu, 15 Jan 2015 09:27:29 +0100 Kurt Jaeger li...@opsec.eu wrote Hi! So I won't be submitting the pr(1) until tomorrow. OK killed all the errors, rolled up a release, and submitted an svn diff. Please see the pr(1): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196746 Testing @work. The build still emits a fair amount of warnings. but none are show stoppers. Indeed, very noisy 8-} Linux-isms in/from errno.h quoting issues in newer GCC's, but mostly CLANG. I'll eliminate all the warnings, for the next version. Will you report those upstream ? As previously mentioned; upstream's code is fairly unmaintained (messy). In fact, I removed over 3,000 extraneous new-lines from one source file alone. Committing to maintain a port necessitated performing a mass code cleanup. If they (upstream) will accept a git push. Then we can still draw from upstream. Otherwise, I'll be forced to either 1) cherry-pick from upstream 2) fork/branch rename the port/project After I squash the remaining warnings emitted, I submit a push request, and see where it goes. But it will involve every file in their source pool. So they may be reluctant. We'll see. :) Thanks for the prompt commit, and attention to this, Kurt! -- p...@opsec.eu+49 171 3101372 5 years to go --Chris --- ___ 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: sysutils/bbcp: Anyone interesting in helping upgrade this port?
On Thu, 15 Jan 2015 09:56:31 +0100 Kurt Jaeger li...@opsec.eu wrote Hi! So I won't be submitting the pr(1) until tomorrow. OK killed all the errors, rolled up a release, and submitted an svn diff. Please see the pr(1): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196746 Testing @work. Poudriere build on 10.1-amd64, 9.3-amd64, 8.4-i386 went fine. Commited, thanks very much for a smooth patch 8-) Wouldn't have it any other way. :-) Thank *you*, Kurt, for all your time, and attention to this! -- p...@opsec.eu+49 171 3101372 5 years to go --Chris --- ___ 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: sysutils/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 22:50:09 -0800 Chris H bsd-li...@bsdforge.com wrote On Tue, 13 Jan 2015 18:34:45 -0800 Chris H bsd-li...@bsdforge.com wrote On Tue, 13 Jan 2015 13:54:56 -0700 John Hein john.h...@microsemi.com wrote Kurt Jaeger wrote at 20:29 +0100 on Jan 13, 2015: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I don't think he will (as can be seen from PR 192405). Provide a PR with the patch and I'll commit it after testing the build. I'll update it if no one else gets to it this week or review a PR. Thanks for the offer, and reply, John. So far I've squashed ~20 errors. I'm now at the IPv6 specific ones. Willing to hand it over if someone wants it. Thanks, John. I might just take you up on that. :) Thanks again, John. OK. All the errors have been chased, and crushed. But it's now late. So I won't be submitting the pr(1) until tomorrow. OK killed all the errors, rolled up a release, and submitted an svn diff. Please see the pr(1): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196746 The build still emits a fair amount of warnings. but none are show stoppers. The source wants an earlier GCC, and really isn't well suited for clang. This was all built, tested on 11-CURRENT. I'll eliminate all the warnings, for the next version. All the best. --Chris ___ 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 ___ 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
Re: BIND REPLACE_BASE option
On Wed, 14 Jan 2015 08:11:39 -0800 (PST) Roger Marquis marq...@roble.com wrote Maybe you're right but, to perhaps better illustrate the point, you would never see something like this in Ubuntu, Debian, Redhat, or SuSE. Honestly. Need I remind you, this is FreeBSD, *not* Linux? In all honesty, I am *not* pleased with the current efforts to turn the FreeBSD motto The Power to Serve into FreeBSD, it's the new Linux. But I [begrudgingly] understand the inclination to do so. Amen to that. I also think a lot of people expect that emulating Linux' binary package systems will stop our favorite OS' declining market share. Unfortunately, there's a lot more to it. FreeBSD has had binary packages for years and they haven't had the desired effect. What's missing is perhaps an understanding of what Linux differences account for its success over FreeBSD. Clearly the topic of this thread, deprecating REPLACE_BASE, isn't going to help in this regards. Portsng and pkgng aren't helping yet either though their improvements have laid the foundation for easier coding of new features (like better dependency tracking, a non-cli menu, ad-hoc queries, ...). That said. While I understand your inclination to think FreeBSD must somehow be broken, when it doesn't operate as you're accustomed with Linux. Not my inclination :-) Please take care with those attributes. Fair enough. My entire reply was *intended* to be light hearted. But like you, I *too* have some issues with some of the decisions made. I'm afraid I let that influence my reply. Sorry. This is FreeBSD, after all, and as hard as everyone works to eliminate the element of surprise, this is still FreeBSD. So celebrate the difference. Don't curse it, or more importantly; it's hard working developers. :) I trust we are _all_ grateful to the developers who are doing a good job, at least when not deprecating popular features and responding to the resulting end-user frustration with statements like REPLACE_BASE was an abomination that should never have existed, now that it's gone, it'll never get back, and you'll never see it again. The hard work that goes into so many ports _is_ BSD's primary advantage over Linux backed-up by ZFS, jails, security and the BSD license. Personally I believe that a lot of this differential is due to the GPL which doesn't allow Linux deltas to propagate back to BSD but nobody seems to be discussing way of addressing this (like a CDDL BSD perhaps). IMHO it's still too early to tell whether all the big changes made during 2014 will, or have had, the positive, or desired affect intended. But for sure, it's been a *wild* ride for many of us. But getting back to the meta-topic i.e., where BSDs are at a disadvantage, has anyone here used kickstart, satellite, sssd, IPA, gparted, synaptic, a live desktop DVD or the Ubuntu GUI installer? Thanks for your *thoughtful* reply, Roger. --Chris Roger Marquis ___ 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
Re: BIND REPLACE_BASE option
On Wed, 14 Jan 2015 04:27:42 -0800 Jeffrey Bouquet via freebsd-ports freebsd-ports@freebsd.org wrote On 01/13/15 07:55, Kurt Jaeger wrote: Hi! customizations you need available. If the default options don't cut it for you, in order to use only binary packages that means you need to run your own poudriere setup -- which is well worth it if you're managing several machines / jails etc. poudriere allows you to manage several seperate pkg trees with different options, so you can: - build a default tree (and pkg repo), provide it to all generic hosts - build a seperate tree (and pkg repo) with modified options, and provide it to the special hosts It helps to keep the poudriere build tree on fast flash/SSD drives 8-} This all works and is very, very good! Thanks for the work! As I probably won't ever know enough from experience, if one wants a local lan build tool is there any flowchart with use cases 1... foo foo bar use case tinderbox 2... foo foo bar use case build jail 3... foo foo bar use case bhyve 4... foo foo bar use case poudriere 5... foo foo bar use case csbd OR qjail OR ezjail OR man jail OR bastille script 6... foo foo bar use case server on lan serving packages And where they may overlap, which takes the least setup time, which takes the least maintenance time, which can be most easily migrated version version ... Excellent observation. These look like prime install candidates. A sort of meta-install, much like a Server, or Desktop install is already. Maybe someone with good install-foo could easily cobble up appropriate scripts to accommodate such a thing. Thanks for bringing it up, Jeffrey! --Chris Not to mention the wiki, but if that information was [some term ] use cases like virtualization or multi-machine or... on the freebsd.org page prominently, it may result in a larger userbase... more coders onboard. Recognizing that a lot of this is emerging technology. Apologies. I've a slight interest in reading any such document, having read an hour or so yesterday not a few htm explaining jails, (10 pages of threads linked from a search 'ezjail' in the forums, for example) to know that acquiring the expertise of a quickstart group of terms to focus on in any particular scenario is something I don't easily expect to acquire. On the other hand, to include the wiki... vs links from it. ___ 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
Re: BIND REPLACE_BASE option
On Wed, 14 Jan 2015 16:18:07 + Matthew Seaman matt...@freebsd.org wrote On 2015/01/14 15:34, Roger Marquis wrote: So one difference then would be that Poudriere determines which dependencies are run-time vs build-time and creates packages for those by default, is that correct? I can see how that might be convenient for packages with a large number of dependencies (like sssd) but it also seems like a lot of additional infrastructure simply to build binaries on one host to be used by many. Poudriere by definition will create packages for all of the build- and run-depends, as it needs the build-depends packages itself in order to build everything. It builds everything in temporary jails which it installs all the needed dependencies to, and then destroys after that package has been built. However, when you go to install a package from the repo, pkg(8) will only pull down the run-time dependencies of whatever you choose to install. That means there are a good chunk of packages you simply don't need to have on your production servers any more. Yes, poudriere does a lot of stuff, but if you didn't use a central builder, you'ld end up replicating all of that stuff onto every machine you wanted to manage. Poudriere itself can run on a fairly modest machine -- it depends on how many packages you need to build and how quickly you want them. It's quite feasible to use poudriere for a small-ish repo on a machine at night, when it is otherwise quiet, and then use the same machine for something else during the day. This might be a good place to put some links to how-to's for common use-cases for poudriere. I see questions like this quite often on the lists, and in the forums. Anyone have one? --Chris Cheers, Matthew ___ 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
Re: BIND REPLACE_BASE option
On Tue, 13 Jan 2015 19:11:50 -0800 (PST) Roger Marquis marq...@roble.com wrote The dialog option you talk about says: [ ] REPLACE_BASEEOL, no longer supported I'm quite sure the end-user you're talking about can get a clue from it, and if he either already had selected it before, or he just selected it, he will get: === bind99-9.9.6P1_3 REPLACE_BASE is no longer supported. The end-user can then get another clue and maybe unselect it. Maybe you're right but, to perhaps better illustrate the point, you would never see something like this in Ubuntu, Debian, Redhat, or SuSE. Honestly. Need I remind you, this is FreeBSD, *not* Linux? In all honesty, I am *not* pleased with the current efforts to turn the FreeBSD motto The Power to Serve into FreeBSD, it's the new Linux. But I [begrudgingly] understand the inclination to do so. That said. While I understand your inclination to think FreeBSD must somehow be broken, when it doesn't operate as you're accustomed with Linux. This is FreeBSD, after all, and as hard as everyone works to eliminate the element of surprise, this is still FreeBSD. So celebrate the difference. Don't curse it, or more importantly; it's hard working developers. :) --Chris Roger ___ 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
Re: sysutils/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 10:08:05 -0800 Freddie Cash fjwc...@gmail.com wrote Good morning, With the requirement for the NONE cipher in OpenSSH requiring a custom compile of the world or a custom compile of the openssh-portable port (all my production servers are binary-package-only now), I've started using bbcp instead of zfs send over SSH. And looking at using bbcp instead of rsync over SSH for another system (transfer speed is more important than encrypting the data as the transfer is done over a very local LAN link). The bbcp port is version 20120520; the latest version available is 20140902. There have been several new features added over the past 2 years that make it (at least on paper) a decent rsync replacement for our uses. Is there anyone interested in bringing this port up-to-date. I had a quick look, but it requires some C hacking that's beyond my skills. :( I've only tried compiling it with clang, which gives lots of errors. Haven't tried with gcc, though. I just had a look. Looks interesting. I can't foresee any issue moving it ahead. But before I step up, and say I'll take it. Have you contacted the maintainer? I don't want to step on any toes. :) --Chris I have 3 FreeBSD 9.3 systems that transfer data to a 4th FreeBSD 9.3 system using zfs send over bbcp that can be used for testing things. As well as a Debian 7.0 box that can be tested for pulling data off a FreeBSD system. I'd prefer to not install the ports tree on any of the production systems, but I could spin up a KVM-based VM if needed. -- Freddie Cash fjwc...@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 ___ 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: sysutils/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 18:34:45 -0800 Chris H bsd-li...@bsdforge.com wrote On Tue, 13 Jan 2015 13:54:56 -0700 John Hein john.h...@microsemi.com wrote Kurt Jaeger wrote at 20:29 +0100 on Jan 13, 2015: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I don't think he will (as can be seen from PR 192405). Provide a PR with the patch and I'll commit it after testing the build. I'll update it if no one else gets to it this week or review a PR. Thanks for the offer, and reply, John. So far I've squashed ~20 errors. I'm now at the IPv6 specific ones. Willing to hand it over if someone wants it. Thanks, John. I might just take you up on that. :) Thanks again, John. OK. All the errors have been chased, and crushed. But it's now late. So I won't be submitting the pr(1) until tomorrow. --Chris --Chris ___ 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 ___ 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: sysutils/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 20:23:09 +0100 Mark Martinec mark.martinec+free...@ijs.si wrote Chris H wrote: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I had an open request to upgrade sysutils/bbcp since August 2014, apparently the maintainer is absent or not interested. [Bug 192405] Please upgrade sysutils/bbcp, current version does not support IPv6 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192405 Ouch! Since *August*? Looks like the maintainer's otherwise occupied. I'm on it. I'll submit a new pr(1) when I'm done, and append a note to your previous one, as well. --Chris It would be very nice to bring it up-to-date. Mark ___ 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
Re: sysutils/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 13:54:56 -0700 John Hein john.h...@microsemi.com wrote Kurt Jaeger wrote at 20:29 +0100 on Jan 13, 2015: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I don't think he will (as can be seen from PR 192405). Provide a PR with the patch and I'll commit it after testing the build. I'll update it if no one else gets to it this week or review a PR. Thanks for the offer, and reply, John. So far I've squashed ~20 errors. I'm now at the IPv6 specific ones. Willing to hand it over if someone wants it. Thanks, John. I might just take you up on that. :) Thanks again, John. --Chris ___ 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
Re: getpatch scripit rewroted in plain shell
On Tue, 13 Jan 2015 13:49:31 + Rodrigo Osorio rodr...@bebik.net wrote Hi ports :) For a long time, I was missing some features in the exising getpatch script ( svn repo Tools/scripts/getpatch) and since I'm not a py fan boy, I rewrote the tool in plain shell. This is its storry The new features are : - use the bug id as a directory to store the attachements inside (can be turned off) - decide if you want or not obsolete patches (by default is no) - an env variable to define where attachements are stored (by default ./) - be verbose - only uses tools from base example : rodrigo@scotty % printenv GETPATCH_DIR /home/rodrigo/patches/ rodrigo@scotty % getpatch 191840 Bug ID: 191840 + att-144615: pidgin-gnome-keyring.tar.gz is obsolete, skip + att-144641: pidgin-gnome-keyring.tar.gz download success + att-144642: pidgin-gnome-keyring-1.20_1.txz download success Patches stored in /usr/home/rodrigo/patches/191840 The code is here : http://files.bebik.net/code/getpatch Suggestions and comments are wellcomed Looks good. Your native language appears to be français. :) I would only offer grammatical changes: s/a dedicate/the dedicated/g s/dedicate/dedicated/g # I try to avoid contractions because some shells trip on the apostrophe. s/Can\'t/Unable to/g s/catched/caught/g Bon travail! --Chris Regards, - rodrigo PS: There are room for improvements, I know. Bugzilla request can be reduced to a single one but this leads to xml and b64 management in shell, and it sounds a little bit insane to me... ___ 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
Re: BIND REPLACE_BASE option
On Tue, 13 Jan 2015 16:12:32 +0100 Mathieu Arnold m...@freebsd.org wrote I'm only going to answer that part, the rest of the thread being, I feel, mostly FUD. Apologies for any contribution(s) I might have made in that area. +--On 10 janvier 2015 21:25:11 -0600 The BSD Dreamer beas...@tardisi.com wrote: | Count the | PORTREVISIONs to bind before 9.9.4 and after. Plus look at all the other | annoying changes in those PORTREVISIONs without that things have been | working fine for the rest of us before. Yes, let's say there are two kinds of maintainers, those who keep the bugs they find in the port until there is a new release to an absolute minimum so that people are not scared of the number of changes, and there are those, like me, that would rather have a dozen updates between releases, each addressing a bug when it arises. The BIND ports were in such a miserable way, with kludges everywhere, when I took over that it took me some time to get them right. I saw that mess -- more than once. Thank you for taking that on! --Chris -- Mathieu Arnold ___ 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
Re: BIND REPLACE_BASE option
On Tue, 13 Jan 2015 16:55:53 +0100 Kurt Jaeger li...@opsec.eu wrote Hi! customizations you need available. If the default options don't cut it for you, in order to use only binary packages that means you need to run your own poudriere setup -- which is well worth it if you're managing several machines / jails etc. poudriere allows you to manage several seperate pkg trees with different options, so you can: - build a default tree (and pkg repo), provide it to all generic hosts - build a seperate tree (and pkg repo) with modified options, and provide it to the special hosts I use a similar, but somewhat different strategy. Which works nice if you have any spare hardware available. I simply use a fresh install of whatever RELEASE/RELENG I'm chasing. * create a dump(8) to external storage * build/install (custom) world/kernel * (batch) build install clean ports with desired options * dump to external storage * restore to target host/machine and as Kurt mentioned; flash/SSD media *is* the way to go! :) I ended up going this route because I found the builds ran quicker, and it all ended up being a bit tidier. Also makes it trivial to rollback to any chosen revision. --Chris It helps to keep the poudriere build tree on fast flash/SSD drives 8-} This all works and is very, very good! Thanks for the work! -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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
Re: sysutils/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 10:43:15 -0800 Freddie Cash fjwc...@gmail.com wrote On Tue, Jan 13, 2015 at 10:17 AM, Chris H bsd-li...@bsdforge.com wrote: On Tue, 13 Jan 2015 10:08:05 -0800 Freddie Cash fjwc...@gmail.com wrote Good morning, With the requirement for the NONE cipher in OpenSSH requiring a custom compile of the world or a custom compile of the openssh-portable port (all my production servers are binary-package-only now), I've started using bbcp instead of zfs send over SSH. And looking at using bbcp instead of rsync over SSH for another system (transfer speed is more important than encrypting the data as the transfer is done over a very local LAN link). The bbcp port is version 20120520; the latest version available is 20140902. There have been several new features added over the past 2 years that make it (at least on paper) a decent rsync replacement for our uses. Is there anyone interested in bringing this port up-to-date. I had a quick look, but it requires some C hacking that's beyond my skills. :( I've only tried compiling it with clang, which gives lots of errors. Haven't tried with gcc, though. I just had a look. Looks interesting. I can't foresee any issue moving it ahead. But before I step up, and say I'll take it. Have you contacted the maintainer? I don't want to step on any toes. :) Well, now I feel sheepish. I was looking at the freshports.org page for it and just saw portmgr-related commits to the port and assumed it was maintained by freebsd-ports (aka not maintained). I completely missed the little Maintainer line at the top. :( I've CC'd the port Maintainer to bring them into the loop. [Being a past port maintainer, I really should know better.] LOL No worries. :) I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) All the best! -- Freddie Cash fjwc...@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 --Chris --- ___ 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: powerdns meta packages?
On Mon, 12 Jan 2015 15:10:12 + Joe Holden li...@rewt.org.uk wrote Hi guys, What is the process for adding/submitting meta packages for ports for example powerdns that have multiple backend options and the default isn't suitable, or failing that have the ability to install powerdns with default backend but allow the installation of others? Currently the port defaults to postgres, in this case I'd like sqlite backend for some servers (slaves), at the moment I'm just building that manually but it does mean I can't just do 'pkg upgrade' As I understand it, you want to create a custom meta-port. You might do well to have a look at some of the other meta-ports available, for the best way to accomplish it for your needs; x11/xorg x11/xorg-minimal x11/xorg-apps lang/php5-extensions are some that come to mind. Best wishes. --Chris Cheers, J ___ 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
Re: BIND REPLACE_BASE option
On Mon, 12 Jan 2015 07:10:46 -0900 Royce Williams ro...@tycho.org wrote
On Mon, Jan 12, 2015 at 4:08 AM, Kurt Jaeger li...@opsec.eu wrote:
No disputing that, just thinking, is FreeBSD being driven by user need,
financial contributer need, developer need, security need, making things
'better' or just by people wanting to make their mark in a warped sense
of it'll all get better...?
Probably by developer *capacity* (not need) and fire-fighting,
like most IT stuff 8-(
But like most IT stuff, resources are being asymmetrically applied to
the root causes of the fires.
Read the list of projects from last quarter:
- Address Space Layout Randomization (ASLR)
- amd64 Xen Paravirtualization
- bhyve
- Chelsio iSCSI Offload Support
- Debian GNU/kFreeBSD
- FreeBSD Preseed Installation (PXE)
- Jenkins Continuous Integration for FreeBSD
- New Automounter
- QEMU bsd-user-Enabled Ports Building
- VMWare VAAI and Microsoft ODX Acceleration in CTL
- ZFSguru
- Intel GPU Driver Update
- SDIO Driver
- UEFI Boot
- Updated vt(4) System Console
- Updating OpenCrypto
- FreeBSD on Newer ARM Boards
- FreeBSD/arm64
- LLDB Debugger Port
- LLVM Address Sanitizer (Asan)
- SSE Variants of libc Routines for amd64
- FreeBSD Python Ports
- GNOME/FreeBSD
- KDE on FreeBSD
- The Graphics Stack on FreeBSD
- Xfce
The Foundation section also lists these items not overlapping with the above:
- FreeBSD Journal
- PostgreSQL performance improvements
- Ongoing release process
- Development snapshots
- VM images for releases
- Secure Boot planning
- Infrastructure hardware
- Java licensing
- Summits and summit sponsorship
- Travel grants, tutorials, and talks
- New Design and Implementation book
- Recruitment flyers
Are there long-term improvement projects that aren't being listed? If
so, they should be.
At face value, the main project list is heavily weighted towards
relatively esoteric OS features. The Foundation list is heavily
weighted towards advocacy and communication (as it should be).
What is missing are high-level projects to help sysadmins maintain and
use FreeBSD on an ongoing basis.
Here are some projects that would help to close the sysadmin gap:
- Automatic error reporting and analysis
- OS and port debugging tools for sysadmins
- Independent project-wide usability analysis
- Ports dependency isolation and reduction framework
- Ports system reliability parity with Linuxes
- Searchable, taggable project FAQ
- Searchable hardware support matrix integrated with bug tracker
- Wiki curation and platform improvements
These projects decentralize and improve support for sysadmins and new
adopters. As a business case for the Foundation, these projects
should also deeply free up developer resources to focus on other major
projects.
In the past, when I have pointed out this sysadmin gap, I receive
one of two answers:
1. Sounds great. Let us know when you have it finished.
2. We're too busy to do any of those things.
... to which I answer:
1. These projects require technical skill and political capital within
the project. They are ideally suited for well-established independent
FreeBSD consultants with large blocks of time sponsored by the FreeBSD
Foundation. I can help (especially with the wiki work), but cannot
tackle these deeper problems in the way that others can.
FWIW I'm already in the process of creating a wiki that will serve
as a FreeBSD Documentation Factory. I've created the wiki, and am
currently plugging in all the necessary bits. This will permit
live documentation creation, and editing -- including man(1)
pages. It's currently backed by git(1), but conversions to other
RCS, SCM, VCS, {...} are all possible. In fact, I already have the
conversion methods available. This all makes it possible to import
any revision of any doc/man page as an official doc set.
Point being; as FreeBSD is Open Source, it heavily depends on
user-contribution. I'm not attempting to discount your previous
points, however. Just saying. As to the sysadmin gap a look to
the ports tree seems to indicate quite a volume of sysadmin
related ports. Are some missing?
All the best.
--Chris
2. The reason you're busy is that you don't have these things.
I applaud recent work on Jenkins and cluster infrastructure. I also
appreciate Colin Percivals's automated error reporting work, because
it directly attacks the sysadmin gap. And I know that getting
releases out the door is time-consuming and keeps the lights on.
But the overall project list needed to be rebalanced towards system
administration. I request that the Foundation consider this when
calling for proposals for the next round of funded projects.
Royce
___
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: BIND REPLACE_BASE option
On Mon, 12 Jan 2015 11:57:26 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Mon, 12 Jan 2015, Chris H wrote: Here is where we will clash; I've been riding *BSD for over 20yrs. It's *biggest* asset has been in it's flexibility -- it wasn't another Linux dist, that required me to essentially become a clone of every other Linux install. The Ports system, and /src allowed one to tailor my build/install to meet *my* needs. I wasn't required, in fact I was *encouraged*, to have a unique system. Frankly the new pkg(8) *requirement* was a complete 180 on this philosophy. Huh? It is the same as the old package system, required if you want to use ports or packages. The difference is that pkg is not in base, so it can be easily upgraded without doing an OS upgrade. Ports continue to work as they did with the old package system, only package operations are faster and more reliable. Sure, it's intended to *feel* like pkg_, but the (way) it's implemented bears little resemblance to pkg_, and it's implementation also *abruptly* pulled the rug out from under many years of development work, carefully crafted work by development shops to keep their stream flowing smoothly and more efficiently. [I'm kicking a dead horse here] My main complaint with pkg is the persistent misunderstanding that binary packages are a direct replacement for ports. http://www.wonkity.com/~wblock/docs/html/pkg.html I'd be inclined to agree here. As for the original topic, BIND in base had the same upgrade problems as the old package system. The port overwriting the base was a convenient but nasty hack. Not even that convenient, because all that changes with the port is the config files are in /usr/local/etc rather than /etc. A chroot adds little security or isolation, and if you want that it should be in a jail or other type of VM anyway. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail.html# Speaking of kicking dead horses; I'm still amazed that this topic still continues. I remember the initial discussion on this about 9mos ago, and thought; OK. That seems to make sense. I'd better see if I can cobble up something that mimic's the old setup, so I can keep things going, until I find a suitable replacement for the BIND. Took me less than 2hrs. Point being; there was a fair amount of time before the BIND got yanked (unlike the pkg change). So I'm amazed so many people are, well, amazed. --Chris --- ___ 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: BIND REPLACE_BASE option
On Mon, 12 Jan 2015 07:55:45 -0900 Royce Williams ro...@tycho.org wrote On Mon, Jan 12, 2015 at 7:38 AM, Chris H bsd-li...@bsdforge.com wrote: As to the sysadmin gap a look to the ports tree seems to indicate quite a volume of sysadmin related ports. Are some missing? To the contrary -- there are too many. A good project would be to survey which ones people actually use, and why -- and then bring their best features into base. I agree something like thishas value. But obtaining access to the usage matrix is the key. This would be difficult to do as a independent skunkworks project, and would be better suited as a high-level, Foundation-sponsored one. see above. (For example, in the Debian ecosystem, for most people, there is no reason to use something other than apt-get, because it does what it should and does it well. Every time I upgrade a port, I have to study /usr/ports/UPDATING, read multiple mailing lists, and hold my breath. I cannot remember the last time I worried about running apt-get. Arguments about flexibility and diversity ecosystem don't hold up well when the basics fail on a regular basis.) Here is where we will clash; I've been riding *BSD for over 20yrs. It's *biggest* asset has been in it's flexibility -- it wasn't another Linux dist, that required me to essentially become a clone of every other Linux install. The Ports system, and /src allowed one to tailor my build/install to meet *my* needs. I wasn't required, in fact I was *encouraged*, to have a unique system. Frankly the new pkg(8) *requirement* was a complete 180 on this philosophy. It's implementation was also flawed in many respects (which speaks to your point). I have no objection to pkg(8), per se; But it *should* have been optional, it *should* have been better (longer) tested, *before* pushed into the ecosystem, and should *not* have been implemented with a backend with single-point-of-failue (sqlite3(1). Honestly; why did pkg(8) have to be *required*? Is FreeBSD simply hoping to become a new distro? But, given it's there, and how it's there. You have/bring up some valid, points; it *is* a bit of a game of roulette. I *too* get a knot in my stomach even at the *thought* of an upgrade. Sure there are plenty of choices in an upgrade path/implementation. But, as it sits now, I'm not sure I can say it's gotten any easier, or trouble free, as a result of pkg(8). --Chris Royce ___ 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 --Chris --- ___ 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: powerdns meta packages?
On Mon, 12 Jan 2015 16:42:45 + Joe Holden li...@rewt.org.uk wrote On 12/01/2015 16:05, Chris H wrote: On Mon, 12 Jan 2015 15:10:12 + Joe Holden li...@rewt.org.uk wrote Hi guys, What is the process for adding/submitting meta packages for ports for example powerdns that have multiple backend options and the default isn't suitable, or failing that have the ability to install powerdns with default backend but allow the installation of others? Currently the port defaults to postgres, in this case I'd like sqlite backend for some servers (slaves), at the moment I'm just building that manually but it does mean I can't just do 'pkg upgrade' As I understand it, you want to create a custom meta-port. You might do well to have a look at some of the other meta-ports available, for the best way to accomplish it for your needs; x11/xorg x11/xorg-minimal x11/xorg-apps lang/php5-extensions are some that come to mind. Best wishes. This is what I'd normally do but I was hoping with the new pkg stuff we could have some sort of virtual packages but this will do I guess! Will need to read up on package building now - seems a bit silly to have my own repo just for -mysql, -sqlite type packages though Well, I thought you might want to make the (meta)port, and submit it. Then other like-minded people could also benefit from your contribution. :) If you submit it as a port, the pkg(8) business takes care of itself. All the best. --Chris Cheers --Chris Cheers, J ___ 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 --Chris --- ___ 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: Who do I contact to send pr(1)'s? [WAS No subject]
On Sat, 10 Jan 2015 13:02:19 -0800 Chris H bsd-li...@bsdforge.com wrote On Sat, 10 Jan 2015 21:51:35 +0100 Kurt Jaeger li...@opsec.eu wrote Hi! The FreeBSD copy of bugzilla appears to be broken. All attempts to reach it return: Error 503 Service Unavailable Yes. mva@, one of the bugzilla admins, reported the cause a few hours ago: While doing maintenance on bugzilla, the production database broke due to operator error and probably loss of some changes. So currently some recovery operations are ongoing. So, I guess bugmeister's very busy right now. Ahh. I see. Bummer. Thanks for taking the time to reply, Kurt. Anyone have an ETA on the availability of FreeBSD's bugzilla? (https://bugs.freebsd.org/bugzilla/) Thanks --Chris -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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 ___ 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
[no subject]
Greetings, The FreeBSD copy of bugzilla appears to be broken. All attempts to reach it return: Error 503 Service Unavailable Where do we go to manage pr(1)'s? I would have sent this to freebsd-www@ but that list has been obsoleted. Thanks. --Chris --- ___ 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
Who do I contact to send pr(1)'s?
Where do we go to manage pr(1)'s? The FreeBSD copy of bugzilla appears to be broken. All attempts to reach it return: Error 503 Service Unavailable I would have sent this to freebsd-www@ but that list has been obsoleted. Thanks. --Chris --- ___ 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: Who do I contact to send pr(1)'s? [WAS No subject]
On Sat, 10 Jan 2015 21:51:35 +0100 Kurt Jaeger li...@opsec.eu wrote Hi! The FreeBSD copy of bugzilla appears to be broken. All attempts to reach it return: Error 503 Service Unavailable Yes. mva@, one of the bugzilla admins, reported the cause a few hours ago: While doing maintenance on bugzilla, the production database broke due to operator error and probably loss of some changes. So currently some recovery operations are ongoing. So, I guess bugmeister's very busy right now. Ahh. I see. Bummer. Thanks for taking the time to reply, Kurt. --Chris -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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
Re: do-install fails when files in .PLIST.mktmp are truncated
On Fri, 9 Jan 2015 20:33:42 +0800 Ben Woods woods...@gmail.com wrote On Friday, January 9, 2015, Freddy Andersen fander...@youmail.com wrote: Thank you ben! you have no idea how helpful the make and makeplist was for me :) the issues was not with my Makefile but rather that I did not understand what roll the pkg-plist had in the do-install process. I’m all good now and my updated hadoop2 builds and install … Now I just need to figure how I can get this sent to upstream after some testing on my end. On Jan 8, 2015, at 3:02 PM, Ben Woods woods...@gmail.com javascript:_e(%7B%7D,'cvml','woods...@gmail.com'); wrote: First off, since this is your first attempt to update a port, welcome! There may be a slight hurdle to get over to understanding port basics, but once you get there it is quite rewarding. This resource is priceless, read it and refer back to it often: https://www.freebsd.org/doc/en/books/porters-handbook/book.html Also, the great thing about ports is you can read all of the shell scripts that are doing the work if you don't understand something (such as copytree_share), by grepping through the files here: /usr/ports/Mk/ Lastly, the mailing lists do not have the formatting features of the forums, so no need for the [FILE][/FILE] stuff. I would say the most obvious thing for your port is the need to update the pkg-plist file which lists ever file your port will install on the system. Easy way to test this with your updated port is to do the following: # cd PORTDIR # make clean # make # make makeplist That will dump the new plist to the console standard output, but doesn't actually update the pkg-plist for you (you have to do that by redirecting the output to the file). But note, you need to follow the instructions of the first line (delete the first line, and check the output of the rest of the file looks reasonable). I would redirect the output to a new plist file and compare the difference before overwriting the main plist file: # make makeplist pkg-plist.new # diff -u pkg-plist pkg-plist.new Good luck! -- -- From: Benjamin Woods woods...@gmail.com javascript:_e(%7B%7D,'cvml','woods...@gmail.com'); Submit a bug report here: bugs.freebsd.org/bugzilla/ Include devel/hadoop2 at the start of the bug title. Then you need to attach a patch of the changes to the ports tree that will update the port per your work. The easiest way to generate the patch file to update is to ensure you retrieved your ports tree using svn (Per https://www.freebsd.org/doc/handbook/svn.html). Then change devel/hadoop2 to match your needs, and run: # cd /usr/ports # svn diff devel/hadoop2 /home/USERNAME/hadoop2.patch Good luck! In an effort to insure you're submitting a patch ( svn(1) diff(1) ) against what's currently current in the ports tree, you might find the following helpful: svn co --depth empty svn://svn.freebsd.org/ports/head 2015-01-09 svn up --set-depth empty 2015-01-09/devel svn up 2015-01-09/devel/hadoop2 # make your modifications to your port files, then... cd 2015-01-09/devel svn diff 2015-01-09.diff Then simply attach the diff to a new pr(1) (https://bugs.freebsd.org/bugzilla/) Best wishes. --Chris -- -- From: Benjamin Woods woods...@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 ___ 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: Where are textproc/gtkspell dictionaries?
On Thu, 8 Jan 2015 12:01:05 +0100 Vlad \Blackflow\ K. acheron.blackf...@gmail.com wrote textproc/hunspell it is, thanks, I didn't know about that one. I tried aspell and that didn't work so I posted. Excelent! :) Why is it hunspell? Is that some default on FreeBSD? I see stuff like LibreOffice and FireFox depend on it. I tried to browse the gtkspell source on but couldn't find any reference to a preferred dictionary set. Honestly, I have no idea. Like I said in my original reply -- just guessing. I'll differ to someone that actually has that answer. :) --Chris On Thu, Jan 8, 2015 at 3:33 AM, Chris H bsd-li...@bsdforge.com wrote: On Thu, 8 Jan 2015 02:07:31 +0100 Vlad \Blackflow\ K. acheron.blackf...@gmail.com wrote So Pidgin (net-im/pidgin) can apparently use textproc/gtkspell to provide spell checking, and the knob is on by default, but the gtkspell package does not carry any dictionaries and I assume that's the reason why there's no spell checking support in Pidgin. What provides these dictionaries? Just guessing here; but is it the usual suspects? textproc/aspell-ispell textproc/hunspell along wih their dictionaries: textproc/(en|es|...)-aspell textproc/(en|es|...)-hunspell Like I said, just a guess. --Chris Or maybe I'm asking the wrong question and should ask instead how to get spell checking in Pidgin. ___ 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 ___ 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
Re: Where are textproc/gtkspell dictionaries?
On Thu, 08 Jan 2015 07:05:48 -0800 Chris H bsd-li...@bsdforge.com wrote On Thu, 8 Jan 2015 12:01:05 +0100 Vlad \Blackflow\ K. acheron.blackf...@gmail.com wrote textproc/hunspell it is, thanks, I didn't know about that one. I tried aspell and that didn't work so I posted. Excelent! :) Why is it hunspell? Is that some default on FreeBSD? I see stuff like LibreOffice and FireFox depend on it. I tried to browse the gtkspell source on but couldn't find any reference to a preferred dictionary set. Honestly, I have no idea. Like I said in my original reply -- just guessing. I'll differ to someone that actually has that answer. :) Ahem... that was *defer*, not differ. Given that this subject is regarding spell checking, I felt compelled to reply with the correction. Being reminded off-list, didn't hurt either. (I caught the mistake *just* as I had hit the send button). --Chris --Chris On Thu, Jan 8, 2015 at 3:33 AM, Chris H bsd-li...@bsdforge.com wrote: On Thu, 8 Jan 2015 02:07:31 +0100 Vlad \Blackflow\ K. acheron.blackf...@gmail.com wrote So Pidgin (net-im/pidgin) can apparently use textproc/gtkspell to provide spell checking, and the knob is on by default, but the gtkspell package does not carry any dictionaries and I assume that's the reason why there's no spell checking support in Pidgin. What provides these dictionaries? Just guessing here; but is it the usual suspects? textproc/aspell-ispell textproc/hunspell along wih their dictionaries: textproc/(en|es|...)-aspell textproc/(en|es|...)-hunspell Like I said, just a guess. --Chris Or maybe I'm asking the wrong question and should ask instead how to get spell checking in Pidgin. ___ 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 ___ 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 ___ 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: Help with porting FreeCAD
On Wed, 07 Jan 2015 09:47:53 +0100 Andrea Venturoli m...@netfence.it wrote
On 01/07/15 00:10, Chris H wrote:
Sure. OK.
Maybe something along the lines of:
BUILD_DEPENDS+=${PREFIX}/bin/gcc49:${PORTSDIR}/lang/gcc49
This did not help.
Some extract from the configuration/build:
=== freecad-20150106 depends on executable: gfortran48 - found
...
/usr/local/bin/g++49 -pipe -g -Wl,-rpath=/usr/local/lib/gcc49
-fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc49 -Wno-deprecated
-Wno-write-strings -pipe -g -Wl,-rpath=/usr/local/lib/gcc49
-fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc49 -DFC_DEBUG
-Wl,-rpath=/usr/local/lib/gcc48 -L/usr/local/lib/gcc48 -B/usr/local/bin
-Wl,-rpath=/usr/local/lib/gcc49 -L/usr/local/lib/gcc49
CMakeFiles/FreeCADMain.dir/MainGui.cpp.o -o ../../bin/FreeCAD
../../lib/libFreeCADGui.so ../../lib/libFreeCADApp.so
../../lib/libFreeCADBase.so /usr/local/lib/libpython2.7.so
/usr/local/lib/libxerces-c.so -lz -lutil /usr/local/lib/libCoin.so
/usr/local/lib/qt4/libQtOpenGL.so /usr/local/lib/qt4/libQtSvg.so
/usr/local/lib/qt4/libQtUiTools.a /usr/local/lib/qt4/libQtWebKit.so
/usr/local/lib/qt4/libQtGui.so /usr/local/lib/qt4/libQtXml.so
/usr/local/lib/qt4/libQtNetwork.so /usr/local/lib/qt4/libQtCore.so
/usr/local/lib/libboost_filesystem.so
/usr/local/lib/libboost_program_options.so /usr/local/li! b/libboost
_regex.so /usr/local/lib/libboost_signals.so
/usr/local/lib/libboost_system.so /usr/local/lib/libboost_thread.so
/usr/local/lib/libGL.so /usr/local/lib/libshiboken-python2.7.so
/usr/local/lib/libpyside-python2.7.so
-Wl,-rpath,/tmp/usr/ports/cad/freecad/work/.build/lib:/usr/local/lib:/usr/loc
al/lib/qt4: ../../lib/libFreeCADGui.so: undefined reference to
'std::__throw_out_of_range_fmt(char const*, ...)'
My guess is the problem still comes from -L/usr/local/lib/gcc48 coming
before -L/usr/local/lib/gcc49.
My guess is a problem with qt(4|5)
There was also a suggestion regarding making use of hints in
Mk/Uses/fortran which may also be of help to you here. I can't
believe I overlooked that myself. :P
Best wishes.
--Chris
Also, regarding your USE_GCC
you would do well to choose:
USE_GCC=4.9+
which says: Must use gcc49, or greater.
Ok, now I'm just trying to get it working, but your suggestion is welcome.
bye Thanks
av.
___
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
Re: Where are textproc/gtkspell dictionaries?
On Thu, 8 Jan 2015 02:07:31 +0100 Vlad \Blackflow\ K. acheron.blackf...@gmail.com wrote So Pidgin (net-im/pidgin) can apparently use textproc/gtkspell to provide spell checking, and the knob is on by default, but the gtkspell package does not carry any dictionaries and I assume that's the reason why there's no spell checking support in Pidgin. What provides these dictionaries? Just guessing here; but is it the usual suspects? textproc/aspell-ispell textproc/hunspell along wih their dictionaries: textproc/(en|es|...)-aspell textproc/(en|es|...)-hunspell Like I said, just a guess. --Chris Or maybe I'm asking the wrong question and should ask instead how to get spell checking in Pidgin. ___ 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
Re: Help with porting FreeCAD
On Tue, 06 Jan 2015 23:12:48 +0100 Andrea Venturoli m...@netfence.it wrote Hello. A while ago I dirty-ported FreeCAD 0.14 and more or less got it working. Now it won't work anymore due to incompatible changes in OpenCASCADE (which is a dependency); so I'm trying 0.15 (which is still a beta). The box I'm using runs 9.3 and I'm facing a problem I'm too inexperienced about the port system to solve: _ g++ 4.9 seems to be needed (previous versions having an unsolved bug), so I put USE_GCC=4.9; _ however, fortran is required and USES=fortran:gcc picks up gfortran48; _ so in the link stage -L/usr/local/lib/gcc48 comes before -L/usr/local/lib/gcc49 and I get unresolved symbols. Is there a way I can tell the port system to pick gfortran49 instead of gfortran48 and forget about -L/usr/local/lib/gcc48? Of course I could try uninstalling gcc-4.8.4, but this is unfortunately a run dependency of several other ports. I think what you're looking for here is BUILD_DEPENDS= and RUN_DEPENDS= --Chris bye Thanks av. ___ 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
Re: Help with porting FreeCAD
On Tue, 06 Jan 2015 23:49:41 +0100 Andrea Venturoli m...@netfence.it wrote
On 01/06/15 23:41, Chris H wrote:
On Tue, 06 Jan 2015 23:12:48 +0100 Andrea Venturoli m...@netfence.it wrote
Hello.
A while ago I dirty-ported FreeCAD 0.14 and more or less got it working.
Now it won't work anymore due to incompatible changes in OpenCASCADE
(which is a dependency); so I'm trying 0.15 (which is still a beta).
The box I'm using runs 9.3 and I'm facing a problem I'm too
inexperienced about the port system to solve:
_ g++ 4.9 seems to be needed (previous versions having an unsolved bug),
so I put USE_GCC=4.9;
_ however, fortran is required and USES=fortran:gcc picks up gfortran48;
_ so in the link stage -L/usr/local/lib/gcc48 comes before
-L/usr/local/lib/gcc49 and I get unresolved symbols.
Is there a way I can tell the port system to pick gfortran49 instead of
gfortran48 and forget about -L/usr/local/lib/gcc48?
Of course I could try uninstalling gcc-4.8.4, but this is unfortunately
a run dependency of several other ports.
I think what you're looking for here is
BUILD_DEPENDS=
and
RUN_DEPENDS=
Thanks, but, sorry, I don't quite get your suggestion.
What should I put into those variables?
How would that solve the above problem?
Sure. OK.
Maybe something along the lines of:
BUILD_DEPENDS+= ${PREFIX}/bin/gcc49:${PORTSDIR}/lang/gcc49
Also, regarding your USE_GCC
you would do well to choose:
USE_GCC=4.9+
which says: Must use gcc49, or greater.
All the best.
--Chris
bye Thanks
av.
___
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
How does the Additional FreeBSD Contributors page work?
Greetings, and Happy New Year! I was reading through the Porters Handbook today, and while reading 3.6. Submitting the New Port, I noticed the link at the end to 8. Additional FreeBSD Contributors (https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/contrib-additional.html). Being a maintainer of ~35 ports (https://www.freebsd.org/cgi/ports.cgi?query=portmaster@stype=maintainer) (tho ~5 are still waiting to be committed), I thought I'd see if I was listed. But discovered I wasn't. Given that maintainers of 1 port, and as little as 1mos. tenure are listed. I assumed that I must have misunderstood what the page represents. Would anyone be willing to clarify? Or am I simply blacklisted? ;) Thanks, and again, Happy New Year, to all! --Chris ___ 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: How does the Additional FreeBSD Contributors page work?
On Thu, 1 Jan 2015 22:06:43 -0600 Mark Linimon lini...@lonesome.com wrote On Thu, Jan 01, 2015 at 06:05:38PM -0800, Chris H wrote: Would anyone be willing to clarify? Or am I simply blacklisted? ;) The list is not complete. No doubt you've merely been overlooked, sorry. No worries -- *really*. In all honestly, I just wasn't sure if I *really* knew what/who the page *actually* represented. :) Thank you for taking the time to respond, Mark. --Chris mcl ___ 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: x11-servers/xorg-vfbserver depends on x11/xkeyboard-config
On Mon, 29 Dec 2014 12:54:50 -0500 Robert Simmons rsimmo...@gmail.com wrote When I start Xvfb it fails with the following error: XKB: Failed to compile keymap It appears that xvfb now requires xkeyboard-config. After installing x11/xkeyboard-config everything works as expected. I wanted to modify the port to add this dependency, but I wanted to make sure it is correct. I looked in the /usr/ports/Mk/bsd.xorg.mk and did not see this port listed to add it to the USE_XORG= line in the Makefile. In this case, should this be set in RUN_DEPENDS= ? Yes. That would get it for you. --Chris ___ 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
Re: gnupg pinentry
On Wed, 24 Dec 2014 12:23:38 +0300 (MSK) Dmitry Morozovsky ma...@rinet.ru
wrote
On Tue, 23 Dec 2014, Chris H wrote:
It looks as though it would be feasible to write an extremely
lightweight pinentry-compatible program to depend on so we can kill the
dependency bloat and have a simple shell-based password entry option.
Anyone up for a weekend challenge? :-)
There has been another thread on this mailing list discussing making the
port honour the WITHOUT_X11 and OPTIONS_UNSET+=X11 options from
make.conf which would make it only depend on security/pinentry-curses
instead of security/pinentry. This seems like a good solution to me. It
would mean if one of those options is set it will only drag in a single
dependancy rather than all the X11 libraries and GTK.
A quick look @ the security/pinentry Makefile, indicates that the
request for this type of modification is trivial. It simply requires
reversing the (PORT_)OPTIONS logic -- this port could completed in
under 5 minutes. So unless instructed otherwise, I'll go ahead with
this.
One last question; pinentry-console, or pinentry-nox?
already defined: pinentry-curses ;)
Right you are, Dmitry. :)
(see side thread)
Patch I snet previoursy is syntax incorrect, the following seems to be more
useful:
Index: Makefile
===
--- Makefile(revision 375271)
+++ Makefile(working copy)
@@ -22,7 +22,11 @@
libksba.so:${PORTSDIR}/security/libksba \
libnpth.so:${PORTSDIR}/devel/npth
BUILD_DEPENDS= libgpg-error=1.11:${PORTSDIR}/security/libgpg-error
+.if defined(WITHOUT_X11) || !empty(OPTIONS_UNSET:MX11)
+RUN_DEPENDS= pinentry0:${PORTSDIR}/security/pinentry-curses
+.else
RUN_DEPENDS= pinentry0:${PORTSDIR}/security/pinentry
+.endif
GNU_CONFIGURE= YES
USES= gmake iconv tar:bzip2
Yes, I had a closer look at the code last night, and the only
possible addition I could find. Was possibly adding:
--disable-fallback-curses
to the -ncurses slave port. But in the end, what would be gained?
I think your patch above does it all.
Thanks for your time, and consideration, Dmitry, and
have a Merry Christmas!
--Chris
--
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: ma...@freebsd.org ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***
___
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: gnupg pinentry
On Tue, 23 Dec 2014 13:51:11 + Matt Smith f...@xtaz.co.uk wrote On Dec 23 07:44, Mark Felder wrote: It looks as though it would be feasible to write an extremely lightweight pinentry-compatible program to depend on so we can kill the dependency bloat and have a simple shell-based password entry option. Anyone up for a weekend challenge? :-) There has been another thread on this mailing list discussing making the port honour the WITHOUT_X11 and OPTIONS_UNSET+=X11 options from make.conf which would make it only depend on security/pinentry-curses instead of security/pinentry. This seems like a good solution to me. It would mean if one of those options is set it will only drag in a single dependancy rather than all the X11 libraries and GTK. A quick look @ the security/pinentry Makefile, indicates that the request for this type of modification is trivial. It simply requires reversing the (PORT_)OPTIONS logic -- this port could completed in under 5 minutes. So unless instructed otherwise, I'll go ahead with this. One last question; pinentry-console, or pinentry-nox? Best wishes. --Chris -- Matt ___ 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
Re: hs-git-annex vs. git-subversion
On Tue, 16 Dec 2014 21:59:17 -0700 Russell L. Carter rcar...@pinyon.org wrote Hi porters, It seems that devel/hs-git-annex and devel/git-subversion don't like each other, to the extent that installing one requires removing the other. Is this something fundamental? If not, what would be the required change, locally? I once looked inyto the haskell hive-brain and ended up a couple of hours later retching, with tattered clothes, in a freezing ditch, which I was lucky to be able to climb out of, mind only slightly damaged. So I am a bit reluctant to look further down that path. hs-pandoc seems to be working though, so we let the monster roam the house, still. Somewhat OT, but it might be nice to get a freebsd-haskell@ list. If for no other reason than that every other lang has one. But in the case of your reported issue w/it. You might receive more expert advice. :) --Chris This is on stable/10, pkg builds maintained by poudriere nightly. Thanks, Russell ___ 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
Re: Resetting maintainership
On Fri, 12 Dec 2014 18:01:29 -0600 chris ch...@bsdjunk.com wrote On Fri, 12 Dec 2014 17:31:54 -0600 Dan Langillelt;d...@langille.orggt; wrote gt; On Dec 10, 2014, at 5:27 PM, Pietro Cerutti lt;g...@freebsd.orggt; wrote: gt; gt; All, gt; gt; unfortunately, I don't foresee having time to take care of my ports as gt; they deserve in the near future. Hence, I'm dropping maintainership of gt; all of them. Of course, I'll be occasionally patching and updating stuff gt; here and there anyway. Here's the list of ports. Please be greedy :) That’s a whole lot of ports. Thanks for your work. Best wishes. — Dan Langille http://langille.org/ Please send list so I can see if any interest me. Please learn to use the mailing list archives for such things: https://docs.freebsd.org/mail/current/freebsd-ports.html Thanks. --Chris ___ 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
Re: Re: Resetting maintainership
On Fri, 12 Dec 2014 19:35:15 -0800 dte...@freebsd.org wrote Chris,… Why on Earth are you requesting read-receipts for this (and your previous) e-mail? /me disturbed by such actions from e-mails sent to all developers Hey, Devin. :) Umm. This is very hard to debug. It appears you have replied directly to both chris, and Chris H, and you respond with; Chris,… So. You talkin' to *me*? If so. I can assure I don't request read receipts. Well, certainly not on a mailing list, anyway. :) All the best. --Chris (H) -- Devin From: owner-all-develop...@freebsd.org [mailto:owner-all-develop...@freebsd.org] On Behalf Of chris Sent: Friday, December 12, 2014 6:45 PM To: Chris H Cc: Dan Langille; po...@freebsd.org; FreeBSD Developers; Pietro Cerutti Subject: Re: Re: Resetting maintainership On Fri, 12 Dec 2014 20:25:42 -0600 Chris H bsd-li...@bsdforge.com mailto:bsd-li...@bsdforge.com wrote On Fri, 12 Dec 2014 18:01:29 -0600 chris ch...@bsdjunk.com mailto:ch...@bsdjunk.com wrote On Fri, 12 Dec 2014 17:31:54 -0600 Dan Langillelt;d...@langille.org mailto:d...@langille.org gt; wrote gt; On Dec 10, 2014, at 5:27 PM, Pietro Cerutti lt;g...@freebsd.org mailto:g...@freebsd.org gt; wrote: gt; gt; All, gt; gt; unfortunately, I don't foresee having time to take care of my ports as gt; they deserve in the near future. Hence, I'm dropping maintainership of gt; all of them. Of course, I'll be occasionally patching and updating stuff gt; here and there anyway. Here's the list of ports. Please be greedy :) That’s a whole lot of ports. Thanks for your work. Best wishes. — Dan Langille http://langille.org/ Please send list so I can see if any interest me. Please learn to use the mailing list archives for such things: https://docs.freebsd.org/mail/current/freebsd-ports.html Thanks. --Chris ___ freebsd-ports@freebsd.org mailto: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 mailto:freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailto: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 mailto:freebsd-ports-unsubscr...@freebsd.org I'll take all of those if possible. Chris ___ 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
Re: port www/elog
On Wed, 10 Dec 2014 08:26:03 -0500 Chen Xu xuc...@brandeis.edu wrote Tom, I found an old bug report about this port which might give some information. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165858 Thanks, Chen On Dec 10, 2014 6:25 AM, Thomas Mueller mueller6...@bellsouth.net wrote: Dear ALL, I am using this software with outdated version of FreeBSD. As I can see, this port is DEPRECATED and no longer available. Can any step up to maintain it? Please! -Chen I just looked found www/elog was not in the ports tree. I am not familiar with elog and wouldn't know where to find it. Tom I'll take it. Hi Chen, I checked out the last available revision from FreeBSD's svn. I'll have a new pr(1) submitted for it, in about an hour. All the best. --Chris ___ 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
Re: Resetting maintainership
On Wed, 10 Dec 2014 22:27:50 + Pietro Cerutti g...@freebsd.org wrote All, unfortunately, I don't foresee having time to take care of my ports as they deserve in the near future. Hence, I'm dropping maintainership of all of them. Of course, I'll be occasionally patching and updating stuff here and there anyway. Here's the list of ports. Please be greedy :) audio/ccaudio2 audio/dcd audio/etcd audio/gervill audio/gmixer audio/gnomoradio audio/jack_mixer audio/libaiff audio/libebur128 audio/libgroove audio/musica audio/osalp audio/tcd audio/tuxguitar audio/wavbreaker cad/meshdev cad/meshlab databases/mysql-connector-c databases/mysql-connector-c++ databases/speedtables deskutils/ganttproject deskutils/taskd deskutils/taskwarrior deskutils/vit devel/build devel/catch devel/cbrowser devel/cdash devel/cscope devel/csoap devel/dcmtk devel/dparser devel/ftjam devel/gdcm devel/libghthash devel/libpeak devel/libqxt devel/pypersrc devel/qt4-qtsolutions-soap devel/sourcenav devel/ucommon devel/xwpe devel/yajl editors/codelite editors/fxite editors/texworks ftp/ftpcube games/adgali games/atr3d graphics/aeskulap graphics/aqsis graphics/ayam graphics/figurine graphics/freeimage graphics/libosmesa graphics/separate graphics/tulip java/netbeans java/netbeans-devel lang/cfortran lang/io lang/kawa lang/nbfc lang/seed7 mail/ez-pine-gpg mail/mbox2imap math/abacus math/carve math/gambit math/goblin math/libtommath math/mpir math/newmat math/ogdf math/oleo math/vtk5 math/vtk5-data math/vtk6 math/yacas multimedia/gmencoder net/gnu-radius net/jags net/jrdesktop net/trickle net-im/jarl net-im/openfire net-im/telegram net-p2p/dclib net-p2p/valknut ports.txt print/lilypond print/lilypond-devel security/py-pow sysutils/createrepo sysutils/deltarpm sysutils/heirloom sysutils/pam_mount sysutils/pwsafe sysutils/tmux textproc/hevea textproc/scew textproc/xerces-c3 textproc/xqilla textproc/zorba www/igal2 www/tivoka www/wsmake www/xaraya x11/erun x11/ooxcb x11/slock x11/thingylaunch x11-fm/ezfm x11-fm/xfe x11-themes/e16-themes x11-toolkits/fltk x11-toolkits/fltk-devel x11-toolkits/fox14 x11-toolkits/fox16 x11-toolkits/fox17 x11-toolkits/movingmotif x11-toolkits/vtkfox x11-toolkits/wxgtk30 x11-toolkits/xforms x11-wm/e16 x11-wm/enlightenment-docs x11-wm/epplets x11-wm/flwm x11-wm/jewel x11-wm/obpager I'm very much interested in x11-toolkits/wxgtk30 I see it's currently maintained by ports@ I put in a req for maintainer. Thanks, Pietro! --Chris -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp ___ 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: Next Perl update, and plans beyo nd…
On Tue, 9 Dec 2014 17:30:39 +0100 Mathieu Arnold m...@freebsd.org wrote Hello there, In a few days, I'll be changing the way Perl works wrt compiled modules it produces. The current patch[1] is on our code review tool. Right now, we have: $ readelf -d /usr/local/lib/perl5/5.18/mach/CORE/libperl.so|grep SONAME 0x000e (SONAME) Library soname: [libperl.so.5.18] $ That is, libperl.so has a name, and it is versionned, and the version will change if you have 5.16 or 5.20. If your libperl.so does not have a SONAME, you don't have an up-to-date Perl. Which is good, because if some app is linked with libperl.so, it has: # readelf -d /usr/local/bin/vim|grep perl 0x0001 (NEEDED) Shared library: [libperl.so.5.18] 0x000f (RPATH) Library rpath: [/usr/local/lib:/usr/local/lib/perl5/5.18/mach/CORE] 0x001d (RUNPATH)Library runpath: [/usr/local/lib:/usr/local/lib/perl5/5.18/mach/CORE] So if you change your Perl version, pkg will know it has to upgrade vim too because a NEEDED shlib changed. Now, for Perl modules, it's not like that, it reads like this: $ readelf -d /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so|grep perl $ So what the patch[1] does, is force linking with libperl.so.x.yy. After the patch, a compiled Perl module will look like this: $ readelf -d /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so | grep perl 0x0001 (NEEDED) Shared library: [libperl.so.5.18] 0x000f (RPATH) Library rpath: [/usr/local/lib/perl5/5.18/mach/CORE] 0x001d (RUNPATH) Library runpath: [/usr/local/lib/perl5/5.18/mach/CORE] $ Apologies if I seem a bit obtuse. But as I read this, it appears that Perl modules go from being text based (DateTime.pm) to becoming compiled? I *must* be missing something obvious. --Chris So pkg will detect it needs to be reinstalled when the Perl version change. As for the plans beyond that I was talking about in the subject, there will be a Perl 5.22 released next May, (and 5.24 the May after that,) when that happens, I'll change the default Perl to be 5.20, and deprecate 5.18 which won't, then, be supported. Sometime at the end of the summer, like sometime September, I'll change the default Perl to 5.22 and try to keep it that way, that is, a new Perl goes in in May, and gets to be the default in September. 1: https://reviews.freebsd.org/D1241 -- Mathieu Arnold ___ 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: Next Perl update, and plans beyo nd…
On Tue, 09 Dec 2014 18:02:23 +0100 Mathieu Arnold m...@freebsd.org wrote +--On 9 décembre 2014 08:53:13 -0800 Chris H bsd-li...@bsdforge.com wrote: | $ readelf -d | /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so|grep | perl $ | | So what the patch[1] does, is force linking with libperl.so.x.yy. After | the patch, a compiled Perl module will look like this: | | $ readelf -d | /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so | grep | perl 0x0001 (NEEDED) Shared library: | [libperl.so.5.18] 0x000f (RPATH) Library rpath: | [/usr/local/lib/perl5/5.18/mach/CORE] 0x001d (RUNPATH) | Library runpath: [/usr/local/lib/perl5/5.18/mach/CORE] $ | Apologies if I seem a bit obtuse. But as I read this, it appears | that Perl modules go from being text based (DateTime.pm) to becoming | compiled? | I *must* be missing something obvious. Huhu, yes, DateTime.so is already compiled: $ readelf -d /usr/local/lib/perl5/site_perl/mach/5.18/auto/DateTime/DateTime.so Dynamic section at offset 0x3d70 contains 21 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libc.so.7] 0x000c (INIT) 0x958 0x000d (FINI) 0x3878 0x0004 (HASH) 0x158 0x6ef5 (GNU_HASH) 0x218 0x0005 (STRTAB) 0x518 0x0006 (SYMTAB) 0x260 0x000a (STRSZ) 446 (bytes) 0x000b (SYMENT) 24 (bytes) 0x0003 (PLTGOT) 0x203f28 0x0002 (PLTRELSZ) 384 (bytes) 0x0014 (PLTREL) REAL 0x0017 (JMPREL) 0x7d8 0x0007 (REAL) 0x730 0x0008 (RELASZ) 168 (bytes) 0x0009 (RELAENT)24 (bytes) 0x6ffe (VERNEED)0x710 0x6fff (VERNEEDNUM) 1 0x6ff0 (VERSYM) 0x6d6 0x6ff9 (RELACOUNT) 2 0x (NULL) 0x0 But it's not linked with libperl.so right now. Ugh. Sorry. I *clearly* didn't think it through. I didn't examine the paths close enough. Of *course* the libs are there. Again, sorry, and thank you very much for taking the time to reply. --Chris -- Mathieu Arnold ___ 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: The futuire of 'interpreter-based threads' in perl
On Tue, 09 Dec 2014 21:03:04 +0100 Mark Martinec mark.martinec+free...@ijs.si wrote Mathieu Arnold wrote in another thread: Next Perl update, and plans beyond... As for the plans beyond that I was talking about in the subject, there will be a Perl 5.22 released next May, (and 5.24 the May after that,) when that happens, I'll change the default Perl to be 5.20, and deprecate 5.18 which won't, then, be supported. Sometime at the end of the summer, like sometime September, I'll change the default Perl to 5.22 and try to keep it that way, that is, a new Perl goes in in May, and gets to be the default in September. That reminds me of a question I have been brewing for some time now. As far as I can tell, all four lang/perl5.* ports have by default option THREADS (Build threaded perl) enabled by default. Don't remember when it became a default in ports, must have been at least a year ago. Which is very nice. I got accustomed to it, at our site we have developed a couple of in-house applications that make good use of perl ithreads. In some cases these interpreter threads save a lot of complexity (like managing a herd of cooperating processes, message passing queueing). The price is a potentially somewhat larger memory footprint (multiple interpreters) and a due care needed when one has to deal with shared variables, locks and queues. All in all, this feature can be very valuable. But now, just as we have started depending on it, the perl docs say (perl5200delta, ): Interpreter-based threads are now discouraged The interpreter-based threads provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help. The use of interpreter-based threads in perl is officially discouraged. I don't buy arguments 'makes them easy to misuse' and 'few people know how to use them correctly'. Yes, multithreading has its share if implications that require more careful design. But at the same time for certain near-real time applications it can be a very valuable tool. I wonder if FreeBSD has any say in this perl developers decision. And if not, what are the plans to keep compatibility with existing multithreaded applications without being locked down to some stale version of perl. I agree with Perl. In fact wheel manufacturers should take their lead; We are going to discontinue the creation, and distribution of wheels. We have found that it is far too easy for people to abuse wheels. They put them on cars, and hit other cars, or other people. They drink too much, and use them to drive around in cars with them... Don't you just *love* the Perl Police. C'mon already. This is just nonsense. They haven't made many friends in the past either. Many simply write modules to overcome such removals. In fact, I created Perl::Police, with the intention of it being a collection/collaboration effort to combine all of the silliness that comes out of such decisions to remove such valuable resources from Perl. It might be a bit trickier adding threads back in via a module. About the easiest way I can imagine, would be to create a module that requires everything from base, along with the addition of threads. But that ends up just being another Perl version/branch. So probably won't help here. But I couldn't help but chime in. I *sincerely* hope threads don't get removed. Thanks for the heads up, Mark. --Chris Mark ___ 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
How to recover local.sqlite (pkg(8) problem)
Greetings, During the building of a meta-port in the ports tree. My /var/db/pkg/local.sqlite database became corrupted. I spent some time, both with the pkg man pages, and with sqlite3 itself attempting to use one of the backups created by periodic(8). Located in /var/backups. But all to no avail. For the record, I used pkg backup -r /var/backup/pkg.sql.xz, as well as unpacking a copy of that file, and issuing the same. Moving (renaming) the corrupted database aside, prior to. I also issued sqlite3 local.sqlite followed by read pkg.sql and quit went w/o issue. But issuing pkg info emitted several error messages. Which appeared to be from sqlite3(8). This is on RELENG_9, w/source, and kernel world from about 1 week ago. I know that the backup is in good shape, as I had been using it w/o issue. Is this a bug? Thank you for all your time, and consideration. --Chris ___ 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: How to recover local.sqlite (pkg(8) problem)
On Wed, 19 Nov 2014 01:21:27 +0100 Baptiste Daroussin b...@freebsd.org wrote On Tue, Nov 18, 2014 at 04:18:33PM -0800, Chris H wrote: Greetings, During the building of a meta-port in the ports tree. My /var/db/pkg/local.sqlite database became corrupted. I spent some time, both with the pkg man pages, and with sqlite3 itself attempting to use one of the backups created by periodic(8). Located in /var/backups. But all to no avail. For the record, I used pkg backup -r /var/backup/pkg.sql.xz, as well as unpacking a copy of that file, and issuing the same. Moving (renaming) the corrupted database aside, prior to. I also issued sqlite3 local.sqlite followed by read pkg.sql and quit went w/o issue. But issuing pkg info emitted several error messages. Which appeared to be from sqlite3(8). This is on RELENG_9, w/source, and kernel world from about 1 week ago. I know that the backup is in good shape, as I had been using it w/o issue. Is this a bug? Thank you for all your time, and consideration. This is really surprising and first time this can of things get reported, can you provide me the the pkg.sql.xz file? Are you runing on nfs? if yes start the lockd first (pkg should fallback on a working solution (I need to check for pkg backup) but sqlite3 cli tool does not and sqlite3 cli tool on nfs without proper locking is known to corrupt database file. Thank you for your rapid reply, Baptiste! No. This is UFS2 only -- no nfs, no zfs. I'll send you a copy of the pkg.sql.xz directly. I did notice that when I used the sqlite3 cli, that the database was created, and that the size looked correct. But issuing pkg info resulted in many SQL related errors. Anyway. I'll send you the file. Thanks, again. --Chris Best regards, Bapt ___ 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: help w/ port just installing files...
On Mon, 17 Nov 2014 19:31:10 -0800 John-Mark Gurney j...@funkthat.com wrote
So, I'm trying to get a port that will install the NIST's KAT vectors
so I can write a test program using them...
I don't know what is the best way to handle plist creation and
installation. I have this Makefile so far:
# Created by: John-Mark Gurney j...@freebsd.org
# $FreeBSD$
PORTNAME=nist-kat
DISTVERSION=1.0
CATEGORIES=security
MAINTAINER=j...@freebsd.org
COMMENT=Collection of NIST's Know Answer Test Vectors
#LICENSE=PUBLICDOMAIN
BASE_URL=http://csrc.nist.gov/groups/STM/cavp/documents
MASTER_SITES=${BASE_URL}/aes/:aes
MASTER_SITES+=${BASE_URL}/des/:des
MASTER_SITES+=${BASE_URL}/mac/:mac
DISTFILES=KAT_AES.zip:aes
DISTFILES+=XTSTestVectors.zip:aes
DISTFILES+=KAT_TDES.zip:des
DISTFILES+=gcmtestvectors.zip:mac
DISTFILES+=hmactestvectors.zip:mac
# We want each dist file in it's own subdir
EXTRACT_CMD=mkdir $${file%.zip}; ${TAR}
EXTRACT_AFTER_ARGS=-C $${file%.zip}
NO_BUILD=
NO_WRKSUBDIR=
do-install:
mkdir -p ${PREFIX}/share/nist-kat \
cp -Rp ${WRKSRC}/ ${PREFIX}/share/nist-kat
.include bsd.port.mk
But the cp command copies more than I want, including the staging dir.
Does someone know an easier way to do this?
Thanks.
I don't know the exact layout you have in ${WRKSRC}
But it might be as simple as:
(cd ${WRKSRC} cp -Rp . ${STAGEDIR}${PREFIX}/share/nist-kat)
or some slight derivative. :)
Hope this helps.
--Chris
--
John-Mark GurneyVoice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
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
gcc48-4.8.4.s20141030.txz: Forbidden?!
OK. I'm on 11 (r274393 amd64, custom kernel. fresh world) svn info /usr/ports -- r372460 src, and make.conf were both empty. While building a port, lang/gcc48, and lang/gcc-ecj45 were sucked in as dependency. During the building of one of them (ecj45?) I noticed a (core dumped). I was unable to capture the context of the event. But decided to make deinstall both. Followed by a pkg install of both. The ecj45 installed w/o issue. But gcc48 failed with gcc48-4.8.4.s20141030.txz: Forbidden. Why? Thank you for all your time, and consideration. --Chris ___ 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: gcc48-4.8.4.s20141030.txz: Forbidden?!
On Thu, 13 Nov 2014 13:15:26 -0600 Bryan Drewery bdrew...@freebsd.org wrote On 11/13/2014 12:04 PM, Chris H wrote: OK. I'm on 11 (r274393 amd64, custom kernel. fresh world) svn info /usr/ports -- r372460 src, and make.conf were both empty. While building a port, lang/gcc48, and lang/gcc-ecj45 were sucked in as dependency. During the building of one of them (ecj45?) I noticed a (core dumped). I was unable to capture the context of the event. But decided to make deinstall both. Followed by a pkg install of both. The ecj45 installed w/o issue. But gcc48 failed with gcc48-4.8.4.s20141030.txz: Forbidden. Why? Thank you for all your time, and consideration. Was this error from 'pkg install' during the fetch phase? I'd suggest just trying again, the mirror may have been updating at the time. 'pkg update -f' and try again. Yes. This was via pkg install lang/gcc48 Probably during a fetch. Funny though. I got impatient, and decided to try a cd /usr/ports/lang/gcc48; make which resulted in the first 6 servers fetch attempted, replying Forbidden. I know clang is the preferred method. But isn't this going a bit too far. ;) The 7th server succeeded, and it seems to be building fine. Thanks for taking the time to reply, Bryan. --Chris -- Regards, Bryan Drewery ___ 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: xfstt port
On Wed, 12 Nov 2014 14:23:41 +0100 Guillem Jover guil...@hadrons.org wrote Hi! Due to the Berlios shutdown, I've relocated the project home to http://www.hadrons.org/software/xfstt/. Just wanted to let you know, because it seems to be a bit difficult to find currently, given that freecode.com/freshmeat.net is one of the first web engine hits and seems to be on its way out, and read-only. :/ Latest release is 1.9.1. FWIW, it currently appears to be located here: http://sourceforge.net/projects/xfstt.berlios/files/ I filed a pr(1) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194968 Thanks for the heads up. --Chris Thanks, Guillem ___ 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: How exactly does the base toolchain determine WHICH language to build with?
On Sat, 8 Nov 2014 14:46:21 +0100 Dimitry Andric d...@freebsd.org wrote On 08 Nov 2014, at 01:23, Chris H bsd-li...@bsdforge.com wrote: Sorry for the long title. I've been [needlessly] struggling with getting ports within the ports tree to build, on a fresh 11-CURRENT install from 2014-11-05. With custom KERNEL and WORLD built, and installed. Here's my situation, which has worked well since ~8.2; make.conf(5) WITHOUT_CLANG=true FAVORITE_COMPILER=gcc src.conf(5) WITHOUT_CLANG=true If you don't want to use and build clang at all, I think you also need these two settings (at least on recent -CURRENT): WITHOUT_CLANG_BOOTSTRAP=foo WITHOUT_CLANG_IS_CC=foo The latter variable determines whether /usr/bin/cc, /usr/bin/c++ and so on are linked to clang or gcc. I suspect the root of all your problems is that you don't have this setting. I'll neither argue, nor defend rational for w/o clang. To boring and out of scope for this thread. That said; I realize that lang/clang(33/34/35) is the default toolchain for 10+, and that's just fine by me. So I shouldn't be terribly surprised when install kernel/world, followed by make delete-old removes the clang built, or provided by the base install from the (initial) install procedure. But what _does_ surprise me, is that the install of lang/gcc-48 does _not_ become the compiler of choice with the above $ENV, after [seemingly] deleting clang. It does not work that way. If you configure the base system to use gcc only, individual ports can decide that they need newer C++ support, or other features not available in the version of gcc in base (which is very old by now). In that case, they will use one of the gcc ports, or possibly even one of the clang ports. Ahh. Thank you. It's now perfectly clear, and makes complete sense, now. For the record; I have nothing against clang/llvm, per se. I am just looking to obtain a bit more control over my environment. As this installation is intended for development purposes. In fact, I'll probably install all 3 versions of lang/clang. :) Oh, and GNC C, as well. Thank you again, for the reply. Now that I have also been informed about freebsd-toolchain@. I should probably take this opportunity to apologize for the noise, and thank all for their thoughtful replies. :) --Chris -Dimitry ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Fri, 7 Nov 2014 09:08:28 + Bartek Rutkowski ro...@freebsd.org wrote On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, tijl@ spotted an interesting point, distinfo and pkg-descr files files convenient are taking a lot of space for free, we can reduce the size of the while ports tree by a factor 2 by simply merging them into one of the other files (Makefile and/or pkg-plist) from my testing it really devides significantly the size of the tree. Problem is how to merge them if we want to. What we do not want to loose: - Easyness of parsing distinfo - Easyness to get informations about the description so far I have not been able to figure out a user friendly way Ideas I got so far only concerns pkg-descr: Adding an entry in the Makefile for the WWW: WWW= bla or an entry in the plist: @www http... for the description the Makefile is not suitable as multi line entry in Makefiles are painful Maybe a new keyword: @descr EOD mydesc in multiline EOD which could easily be added to the plist parser in pkg. But I'm do not find that very friendly in particular for make(1) to extract the data. Concerning the distinfo I have no idea. so this mail is a call of ideas :), if nothing nice ideas is found we will just do nothing here :) regards, Bapt At first I liked the idea, since I was wondering on my own if pkg-descr and distinfo couldnt be simply part of the Makefile. In vast majority of cases that would look good and wouldnt introduce too much content into existing Makefiles. There are ports like www/nginx or www/tengine that have enourmous distinfo files with number of entries that would ruin readability of their Makefiles, but so far I havent seen too many of these so I suppose they'd be the liveable drawbacks of new approach. However, after reading this discussion and some more tinkering about the idea I changed my mind - if the goal of current pkgports activities is to make the pkg the default way of installing packages and 'deprecate' ports when that happens, Aak! Seriously?! Eliminate ports? I _sincerely_ hope that isn't the intended result of the introduction of pkg(8). That would be a _horrible_ decision. For more reasons than I can list in a mailing list reply. Honestly. If this is true, has any real thought gone into the potential consequences resulting from this? We're not just talking about the affects on geeks, and hobbyists here. We're talking about Shops, and Businesses that create specific products, for specific needs, and chose *BSD for what at least _was_ the freedom, and amount of _choices_ it offered. Making it, by comparison, more _flexible_ than it's alternatives. You'll effectively eliminate that market, traveling in the direction you appear to be going. If what I understand you to be saying is true. It appears FreeBSD is simply looking to parrot Linux, and relinquish The power to serve. In exchange for competing for a strictly Desktop market. If true. This will mark a very dark year in history, for FreeBSD. Sincerely, Disappointed. then the amount of work and the risk of breaking things by doing this ports improvement outweights its benefits. At this point I'd much rather like us to concentrate on making pkg a perfect replacement (I am mostly thinking about being able to package base for stripped down FreeBSD builds and pkg 'flavours' that would allow me install packages with custom options, like ports) and hold off making any changes to ports until we can safely state that 'pkg is the way to go for 99% of FreeBSD users and ports are for that 1% of package builders, nerds, tinkerers' etc., unless we simply cant move forward without some change. And just to be sure, I am not against improving ports, but rather about making better choice of where to put our limited resources - I am supper happy to get back to this discussion once we can replace ports with pkg :) Kind regards, Bartek Rutkowski ___ 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
Re: What is xmmintrin.h, and why aren't ports finding it?
On Fri, 7 Nov 2014 13:10:51 +0100 Dimitry Andric d...@freebsd.org wrote On 07 Nov 2014, at 04:36, Chris H bsd-li...@bsdforge.com wrote: Greetings, Working on a recent 11-CURRENT install (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014) svn info /usr/ports Revision: 372176 Given the above, and the fact that I have installed lang/gcc-48. Is there any reason that any port wanting to include xmmintrin.h fails to find it? Even though dmesg messages reflects the fact that gcc48 is included within my $PATH? What you have in your PATH does not matter. The xmmintrin.h header contains SSE intrinsics, and should automatically be found by your gcc 4.8 port. Normally it is located in: /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include/xmmintrin.h or if you have a slightly different gcc version, just run: find /usr/local/lib/gcc48 -name xmmintrin.h to find it. If you run: gcc48 -v -x c -c /dev/null -o /dev/null it should show you the paths it searches for include files (look for the #include ... search starts here: line). For example, on my system this shows: #include ... search starts here: /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include /usr/local/include /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include-fixed /usr/include End of search list. The directory where you found xmmintrin.h should be listed in the search directories. Thank you _very_ much for the reply, Dimitry. Indeed, following your example above. Indicates that xmmintrin.h _is_ in the search path. I think it must be a matter of _which_ CC USE_GCC is defaulting to. I'll have to examine things in that range, a little closer. Thank you again, for the informative reply, Dimitry. --Chris -Dimitry ___ 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
Re: Reducing the size of the ports tree (brainstorm v2)
On Fri, 7 Nov 2014 19:32:25 +0100 Bartek Rutkowski ro...@freebsd.org wrote On Fri, Nov 7, 2014 at 6:47 PM, Chris H bsd-li...@bsdforge.com wrote: On Fri, 7 Nov 2014 09:08:28 + Bartek Rutkowski ro...@freebsd.org wrote On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, tijl@ spotted an interesting point, distinfo and pkg-descr files files convenient are taking a lot of space for free, we can reduce the size of the while ports tree by a factor 2 by simply merging them into one of the other files (Makefile and/or pkg-plist) from my testing it really devides significantly the size of the tree. Problem is how to merge them if we want to. What we do not want to loose: - Easyness of parsing distinfo - Easyness to get informations about the description so far I have not been able to figure out a user friendly way Ideas I got so far only concerns pkg-descr: Adding an entry in the Makefile for the WWW: WWW= bla or an entry in the plist: @www http... for the description the Makefile is not suitable as multi line entry in Makefiles are painful Maybe a new keyword: @descr EOD mydesc in multiline EOD which could easily be added to the plist parser in pkg. But I'm do not find that very friendly in particular for make(1) to extract the data. Concerning the distinfo I have no idea. so this mail is a call of ideas :), if nothing nice ideas is found we will just do nothing here :) regards, Bapt At first I liked the idea, since I was wondering on my own if pkg-descr and distinfo couldnt be simply part of the Makefile. In vast majority of cases that would look good and wouldnt introduce too much content into existing Makefiles. There are ports like www/nginx or www/tengine that have enourmous distinfo files with number of entries that would ruin readability of their Makefiles, but so far I havent seen too many of these so I suppose they'd be the liveable drawbacks of new approach. However, after reading this discussion and some more tinkering about the idea I changed my mind - if the goal of current pkgports activities is to make the pkg the default way of installing packages and 'deprecate' ports when that happens, Aak! Seriously?! Eliminate ports? I _sincerely_ hope that isn't the intended result of the introduction of pkg(8). That would be a _horrible_ decision. For more reasons than I can list in a mailing list reply. Honestly. If this is true, has any real thought gone into the potential consequences resulting from this? We're not just talking about the affects on geeks, and hobbyists here. We're talking about Shops, and Businesses that create specific products, for specific needs, and chose *BSD for what at least _was_ the freedom, and amount of _choices_ it offered. Making it, by comparison, more _flexible_ than it's alternatives. You'll effectively eliminate that market, traveling in the direction you appear to be going. If what I understand you to be saying is true. It appears FreeBSD is simply looking to parrot Linux, and relinquish The power to serve. In exchange for competing for a strictly Desktop market. If true. This will mark a very dark year in history, for FreeBSD. Sincerely, Disappointed. Thank you for the reply, and clarification, Bartek. I think we've a little misunderstanding here. At no point I've said nor heard that ports are about to be eliminated. I did hovewer heard that the goal is to deprecate them, as in, encourage users to move to pkg entirely, once pkg is a viable ports replacement, and to make that a default way to install/maintain software on FreeBSD. At the end, it would be very hard to 'eliminate' ports, since we still have to generate the packages with something, dont we? ;) One wouldn't think so. But I've been surprised before. :) Even said that, I could be completely wrong here, misunderstood someone else and so on, and by no means this discussion is a statement of what is going on to happen with ports/pkg oficially, so, to quote D. Adams: DON'T PANIC. :) Well. So could I. Hopefully I am. :) Thanks again, for the thoughtful reply, Bartek. --Chris Kind regards, Bartek Rutkowski then the amount of work and the risk of breaking things by doing this ports improvement outweights its benefits. At this point I'd much rather like us to concentrate on making pkg a perfect replacement (I am mostly thinking about being able to package base for stripped down FreeBSD builds and pkg 'flavours' that would allow me install packages with custom options, like ports) and hold off making any changes to ports until we can safely state that 'pkg is the way to go for 99% of FreeBSD users and ports are for that 1% of package builders, nerds, tinkerers' etc., unless we simply cant move forward without some change. And just to be sure, I am
How exactly does the base toolchain determine WHICH language to build with?
Greetings, Sorry for the long title. I've been [needlessly] struggling with getting ports within the ports tree to build, on a fresh 11-CURRENT install from 2014-11-05. With custom KERNEL and WORLD built, and installed. Here's my situation, which has worked well since ~8.2; make.conf(5) WITHOUT_CLANG=true FAVORITE_COMPILER=gcc src.conf(5) WITHOUT_CLANG=true I'll neither argue, nor defend rational for w/o clang. To boring and out of scope for this thread. That said; I realize that lang/clang(33/34/35) is the default toolchain for 10+, and that's just fine by me. So I shouldn't be terribly surprised when install kernel/world, followed by make delete-old removes the clang built, or provided by the base install from the (initial) install procedure. But what _does_ surprise me, is that the install of lang/gcc-48 does _not_ become the compiler of choice with the above $ENV, after [seemingly] deleting clang. I understand that it may not be advisable to eliminate the default [base] toolchain. But leaving only remnants of clang, causes quite a bit of what I would consider POLA. Given that clang's bin files are [still] located in /usr/bin, while additional compilers are located in /usr/local/bin. All past installs -- even an older 11, did not exhibit this problem. What's changed? What's the rational, and how to best setup an effective build $ENV under the current circumstances? Or is this simply an [unintended] anomaly? Currently, the only way I can envision overcoming this, is by way of make.conf(5). Using the CC, CXX, and CPP directives. Which IMHO is not ideal. Thank you for all your time, and consideration, and sorry for the somewhat longish post. --Chris ___ 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: How exactly does the base toolchain determine WHICH language to build with?
On Fri, 7 Nov 2014 22:39:27 -0600 Scot Hetzel swhet...@gmail.com wrote
On Fri, Nov 7, 2014 at 6:23 PM, Chris H bsd-li...@bsdforge.com wrote:
Greetings,
Sorry for the long title. I've been [needlessly] struggling
with getting ports within the ports tree to build, on a
fresh 11-CURRENT install from 2014-11-05. With custom
KERNEL and WORLD built, and installed.
Here's my situation, which has worked well since ~8.2;
make.conf(5)
WITHOUT_CLANG=true
FAVORITE_COMPILER=gcc
src.conf(5)
WITHOUT_CLANG=true
I'll neither argue, nor defend rational for w/o clang. To
boring and out of scope for this thread. That said; I
realize that lang/clang(33/34/35) is the default toolchain
for 10+, and that's just fine by me. So I shouldn't be
lang/clang(33/34/35) is not the default toolchain in 10+. 10+ uses a
version of clang that is included in the FreeBSD source (/usr/src).
terribly surprised when install kernel/world, followed by
make delete-old removes the clang built, or provided by
the base install from the (initial) install procedure. But
what _does_ surprise me, is that the install of lang/gcc-48
does _not_ become the compiler of choice with the above
$ENV, after [seemingly] deleting clang. I understand that
FAVORITE_COMPILER is used by Mk/Uses/compiler.mk.
If you want ports to build with lang/gcc-48, then you would need to
check that the ports you are trying to compile have either
USES=compiler or USES_GCC defined in their Makefile. Otherwise the
ports will use the compiler that is provided by the FreeBSD source
(gcc 2.4.x or clang).
When WITHOUT_CLANG is defined in make.conf/src.conf. The FreeBSD
source will be built using gcc 2.4.x from the FreeBSD source.
/usr/bin/{cc,c++} will then be linked to the gcc versions. The ports
will then use this version to build if there is no USES_GCC or
USES=compiler in the ports Makefile.
Perfect, and thank you very much, Scott, for the clarification.
For what ever reason. Mine (CC,cc++,...) are linked to what's left
of clang. I guess I'll need to try and dig deeper, and see if I can
discover, why, and what happened.
Just for the record. Re-reading my comment above, I realize that
my statement regarding clang, might be interpreted as my having
negative feelings about clang/llvm. For clarity, that is not the
case. This install is targeted at development. As such, I want
more granular control of what I build, and test with. So I'll
actually be installing every version of lang/clang, and testing
accordingly.
Thank you again, Scott, for taking the time to respond.
--Chris
--
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
___
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
What is xmmintrin.h, and why aren't ports finding it?
Greetings, Working on a recent 11-CURRENT install (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014) svn info /usr/ports Revision: 372176 Given the above, and the fact that I have installed lang/gcc-48. Is there any reason that any port wanting to include xmmintrin.h fails to find it? Even though dmesg messages reflects the fact that gcc48 is included within my $PATH? This is causing me no end of grief, and try as I might, I can't seem to get past this problem. Thank you for all your time, and consideration. --Chris ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Thu, 06 Nov 2014 22:26:07 -0600 Mark Felder f...@freebsd.org wrote On Thu, Nov 6, 2014, at 03:24, Anton Shterenlikht wrote: I'm not sure what you mean here. I've systems where I install 99% of packages from official repo servers, and then rebuild 1% from ports where the default options are no good for me. Is this not supported? Or do you mean something else? You're treading dangerous ground unless you can be sure your ports tree svn checkout matches the checkout that was used to build the public packages. An example would be a situation where there was a library bump and your ports and packages don't match and now you have some binaries which don't work. If you have problems and you are using ports and packages mixed you will not find much sympathy in my experience. Bapt has mentioned a desire for tracking packages built from ports and making this much easier to support by having pkg upgrade detect the need to rebuild the port with your custom options and automatically updating the ports tree and building. This would be a supported process. I think this sounds like a fantastic way to solve this problem for the masses. Doesn't pkg(8) already provide the means to tell you what packages depend on what? I try to avoid pkg(8) as much as possible. But I'm quite sure I was able to ascertain what belonged to what. Last time I had the need, and looked up the incantation, in the man pages. I also find that many choose the route of mixing ports, and packages, and do it w/o incident. Including myself. I rarely choose packages. But if I'm really pressed, and a port build fails w/o foreseeable remedy. I might take the shortcut, and install a package. Marking it as needs to be replaced by the port version. This has worked nearly w/o incident. So I find it fairly odd to hear so much hubub about mixing ports, and packages. Anyone who keeps reasonable inventory of their system, will keep things in sync. If their careless to do otherwise. Mixing ports, and packages are likely one of the least of their troubles. :) All the best. --Chris ___ 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
Re: Reducing the size of the ports tree (brainstorm v2)
On Wed, 05 Nov 2014 07:26:01 -0500 Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org wrote Chris H bsd-li...@bsdforge.com writes: Difficult to tell for sure. I haven't examined the [UFS/ZFS] source to know for sure. Be valuable info. :) Reading source not required: start with man newfs; note blocksize and frag-size. Indeed; -b .. The default size is 32768 bytes, and the smallest allowable size is 4096 bytes. .. Which only raises another question in my mind. I've got an old 40G pata I use for utilitarian duties. It has a hardware limit of 512b. Does FreeBSD then re-calculate to ensure the =4k block size via CHS? Or does it remain unchanged? BTW the only point with this, was it all seemed quite simple to compensate, or cater to a mass of small files, and as such, seemed like a trivial nit. I just seemed like there were bigger fish to fry. :) Thanks for the reply. --Chris ___ 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
Re: updating x11/xbindkeys for newer Tcl/Tk
On Wed, 5 Nov 2014 22:34:18 + (UTC) Will Parsons varro@nodomain.invalid wrote When I went to build xbindkeys with Tcl support, I noticed it was trying to install Tcl8.4, which is quite old. Since I already have Tcl 8.5 and Tcl 8.6 installed, installing Tcl8.4 seemed to be a waste. I edited the Makefile to replace references to 8.4 with 8.5, and it seems to build correctly with the later Tcl, but it would seem be good to have the official port updated. Seeing how the maintainer is po...@freebsd.org (which I gather means it has no maintainer), is submitting a PR likely to get this fixed, or does it need an official maintainer first? A pr(1) would be an excellent idea. You are not required to become the maintainer to submit the pr, get results from sending a pr, or creating a patch(1)/svn diff(1) for a committer to commit. :) HTH --Chris -- Will ___ 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
Re: Reducing the size of the ports tree (brainstorm v2)
On Mon, 3 Nov 2014 21:24:38 +0100 Tijl Coosemans t...@freebsd.org wrote On Mon, 03 Nov 2014 09:22:09 +0100 Matthias Andree matthias.and...@gmx.de wrote: Am 31.10.2014 um 19:56 schrieb Baptiste Daroussin: Hi all, tijl@ spotted an interesting point, distinfo and pkg-descr files files convenient are taking a lot of space for free, we can reduce the size of the while ports tree by a factor 2 by simply merging them into one of the other files (Makefile and/or pkg-plist) from my testing it really devides significantly the size of the tree. Problem is how to merge them if we want to. What we do not want to loose: - Easyness of parsing distinfo - Easyness to get informations about the description so far I have not been able to figure out a user friendly way Ideas I got so far only concerns pkg-descr: Adding an entry in the Makefile for the WWW: WWW= bla or an entry in the plist: @www http... for the description the Makefile is not suitable as multi line entry in Makefiles are painful Maybe a new keyword: @descr EOD mydesc in multiline EOD which could easily be added to the plist parser in pkg. But I'm do not find that very friendly in particular for make(1) to extract the data. Concerning the distinfo I have no idea. so this mail is a call of ideas :), if nothing nice ideas is found we will just do nothing here :) My urgent recommendation is to leave it as is. Even if it wastes 200 MB. Space is so cheap these days it's not worth introducing new instabilities, re-train all contributors and all that. We haven't even shaken off all the staging and pkg fall-out, and now we're talking about the next revolution. The numbers on http://beefy1.isc.freebsd.org/ and http://beefy2.isc.freebsd.org/ have never been better. And if we really decided that we want to change things, we would need these things BEFORE the implementation: 1. a clear list of the problems. 1a. Space does not count, see above. 1b. Insufficient tools (SVN) do not count. If the tools are bad, we need other tools, not change our way of doing things. Other tools won't change anything. It's the file system that would have to change which is not going to happen. gpart(8) -a gives you what you need. If it's truly as bad as all that, mounting the ports tree on a 512k aligned slice will reduce the slack you appear to be referring to. zfs(8) also has this ability. When the ports tree was created disks were much smaller and file systems were better (still not good) at storing small files. Today disks are much bigger and file systems have adapted to that. Now it's time for the ports tree to adapt. Here's another way to look at it. Suppose that distinfo never existed and we always specified file sizes and checksums in the Makefile. Then someone would come along and suggest to do just that, put file sizes and checksums in a separate file named distinfo. Nobody would support that. IMHO sorting out all the pkg(8) issues still at large, would be more prudent use of time, and resources. Just saying. --Chris ___ 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
Re: Reducing the size of the ports tree (brainstorm v2)
On Tue, 04 Nov 2014 13:21:31 -0800 Chris H bsd-li...@bsdforge.com wrote On Mon, 3 Nov 2014 21:24:38 +0100 Tijl Coosemans t...@freebsd.org wrote On Mon, 03 Nov 2014 09:22:09 +0100 Matthias Andree matthias.and...@gmx.de wrote: Am 31.10.2014 um 19:56 schrieb Baptiste Daroussin: Hi all, tijl@ spotted an interesting point, distinfo and pkg-descr files files convenient are taking a lot of space for free, we can reduce the size of the while ports tree by a factor 2 by simply merging them into one of the other files (Makefile and/or pkg-plist) from my testing it really devides significantly the size of the tree. Problem is how to merge them if we want to. What we do not want to loose: - Easyness of parsing distinfo - Easyness to get informations about the description so far I have not been able to figure out a user friendly way Ideas I got so far only concerns pkg-descr: Adding an entry in the Makefile for the WWW: WWW= bla or an entry in the plist: @www http... for the description the Makefile is not suitable as multi line entry in Makefiles are painful Maybe a new keyword: @descr EOD mydesc in multiline EOD which could easily be added to the plist parser in pkg. But I'm do not find that very friendly in particular for make(1) to extract the data. Concerning the distinfo I have no idea. so this mail is a call of ideas :), if nothing nice ideas is found we will just do nothing here :) My urgent recommendation is to leave it as is. Even if it wastes 200 MB. Space is so cheap these days it's not worth introducing new instabilities, re-train all contributors and all that. We haven't even shaken off all the staging and pkg fall-out, and now we're talking about the next revolution. The numbers on http://beefy1.isc.freebsd.org/ and http://beefy2.isc.freebsd.org/ have never been better. And if we really decided that we want to change things, we would need these things BEFORE the implementation: 1. a clear list of the problems. 1a. Space does not count, see above. 1b. Insufficient tools (SVN) do not count. If the tools are bad, we need other tools, not change our way of doing things. Other tools won't change anything. It's the file system that would have to change which is not going to happen. gpart(8) -a gives you what you need. If it's truly as bad as all that, mounting the ports tree on a 512k aligned slice will reduce the slack ahem... that was s/512k/512b/g :P you appear to be referring to. zfs(8) also has this ability. When the ports tree was created disks were much smaller and file systems were better (still not good) at storing small files. Today disks are much bigger and file systems have adapted to that. Now it's time for the ports tree to adapt. Here's another way to look at it. Suppose that distinfo never existed and we always specified file sizes and checksums in the Makefile. Then someone would come along and suggest to do just that, put file sizes and checksums in a separate file named distinfo. Nobody would support that. IMHO sorting out all the pkg(8) issues still at large, would be more prudent use of time, and resources. Just saying. --Chris ___ 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 ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Tue, 4 Nov 2014 16:16:09 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Tue, 4 Nov 2014, Chris H wrote: gpart(8) -a gives you what you need. If it's truly as bad as all that, mounting the ports tree on a 512k aligned slice will reduce the slack you appear to be referring to. zfs(8) also has this ability. Not alignment, but filesystem block size. But that can only be set for an entire filesystem, and it's a tradeoff. Quite true. Which was meant to be my point. Meaning that the ports tree could then be mounted where ever was deemed convenient, and wouldn't carry the slack it does on a 4k boundary. Maybe even on a removable SSD? --Chris ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Tue, 4 Nov 2014 20:29:44 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Tue, 4 Nov 2014, Chris H wrote: On Tue, 4 Nov 2014 16:16:09 -0700 (MST) Warren Block wbl...@wonkity.com wrote On Tue, 4 Nov 2014, Chris H wrote: gpart(8) -a gives you what you need. If it's truly as bad as all that, mounting the ports tree on a 512k aligned slice will reduce the slack you appear to be referring to. zfs(8) also has this ability. Not alignment, but filesystem block size. But that can only be set for an entire filesystem, and it's a tradeoff. Quite true. Which was meant to be my point. Meaning that the ports tree could then be mounted where ever was deemed convenient, and wouldn't carry the slack it does on a 4k boundary. Maybe even on a removable SSD? I thought that block suballocation was a thing on most modern filesystems. There would still be an extra seek or several to locate the small sub-blocks inside a full block, but it should make space usage with small files more efficient. But I don't know what either UFS or ZFS does for that. Difficult to tell for sure. I haven't examined the [UFS/ZFS] source to know for sure. Be valuable info. :) OTOH I only mentioned utilizing a smaller boundary, as I felt it was a reasonable solution related to size issue mentioned. I have just about enough spares laying about, to do some comparison/ benchmarking on UFS v ZFS v 4k v 512b. If I get a chance this week. I'm going to give it a go, and see if I can extrapolate useful data. --Chris ___ 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: www/dansguardian revival?
On Fri, 31 Oct 2014 16:55:47 -0700 Nick Rogers ncrog...@gmail.com wrote
On Tue, Oct 21, 2014 at 6:29 PM, Chris H bsd-li...@bsdforge.com wrote:
On Tue, 21 Oct 2014 09:39:30 +0200 Marko Cupać marko.cu...@mimar.rs
wrote
On Mon, 20 Oct 2014 17:47:19 -0700
Chris H bsd-li...@bsdforge.com wrote:
Unless theirs any objection. I'll take it. I'll open a pr(1)
with a shar(1) ready, in about an hour.
--Chris
Nice to hear that dansguardian will be back in ports. I also used it
for years in combination with www/squid33 without problem. I was
compiling it from ports, and the trick was to compile squid33 first,
and dansguardian only after, as dansguardian would only check existence
of /use/local/bin/squid, and if it was already there, no matter which
version, it would happily compile, install and work.
Right. But there's ${STAGE} to deal with, as well. I may
make sqid34 the DEPENDS (I'm still testing).
I'm also working with the -devel version, and will likely
convert it to the (un)devel version, as there is less user
overhead involved -- RESTRICTED/COPYRIGHT/LICENSE/{...}
Should be able to post a complete version, sometime
tomorrow.
Hey Chris. Any luck getting your new dansguardian port to work? I can't
find a PR for it. Just wondering if theres anything I can do to help test
or if it would be worth my while to just submit a PR with the last-known
www/dansguardian for the time being. Thanks.
-Nick
Sorry for the delay, and thank you for your generous offer, Nick.
There were some issues with www/squid(34), and decided to wait
to see if they would be addressed soonish. I see that there was
a [partial] resolution just submitted. I'll see if they made it
into the ports tree. If so, I'll see where things are with
regard to their (e|a)ffect on www/dansguardian. If there's still
issues, I'll take you up on your generous offer. :)
FWIW I run my dev box on 11 (CURRENT).
Thanks, again.
--Chris
--Chris
--
Marko Cupać
https://www.mimar.rs
___
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
___
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
Re: RE: reducing the size of the ports tree
On Sat, 1 Nov 2014 03:32:16 -0700 Jeffrey Bouquet via freebsd-ports freebsd-ports@freebsd.org wrote Not initially welcoming this new effort... explanation and other PKG problems taking precedence... I've a few scripts which use the smaller files, and have used them extensively in pipes. Syntax within the Makefile would make those counterintuitive.I would wonder also if it would break port infrastructure like the Mk and Tools and make search and portsearch (etc -- ports )... essentially breaking more things than would be solved. Indeed, I've many ideas for MORE small files for people crafting shell scripts that would be of more use down the road, and incorporated someday into additional port tools, portmasters, portupgrades, etc... So as far as this particular suggestion, maybe if someone wants it bad enough one should build a prototype and test locally several years with many ports and upgrades to determine what it breaks... and how to write new tools. But I conjecture that effort would be better spent with PR backlogs, fixing pkg2ng (which fails here on one machine ) etc... and making pkg more robust... (complete recovery if the database is hosed, with a something local_sqlite_hosed_reuild_sh.sh etc etc And the documentation. Many many more examples of everyday usage over the course of a year and UPDATING scenarious would be appreciated... and also streamlining pkg so it works better on low power machines with many ports installed. Including less segfaults... As an aside, I am now on a machine which never had the problem before, after a failed pkg2ng conversion, A... pkg install -f nettle wants to install csound! what file is telling it that? The database ??? ... and seven others I had just deinstalled B... make install ( proceeds with Child process terminated abnomally... segmentation fault) before the install. Not known if anything was running beforehand. Not problems with the install. But it keeps occuring... What process? Something in the background wanting that nettle csound dependency? Pkg working before the make command? Part of the make command infrastructure now more buggy? Thankfully that machine is not the primary one here, and all the programs installed still work on it as far as I know. But its registration data is not exact and pkg-devel as installed on it could be debugged more... as well as pkg2ng retested to work on v9 more precisely... It failed three times to convert that machine. (not installed unless desinstalling direct from the port, so could not upgrade.. or pkg info the port) I feel inclined to add a me too here. If nothing else, the proposal seems to violate POLA (not unlike pkg(8) did). Mind you, I _do_ recognize the advantages that pkg(8) brought. But [as yet] am not convinced it was (quite) time to make it _replace_ pkg(7). That said, and more to the point of this thread. I too believe it will introduce many issues for the toolsets users have built, and maintained against the current ports structure. As mentioned already; it will also _break_ many tools/utilities already available in the ports tree now. What to do then? Abandon/remove them? The requirement for sqlite3(1) that pkg(8) introduced was a poor decision IMHO. It introduces a single-point-of-failure that is generally considered bad practice for critical software. If something goes wrong with the database, you're up a creek, even with a backup. The introduction also broke many toolchains previously built against the largely text-based record keeping of pkg(7). Imagine if the DNS only required a single NS. What happens if that NS becomes unreachable? So it is for the sqlite3(1) requirement. What if you're an average user? You will likely have little knowledge of SQL syntax, and it will not be very helpful to them, if they need information about their ports install(s), or to manipulate things. While I've probably commented beyond the initial scope of this threads [intended] context. I think the other points I've made, also speak to the reasons I don't feel further modifications of the ports infrastructure would be welcomed, or advantageous. In this way, or at this time. Thank you for all your time, and consideration. --Chris ___ 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
Re: why is 'make' installing?
On Sun, 2 Nov 2014 08:35:33 -0800 Waitman Gobble uzi...@da3m0n8t3r.com wrote Issue, help appreciated. Missed day two of MeetBSD sorry alot going on today. Day one was great. I'm updating a port and noticed that 'make' is actually calling install in my program Makefile. seems strange. It's not registering the port as installed but the compiled binary is going into /usr/local/bin ie: ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make === License GPLv2 accepted by the user === Found saved configuration for dcraw-m-9.22 === dcraw-m-9.22 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by dcraw-m-9.22 for building === Extracting for dcraw-m-9.22 = SHA256 Checksum OK for dcraw-m-9.22.tar.gz. === Patching for dcraw-m-9.22 === dcraw-m-9.22 depends on shared library: libjasper.so - found (/usr/local/lib/libjasper.so.4.0.0) === dcraw-m-9.22 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) === dcraw-m-9.22 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) === dcraw-m-9.22 depends on shared library: libMagickWand-6.Q16.so - found (/usr/local/lib/libMagickWand-6.Q16.so.2.0.0) === Configuring for dcraw-m-9.22 === Building for dcraw-m-9.22 === Staging for dcraw-m-9.22 === Generating temporary packing list install -m 0755 -g wheel -o root dcraw-m /usr/local/bin Compressing man pages (compress-man) Running Q/A tests (stage-qa) ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m AFAIK a port 'make' should not actually call install in the Makefile. ? rm /usr/local/bin/dcraw-m cd work/waitman-dcraw-m-1b90326/ make clean make cc -O2 -pipe -Wall -Werror -I/usr/local/include 'MagickWand-config --cflags --cppflags' -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -DNO_JASPER -L/usr/local/lib 'MagickWand-config --ldflags --libs' -lm -llcms2 -ljpeg -o dcraw-m dcraw-m.c ls /usr/local/bin/dcraw-m ls: /usr/local/bin/dcraw-m: No such file or directory make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin ls /usr/local/bin/dcraw-m /usr/local/bin/dcraw-m hmmm why is 'make' on the port Makefile calling install? Because you asserted make install? make install install -m 0755 -g wheel -o root dcraw-m /usr/local/bin That's all I can gather from the limited output you provided. :) --Chris uname -a FreeBSD dx.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2: Mon Oct 27 18:47:44 PDT 2014 r...@dx.waitman.net:/usr/obj/usr/src/sys/AMINEH amd64 Thank you, -- Waitman Gobble Los Altos California USA +1.510-830-7975 ___ 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
Re: www/dansguardian revival?
On Tue, 21 Oct 2014 09:39:30 +0200 Marko Cupać marko.cu...@mimar.rs wrote
On Mon, 20 Oct 2014 17:47:19 -0700
Chris H bsd-li...@bsdforge.com wrote:
Unless theirs any objection. I'll take it. I'll open a pr(1)
with a shar(1) ready, in about an hour.
--Chris
Nice to hear that dansguardian will be back in ports. I also used it
for years in combination with www/squid33 without problem. I was
compiling it from ports, and the trick was to compile squid33 first,
and dansguardian only after, as dansguardian would only check existence
of /use/local/bin/squid, and if it was already there, no matter which
version, it would happily compile, install and work.
Right. But there's ${STAGE} to deal with, as well. I may
make sqid34 the DEPENDS (I'm still testing).
I'm also working with the -devel version, and will likely
convert it to the (un)devel version, as there is less user
overhead involved -- RESTRICTED/COPYRIGHT/LICENSE/{...}
Should be able to post a complete version, sometime
tomorrow.
--Chris
--
Marko Cupać
https://www.mimar.rs
___
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
Re: www/dansguardian revival?
On Mon, 20 Oct 2014 16:08:43 -0700 Nick Rogers ncrog...@gmail.com wrote Hello, I recently learned that the www/dansguardian port was deprecated due to its dependency on the old www/squid port (squid 2.7). Is there any way this port can be revived? I've been using it for years with great success against newer versions of squid (3.3, 3.4). Usually I would just change the RUN_DEPENDS to look for squid33 or squid34. The squid dependency could arguably be removed entirely because all dansguardian does is proxy www traffic to squid - it doesn't really matter what version it is and the application itself does not require the squid port to run. Point being, the port works just fine as is (was). In fact, it would work in its last-known state correctly now that squid34 is simply www/squid. I realize the maintainer has not updated the port in a while, but I've been using dansguardian with FreeBSD for nearly the last decade and it is unfortunate to see it removed as a port simply because the previous state of the squid ports was undesirable. It would be great if this could be added back. Clearly I am not the only one still using it. I've CC'd the current dansguardian source code maintainer and author in hopes they can assist and find a new maintainer for the FreeBSD port. Thanks. -Nick Unless theirs any objection. I'll take it. I'll open a pr(1) with a shar(1) ready, in about an hour. --Chris ___ 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
Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
Hi, As you may know, the ports tree currently provides two versions of the X.Org server and related pieces of software: 1. xserver 1.7, Mesa 7.6 and libdrm 2.4.17 2. xserver 1.12, Mesa 9.1 and libdrm 2.4.52 We are about to remove the older set. The primary reason is the maintenance cost. The Graphics team is small and it's a nightmare to test changes. The consequence is infrequent updates to those packages and, of course, way more work each time we decide to jump to a later version. All this time spent on keeping the legacy stack in a working state isn't invested on improving the current one and today's hardware support. The recent update to Cairo is a good example of this unsustainable situation: we tested what we could with the time we had and we sent a Call for testers on freebsd-x11@ and freebsd-current@ mailing-lists as well as asking for help on several Quarterly Status Reports. The benefit (if not the requirement) of the update and the lack of failure reports were instrumental in the final decision. Unfortunately, many users of the old X.Org server on Intel GPUs are now having crashes with any Gtk+ applications or the X.Org server itself. This time, we won't revert anything or spend more time on trying to fix the old stack. Now, what does it change for the community? What are the benefits of this solution? 1. No more headache with WITH_NEW_XORG, alternate pkg(8) repository, mismatching ABI versions between xf86-input-* and xserver. 2. More frequent and independant updates (ie. no need to update the whole stack in one pass). 3. KDE and, in the near future, GNOME 3 available as packages in the main repository and on install medias. Great, but what does it break? The only regression is for users of Intel GPUs and FreeBSD 8.x and 9.0. Those versions of FreeBSD lack the required kernel driver and therefore xf86-video-intel won't work (the last UMS-aware version doesn't work with xserver 1.12). Users can still use xf86-video-vesa if they can't/don't want to update their FreeBSD workstation. To install xf86-video-vesa, run: pkg install xf86-video-vesa or portmaster x11-drivers/xf86-video-vesa There won't be any regression for owners of Radeon GPUs because xf86-video-ati 6.14.6 (the last one with UMS support, which fortunately works with xserver 1.12) is provided as a separate port. To install this UMS driver: pkg install xf86-video-ati-ums or portmaster x11-drivers/xf86-video-ati-ums In the longer term, we suggest you update to FreeBSD 10.x (10.1-RELEASE is around the corner). For example, you can find instructions to update to 10.0-RELEASE here: https://www.freebsd.org/releases/10.0R/installation.html Note that there's a know regression with syscons and kernel video drivers: you can't switch back to a console once an X.Org session is started. A new console driver called vt(4) fixes this issue while bringing nice features. It's available in FreeBSD 9.3-RELEASE and 10.1-RELEASE but isn't enabled by default. To enable it, put the following line in your /boot/loader.conf: kern.vty=vt Ugh. We've just spent the last 4 mos. tooling up for a migration of all our server farms from RELENG_8 -- RELENG 9. It would have only taken 1 mos. but for pkg(8) debacle. Now, if I understand correctly. The current release schedule has effectively become: RELENG_8.4: June 30, 2015 === October 8, 2014 RELENG_9: December 31, 2016 === October 8, 2014 :( FWIW I'm looking forward to the NEW_XORG. But testing 11-CURRENT indicates vt(4) isn't ready for prime time. Which makes it difficult to justify it's requirement in RELENG. Sincerely, disappointed. Note official packages reflecting this sitation will start building on Wednesday 8th of October and hit your mirrors as soon as possible for both quarterly branch and regular head. regards, Bapt on behalf on the X11 team ___ 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: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
On Fri, Oct 03, 2014 at 07:47:23AM -0700, Chris H wrote: Hi, As you may know, the ports tree currently provides two versions of the X.Org server and related pieces of software: 1. xserver 1.7, Mesa 7.6 and libdrm 2.4.17 2. xserver 1.12, Mesa 9.1 and libdrm 2.4.52 We are about to remove the older set. The primary reason is the maintenance cost. The Graphics team is small and it's a nightmare to test changes. The consequence is infrequent updates to those packages and, of course, way more work each time we decide to jump to a later version. All this time spent on keeping the legacy stack in a working state isn't invested on improving the current one and today's hardware support. The recent update to Cairo is a good example of this unsustainable situation: we tested what we could with the time we had and we sent a Call for testers on freebsd-x11@ and freebsd-current@ mailing-lists as well as asking for help on several Quarterly Status Reports. The benefit (if not the requirement) of the update and the lack of failure reports were instrumental in the final decision. Unfortunately, many users of the old X.Org server on Intel GPUs are now having crashes with any Gtk+ applications or the X.Org server itself. This time, we won't revert anything or spend more time on trying to fix the old stack. Now, what does it change for the community? What are the benefits of this solution? 1. No more headache with WITH_NEW_XORG, alternate pkg(8) repository, mismatching ABI versions between xf86-input-* and xserver. 2. More frequent and independant updates (ie. no need to update the whole stack in one pass). 3. KDE and, in the near future, GNOME 3 available as packages in the main repository and on install medias. Great, but what does it break? The only regression is for users of Intel GPUs and FreeBSD 8.x and 9.0. Those versions of FreeBSD lack the required kernel driver and therefore xf86-video-intel won't work (the last UMS-aware version doesn't work with xserver 1.12). Users can still use xf86-video-vesa if they can't/don't want to update their FreeBSD workstation. To install xf86-video-vesa, run: pkg install xf86-video-vesa or portmaster x11-drivers/xf86-video-vesa There won't be any regression for owners of Radeon GPUs because xf86-video-ati 6.14.6 (the last one with UMS support, which fortunately works with xserver 1.12) is provided as a separate port. To install this UMS driver: pkg install xf86-video-ati-ums or portmaster x11-drivers/xf86-video-ati-ums In the longer term, we suggest you update to FreeBSD 10.x (10.1-RELEASE is around the corner). For example, you can find instructions to update to 10.0-RELEASE here: https://www.freebsd.org/releases/10.0R/installation.html Note that there's a know regression with syscons and kernel video drivers: you can't switch back to a console once an X.Org session is started. A new console driver called vt(4) fixes this issue while bringing nice features. It's available in FreeBSD 9.3-RELEASE and 10.1-RELEASE but isn't enabled by default. To enable it, put the following line in your /boot/loader.conf: kern.vty=vt Ugh. We've just spent the last 4 mos. tooling up for a migration of all our server farms from RELENG_8 -- RELENG 9. It would have only taken 1 mos. but for pkg(8) debacle. Now, if I understand correctly. The current release schedule has effectively become: RELENG_8.4: June 30, 2015 === October 8, 2014 RELENG_9: December 31, 2016 === October 8, 2014 :( FWIW I'm looking forward to the NEW_XORG. But testing 11-CURRENT indicates vt(4) isn't ready for prime time. Which makes it difficult to justify it's requirement in RELENG. Sincerely, disappointed. No 8 is still supported and 9 as well, what you miss is that in any case the graphic stack with old xorg on Intel it anyway broken right now, X server or gtk application segfaulting all the time. meaning that xorg 1.12 and xorg 1.7 makes pretty much no differences on intel on FreeBSD 8 and FreeBSD 9. For all other drivers xorg 1.12 works pretty well on FreeBSD 8 and FreeBSD 9 as long as you do use the ums driver for ATI, nvidia work normally, vesa as well. No changes here, with the previous, you do not need kms neither vt. Thank you _very_ much for the clarification, Baptiste. If I understand [you] correctly; I will be able to use the NEW Xorg in RELENG_9, and that [effectively] only the Intel drivers are affected? en re vt(4); I am experiencing issues with vt(4). I'm testing on 11-CURRENT. Specifically; [left-button drag] selecting text withing xterm, and [left+right click] pasting, causes the d character to be prefixed to the pasted test, and again, the d character is suffixed to the pasted text, and will repeat (infinitely) unless the backspace key is pressed to stop it. Has this been addressed
Re: [cups] Setup cups and Brother HL-4150CDN on FreeBSD 10
More informational, than anything else. But perhaps it will help... Hello Don, cups and freebsd friends, On Mon, Jun 09, 2014 at 11:17:56AM -0700, Don Lewis wrote: On 9 Jun, Willy Offermans wrote: Hello Chris and cups, and freebsd friends, On Mon, Jun 09, 2014 at 07:20:09AM -0700, Chris H wrote: Greetings... Dear cups and freebsd friends, I'm trying to setup CUPS on FreeBSD 10. I managed to install the software and I managed to make the printer available to the OS via /dev/ulpt0: from messages: snip ... Jun 8 17:16:13 donald kernel: ugen1.2: Brother at usbus1 Jun 8 17:16:13 donald kernel: ulpt0: Brother HL-4150CDN series, class 0/0, rev 2.00/1.00, addr 1 on usbus1 Jun 8 17:16:13 donald kernel: ulpt0: using bi-directional mode Jun 8 17:16:13 donald kernel: ulpt0: offline ... /snip from ll /dev/ulpt0 crw-rw 1 root cups - 0x65 Jun 8 17:16 /dev/ulpt0 If I executed the following command: echo 'true' /dev/ulpt0 then the printer reacts and shows that data is transferred to the printer. However, if I try to add the printer to CUPS via the web-interface, then the printer is not detectable. I would expect the printer to be found after searching. I can find an error message in error_log: snip ... E [08/Jun/2014:17:37:53 +0200] [Client 15] Invalid peer credentials for root - got 8, expected 0! ... /snip I'm not sure if this is related to the fact that the printer cannot be detected. If I add the printer manually to the printer.conf file: /Printer Printer BHL4150CDN_2 UUID urn:uuid:de11cfc5-3cbd-361e-5750-8b0e3f0ff4ad AuthInfoRequired none Info Brother HL-4150CDN series Location attic MakeModel Brother HL-4150CDN series CUPS DeviceURI usb:/dev/ulpt0 State Idle StateTime 1402241099 Type 8392780 Accepting Yes Shared No JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy stop-printer /Printer then I still cannot print to the printer. Does anyone has a clue what is going on? Or how can I debug this problem? It appears that the user under which you are attempting all this, doesn't have permission to manage, or otherwise manipulate/view the printer facilities. My suggestion would be to (if available) go to http://localhost:631/admin in your browser, and login with the root password, and then GRANT permission(s) to the user you want to give access to. Also insure that the cups user/group were added correctly. Best wishes. --Chris -- I did as you told. I logged in with root account, but there were no printers available. Also the /dev/ulpt0 device cannot be detected, although the local printer is connected to this device. find new printer under administration is not successful. No printer will appear. cups doesn't use the /dev/ulpt* device. For USB printers, it uses a the device node under /dev/usb. This device needs to be accessable to the cups user. See the last devfs rule here: http://www.freebsd.org/doc/en/articles/cups/printing-cups-configuring-server.html I already added these rules. The following shows my /etc/devfs.rules snip [system=10] add path 'unlpt*' mode 0660 group cups add path 'ulpt*' mode 0660 group cups add path 'lpt*' mode 0660 group cups add path 'da[1,2,3,4,5,6,7,8,9]*' mode 0660 group users add path 'usb/*' mode 0660 group users add path 'usb/1.2.0' mode 0660 group cups /snip The last line ensures the following in /dev/usb: crw-rw 1 root cups - 0x5f Jun 9 12:19 1.2.0 1.2.0 is where ugen1.2 is pointing at: /dev/ugen1.2 - usb/1.2.0 All the above settings were done before I started to search for new printers or to add new printers with the web interface of cups. So no success so far. Are there any other options? My personal guess is that cups has some problems to use root peer credentials. The following error appears in the log file of cups (error_log): E [10/Jun/2014:11:35:14 +0200] [Client 14] Invalid peer credentials for root - got 8, expected 0! On my system; while I was successful in installing my printer (HP Laser JetDirect). It doesn't work correctly (only prints 1 page). All the information I found, regarding the error, blames ghostscript, and [possible] version incompatibilities. Yet, they make no effort to reconcile such issuers during install. Even after some 6yrs. I digress... Here's the output from my install, with a [somewhat] working cups(d) install -- in that the Printer JetDirect were detected, and the cups(d) runs: # ps waux | grep cupsd root 87930 0.0 0.1 19988 4364 ?? Is 10:34AM 0:00.77 /usr/local/sbin/cupsd -C /usr/local/etc/cups/cupsd.conf # cat /etc/passwd | grep cups cups:*:193:193:CUPS Owner:/nonexistent:/usr/sbin/nologin # cat /etc/group | grep cups cups:*:193: I only mention passwd(1
Re: [ANNOUNCE] ports 2014Q2 branched
Hi all, I am pleased to announce that we have created the 2014Q2 branch of the ports tree. Because the first 2014Q1 branch was experimental you might not have heard of it yet. January 2014 saw the release of the first quaterly branch, intended at providing a stable and high-quality ports tree. Those stable branches are a snapshot of the head ports tree taken every 3 months and currently supported for three months, during which they receive security fixes as well as build and runtime fixes. Packages are built on regular basis on that branch (weekly) and published as usual via pkg.FreeBSD.org (/quarterly instead of the usual /latest). They are signed the same way the /latest branch is. While packages for 2014Q1 were only built for 10 (i386 and amd64) 2014Q2 will be built for both FreeBSD 9 and 10 (i386 and amd64). The first build of 2014Q2 will started this morning (wednesday at 1 am UTC) and should hit your closest mirrors very soon. On behalf of the port management team Bapt A big +1 on this! IMHO l-o-o-n-g over due. Thanks Bapt! --Chris ___ 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: DBIx::Simple: Any user? New maintainer?
I am the current maintainer of databases/p5-DBIx-Simple port (last updated on CPAN is 1.35 in 2011). Are there any user of the port? Have there been problems otherwise? (If it is not obvious, I am not an user.) While here, would anybody want to pick up the maintainership? Greetings, Yes. I use it. I'd be happy to maintain it. I already maintain a couple of other ports, and am on the CPAN, as well. If you're still interested, feel free to contact off list. Best wishes. --Chris -- ___ freebsd-p...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-perl To unsubscribe, send any mail to freebsd-perl-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
Re: DBIx::Simple: Any user? New maintainer?
I am the current maintainer of databases/p5-DBIx-Simple port (last updated on CPAN is 1.35 in 2011). Are there any user of the port? Have there been problems otherwise? (If it is not obvious, I am not an user.) While here, would anybody want to pick up the maintainership? Greetings, Yes, I use it. Yes. I have time, and would be happy to maintain it. Please feel free to contact me off list, for any details. Best wishes. --Chris -- ___ freebsd-p...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-perl To unsubscribe, send any mail to freebsd-perl-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
Re: [: -le: argument expected
Hello Tom, and thank you for your thoughtful reply.
Quoting Tom Evans [EMAIL PROTECTED]:
On Thu, 2008-01-31 at 18:41 -0800, Chris H. wrote:
The cause is in the file: lang/php5/files/patch-Zend_zend_list.c
It accounts for all /3/ errors emitted during the initial portion
of the make process. The lines are as follows:
--- Zend/zend_list.c.orig 2007-01-01 10:35:46.0 +0100
+++ Zend/zend_list.c2008-01-29 11:05:14.0 +0100
@@ -48,7 +48,7 @@
return index;
}
-ZEND_API int _zend_list_delete(int id TSRMLS_DC)
+ZEND_API int _zend_list_delete(ulong id TSRMLS_DC)
{
*** zend_rsrc_list_entry *le;
@@ -65,7 +65,7 @@
}
-ZEND_API void *_zend_list_find(int id, int *type TSRMLS_DC)
+ZEND_API void *_zend_list_find(ulong id, int *type TSRMLS_DC)
{
*** zend_rsrc_list_entry *le;
@@ -78,7 +78,7 @@
}
}
-ZEND_API int _zend_list_addref(int id TSRMLS_DC)
+ZEND_API int _zend_list_addref(ulong id TSRMLS_DC)
{
*** zend_rsrc_list_entry *le;
(highlighted with three asterisks for clarity).
While it's nice that I found them. I'm not sure what to do to
make them correct. Any thoughts? Should I simply send-pr -
php5-apache-module build failure (lang/php5/files/patch-Zend_zend_list.c)?
I doubt that patch is the issue. The error comes from a malformed call
to /bin/test (or /bin/[ ). The -le test tests two numbers to see if the
first is less than the second.
With correct usage:
/bin/[ 5 -le 10 ] echo first is less
first is less
With incorrect usage
/bin/[ 5 -le ] echo first is less
[: -le: argument expected
The patch you have shown changes the id of a zend_rsrc_list_entry to be
an unsigned long rather than an int, the fact that the variable name
(which does not get updated, modified or altered) is called 'le' for
'list element' is neither here nor there.
Quite so. I eventually figured that out. But by then had been up for far
too long, and decided to get some sleep, and reply in the morning. Good
morning. :)
I would thoroughly recommend using apache 2.2 with the prefork MPM if
you wish to run PHP. Your arguments for choosing 2.0 over 2.2 are
spurious, as there are virtually no difference in conf directives,
server layout or security, where as apache 2.2 is well maintained and
secure. Apache 2.2 has many notable improvements, especially in
performance and proxying. See [1].
The real hint is on apache.org [2] - 'We consider Apache 2.2 to be the
best available version at the time of this release. We offer Apache
2.0.63 as the best legacy version of Apache 2.0 available. Users should
first consider upgrading to the current release of Apache 2.2 instead.'
I would have to assert that in my case, your assertions are also a bit
moot. Would make deinstall apache2.0 make install apache2.2
make install php5 -DWITH_CGI=TRUE -DWITH_CLI=true -DWITH_APACHE=true
accomplish a successful build? In fact, no. As the real problem at
hand, is getting php5 to build the apache module (libphp5.so). :)
On the other hand. Assuming a successfully built apache module;
How large is the difference between the same modules in
1.2 vs 2.0 vs 2.2?
How large is the difference in apache' reaction to calls made to
apache, where these modules are involved?
Does Apache 2.2 offer the -DWITH_MPM=threadpool? I couldn't find it.
Thank you for your informative, and thoughtful reply.
--Chris H
On the other hand, your server, your rules. :)
Tom
[1] http://httpd.apache.org/docs/2.2/new_features_2_2.html
[2] http://www.apache.org/dist/httpd/Announcement2.0.html
--
panic: kernel trap (ignored)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
