State of mail/postfix-sasl for older FreeBSD
(Please CC me, as I am not on -ports) I would like to know what has happened to mail/postfix-sasl, particularly with regards to FreeBSD 11.x (warning: I will ignore any responses about it being EoL). I clearly see committers tinkering around with things for postfix 3.6, which supports OpenSSL 1.1.1 and newer only. postfix 3.5 however works just fine with older base OpenSSL (1.0.2u-freebsd), and said committers seem to recognise that fact with the addition of mail/postfix35. That said: I see mail/postfix-sasl as orphaned, but no mail/postfix35-sasl stub port. Simultaneously, I see mail/postfix35 lacks the SASL_SLAVE -- for reasons completely unknown/undiscussed (not in commit messages, etc.), which is very strange considering this model has been in place in mail/postfix for a very, very long time -- thus likely why there's no stub port. Please, *please* do this properly, i.e. bring back SASL_SLAVE in mail/postfix35 and make a mail/postfix35-sasl stub port. Understand that there's a large percentage of FreeBSD users who do not want to deal with poudrier and its nonsense just to get something as basic as SASL support in their MTA. Stub ports are important for this very reason. Thank you. # pkg version -v | grep postfix postfix-sasl-3.5.10,1 ? orphaned: mail/postfix-sasl # pkg search ^postfix postfix-logwatch-1.40.03_1 Postfix MTA log parser postfix-policyd-sf-1.82_1,1Anti-spam plugin for Postfix (written in C) postfix-policyd-spf-perl-2.010_1 SPF policy service for Postfix written in Perl postfix-policyd-weight-0.1.15.2_6 Weighted policy daemon for postfix postfix-postfwd-2.03 Postfix firewall policy daemon postfix35-3.5.10,1 Secure alternative to widely-used Sendmail postfixadmin-3.2.4 PHP web-based management tool for Postfix virtual domains and users # pkg search -f postfix35-3.5.10,1 | grep SASL LDAP_SASL : off SASL : off SASLKMIT : off SASLKRB5 : off https://github.com/freebsd/freebsd-ports/commit/efa868ac9533de8e3f73b9cc6c938af81bc9caaf#diff-aa9e338474f4fce707a72f5adf92f7ca9cdf10529245a09e1fd215f111ebf9dc -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administrator PGP 0x2A389531 | | Making life hard for others since 1977.| ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADSUP] Re: Is IPV6 option still necessary?
> Now we can get back on the ipv6 option. > > so if we want to proceed further in removing the option to build with or > without > ipv6 for the ports side. Please speak up in reply to this email, if you are > building without ipv6, why are you doing so, what are the real benefit for it. > How bad it will impact you if we do remove that option? Whenever I use ports over FreeBSD-provided packages (or to use ports to build my own packages), I often disable IPV6 support. The lengthy response below should explain why. In short: the IPV6 option is useful and important. Please keep it. In length: I think anyone operating in the Real World knows quite well that IPv6 is still treated as a third-class citizen when it comes to both general connectivity/reliability* and general use cases code-wise**. It's still very much in utero; or a toddler, if you will. When you encounter IPv6 vs. IPv4 prioritisation issues, they are painful and annoying. No user or administrator is going to sit for hours fiddling with it all to restore things to a working state when simply removing IPv6 relieves the problem permanently. Time and time again I see companies advertising records and webservers listening on IPv6 yet IPv6 transit fails but their A/IPv4 endpoint works fine. It's the dual-stack nature that makes a lot of this worse than it should be. (I do think this subject should be re-visited once the world as a whole starts to seriously decommission IPv4, though. Yes I'm serious.) I've worked for several companies that are IPv4-only, where the belief (and one I share) is that IPv6-only clients have some 6-to-4-ish gateway/NAT somewhere upstream, otherwise they wouldn't be able to reach most of the Internet. IPv4 NAT still works for the majority of use cases still as of 2019. Furthermore, faux-political statements like "IPv6 is more widely used than 2012" should be ignored and facts reiterated: IPv6 adoption is around 25% as of mid-2019. And it's taken over 10 years to reach that. IPv4 is also well-understood, and not, as Dave Horsfall accurately described, "a horse designed by a committee"; people are still trying to wrap their head around IPv6 NDP/RA, SLAAC, and a myriad of other things (dare I mention syntax?). It's this which explains the sluggish adoption rate. And yes, I am well-aware of how important IPv6 is in other regions, particularly Asia. I am not belittling that need at all. But not everyone globally has the same needs. What should really be asked for is the opposite: for the FreeBSD ports folks to justify its removal. How is this hurting you on a daily basis? Is there a large percentage of Mk/ framework bits causing you pain? Are the bulk of per-port patches inducing maintainer grief? At what scale is this impacting you? In 7 years (since the OP picked 2012), how much time has been spent by maintainers ensuring IPV6=true works for their port(s)? Are you truly OK throwing away the integration work done by many, many people (not just Project members!) over the past N years (see: per-port patches), and forcing people who still need the option to make their own ports tree to retain it? Here's some harsh advice for the FreeBSD Project: quit changing shit for sake of change, often masked by lies like "XXX is stagnant/old" or similarly fallacious and loaded statements. The project (both src and ports, but especially ports) have lost many very good people in the past 10+ years (and I'm not talking about me) *because* of that change for sake of change mindset -- the same mindset driving this request! It's changes like this that drive people away from FreeBSD. Really. It's the same mindset that provoked people to stop using Linux distros due to systemd integration. I will not be replying to this thread past this point. I have said all that I care to say / spent enough time on it. Just please stop hurting administrators and end users with proposals/actions like this. * - Real-world IPv6 failures impacting end users tend to be higher than IPv4; this is anecdotal on my part, but I have a myriad of peers who have had to disable IPv6 for similar reasons. The IPv4 fallback in software (both userland apps and network stacks) does not always work "correctly". Just go see how often IPv6 failures/issues are reported on both NANOG and the outages@ mailing list. And yes I am quite aware that a good portion of the Internet backbone at this point is IPv6 (that's nice, and not what we're talking about here). ** - I still continue to see open-source software committing major fixes to AF_INET6 related code bits. Major pieces of software include curl, wget, Busybox, DNS servers (pick one!), and ntp... just for starters. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administrator PGP 0x2A389531 | | Making life hard for others since 1977.|
How to disable staging support in ports tree universally?
(Please keep me CC'd, as I am not subscribed to any FreeBSD lists) Plain, simple, obvious question: how do I disable staging support in the latest ports tree? Today I rebuilt a port (which had been upgraded to remove NO_STAGE=yes from it Makefile) as follows: # make deinstall # make clean install ...and proceeded to watch my /usr/ports filesystem I/O go through the roof with unnecessary crap, starting about here: === Staging for sudo-1.8.8 === Generating temporary packing list ...which is normal, except I suddenly start tons of disk I/O involving $WRKDIR/stage, proceeded by this: === Building package for sudo-1.8.8 Creating package /usr/ports/security/sudo/work/sudo-1.8.8.tbz Registering depends:. Creating bzip'd tar ball in '/usr/ports/security/sudo/work/sudo-1.8.8.tbz' All of this comes from Mk/bsd.port.mk, per _STAGE_SEQ, which is preceded by a plain and simple .if !defined(NO_STAGE). I thought okay, so just put NO_STAGE=yes in /etc/make.conf but make.conf(5) had no mention of this so I was wary. Then I found these two posts clearly stating this is not a make.conf variable and things will bust if you do that: http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086692.html http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086697.html I tried it anyway (in a VM) -- yup, it sure does leave quite a mess laying around if you set it globally, so definitely don't do that. So I read /usr/ports/UPDATING, and /usr/ports/CHANGES, and this: https://wiki.freebsd.org/ports/StageDir ...to no avail. So how do I stop this staging nonsense when it doesn't apply to any of my systems/environments? I install third-party software directly from the ports tree, I DO NOT USE pkg, nor do I ever plan on using pkg given that I customise ports individually (through make config and some make.conf knobs) quite heavily. I want to know how to stop this excess waste of disk I/O when it doesn't apply to my environments/systems, and I'm sure many others do as well. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Recent Mk/bsd.perl.mk changes (r320679)
On Wed, Jun 26, 2013 at 03:23:06AM -0700, Jeremy Chadwick wrote: On Wed, Jun 26, 2013 at 12:15:37AM -0700, Jeremy Chadwick wrote: On Wed, Jun 26, 2013 at 08:40:52AM +0200, Baptiste Daroussin wrote: On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote: On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote: Hello, and first please accept my apologies for this situation. Understood, I just hope this can get addressed/fixed sooner than later, because what we have right now is reproducible breakage. :-) pkg_add -r perl (this will install perl-5.14.2_3.tbz) svn up /usr/ports cd /usr/ports/whatever/p5-whatever make install pkg_delete p5-whatever As I know we are never supported mixing of ports and packages. If you initially installed something from package and decide to use ports in this case better to rebuild all or stay with packages. And here is where you are sadly mistaken. While I cannot find any sort of official statement on the mixing of the two, the fact of the matter is (and possibly you did not know this -- I'm not sure) that packages are built **from** ports (make package does the magic). This is confirmed as well: http://www.freebsd.org/ports/index.html http://www.freebsd.org/doc/en/articles/linux-users/software.html Please be aware when I say package I am talking about the .tbz balls utilised by the base system's pkg_* tools (not pkg(8)) and used by the OS installer and so on. For pkg(8) I believe poudriere is used to make the packages. I don't use/can't speak about pkg(8) et al. Wrong and totally wrong, the way the ports tree works with pkg(8) is exactly the same way it works with pkg_install (make package does the same). poudriere is just some script to make sure everything is done in the right order, cleanly and works transparently with both pkg(8) and pkg_install. Thanks for the clarification and the education on this point -- like I said, I have no experience with pkg(8) and its kin. For both pkg_* tools and ports, both use the same default base path (/usr/local), **and** both register their bits in /var/db/pkg. Wrong and wrong, ports knows nothing about /var/db/pkg, ports ask the package tool to register a package may that be pkg_install or pkg(8) this tool will register the package where ever it seems suitable to itself meaning /var/db/pkg in the case of both pkg(8) and pkg_install. Please go look at Mk/bsd.port.mk and look up PKG_DBDIR. Just go look for it throughout the entire file and look at how/where it's used. It's used *heavily* throughout dependency checking and actual installation (think Registering installation of ... messages and what happens under the hood, if I remember right -- otherwise you have a port installed that you cannot pkg_delete). Package installation does not utilise any part of the ports/Mk/* framework, but that isn't anything new -- it's been like that since at least the 2.2.x days, possibly earlier. So in summary, when making changes to ports/Mk/*, you really have to think about the combination of the two, and make sure you don't break anything when changing key pieces of those framework bits. That is exactly what has been done in the case of the change. But only when looking forward, not when looking at existing installations or new installations. I will repeat my instructions for how to reproduce the problem: pkg_add -r perl (this will install perl-5.14.2_3.tbz) svn up /usr/ports cd /usr/ports/whatever/p5-whatever make install pkg_delete p5-whatever Please go do it on a fresh FreeBSD 9.2-RELEASE system and watch what happens -- it breaks, and that breakage results in leftover shit in LOCALBASE. What I'd like to know: - Why the major.minor.patchlevel -- major.minor path change in the first place. I have never, ever seen this done anywhere on any *IX system I've used. Where's the justification? Was this discussed on some perl mailing list somewhere as a new and better way? It's essentially saying x.y.z is always going to be compatible with x.y.z+1 which is not true (particularly with XS, as I understand it). Where was this discussed publicly? http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26605+0+archive/2013/freebsd-perl/20130609.freebsd-perl I don't want to start yet another bikeshed here. Maybe link above will make some things more clear to you. Thanks -- I wasn't aware of the freebsd-perl mailing list. I just finished reading the entire thread. The justification seems to be because Fedora and Debian do it (that's the best I can find). Okay, fine/great/whatever -- I guess that's a form of justification, just not one
Re: Vim and Vim-lite ports broken options
(Please keep me CC'd as I'm not subscribed to -ports)
Yup, it's all broken. I use vim-lite myself; the solution I found
is to drop this into /etc/make.conf:
.if ${.CURDIR:M*/editors/vim-lite}
WITH_VIM_OPTIONS=yes
.endif
Then cd /usr/ports/editors/vim-lite ; make config, make sure
everything is de-selected, and it should be fine from there; the only
dependencies at that point will be libiconv and libtool. This causes
the port to use the OPTIONS framework.
Do not ask me why this flag exists, as from what I can discern the
standard OPTIONS framework should suffice without sub-knobs. I get
the impression the driving force is to induce a non-interactive
behaviour, e.g. what BATCH sort of used to do (not sure if it still
does).
There seems to be an unspoken reluctance upon the part of a single
committer who also happens to maintain very key/important ports. A
similar situation happened with shells/bash, prompting shells/bash-devel
to be created/maintained by someone else. There are public discussions
about that, multiple times:
http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083948.html
http://lists.freebsd.org/pipermail/freebsd-ports/2013-January/080336.html
http://lists.freebsd.org/pipermail/freebsd-ports/2013-January/080363.html
http://lists.freebsd.org/pipermail/freebsd-ports/2013-January/080656.html
The key/major discussion I cannot find right now (maybe it wasn't on -ports,
that's all I looked at, and only for the word bash).
P.S. -- Unrelated to this matter, but the patch count for 7.3 is now up
to 1278 (i.e. the submitted patch count is up to 1278):
https://groups.google.com/forum/#!forum/vim_dev
Bram should be completely and totally ashamed (all while simultaneously
blabbing about too many patches, test 7.4 in May, yet there is no
such thing anywhere); a very sad state of affairs for such an important
editor.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
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: Subversion 1.8 / FreeBSD 8 x86 STABLE Symlinks
On Sun, Jun 30, 2013 at 02:20:21PM -0400, Jason Hellenthal wrote: When using svn 1.8 I have come across a situation where when it is used pointing to a symlink that refers to a working directory that a update will either segfault or exit prematurely and leave a lock held on the working directory that the symlink points to. This leaves you with one choice but to run cleanup on the referenced actual working directory which was AFAIK never the case for any version below 1.8. Not sure if this is a problem with svn or FreeBSD itself but thought I would report the characteristics in case it's noticed elsewhere. Details: Using UFS FreeBSD 8-STABLE i386 as of this date. In the directory... cd /exports/usr ln -s src8 src svn up /exports/usr/src Known bug/problem in Subversion, not FreeBSD: http://svn.apache.org/viewvc?view=revisionrevision=r1496007 Previous discussion: http://lists.freebsd.org/pipermail/freebsd-questions/2013-June/251842.html -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Recent Mk/bsd.perl.mk changes (r320679)
On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote: Hello, and first please accept my apologies for this situation. Understood, I just hope this can get addressed/fixed sooner than later, because what we have right now is reproducible breakage. :-) pkg_add -r perl (this will install perl-5.14.2_3.tbz) svn up /usr/ports cd /usr/ports/whatever/p5-whatever make install pkg_delete p5-whatever As I know we are never supported mixing of ports and packages. If you initially installed something from package and decide to use ports in this case better to rebuild all or stay with packages. And here is where you are sadly mistaken. While I cannot find any sort of official statement on the mixing of the two, the fact of the matter is (and possibly you did not know this -- I'm not sure) that packages are built **from** ports (make package does the magic). This is confirmed as well: http://www.freebsd.org/ports/index.html http://www.freebsd.org/doc/en/articles/linux-users/software.html Please be aware when I say package I am talking about the .tbz balls utilised by the base system's pkg_* tools (not pkg(8)) and used by the OS installer and so on. For pkg(8) I believe poudriere is used to make the packages. I don't use/can't speak about pkg(8) et al. For both pkg_* tools and ports, both use the same default base path (/usr/local), **and** both register their bits in /var/db/pkg. Package installation does not utilise any part of the ports/Mk/* framework, but that isn't anything new -- it's been like that since at least the 2.2.x days, possibly earlier. So in summary, when making changes to ports/Mk/*, you really have to think about the combination of the two, and make sure you don't break anything when changing key pieces of those framework bits. What I'd like to know: - Why the major.minor.patchlevel -- major.minor path change in the first place. I have never, ever seen this done anywhere on any *IX system I've used. Where's the justification? Was this discussed on some perl mailing list somewhere as a new and better way? It's essentially saying x.y.z is always going to be compatible with x.y.z+1 which is not true (particularly with XS, as I understand it). Where was this discussed publicly? http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26605+0+archive/2013/freebsd-perl/20130609.freebsd-perl I don't want to start yet another bikeshed here. Maybe link above will make some things more clear to you. Thanks -- I wasn't aware of the freebsd-perl mailing list. I just finished reading the entire thread. The justification seems to be because Fedora and Debian do it (that's the best I can find). Okay, fine/great/whatever -- I guess that's a form of justification, just not one I was hoping for. I won't dwell on this at this point -- I got the answer I was looking for. I see no actual harm in moving to major.minor, but the issue here is that backwards compatibility in Mk/bsd.perl.mk for existing perl installations. Many people, for example, do not want to build X.org from source -- so they pkg_add -r X, then build other bits/pieces related to X from ports/source. Even more people do this for OpenOffice/LibreOffice or whatever it's called today ( :-) ). This combination needs to be supported. I know it hurts to have to retain backwards compatibility, but it's necessary given how all of this was designed. Such backwards compatibility could be removed, as I said, once sufficient time has passed, particularly once the FreeBSD versions shipping with a ports tree snapshot with perl versions older than those in r320679 have been EOL'd. After that you could remove the framework and cite EOL on such support. This is normal too -- for example on occasion FreeBSD [67].x people show up on -ports and complain that something won't build/some part of the Mk/* framework is broken for them, and EOL is the proper response to that. I know this probably won't hold any ground because I'm not one any longer, but I was a FreeBSD ports committer myself some years ago (~5), so please don't think that I'm just flying off the handle without some existing familiarity with things. If there is truly going to be a split between ports and packages in this way, then someone needs to start doing SVN tagging/branches for major changes like this. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Recent Mk/bsd.perl.mk changes (r320679)
On Wed, Jun 26, 2013 at 08:40:52AM +0200, Baptiste Daroussin wrote: On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote: On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote: Hello, and first please accept my apologies for this situation. Understood, I just hope this can get addressed/fixed sooner than later, because what we have right now is reproducible breakage. :-) pkg_add -r perl (this will install perl-5.14.2_3.tbz) svn up /usr/ports cd /usr/ports/whatever/p5-whatever make install pkg_delete p5-whatever As I know we are never supported mixing of ports and packages. If you initially installed something from package and decide to use ports in this case better to rebuild all or stay with packages. And here is where you are sadly mistaken. While I cannot find any sort of official statement on the mixing of the two, the fact of the matter is (and possibly you did not know this -- I'm not sure) that packages are built **from** ports (make package does the magic). This is confirmed as well: http://www.freebsd.org/ports/index.html http://www.freebsd.org/doc/en/articles/linux-users/software.html Please be aware when I say package I am talking about the .tbz balls utilised by the base system's pkg_* tools (not pkg(8)) and used by the OS installer and so on. For pkg(8) I believe poudriere is used to make the packages. I don't use/can't speak about pkg(8) et al. Wrong and totally wrong, the way the ports tree works with pkg(8) is exactly the same way it works with pkg_install (make package does the same). poudriere is just some script to make sure everything is done in the right order, cleanly and works transparently with both pkg(8) and pkg_install. Thanks for the clarification and the education on this point -- like I said, I have no experience with pkg(8) and its kin. For both pkg_* tools and ports, both use the same default base path (/usr/local), **and** both register their bits in /var/db/pkg. Wrong and wrong, ports knows nothing about /var/db/pkg, ports ask the package tool to register a package may that be pkg_install or pkg(8) this tool will register the package where ever it seems suitable to itself meaning /var/db/pkg in the case of both pkg(8) and pkg_install. Please go look at Mk/bsd.port.mk and look up PKG_DBDIR. Just go look for it throughout the entire file and look at how/where it's used. It's used *heavily* throughout dependency checking and actual installation (think Registering installation of ... messages and what happens under the hood, if I remember right -- otherwise you have a port installed that you cannot pkg_delete). Package installation does not utilise any part of the ports/Mk/* framework, but that isn't anything new -- it's been like that since at least the 2.2.x days, possibly earlier. So in summary, when making changes to ports/Mk/*, you really have to think about the combination of the two, and make sure you don't break anything when changing key pieces of those framework bits. That is exactly what has been done in the case of the change. But only when looking forward, not when looking at existing installations or new installations. I will repeat my instructions for how to reproduce the problem: pkg_add -r perl (this will install perl-5.14.2_3.tbz) svn up /usr/ports cd /usr/ports/whatever/p5-whatever make install pkg_delete p5-whatever Please go do it on a fresh FreeBSD 9.2-RELEASE system and watch what happens -- it breaks, and that breakage results in leftover shit in LOCALBASE. What I'd like to know: - Why the major.minor.patchlevel -- major.minor path change in the first place. I have never, ever seen this done anywhere on any *IX system I've used. Where's the justification? Was this discussed on some perl mailing list somewhere as a new and better way? It's essentially saying x.y.z is always going to be compatible with x.y.z+1 which is not true (particularly with XS, as I understand it). Where was this discussed publicly? http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26605+0+archive/2013/freebsd-perl/20130609.freebsd-perl I don't want to start yet another bikeshed here. Maybe link above will make some things more clear to you. Thanks -- I wasn't aware of the freebsd-perl mailing list. I just finished reading the entire thread. The justification seems to be because Fedora and Debian do it (that's the best I can find). Okay, fine/great/whatever -- I guess that's a form of justification, just not one I was hoping for. I won't dwell on this at this point -- I got the answer I was looking for. No the justification is that we use to have a perl-after-upgrade script to workaround the fact that we used major.minor.patchlevel my bypassing the package tool to modify directly the content of the package database and more some files
Re: Recent Mk/bsd.perl.mk changes (r320679)
On Wed, Jun 26, 2013 at 12:15:37AM -0700, Jeremy Chadwick wrote: On Wed, Jun 26, 2013 at 08:40:52AM +0200, Baptiste Daroussin wrote: On Tue, Jun 25, 2013 at 11:12:19PM -0700, Jeremy Chadwick wrote: On Wed, Jun 26, 2013 at 09:42:37AM +0400, Andrej Zverev wrote: Hello, and first please accept my apologies for this situation. Understood, I just hope this can get addressed/fixed sooner than later, because what we have right now is reproducible breakage. :-) pkg_add -r perl (this will install perl-5.14.2_3.tbz) svn up /usr/ports cd /usr/ports/whatever/p5-whatever make install pkg_delete p5-whatever As I know we are never supported mixing of ports and packages. If you initially installed something from package and decide to use ports in this case better to rebuild all or stay with packages. And here is where you are sadly mistaken. While I cannot find any sort of official statement on the mixing of the two, the fact of the matter is (and possibly you did not know this -- I'm not sure) that packages are built **from** ports (make package does the magic). This is confirmed as well: http://www.freebsd.org/ports/index.html http://www.freebsd.org/doc/en/articles/linux-users/software.html Please be aware when I say package I am talking about the .tbz balls utilised by the base system's pkg_* tools (not pkg(8)) and used by the OS installer and so on. For pkg(8) I believe poudriere is used to make the packages. I don't use/can't speak about pkg(8) et al. Wrong and totally wrong, the way the ports tree works with pkg(8) is exactly the same way it works with pkg_install (make package does the same). poudriere is just some script to make sure everything is done in the right order, cleanly and works transparently with both pkg(8) and pkg_install. Thanks for the clarification and the education on this point -- like I said, I have no experience with pkg(8) and its kin. For both pkg_* tools and ports, both use the same default base path (/usr/local), **and** both register their bits in /var/db/pkg. Wrong and wrong, ports knows nothing about /var/db/pkg, ports ask the package tool to register a package may that be pkg_install or pkg(8) this tool will register the package where ever it seems suitable to itself meaning /var/db/pkg in the case of both pkg(8) and pkg_install. Please go look at Mk/bsd.port.mk and look up PKG_DBDIR. Just go look for it throughout the entire file and look at how/where it's used. It's used *heavily* throughout dependency checking and actual installation (think Registering installation of ... messages and what happens under the hood, if I remember right -- otherwise you have a port installed that you cannot pkg_delete). Package installation does not utilise any part of the ports/Mk/* framework, but that isn't anything new -- it's been like that since at least the 2.2.x days, possibly earlier. So in summary, when making changes to ports/Mk/*, you really have to think about the combination of the two, and make sure you don't break anything when changing key pieces of those framework bits. That is exactly what has been done in the case of the change. But only when looking forward, not when looking at existing installations or new installations. I will repeat my instructions for how to reproduce the problem: pkg_add -r perl (this will install perl-5.14.2_3.tbz) svn up /usr/ports cd /usr/ports/whatever/p5-whatever make install pkg_delete p5-whatever Please go do it on a fresh FreeBSD 9.2-RELEASE system and watch what happens -- it breaks, and that breakage results in leftover shit in LOCALBASE. What I'd like to know: - Why the major.minor.patchlevel -- major.minor path change in the first place. I have never, ever seen this done anywhere on any *IX system I've used. Where's the justification? Was this discussed on some perl mailing list somewhere as a new and better way? It's essentially saying x.y.z is always going to be compatible with x.y.z+1 which is not true (particularly with XS, as I understand it). Where was this discussed publicly? http://docs.freebsd.org/cgi/getmsg.cgi?fetch=26605+0+archive/2013/freebsd-perl/20130609.freebsd-perl I don't want to start yet another bikeshed here. Maybe link above will make some things more clear to you. Thanks -- I wasn't aware of the freebsd-perl mailing list. I just finished reading the entire thread. The justification seems to be because Fedora and Debian do it (that's the best I can find). Okay, fine/great/whatever -- I guess that's a form of justification, just not one I was hoping for. I won't dwell on this at this point -- I got the answer I was looking for. No the justification is that we use to have a perl-after-upgrade script
Recent Mk/bsd.perl.mk changes (r320679)
(I am not subscribed to -ports so please keep me CC'd)
To the committers and reviewers of r320679:
http://svnweb.freebsd.org/ports?view=revisionrevision=320679
The pathing change in bsd.perl.mk has broken things quite badly for
anyone who **does not** upgrade lang/perl* but chooses to upgrade a perl
module port (ex. p5-*) -- or even reinstall an existing one. This
creates a very broken situation. The issue is 100% reproducible;
simplest method:
pkg_add -r perl (this will install perl-5.14.2_3.tbz)
svn up /usr/ports
cd /usr/ports/whatever/p5-whatever
make install
pkg_delete p5-whatever
What I'd like to know:
- Why the major.minor.patchlevel -- major.minor path change in the
first place. I have never, ever seen this done anywhere on any *IX
system I've used. Where's the justification? Was this discussed on
some perl mailing list somewhere as a new and better way? It's
essentially saying x.y.z is always going to be compatible with x.y.z+1
which is not true (particularly with XS, as I understand it). Where
was this discussed publicly?
- Why bsd.perl.mk was changed how it was, i.e. why it didn't stick with
using the major.minor.patchlevel pathing scheme by default, and if one
of the newer perl versions was used (which would warrant the user having
to uninstall their perl, thus forced to rebuild/reinstall all their p5-*
stuff anyway), use the newer pathing scheme? It could be dealt with
equivalently (pseudo-code per se) as:
if ($PERL_VERSION =~ /^5\.12\.[5-9]/
or $PERL_VERSION =~ /^5\.14\.[4-9]/
or $PERL_VERSION =~ /^5\.16\.[3-9]/) {
$use_newer_paths = 1;
}
else {
$use_newer_paths = 0;
}
The logic here could be modified (or inverted) if desired. And this
framework would only have to be left in for a little while (maybe a few
years) until all the older FreeBSD versions had been officially EOL'd.
(Remember: those using EOL'd FreeBSD versions but with ports trees
updated past that EOL date are living dangerously, as no compatibility
is guaranteed -- this has come up many times on the lists, and even
somewhat recently).
You should have seen the look on my face when I went to update
p5-Mail-SpamAssassin (and nothing else) on my system and suddenly found
it shitting the bed, forcing me to pkg_delete -af rm -fr /usr/local
and start over fresh due to leftover cruft populating /usr/local.
I say all this well aware of what ports/UPDATING said -- however the
instructions blindly make the assumption the person is building from
source or using pkg (not pkg_* tools). The versions of perl on the
official package mirrors in Latest/ do not work properly with these
changes, and those are still packages which are **actively used**
during **present-day-supported** FreeBSD installations. FreeBSD users
do expect to pkg_add -r something (which can also be done from the
installer on fresh installations), then install things from /usr/ports
with make install; this is normal and must be supported.
Something tells me this is one of those situations where if we still had
dougb@ he would have caught it in advance and yelled loudly.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
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: Recent Mk/bsd.perl.mk changes (r320679)
On Wed, Jun 26, 2013 at 06:50:51AM +0200, Kurt Jaeger wrote: Hi! - Why the major.minor.patchlevel -- major.minor path change in the first place. Probably this: Currently, if the perl port is updated to the next patchlevel, one has to recompile a lot of ports. That doesn't make any sense. An example of what we (FreeBSD users/ports) had prior to r320679: User has perl-5.12.3 installed (package or port, doesn't matter), and also some perl module (we'll call it p5-Snakes-1.00). User updates /usr/ports, and finds that lang/perl5.12 has been updated to perl 5.12.4 -- this doesn't matter in the least, nothing forces them to update to that, it's unnecessary unless the individual port mandates it (via $PERL_LEVEL). The user also sees p5-Snakes has been updated to 1.02, so the user pkg_delete/deinstalls it, make installs, and now has p5-Snakes-1.02 (fully usable) on their system. It Just Works(tm), built completely off the existing perl-5.12.3 bits. If the user wants to update to perl-5.12.4, yes, they will need to reinstall all their ports -- and justifiably so. Expanding on that: There is no reason I'd assume a.b.c would necessarily be completely compatible with a.b.c+1 or subsequent updates. The two things that come to mind with perl are perlxs and libperl.so (note that there is no .so.N versioning scheme with perl .so bits). The DBI/DBD layer comes to mind here (and that degree of breakage would really upset FreeBSD users). Perl as a language tries to be backwards-compatible as much as possible, but AFAIK this is purely a language/operational compatibility; whether or not the underlying libraries and ABI/API of the shared objects are compatible between minor revisions is an assumption -- unless someone can show me proof otherwise. But even if they can show such proof, it's not justification for the backwards-compatibility breakage in bsd.perl.mk One of my reference hosts still compiles, started approx. a week ago. I understand, but prior to r320679, you wouldn't have had to do that unless you chose to updated lang/perl5.xx. Instead, what we have *right now* is something that makes assumptions (see above paragraph) **and** breaks fresh FreeBSD installs where the person chooses to install the perl package + update /usr/ports + install a perl module from ports, **as well** as an existing system where an admin just wants to update a perl module from ports. This is for present-day supported FreeBSD versions, not EOL! I'm fine with the major.minor.patchlevel -- major.minor pathname change, **as long** as shims in bsd.perl.mk are put in place to retain use of major.minor.patchlevel paths if an older version of perl is installed on the system. Those shims were not written, and I want to know why, because as I see it we *can* have it both ways. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: net/mtr broken without ipv6
(I'm not subscribed to this list so keep me CC'd) Re: http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083766.html I've already discussed this before -- with you in fact -- and did the full analysis. Users should read it in full: http://lists.freebsd.org/pipermail/freebsd-ports/2013-March/082144.html I also CC'd the port maintainer on that Email, who did not respond. Proof of that: From: Jeremy Chadwick j...@koitsu.org To: s...@tormail.org Date: Fri, 15 Mar 2013 21:32:14 -0700 Cc: sunp...@freebsd.org, freebsd-ports@freebsd.org Subject: Re: net/mtr failed to build I am now CC'ing portmgr@ due to negligence. FreeBSD Ports Management Team: Please read my analysis (March mail above). TL;DR version: This port needs to be reverted to 0.82. I will not mince words: mtr 0.84 is a complete clusterfuck on all BSDs, including OS X. It should be nuked from orbit. As stated in my March Email, while there are fixes in the official mtr github repo for all of this nonsense, but figuring out which fixes/commits is time-consuming and honestly not worth it given the massive scale of breakage (as I said, it affects all BSDs). Please see that this port is rolled back to 0.82 (specifically reverting r213277). I believe PORTREVISION should also be set to 2 when rolling back, because there have been other Makefile changes between 0.82 PORTREVISION=1 and now (specifically r316355). Verification: http://svnweb.freebsd.org/ports/head/net/mtr/Makefile?r1=300897r2=314277 http://svnweb.freebsd.org/ports/head/net/mtr/Makefile?r1=314277r2=316355 Thank you. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: net/mtr broken without ipv6
On Sat, May 25, 2013 at 11:40:05PM -0700, Jeremy Chadwick wrote: Please see that this port is rolled back to 0.82 (specifically reverting r213277). I believe PORTREVISION should also be set to 2 when rolling back, because there have been other Makefile changes between 0.82 PORTREVISION=1 and now (specifically r316355). Verification: You know what pisses me off more than the mtr authors not properly testing their software on all platforms before release? When I somehow completely botch SVN revision numbers. :/ The first line of my quoted paragraph SHOULD have read: Please see that this port is rolled back to 0.82 (specifically reverting r314277 / rolling back to r300897). -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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 curl
(Please keep me CC'd as I'm not subscribed to -ports)
curl tests 591 and 1316 pass for me using vanilla source and running
configure + make test (i.e. not as a port/not using your patch).
However, test 1316 does intermittently fail with socket-related problems
(see the logs referenced below).
What those tests are:
test 591...[FTP multi PORT and 425 on upload]
test 1316...[FTP LIST tunneled through HTTP proxy]
You can list tests by doing:
cd tests
./runtests.pl -l
And can run an individual test:
./runtests.pl -v -k {testnum}
The results are stored in the underlying log/ directory.
I've uploaded two test 1316 log directories (one for the failure, one
for the success during the subsequent run) in case someone wants to
figure this out.
Whether this is a curl bug vs. a test case bug vs. a FreeBSD bug vs. a
regression from older curl versions I do not know, and am not
particularly interested in figuring it out myself. Enjoy:
http://jdc.koitsu.org/freebsd/curl-7.29-tests/
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
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: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1
On Wed, Mar 20, 2013 at 04:20:02PM +0100, Matthias Gamsjager wrote: Due to the security incident, there are still no official FreeBSD packages. Do you know what the status is on that issue? I'd also like to find out what the status of this is. The packages at: ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/ Are still circa October 2012 -- that's 4-5 months ago. While I truly and deeply understand that proper engineering design and infrastructure changes take time, there has been absolutely no communication presented to the community as to what has (or hasn't) transpired, if there is (or isn't) a plan, or if people are simply waiting until future in-person BSD* events to work things out. freebsd-ops-announce has been silent on this matter as well: http://lists.freebsd.org/mailman/listinfo/freebsd-ops-announce At this point users and administrators do not know if newer packages will be made available or if they should stick to building purely from source. Deep down I'm worried that this will solicit a response of switch to ports-mgmt/pkg and ports-mgmt/poudriere. While I'm not opposed to the tools themselves, I'm strongly opposed to that kind of response as I'm tired of seeing the security incident being used as a opportunistic crutch (as it was for the sudden cvsup/csup deprecation). -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: net/mtr failed to build
The breakage you see in curses.c is caused by IPv6 support being mandatory, as a result of the software authors/committers being idiots on numerous levels. The rollout of mtr 0.84 is, basically, completely buggered for the BSDs. The software authors should be utterly ashamed. mtr 0.84 was released roughly a month ago. Around 0.83, glib became a mandatory dependency, and its implementation done stupidly/badly: https://github.com/traviscross/mtr/commits/v0.84 This affected/affects OS X as well as the other BSDs as I said. If we look at HEAD, we find that the idiocy has been cleaned up: https://github.com/traviscross/mtr/commits/master More specifically: https://github.com/traviscross/mtr/commit/8348cfdc39694f0ada686b8277b75b3f72c6a47f#configure.ac Note the introduction of a --without-glib configure option. And note the commit reason too -- make building work on OS X, a.k.a. fix the idiocy committed prior to 0.84. The IPv6 stuff got fixed in HEAD as well. It's hard to see (you gotta dig), but it's there. Look around like 318: https://github.com/traviscross/mtr/blob/master/curses.c I also like this: https://github.com/traviscross/mtr/commit/b32f0bd4295d32c2fd87c36f3c8a0d00fa53e660#README The new situation -- uh, okay, as if readers would know what this means/is/whatever. Gut feeling tells me it has something to do with either neglect or administrator/author drama. Bottom line: The FreeBSD port should be rolled back to 0.82 until 0.85 or newer comes out. Making diffs for all this crap is not worth it; 0.84 should be nuked from orbit. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: sqlite: database is locked
(Please keep me CC'd as I'm not subscribed to the list) === Registering installation for MuSE-0.9.2_14 Installing MuSE-0.9.2_14... done pkg: sqlite: database is locked which results in muse not being registered in the pkg database... This worries me. It appears to indicate that the installation of the package (i.e. sticking files into /usr/local) happens first, followed by an attempted exclusive lock of the pkg sqlite DB, which then failed -- thus leaving files laying around in /usr/local. If that is the case (and boy do I hope it isn't) then that logic is 100% backwards. The DB exlock should happen first, and if the DB exlock fails[1] then things should abort. Otherwise you'll end up with files installed on your filesystem which aren't registered in the pkg DB, and that is unacceptable. This also worries me: ... This persists between reboots, and for fresh pkg runs. What kind of locking mechanism is being used here? flock(2) LOCK_EX would not survive a reboot, but a filesystem-based dotlock would. This really needs investigation and not be swept under the rug. And please don't tell me you have the source, go look at it -- I would much rather the authors who are familiar with the code look at it. :-) [1]: I don't advocate that the locking mechanism should block indefinitely, but there should be some kind of retry attempt at a specific interval (i.e. try 5 times, with 1 second delays) before giving up -- and something on-screen should be printed/shown every time an attempt to lock is made. Maybe that already happens, I don't know, I don't use pkg. This also makes me wonder if there's a SIGINT handler for a person hitting Ctrl-C in the middle of that operation and if proper clean-up is done afterward. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Let's talk about subversion/svn
On Mon, Nov 19, 2012 at 12:51:01PM +0400, Lev Serebryakov wrote: Hello, Jeremy. You wrote 19 2012 ??., 11:16:07: JC However, GDBM and Oracle/Sleepycat DB aren't (by default) enabled JC in 1.7.7 which is what's in ports currently: They weren't enabled for 1.7.6 too, so it is strange, that pointyhat-builded package require it. I need to investigate this. Lev, Politely: any update on this? I see the packages on the master are still the same date (October 2012), but I can confirm that building from ports/source doesn't pull in GDBM nor Oracle/SleepyCat DB. I imagine the security incident on the cluster, combined with 9.1-RELEASE rollout, has stalled some of this, but I just wanted to remind you of it in case you've forgotten. Also, this might interest you since subversion pulls in apr1 (note first paragraph): http://lists.freebsd.org/pipermail/freebsd-apache/2012-December/003008.html http://lists.freebsd.org/pipermail/freebsd-apache/2012-December/003010.html Seems there are many of us trying to get the dependency count down these days. :-) -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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
Let's talk about subversion/svn
to be updated, a static build wouldn't be able to deal with that, but that's just a bunch of hogwash (I can explain why in detail if wanted). So I doubt we'll see something like subversion-static.tbz anytime soon. So what's the point of my Email? I want to find out what is being done by the FreeBSD folks (that means Project members and Committers alike) to deal with this migration from the end-user perspective. The Project has effectively destroyed csup/cvsup in different ways, especially over the past 2 days (I love seeing all CVS commits now done as user svnexp and the cvsweb.cgi interface is 100% broken -- thanks! Nobody used this functionality anyway, right?), so for me svn is the only choice[1]. Finally: for those wanting svn in the base system, good luck. I'm sure licensing issues will be the main reason this can't happen. This just circles back to my age-old argument about how the base system concept on FreeBSD needs to be nuked, and that all base system software should actually just be ports/packages and can be updated/maintained in that same fashion (but obviously with much more scrutiny). There's no technical reason this can't be done, only social reasons. For how this is done properly, see Debian. I look forward to responses, but I can assure you I will respond very little; I tend to be argumentative (case in point) and could battle this all day and night, but more importantly, the work/effort here is not my responsibility -- it is the responsibility of those who have deprecated something that was minimal and just worked out-of-the-box. [1]: Regarding ports and use portsnap: have no problem with portsnap, but it doesn't work for my workflow/model. I absolutely need to see things in more real-time fashion than when a portsnap mirror decides to update its snapshot from the master (could be hours, could be days, who knows -- and we have seen occasions of these delays happen already, and not just recently). I used csup (and when providing diffs for PRs, cvs itself) exclusively for ports and src, and I will therefore use svn for the same purpose. Not for debate. :-) -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Questions about/issues with new OPTIONS framework
On Tue, Aug 07, 2012 at 08:43:18PM +0200, Olli Hauer wrote:
On 2012-08-06 18:04, Jeremy Chadwick wrote:
(Please keep me CC'd, as I'm not subscribed to the list)
I've been trying to adapt my /etc/make.conf to make use of the new
OPTIONS framework. I've run into some snags that I was hoping someone
could help me with, as I'm unable to find any official documentation
other than these two documents, which don't help me in this case:
http://wiki.freebsd.org/Ports/Options/OptionsNG
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html
Below are my questions so far. Note that these questions are all
preceded by a key fact: /var/db/ports/* is completely empty. Keep that
in mind please.
1. databases/mysql55-server and databases/mysql55-client both ask for
the same variables (OPENSSL and FASTMTX). I want FASTMTX to be enabled
by default for both ports.
When I have the following in /etc/make.conf:
mysql_SET= FASTMTX
Doing make config in databases/mysql55-server shows FASTMTX as checked
(which is correct). However, when I do the exact same procedure in
databases/mysql55-client, FASTMTX is not checked.
I am aware that databases/mysql55-client is a slave port, but I'm not
sure how/why that would matter...?
What am I doing wrong, or is this a port bug which needs to be fixed by
the maintainer?
2. ports/KNOBS is very explicit in stating, and even visually
...
2) alredy answerd ...
answer for question 1)
$ cd mysql55-client make -V UNIQUENAME
or
$ make -V UNIQUENAME -C /usr/ports/databases/mysql55-client/
mysql55-client
So it's based off of UNIQUENAME? That's interesting.
The documentation implies that the name of the variable itself
should be the {nameofport}_SET or {nameofport}_UNSET, where {nameofport}
should equal the name of the actual port directory you're in. Yet, take
a look at this:
root@icarus:/usr/ports/devel/apr0 # make -V UNIQUENAME
apr
root@icarus:/usr/ports/devel/apr1 # make -V UNIQUENAME
apr
root@icarus:/usr/ports/devel/apr2 # make -V UNIQUENAME
apr
Another one where the names are consistent (mtr-nox11 is a stub/slave
port):
root@icarus:/usr/ports/net/mtr # make -V UNIQUENAME
mtr
root@icarus:/usr/ports/net/mtr-nox11 # make -V UNIQUENAME
mtr
All of these consistently use the same UNIQUENAME. To me that seems
like the Right Choice(tm), but then there's this:
root@icarus:/usr/ports/databases/mysql55-server # make -V UNIQUENAME
mysql
root@icarus:/usr/ports/databases/mysql55-client # make -V UNIQUENAME
mysql55-client
I would imagine these should return the same thing (e.g. mysql55-client
should have a UNIQUENAME of mysql, or alternately mysql55-server should
have a UNIQUENAME of mysql55-server).
...while for other ports, it does seem to be based off of the port name
itself. Examples ports include apache22-itk-mpm, p5-DBD-mysql,
p5-libwww, and so on.
How are users supposed to know what the name of the variable is they
should be setting in make.conf? There doesn't even appear to be a make
show-xxx command to help people out with this.
Trial and error seems to be the only way to figure it out, and that's
time-consuming. Luckily this is my home system where I only have 81
ports installed, and only a handful require adjustments, but you can see
my point?
make.conf entry constructed from UNIQUENAME
mysql55-client_SET+= FASTMTX
Please note the '+=' instead '='.
If you have a port where you set more then on option but not as one expression
all ${UNIQUENAME}_SET+= are applied else only the last entry in make.conf.
I don't quite understand your last paragraph (maybe a language barrier;
I say that politely, not insultingly). Can you rephrase for me? Also
how does OPTIONS_SET and OPTIONS_UNSET (talking about the global
variables) fit into this?
Next: the documentation does not state to use '+=' on these entries
in make.conf, it says to use '=':
http://wiki.freebsd.org/Ports/Options/OptionsNG
See, for example, the OPTIONS_SET and OPTIONS_UNSET examples, in
addition to the zsh_SET and zsh_UNSET examples on that web page.
There's nothing about any of this framework in make.conf(5) either.
This is frustrating. There isn't even anything in ports/UPDATING about
any of this, so what am I supposed to go off of? :-(
Additional if you have done `make config' already, then your make.conf entry
is useless since with options NG the OPTIONSFILE has now a higher priority.
Absolutely -- and this is why I outlined (for my case anyway) that
/var/db/ports was empty prior to me doing my tests. I'm well-aware of
the options file and how it takes precedence. :-)
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB
Questions about/issues with new OPTIONS framework
(Please keep me CC'd, as I'm not subscribed to the list) I've been trying to adapt my /etc/make.conf to make use of the new OPTIONS framework. I've run into some snags that I was hoping someone could help me with, as I'm unable to find any official documentation other than these two documents, which don't help me in this case: http://wiki.freebsd.org/Ports/Options/OptionsNG http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html Below are my questions so far. Note that these questions are all preceded by a key fact: /var/db/ports/* is completely empty. Keep that in mind please. 1. databases/mysql55-server and databases/mysql55-client both ask for the same variables (OPENSSL and FASTMTX). I want FASTMTX to be enabled by default for both ports. When I have the following in /etc/make.conf: mysql_SET= FASTMTX Doing make config in databases/mysql55-server shows FASTMTX as checked (which is correct). However, when I do the exact same procedure in databases/mysql55-client, FASTMTX is not checked. I am aware that databases/mysql55-client is a slave port, but I'm not sure how/why that would matter...? What am I doing wrong, or is this a port bug which needs to be fixed by the maintainer? 2. ports/KNOBS is very explicit in stating, and even visually demonstrating (using pipe symbols to delimit length maximums and so on), the following: # - Knob description must be 45 characters or less Yet, a very good number of descriptions violate this (see the file for yourself). I'm inclined to think the limit is to be extra friendly towards 80-column terminals, but I'm still not sure. Is this 45-character-limit untrue, or are numerous descriptions blatantly too long? Thanks. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: cannot install textproc/py-libxml2
On Mon, Jun 06, 2011 at 07:37:46AM +0200, joerg_surmann wrote: Thanks for your reply but it's the same issue: It appears you made a copy-paste typo. Look closely (missing whitespace): /usr/ports/textproc/py-libxml2# make CFLAGS+=-I/usr/local/include/pth-L/usr/local/lib/pth install ... I don't know if this will work, but what you want is: make CFLAGS+=-I/usr/local/include/pth -L/usr/local/lib/pth install Also, this looks to be a freebsd-ports topic, not freebsd-stable. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Problem (again) with portsnap5.FreeBSD.org?
On Wed, Oct 20, 2010 at 09:53:24PM +0200, Barbara wrote: On Wed, 20 Oct 2010 01:11:35 +0200 (CEST) Barbara barbara.xxx1975 at libero.it articulated: $ date Wed Oct 20 01:11:10 CEST 2010 # portsnap fetch update Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found. Fetching snapshot tag from portsnap5.FreeBSD.org... failed. Fetching snapshot tag from portsnap6.FreeBSD.org... done. From time to time, portsnap' does that. It usually remedies itself within 24 hours. Other than being a potential superficial annoyance, I doubt that it causes any serious harm. I have noticed that #5 seems to be the most troublesome server however. My only intention was to report that and not complaining about the annoyance. I just wanted to alter people maintaining #5. If it's expected, no problem. I think freebsd-hubs@ is the list where most of the cvsup and portsnap mirror/owners live. I'd consider posting concerns there. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Users needed or not by ports
On Mon, Oct 11, 2010 at 06:01:46PM +0200, David DEMELIER wrote: Before writing a patch for the ports framework, I just want to be sure that FreeBSD ports shouldn't use a same user added by ports. For example pulseaudio adds some users to the system (pulse, pulse-whatever) and should these users be needed from others ports ? I think this is exactly what ports/UIDs and ports/GIDs is for? These are usable via the USERS and GROUPS directives in the port Makefile. My plan is : 1. Register users added and needed by ports in files like +USERS +GROUPS, 2. When make deinstall or pkg_delete port_name check if the user is still needed by other port (if this is possible) Step #2 is probably where most of the work will need to be done, since now the dependency checks will have to involve checking usernames and groups. I imagine this is why you plan on creating +USERS and +GROUPS files in /var/db/pkg/name, since at present this information isn't tracked there. Be aware that you might get some pushback regarding this method of implementation, due to the increased inode usage on systems which have lots of packages/ports installed. This might sound like a silly argument, but on embedded systems it's a serious concern. An alternative/workaround might be to stick the information (user and group names) into +CONTENTS instead. 3. Print a message like The following users and group are not needed anymore by the system : xxx yyy Some ports already echo this -- you'll need to figure out which ones do and make sure the respective maintainers update their ports to utilise the new framework. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: New mutt-devel problems with text/html processing
On Thu, Oct 07, 2010 at 08:22:09AM -0500, Bob Willcox wrote: The new version of mutt-devel nolonger honors my mailcap entry to invoke lynx when it encounters a text/html file type. Instead it simply displays the raw html text. According to their UPDATING file, they say: all text/* parts can be displayed inline without mailcap Which is suspiciously in the realm of the problem I'm seeing. Perhaps there's now some other way of displaying text/html files w/o mailcap and an external program that I'm missing? Looks relevant, with a response from Michael Elkins explaining the change: http://marc.info/?t=12847709334r=1w=2 Basically, it appears that as of 1.5.21, mutt only displays text/* MIME types using its own internal engine. If you want the old behaviour, when selecting the attachment/entry, press m. Personally I don't like this change, but I'll deal with it. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Issues in installing Gmake and Gcc on FreeBSD
On Tue, Oct 05, 2010 at 05:02:08PM +0530, Chetan Shukla wrote: I am trying to install GCC and Gmake on FreeBSd machine and faced following issues: GCC: Steps: 1)At directory gcc-3.3.2 I ran ./configure -enable-obsolete 2)error returned: Please update *-*-freebsd* in gcc/config.gcc Configure in /usr/home/iptk/gcc-3.3.2/gcc failed, exiting. 3)I have included this string in gcc/config.gcc with architecture string as i386 but still facing same issue. The configuration and version details: Machine arch:i386 FreeBSD version: FreeBSD 8.0-RELEASE #0: GCC version :gcc-3.3.2 Gmake: Steps: 1)I have un tarred the gmake-3.79.1.tgz but it did not create any gmake-3.79.1 directory. 2)Hence I am unable to run ./configure and make and make install. The hardware details remain same. The system is not connected to Internet so I cannot use pkg-add. To give backdrop all this is needed to port linux code to FreeBSD. Please let me know your inputs on the above, Also please excuse me if it is wrong mailing list and please redirect it to the correct one. GCC on FreeBSD is special in the sense that you should either use the version that's included in the base system (4.2.1 as of 8.0-RELEASE), or if you need an older/different version, install it from ports/packages. The same goes for gmake. You managed to get the source code to both gcc and gmake on a system which isn't connected to the Internet, so surely you could download the binary versions of the FreeBSD packages and install those...? Take a peek in: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/ Look for gcc* and gmake*. These are probably what you want: -rw-r--r--1 110 1002 351139 Oct 20 2009 gmake-3.81_3.tbz -rw-r--r--1 110 1002 14269507 Oct 20 2009 gcc-3.4.6_3,1.tbz If you download these packages, you can get them onto the machine however possible and simply pkg_add the files (literally: pkg_add xxx.tbz). You might have to download some dependency packages, but pkg_add should tell you what those are if needed. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: package generation on FreeBSD ftp server
On Fri, Oct 01, 2010 at 08:17:53AM +0200, Rainer Hurling wrote: I have a question about packages at ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/ . They are automatically generated from time to time. I understand that this depends on computing capacities on the server farm etc. So some packages are relatively new, some are older and some are missing... For example, for math/saga there had been a package saga-2.0.4_4.tbz for some time. After updating SAGA GIS to version 2.0.5 there is no package any more. There was an error on building math/saga in first half of september, see http://portsmon.freebsd.org/portoverview.py?portname=saga This was corected and the new SAGA GIS version has to differentiate between i386 and amd64 because of dependency libiodbc (patch problem). Does this prevent from automatic package generation? I would be happy if someone could give an explaination on this. My impression has always been that the packages **are not** updated automatically, and are done manually + updated manually by someone. This is confirmed by the high amount of variance in timestamps on all the symlinks in the All/ directory (see for yourself). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Error postgresql90-contrib
On Tue, Sep 28, 2010 at 01:07:33AM +0200, Samuel MartÃn Moro wrote: On Tue, Sep 28, 2010 at 12:40 AM, Robert Fitzpatrick li...@webtent.netwrote: Getting this error when trying to install the port... pgbench.o(.text+0x2b0a): In function `main': : undefined reference to `pthread_create' gmake[1]: *** [pgbench] Error 1 gmake[1]: Leaving directory `/usr/ports/databases/postgresql90-contrib/work/postgresql-9.0.0/contrib/pgbench' gmake: *** [all] Error 2 *** Error code 2 Would it have anything to do with any of these ports built with threads: db2# grep -ir thread /var/db/ports /var/db/ports/perl/options:WITH_THREADS=true /var/db/ports/python26/options:WITH_THREADS=true /var/db/ports/apr/options:WITH_THREADS=true /var/db/ports/apache22/options:WITH_THREADS=true /var/db/ports/pico-alpine/options:WITH_THREADS=true Thanks for any help. ___ 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 obviously, the binary is not compiled with the required library. is pgbench correctly linked with pthread lib (-lpthread) is pthread lib file actually there (in /usr/lib/, libpthread.so and libpthread.a) adding to -lpthread the -L/usr/lib option might also help if that doesn't help, can you send a link to the complete output of compilation? This won't help the OP, but: please be aware this isn't how things are done, and may be a bit unintuitive the first time around. Please look at the -pthread option to gcc on FreeBSD (and no that's not a typo). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: source-highlight broken
On Wed, Sep 22, 2010 at 01:16:37PM +0800, Kevin Lo wrote: Mikle Krutov wrote: Sorry, i've thought that everything needed was included into config.log in first message. Complete make log (e.g. make configure.log) in attach. The source-hightlight port is not broken. It builds fine on my 8.1-stable/-current. There's also no error log on http://pointyhat.freebsd.org/errorlogs/ The OP has a pkg_list that consists of 697 packages installed on the machine. Yes, six hundred ninety seven, and many of which look to be outdated or deprecated. I'm sure pkg_version -v and portaudit -Fda would return some amusing results. I would advise the OP to consider cleaning up his system. In these situations, I do: rsync -avH /usr/local/ /usr/local.old/ pkg_delete -a -f rm -fr /usr/ports/distfiles/* find /usr/ports -name work -type d -print0 | xargs -0 rm -fr And start over. portmaster might help keep things up-to-date cleanly going forward, but the existing situation looks dire. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: source-highlight broken
On Tue, Sep 21, 2010 at 11:11:38PM -0700, Jeremy Chadwick wrote: On Wed, Sep 22, 2010 at 01:16:37PM +0800, Kevin Lo wrote: Mikle Krutov wrote: Sorry, i've thought that everything needed was included into config.log in first message. Complete make log (e.g. make configure.log) in attach. The source-hightlight port is not broken. It builds fine on my 8.1-stable/-current. There's also no error log on http://pointyhat.freebsd.org/errorlogs/ The OP has a pkg_list that consists of 697 packages installed on the machine. Yes, six hundred ninety seven, and many of which look to be outdated or deprecated. I'm sure pkg_version -v and portaudit -Fda would return some amusing results. I would advise the OP to consider cleaning up his system. In these situations, I do: rsync -avH /usr/local/ /usr/local.old/ pkg_delete -a -f rm -fr /usr/ports/distfiles/* find /usr/ports -name work -type d -print0 | xargs -0 rm -fr Oh, and I forgot the most important step: rm -fr /usr/local/* :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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/kdelibs4 build fails, can't find docbook
On Tue, Sep 21, 2010 at 03:25:38AM -0400, Janos Dohanics wrote:
On Mon, 20 Sep 2010 19:05:12 -0700
Jeremy Chadwick free...@jdc.parodius.com wrote:
On Mon, Sep 20, 2010 at 06:49:21PM -0700, Jeremy Chadwick wrote:
On Mon, Sep 20, 2010 at 06:20:09PM -0400, Janos Dohanics wrote:
On Mon, 20 Sep 2010 22:07:16 +0200
olli hauer oha...@gmx.de wrote:
On 2010-09-20 07:37, Janos Dohanics wrote:
On Fri, 17 Sep 2010 15:31:18 -0400
Janos Dohanics w...@3dresearch.com wrote:
While building kde4-4.5.1, I get this error:
# make install clean
=== kde4-4.5.1 depends on
file: /usr/local/kde4/bin/kdebugdialog - not found ===
Verifying install [...]
I did some basic troubleshooting, and found that the files do
not get installed in /usr/local/share/xml/docbook/4.2/, except
the /usr/local/share/xml/docbook/4.2/ent directory is created.
This seems to be happening because the port
uses /usr/bin/unzip instead of /usr/local/bin/unzip.
How can I change this behavior so /usr/local/bin/unzip would
be used?
If you haven't redefined UNZIP_CMD or LOCALBASE somewhere
${LOCALBASE}/bin/unzip will be used.
I have not made any change like that.
You can test this with the follwing command in the directory of
the port where you think the wrong unzip will be used.
In case of docbook-420/docbook-xml
cd ${PORTSDIR}/textproc/docbook-(420|xml)
make -V UNZIP_CMD
make -V EXTRACT_CMD
Thank you...
# make -V UNZIP_CMD
/usr/local/bin/unzip
# make -V EXTRACT_CMD
/usr/local/bin/unzip
# which unzip
/usr/bin/unzip
But wait, in your previous mail you have only docbook-4.1 and
not docbook-4.2 in the portversion -vF docbook* listing which
is needed to install docbook-xml correct.
You are right, docbook-4.2 was not installed; I have installed it
now. However, kde4 is still gets stuck with the reinstall
textproc/docbook-xml message (portversion says docbook-xml-4.2_1
is installed, but the files aren't installed
in /usr/local/share/xml/docbook/4.2/).
I guess my problem is that while both UNZIP_CMD and EXTRACT_CMD
point to /usr/local/bin/unzip, the docbook-xml-4.2_1 port still
uses /usr/bin/unzip.
How can I fix this?
Where did /usr/bin/unzip come from? This program isn't part of the
base system on FreeBSD, nor is it on any system I have access to.
I realise you're complaining that the port finds /usr/bin/unzip
instead of /usr/local/bin/unzip, but your which command above
indicates you actually have something in /usr/bin that shouldn't be
there.
I do see /usr/src/usr.bin/unzip on all RELENG_8 systems I have access
to, and I do see mention of this in CVS:
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/unzip/Makefile
But there's no unzip build target in /usr/src/usr.bin/Makefile.
Here's the most recent commit that would be RELENG_8 and RELENG_8_1:
RELENG_8 --
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/Makefile#rev1.324.2.3
RELENG_8_1 --
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/Makefile#rev1.324.2.3.2.1
If you view the content or annotations for these, you won't find any
mention of unzip in the targets (SUBDIR) list.
On the other hand, HEAD/CURRENT do indicate unzip is a target. Are
you running HEAD/CURRENT?
I don't know where did /usr/bin/unzip come from - I first installed
this machine in January of 2010 using 8.0-RELEASE (?). I have rebuilt
it since to 8.1-PRERELEASE (amd64).
Which tags/releases are you using in your supfiles?
This machine was used for some Django application development - I will
ask my developer if he had installed something...
Okay.
From what you say I gather that I could simlink /usr/bin/unzip
to /usr/local/bin/unzip - thank you for your help...
No, do not do this; simply rm /usr/bin/unzip.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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: update bacula-server 5.0.2 - 5.0.3, Undefined symbol ASN1_INTEGER_it
On Tue, Sep 21, 2010 at 08:42:09PM -0400, Wesley Shields wrote: On Tue, Sep 21, 2010 at 07:51:26PM -0400, Dan Langille wrote: On 9/21/2010 4:46 PM, Wesley Shields wrote: On Tue, Sep 21, 2010 at 09:48:50PM +0200, olli hauer wrote: On 2010-09-21 02:24, Wesley Shields wrote: On Mon, Sep 20, 2010 at 07:39:58PM +0200, olli hauer wrote: On 2010-09-19 08:20, Per olof Ljungmark wrote: FreeBSD 7.3-STABLE #0: Tue Sep 7 22:46:59 CEST 2010 p...@candyman.i.inter-sonic.com:/usr/obj/usr/src/sys/GENERIC amd64 Portupgrade of bacula-server 5.0.2 - 5.0.3 Starting bacula_fd. /libexec/ld-elf.so.1: /usr/local/lib/libbac.so.5: Undefined symbol ASN1_INTEGER_it Starting bacula_sd. Starting bacula_dir. If one deselects OPENSSL and recompile bacula-fd will start without complaints. Is this a known issue with 5.0.3? No, can you provide me some more details. First make sure if you have both bacula-server and bacula-client installed on the same machine both are build with(out) ssl support. Both ports install libs with the same name to the same place, but if the client is build/installed first with SSL support, and then the server without SSL support you can see exact the described issue. Shouldn't the two ports register CONFLICTS then, thus making it (normally) impossible for both to be installed on the same host? -- WXS At the moment I'm thinking about to install the client part within the server part as one port and mark bacula-client/bacula-server as conflict. That sounds OK. Should probably rename bacula-server to just bacula then as it will include both the client and the server. And have separate ports for server and client if that's all the user wants. Conflicts will have to be set accordingly. We had bacula before Why don't we just keep it as bacula-server and add an announcement that it now installs bacula-fd by default. Because if it installs both the client and server portions (like Olli is suggesting) we should probably rename it to just bacula again. I would expect that if I installed a bacula-server port that I would get just the server portion and no client portion. For sake of comparison, this isn't how the MySQL port works. Installing mysql51-server pulls in mysql51-client. But installing mysql51-client doesn't pull in mysql51-server. I believe there are other ports which behave the same way as this. The concept makes sense when you consider that the server is a centralised piece of software (usually installed on one machine), and may need to run the client itself (e.g. backup itself). While other machines in the cluster are just clients (they get backed up by the server). Hope this makes sense. :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Q about perl 5.12 and included newer port modules.
On Mon, Sep 20, 2010 at 11:07:33AM -0400, Michael Scheidell wrote: I noticed, while looking at the SpamAssassin Port (p5-Mail-SpamAssassin) that there are at lease one set of pm dependencies that would pull in obsolete (older) ports versions that would overwrite newer, built in modules in perl 5.12. [...] As the port maintainer for p5-Mail-SpamAssassin, I am looking for ideas, policies, procedures for handling something like this. For the SA port, I can always use if/else statements in the run and build dependencies, looking for PERL version, BUT:. that only handles the immediate issue. [...] First and foremost, thank you for maintaining p5-Mail-SpamAssassin! This is a port we rely on heavily given our hosting role. :-) As I understand it, perl version checking mostly solves the issue. The way it works in pretty much every other port is: you check PERL_LEVEL. Yes, it can get hairy and out of control depending on how many dependencies are required, but the most PERL_LEVEL checks a single port Makefile has is 4 (devel/p5-CPANPLUS). That rough number comes from: grep -r -c PERL_LEVEL /usr/ports | sort -t: -k2 -n | tail -20 I say mostly because there are two one-off cases I can think of, and probably more: 1) If the module version that comes built-in to perl 5.12 doesn't work with SpamAssassin, in which case you need to open up a bug report with them to get it fixed upstream + provide a patch (in p5-Mail-SpamAssassin/files) to temporarily fix the issue. 2) Situations like the RUN_DEPENDS entry for Time::HiRes. I question the mandatory nature of this dependency when the user has something like perl 5.10.2 or perl 5.12 installed. I assume this was done because the version included with perl, at one time, was broken/outdated -- was this ever fixed? If so, PERL_LEVEL fix it. soapbox Welcome to the problem with software that ends up pulling in a zillion dependencies. I have a very young colleague who a few years ago used to tell me why do you care about the large number of perl module dependencies? You're just whining. Fast forward to a few weeks ago, where I caught him complaining about how many his system had installed on it. This model of creeping featurism is becoming more prominent today; for sake of example, why does Apache 2.2 now require Python to build? Sometimes I feel like I'm the only person who questions such design choices in software these days. /soapbox Either case, this does go beyond just on perl port (p5-Mail-SpamAssassin)? or should we update any pm's that are older than 5.12? I can assure you the latter point won't fly -- there are many perl modules which break backwards compatibility (or start emitting warnings when used with newer perl) when a new version is released. Meaning: version 2.598 is not necessarily better than version 2.711. If there are a limited number of these scenarios, it would make most sense for a new port to be created for that specific version of the module and port Makefiles updated to refer to it. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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/kdelibs4 build fails, can't find docbook
On Mon, Sep 20, 2010 at 06:20:09PM -0400, Janos Dohanics wrote:
On Mon, 20 Sep 2010 22:07:16 +0200
olli hauer oha...@gmx.de wrote:
On 2010-09-20 07:37, Janos Dohanics wrote:
On Fri, 17 Sep 2010 15:31:18 -0400
Janos Dohanics w...@3dresearch.com wrote:
While building kde4-4.5.1, I get this error:
# make install clean
=== kde4-4.5.1 depends on
file: /usr/local/kde4/bin/kdebugdialog - not found ===
Verifying install [...]
I did some basic troubleshooting, and found that the files do not
get installed in /usr/local/share/xml/docbook/4.2/, except
the /usr/local/share/xml/docbook/4.2/ent directory is created.
This seems to be happening because the port uses /usr/bin/unzip
instead of /usr/local/bin/unzip.
How can I change this behavior so /usr/local/bin/unzip would be
used?
If you haven't redefined UNZIP_CMD or LOCALBASE somewhere
${LOCALBASE}/bin/unzip will be used.
I have not made any change like that.
You can test this with the follwing command in the directory of the
port where you think the wrong unzip will be used.
In case of docbook-420/docbook-xml
cd ${PORTSDIR}/textproc/docbook-(420|xml)
make -V UNZIP_CMD
make -V EXTRACT_CMD
Thank you...
# make -V UNZIP_CMD
/usr/local/bin/unzip
# make -V EXTRACT_CMD
/usr/local/bin/unzip
# which unzip
/usr/bin/unzip
But wait, in your previous mail you have only docbook-4.1 and not
docbook-4.2 in the portversion -vF docbook* listing which is
needed to install docbook-xml correct.
You are right, docbook-4.2 was not installed; I have installed it now.
However, kde4 is still gets stuck with the reinstall
textproc/docbook-xml message (portversion says docbook-xml-4.2_1 is
installed, but the files aren't installed
in /usr/local/share/xml/docbook/4.2/).
I guess my problem is that while both UNZIP_CMD and EXTRACT_CMD point
to /usr/local/bin/unzip, the docbook-xml-4.2_1 port still
uses /usr/bin/unzip.
How can I fix this?
Where did /usr/bin/unzip come from? This program isn't part of the base
system on FreeBSD, nor is it on any system I have access to. I realise
you're complaining that the port finds /usr/bin/unzip instead of
/usr/local/bin/unzip, but your which command above indicates you
actually have something in /usr/bin that shouldn't be there.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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/kdelibs4 build fails, can't find docbook
On Mon, Sep 20, 2010 at 06:49:21PM -0700, Jeremy Chadwick wrote:
On Mon, Sep 20, 2010 at 06:20:09PM -0400, Janos Dohanics wrote:
On Mon, 20 Sep 2010 22:07:16 +0200
olli hauer oha...@gmx.de wrote:
On 2010-09-20 07:37, Janos Dohanics wrote:
On Fri, 17 Sep 2010 15:31:18 -0400
Janos Dohanics w...@3dresearch.com wrote:
While building kde4-4.5.1, I get this error:
# make install clean
=== kde4-4.5.1 depends on
file: /usr/local/kde4/bin/kdebugdialog - not found ===
Verifying install [...]
I did some basic troubleshooting, and found that the files do not
get installed in /usr/local/share/xml/docbook/4.2/, except
the /usr/local/share/xml/docbook/4.2/ent directory is created.
This seems to be happening because the port uses /usr/bin/unzip
instead of /usr/local/bin/unzip.
How can I change this behavior so /usr/local/bin/unzip would be
used?
If you haven't redefined UNZIP_CMD or LOCALBASE somewhere
${LOCALBASE}/bin/unzip will be used.
I have not made any change like that.
You can test this with the follwing command in the directory of the
port where you think the wrong unzip will be used.
In case of docbook-420/docbook-xml
cd ${PORTSDIR}/textproc/docbook-(420|xml)
make -V UNZIP_CMD
make -V EXTRACT_CMD
Thank you...
# make -V UNZIP_CMD
/usr/local/bin/unzip
# make -V EXTRACT_CMD
/usr/local/bin/unzip
# which unzip
/usr/bin/unzip
But wait, in your previous mail you have only docbook-4.1 and not
docbook-4.2 in the portversion -vF docbook* listing which is
needed to install docbook-xml correct.
You are right, docbook-4.2 was not installed; I have installed it now.
However, kde4 is still gets stuck with the reinstall
textproc/docbook-xml message (portversion says docbook-xml-4.2_1 is
installed, but the files aren't installed
in /usr/local/share/xml/docbook/4.2/).
I guess my problem is that while both UNZIP_CMD and EXTRACT_CMD point
to /usr/local/bin/unzip, the docbook-xml-4.2_1 port still
uses /usr/bin/unzip.
How can I fix this?
Where did /usr/bin/unzip come from? This program isn't part of the base
system on FreeBSD, nor is it on any system I have access to. I realise
you're complaining that the port finds /usr/bin/unzip instead of
/usr/local/bin/unzip, but your which command above indicates you
actually have something in /usr/bin that shouldn't be there.
I do see /usr/src/usr.bin/unzip on all RELENG_8 systems I have access
to, and I do see mention of this in CVS:
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/unzip/Makefile
But there's no unzip build target in /usr/src/usr.bin/Makefile. Here's
the most recent commit that would be RELENG_8 and RELENG_8_1:
RELENG_8 --
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/Makefile#rev1.324.2.3
RELENG_8_1 --
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/Makefile#rev1.324.2.3.2.1
If you view the content or annotations for these, you won't find any
mention of unzip in the targets (SUBDIR) list.
On the other hand, HEAD/CURRENT do indicate unzip is a target. Are you
running HEAD/CURRENT?
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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: Double versions installed
On Sun, Sep 19, 2010 at 10:33:23PM +0200, Jos Chrispijn wrote: On 19-9-2010 19:01, Erik Trulsson wrote: That is perfectly normal. Some programs require one specific version of autoconf, while others require another version, so one easily ends up with more than one version installed. They can live side-by-side so having more than one version installed is not a problem. I see. But out of a programmers point of view, I would never stick to my old versions but update to newer ones because I need to catch up with other new program versions that need mine. In this way a programmer is forced to keep maintaining his older version allthough he moves forward with the rest of the crowd. You've never worked with GNU autotools, have you? :-) It's fairly well-established that they break in different ways every time there's a new release, or certain macros are deprecated/changed in an incompatible way. This is not hearsay, this is fact. Therefore, if a piece of third-party software requires autoconf or automake to build its configure scripts or Makefiles, it's up to the port maintainer of said third-party software to make sure that the correct autoconf/automake version is selected. Sometimes it's even worse than that: the configure scripts that come with the third-party software may have been built on the developers' machine using a buggy version of autoconf. In this case, sometimes the only solution is for the port to include (as a dependency) a version of autoconf that builds a working/proper configure script. I realise this sounds crazy (how can someone release software that's broken out of the box like that?), but it's absolutely true. Simply put: the latest and greatest concept does not apply to the autotools, and what you see in the FreeBSD ports system is validation/proof of that. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Fwd: Tomcat6 port keeps locking up??
On Fri, Sep 17, 2010 at 11:37:13AM +0300, Kaya Saman wrote: This is a snapshot of the 'top' command that shows Java at 100%. Basically it means that the system is more in this state then functional and I can't understand why! Can anyone help me?? You should probably spend a bit of time in a debugger (specifically a Java debugger) figuring out if your code is spinning or not. Debugging anything under Tomcat/Java is a PITA, and I say that from experience. I would advocate you open up a bug/report with the Apache folks and provide them this information, especially if the only thing you're seeing problems with is Tomcat (and not other software). For example -- at my workplace we run Solaris 10, with Tomcat heavily used for different purposes (mainly a translation layer between HTTP and Cisco ICR protocols). For years we saw a problem where a Tomcat thread would take up 100% CPU (ex. on a 4-core machine, 25% CPU) when a Cisco PG would disconnect/reconnect repetitively (common during network problems). The problem turned out to be two fold: a bug in Tomcat, and some improper code on our part, resulted in Tomcat spinning. We did not open up a SunSolve case because there wouldn't have been a point to it. Otherwise I will have to start looking at migrating this service away from BSD and much more costlier option of Nexenta based on OpenSolaris, but hogs RAM as uses ZFS natively meaning min 4GB unlike my FreeBSD build with ZFS and UFS2 using 4GB for that many processes and 7 jails! I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more memory, the Solaris kernel dynamically releases portions of the ARC. We use ZFS on Solaris 10 exclusively at my day job (thousands of x86 servers). When we moved to ZFS, we had to adjust our system memory monitors to take into consideration ARC usage. What I'm trying to say: on Solaris with ZFS, don't let I don't see any free memory in top or prstat equate to there isn't any free memory available for applications. Solaris handles this situation very, *very* well; we have never seen any userland applications get starved for memory as a result of using ZFS on all of our machines. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Fwd: Tomcat6 port keeps locking up??
On Fri, Sep 17, 2010 at 12:19:00PM +0300, Andriy Gapon wrote: on 17/09/2010 11:56 Jeremy Chadwick said the following: I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more ^ memory, the Solaris kernel dynamically releases portions of the ARC. Can you please explain that unlike part? When ZFS was first introduced to FreeBSD, I was given the impression from continual posts on the mailing lists that memory which was allocated to the ARC was never released in the situation that a userland program wanted memory. An example scenario. These numbers are in no way accurate given many other things (network mbufs, UFS and VFS cache, etc.): - amd64 system has 2GB physical RAM (assume ~1920MB usable) - vm.kmem_size=1536M + vfs.zfs.arc_max=1400M - Heavy ZFS I/O results in ARC maxing out at ~1400MB - Userland application runs, requests malloc() of 1024MB - Userland gets 384MB from physical RAM, remaining 640MB from swap - ARC remains at 1400MB Is this no longer the case? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Fwd: Tomcat6 port keeps locking up??
On Fri, Sep 17, 2010 at 12:53:09PM +0300, Andriy Gapon wrote: on 17/09/2010 12:42 Jeremy Chadwick said the following: On Fri, Sep 17, 2010 at 12:19:00PM +0300, Andriy Gapon wrote: on 17/09/2010 11:56 Jeremy Chadwick said the following: I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more ^ memory, the Solaris kernel dynamically releases portions of the ARC. Can you please explain that unlike part? When ZFS was first introduced to FreeBSD, I was given the impression from continual posts on the mailing lists that memory which was allocated to the ARC was never released in the situation that a userland program wanted memory. An example scenario. These numbers are in no way accurate given many other things (network mbufs, UFS and VFS cache, etc.): - amd64 system has 2GB physical RAM (assume ~1920MB usable) - vm.kmem_size=1536M + vfs.zfs.arc_max=1400M - Heavy ZFS I/O results in ARC maxing out at ~1400MB - Userland application runs, requests malloc() of 1024MB - Userland gets 384MB from physical RAM, remaining 640MB from swap - ARC remains at 1400MB Is this no longer the case? I am not sure if this has even been the case :-) It is definitely not the case now. I trust your experience with it *much* more than mine. :-) It's very likely that I'm basing the ARC remains at 1400MB claim entirely off of what top(1) was showing under either Inact or Wired. The terminology in top(1) for memory on BSD has always confused the hell out of me. That might sound crazy coming from someone that's been using *IX since 1990 and BSD since 1996, but it's true. The man page does go over what's what, but the descriptions are short one-liners (ex. wired down doesn't mean anything to me). This just circles back to my lack of knowledge about the VM. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Can't fetch libxml2-2.7.7.tar.gz
On Fri, Sep 17, 2010 at 03:52:01PM +0200, Leslie Jensen wrote: When building the meta port xorg I get an error saying libxml2-2.7.7.tar.gz local modification time does not match remote Ports tree is updated with portsnap update. Any advise ? Can't reproduce... # pkg_info | grep libxml2 libxml2-2.7.7 = up-to-date with port # cd /usr/ports/textproc/libxml2 # ls -l total 10 -rw-r--r-- 1 root wheel 2016 Jun 25 00:23 Makefile -rw-r--r-- 1 root wheel 218 May 11 05:18 distinfo drwxr-xr-x 2 root wheel 512 May 11 05:18 files -rw-r--r-- 1 root wheel 339 Jan 15 2007 pkg-descr -rw-r--r-- 1 root wheel 1822 May 11 2006 pkg-plist # egrep ^PORT Makefile PORTNAME= libxml2 PORTVERSION=2.7.7 PORTREVISION?= 0 # cat distinfo MD5 (gnome2/libxml2-2.7.7.tar.gz) = 9abc9959823ca9ff904f1fbcf21df066 SHA256 (gnome2/libxml2-2.7.7.tar.gz) = af5b781418ba4fff556fa43c50086658ea8a2f31909c2b625c2ce913a1d9eb68 SIZE (gnome2/libxml2-2.7.7.tar.gz) = 4868502 -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Can't fetch libxml2-2.7.7.tar.gz
On Fri, Sep 17, 2010 at 04:36:20PM +0200, Leslie Jensen wrote: On 2010-09-17 16:25, Jeremy Chadwick wrote: On Fri, Sep 17, 2010 at 03:52:01PM +0200, Leslie Jensen wrote: When building the meta port xorg I get an error saying libxml2-2.7.7.tar.gz local modification time does not match remote Ports tree is updated with portsnap update. Any advise ? Can't reproduce... # pkg_info | grep libxml2 libxml2-2.7.7 = up-to-date with port # cd /usr/ports/textproc/libxml2 # ls -l total 10 -rw-r--r-- 1 root wheel 2016 Jun 25 00:23 Makefile -rw-r--r-- 1 root wheel 218 May 11 05:18 distinfo drwxr-xr-x 2 root wheel 512 May 11 05:18 files -rw-r--r-- 1 root wheel 339 Jan 15 2007 pkg-descr -rw-r--r-- 1 root wheel 1822 May 11 2006 pkg-plist # egrep ^PORT Makefile PORTNAME= libxml2 PORTVERSION=2.7.7 PORTREVISION?= 0 # cat distinfo MD5 (gnome2/libxml2-2.7.7.tar.gz) = 9abc9959823ca9ff904f1fbcf21df066 SHA256 (gnome2/libxml2-2.7.7.tar.gz) = af5b781418ba4fff556fa43c50086658ea8a2f31909c2b625c2ce913a1d9eb68 SIZE (gnome2/libxml2-2.7.7.tar.gz) = 4868502 I get r...@bljbsd01/usr/ports/textproc/libxml2:make install clean === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Extracting for libxml2-2.7.7 = MD5 Checksum mismatch for gnome2/libxml2-2.7.7.tar.gz. = SHA256 Checksum mismatch for gnome2/libxml2-2.7.7.tar.gz. === Refetch for 1 more times files: gnome2/libxml2-2.7.7.tar.gz gnome2/libxml2-2.7.7.tar.gz === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE = libxml2-2.7.7.tar.gz doesn't seem to exist in /usr/ports/distfiles/gnome2. = Attempting to fetch from ftp://fr.rpmfind.net/pub/libxml/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Attempting to fetch from ftp://gd.tuwien.ac.at/pub/libxml/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Attempting to fetch from ftp://xmlsoft.org/libxml2/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/gnome2/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/gnome2 and try again. *** Error code 1 It looks to me like the tarball you have in /usr/ports/distfiles, probably from a previous build attempt, it incomplete or corrupt. The checksum validation failure is proof of this. I'm betting the file on your system is too small. ls -l /usr/ports/distfiles/gnome2/libxml2-2.7.7.tar.gz should tell you what size the file is. A proper file: -rw-r--r--1 root wheel 4868502 15 Mar 2010 /usr/ports/distfiles/gnome2/libxml2-2.7.7.tar.gz I think the modification time mismatch indicates that fetch is trying to resume the transfer (e.g. pick up where the corrupted file left off), but the resume can't happen for the above reason. If you attempt make distclean, then make install clean, it should re-fetch the entire tarball from scratch. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Wed, Sep 15, 2010 at 12:19:43AM -0700, per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: ... Is it really absolutely necessary to stop a service before it's files go away? IMO the only time the ports infrastructure itself should do this is if it isn't possible to pkg_delete the port cleanly if it's running. For example, if there is a file being held open that cannot be deleted unless the service is stopped ... Which should be an exceedingly rare circumstance, since the fact of some process(es) having a file open will not ordinarily prevent the removal of any or all directory entries pointing to it. The inode and disk space won't actually be released until the last such process closes the file, but another file could be created having the same pathname as the one whose prior directory entry was removed. ...which also makes the assumption the daemon doesn't do stat(2) or similar to verify a file exists, or does a multitude of other things that might act on a filesystem but not an open descriptor. We can sit here discussing what a daemon might do or not do until we're blue in the face, which is why I tend to side with Doug's argument that these sorts of tasks (stopping daemons, starting daemons, etc.) should be left to the administrator. I sympathise with the OP, but as I stated previously: what kind of administrator upgrades software, especially a daemon, then doesn't test/check to make sure everything's running correctly after the upgrade? I would rather we not try to solve a borderline social problem with software. But, also like Doug, I see the validity in the need for an automated upgrade infrastructure/framework that can provide daemon auto-stop and auto-start (I strongly oppose the latter) if desired. I just don't know how feasible that is, or if it's worth the time. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Sat, Sep 11, 2010 at 08:09:28PM -0400, Wesley Shields wrote: On Sat, Sep 11, 2010 at 05:33:59PM +0300, Ion-Mihai Tetcu wrote: On Sat, 11 Sep 2010 22:29:02 +0900 Norikatsu Shigemura n...@freebsd.org wrote: Hi wxs and jpaetzel. I noticed that dhcpd server stoped after portupgrade, sometimes. It's a painful accident on my network. Because I didn't notice some troubles:-(. Why do you stop the daemons? Is it really absolutely necessary to stop a service before it's files go away? SEE ALSO: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html#AEN5402 $ grep forcestop isc-dhcp*/pkg-plist isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh forcestop 2/dev/null || true isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay forcestop 2/dev/null || true isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd.sh forcestop 2/dev/null || true isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop 2/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh forcestop 2/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay forcestop 2/dev/null || true isc-dhcp41-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop 2/dev/null || true I want to remove these lines in pkg-plist. This 'stop the service before we install' seems to be a new fashion, usually unneeded/disruptive. IMO this should only happen when it's really needed, and with some big warning printed. This is there because that is how the old ISC ports were done. I'm not a fan of this at all. If it doesn't break upgrades I'm going to remove it. Ports/packages should keep their grubby little hands off my services. ;) This problem affects more than just ISC-related ports. It's scattered all over many, and probably for a good reason. Has anyone taken the time to actually study how the daemon behaves in all possible circumstances if you pull certain files out from underneath it? Meaning, pkg_delete might delete/clean up something that the daemon relies upon. For example, with regards to isc-dhcp, has anyone checked the implications of removing the files it does with the daemon still running? Have they tested such with all configuration (e.g. LDAP in use)? For example, I know that with postfix if you let the daemon remain running when pkg_delete'ing the software, it starts freaking out whenever any mail I/O happens. And what about ports like mysqlXX-server? You get my point. I'm actually in favour of having ports ***not*** touch services at all, but I want to be absolutely sure people aren't jumping the gun claiming oh it's totally safe when there's a good chance it might not be. But to play devil's advocate once again: this discussion started because the OP uninstalled or upgraded a port which made use of a daemon, which was (possibly rightfully so) shut down during pkg_delete, and he forgot to restart the daemon. No offence intended, but what administrator upgrades software (a service nonetheless) and then walks away from his computer? Please think about that for a while too, and ask yourself if catering to this mentality through software (ports framework) is a good idea. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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-toolkits/linux-pango disable vulnerabilities
On Fri, Sep 10, 2010 at 10:14:55AM +0100, David Southwell wrote: There have been a number of postings by others in regard to pango but no useful responses except jhell jh...@dataix.net whos suggested compiling using make -DDISABLE_VULNERABILITIES=yes install clean This is incorrect syntax. The command sshould be: make DISABLE_VULNERABILITIES=yes install clean This is the 2nd time this has come up in under a week: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-09/msg00037.html -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: kdehier4 upgrade - Operation not permitted
On Sun, Sep 05, 2010 at 10:19:50PM -0500, Troy wrote: When trying to install kdehier4, the following errors show up. Any ideas? -Troy /usr/ports/misc/kdehier4# make install === Installing for kdehier4-1.0.6 === Generating temporary packing list === Checking if misc/kdehier4 already installed /bin/ln -sf /usr/local/libdata/ldconfig /usr/local/kde4/libdata/ /bin/ln -sf /usr/local/libdata/ldconfig32 /usr/local/kde4/libdata/ /bin/ln -sf /usr/local/libdata/pkgconfig /usr/local/kde4/libdata/ /bin/ln -sf /usr/local/share/PolicyKit/policy /usr/local/kde4/share/PolicyKit/ ln: /usr/local/kde4/share/PolicyKit//policy: Operation not permitted *** Error code 1 Please provide output from the following: /sbin/sysctl kern.securelevel /bin/ls -ldo /usr/local/share/PolicyKit/policy /bin/ls -ldo / /bin/ls -ldo /usr/local /bin/ls -ldo /usr/local/kde4 /bin/ls -ldo /usr/local/kde4/share /bin/ls -ldo /usr/local/kde4/share/PolicyKit -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: textproc/uni2ascii build failure on FreeBSD 7.3
On Tue, Aug 31, 2010 at 04:27:59PM +1000, andrew clarke wrote: uni2ascii no longer builds on FreeBSD 7.3: cc -DNEWSUMMARY -O2 -fno-strict-aliasing -pipe -o ascii2uni ascii2uni.o enttbl.o GetWord.o putu8.o SetFormat.o ascii2uni.o(.text+0xb23): In function main': : undefined reference to getline' FreeBSD 7.x's libc does not include getline(3). The port will have to be modified to probably bring in devel/libgetline and custom patches made to work when built on that OS. Alternatively, one could try and get the author (CC'd) to restore getline.c in the official source but only build it/make use of it when a specific configure or make flag is specified. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: current ports Mk make fetch calls wget fails to support schemes
On Tue, Aug 31, 2010 at 07:39:32PM +0200, Julian H. Stacey wrote:
Submitter-Id:current-users
Originator: Julian H. Stacey
Organization:http://berklix.com BSD Linux Unix Consultancy,
Munich/Muenchen.
Confidential:no
Synopsis:current ports Mk make fetch calls wget fails to support schemes
Severity:serious
Priority:high
Category:ports
Class: sw-bug
Release: current
Environment:
System: FreeBSD fire.js.berklix.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Mon
Jul 12 00:59:43 CEST 2010
j...@fire.js.berklix.net:/usr1/src/sys/amd64/compile/FIRE64.small amd64
Description:
Using a base of 8.0-RELEASE
cd /pri/FreeBSD/branches/-current/ports
setenv PORTSDIR `/bin/pwd`
cd sysutils/tarsnap
make fetch
Mk/ has regressed in current now fails to fetch URLS of type
file:///usr/bla/
/usr/bla/
with error:
/usr/home/jhs/tmp/tarsnap-autoconf-1.0.27.tgz: Unsupported scheme.
file:///host/gate/usr/home/jhs/tmp/tarsnap-autoconf-1.0.27.tgz: \
Unsupported scheme.
From make.conf fragment:
DIS_LOCAL+= /usr/home/jhs/tmp/distfiles/
DIS_LOCAL+= file:///usr/home/jhs/tmp/distfiles/
MASTER_SITE_OVERRIDE= ${DIS_LOCAL}
make fetch used to call src/ BSD licensed fetch
it now calls FSF GNU licensed wget,
You can see why it fails with
cd sysutils/tarsnap ; make fetch-list
Even after one has found where
Unsupported scheme
comes from tried to work round it with make.conf assertion of
FETCH_BINARY=/usr/bin/fetch
as shown in bsd.port.mk
/usr/src/usr.bin/fetch is still not used.
How-To-Repeat:
See above
Fix:
Revert Mk invocation back to longer invoke FSF/GNU licensed
wget instead again invoke BSD licensed src/ provided fetch,
until such time as wget might be capable of offering all
schemes BSD fetch already does.
Hmm... Can't reproduce it here, but this is now the 2nd report of this
problem to hit -ports.
# uname -a
FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Mon Aug 2 07:35:23
PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64
amd64
# cd /usr/ports/sysutils/tarsnap
# make fetch
=== License check disabled, port has not defined LICENSE
=== tarsnap-1.0.27 depends on file: /usr/local/bin/wget - found
= tarsnap-autoconf-1.0.27.tgz doesn't seem to exist in /usr/ports/distfiles/.
= Attempting to fetch from https://www.tarsnap.com/download/.
--2010-08-31 10:54:32--
https://www.tarsnap.com/download/tarsnap-autoconf-1.0.27.tgz
Resolving www.tarsnap.com... 208.79.82.75
Connecting to www.tarsnap.com|208.79.82.75|:443... connected.
WARNING: cannot verify www.tarsnap.com's certificate, issued by
`/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
Certification Authority/serialNumber=07969287':
Self-signed certificate encountered.
HTTP request sent, awaiting response... 200 OK
Length: 587420 (574K) [application/x-gzip]
Saving to: `tarsnap-autoconf-1.0.27.tgz'
100%[==]
587,420 596K/s in 1.0s
2010-08-31 10:54:34 (596 KB/s) - `tarsnap-autoconf-1.0.27.tgz' saved
[587420/587420]
# grep -ri wget /usr/ports/Mk
#
My ports tree was last updated a couple hours ago.
I can confirm that GNU wget doesn't support the file:/// URI and does
return unsupported scheme.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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 next for the pkg_install rewrite
On Mon, Aug 30, 2010 at 11:27:58AM +0200, Ivan Voras wrote: On 30 August 2010 09:27, Anonymous swel...@gmail.com wrote: We can as well use Lua tables to store package database. Their syntax is close to JSON. Besides, I think it's better to divorce ports from base so that pkg_* tools can evolve faster and are not limited to dependencies from base. The only thing we'd need to leave in base is smth like pkg_bootstrap. IMO, this chicken and egg problem is getting quite annoying. Speaking of Lua, I had a thread on this in -current which went IMO fairly well, mostly because Lua is a clean and easy language to import compared to, e.g. Perl, TCL or Python. As I see it, there will not be heavy opposition if Lua is to be imported. In short, if there is going to be a scripting language for pkg_*, Lua is sort-of pre-approved - as opposed to ksh and others mentioned here. Lua would make a nice addition for an unrelated reason (I don't follow -current so someone may have mentioned this already): there is an interest in replacing the Forth/FICL pieces of the FreeBSD bootloader with something in Lua instead. Rink Springer and I discussed this (either in Email or on IRC, I forget), and both of us have interest in such. For those curious about Lua, I highly recommend the book Programming in Lua (2nd Edition). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On Fri, Aug 27, 2010 at 12:46:48PM -0400, Glen Barber wrote: On 8/27/10 12:33 PM, Kurt Jaeger wrote: Hi! I have a few clamav instances running in jails on 32-bit hosts without any issues. A few days ago one of these jails was migrated to a 64-bit host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when queried. The issue seems specific to 32bit/64bit compatibility. I have a gdb session available here: http://gist.github.com/549964 Any thoughts on if this is possible? Try Bytecode no in clamd.conf ? It was set to 'yes' initially. I thought it was disabled with building without JIT. At any rate, no, it still segfaults with the same backtrace. 1) Is clamd built with debugging symbols enabled? If not, you might want to rebuild it with such, else it might be difficult to debug the problem. Also, if the segfault happens after performing the above, can you provide output from bt full instead of just bt? 2) Was the software rebuilt from source after the upgrade from i386 to amd64, or are you expecting the software to work without any hitches running on amd64 with lib32 (32-bit compatibility libaries)? The latter is not always possible/the case. I have no familiarity with the software or functions in question, but an initial guess would be that some piece of the code is making assumptions about the size of pointers (expecting 4 (32-bit) rather than 8 (64-bit)). Speculative on my part, but I ponder such when seeing code like somefunc(sizeof(int)). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On Fri, Aug 27, 2010 at 01:06:49PM -0400, Glen Barber wrote: On 8/27/10 12:54 PM, Jeremy Chadwick wrote: On Fri, Aug 27, 2010 at 12:46:48PM -0400, Glen Barber wrote: On 8/27/10 12:33 PM, Kurt Jaeger wrote: Hi! I have a few clamav instances running in jails on 32-bit hosts without any issues. A few days ago one of these jails was migrated to a 64-bit host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when queried. The issue seems specific to 32bit/64bit compatibility. I have a gdb session available here: http://gist.github.com/549964 Any thoughts on if this is possible? Try Bytecode no in clamd.conf ? It was set to 'yes' initially. I thought it was disabled with building without JIT. At any rate, no, it still segfaults with the same backtrace. 1) Is clamd built with debugging symbols enabled? If not, you might want to rebuild it with such, else it might be difficult to debug the problem. It wasn't initially, but is now. Also, if the segfault happens after performing the above, can you provide output from bt full instead of just bt? Of course. The new backtrace is here: http://gist.github.com/553734 I want to make sure I understand the environment -- on a native i386 (32-bit) FreeBSD host, the software works fine. But on a native amd64 (64-bit) FreeBSD host, the software segfaults. Correct? If so -- it appears as if the system you're providing the backtrace from is a 32-bit system, or within a 32-bit environment? I would expect to see 64-bit addresses in the backtrace, yet they're all 32-bit. I'm not familiar with jailed environments (or the concept/possibility of running a mixed-architecture jail (e.g. 64-bit host OS with 32-bit jails)). I don't use lib32 on my amd64 systems. I did take a look at the clamav code itself (I'd have to spend a few hundred lines outlining it here and would rather not). My guess is that there's a conflict between what the running OS architecture is and what the build process determines the architecture is. Given that you have jails, and possibly a mixed architecture environment on a single host (e.g. 64-bit host OS with 32-bit jails), can you explain exactly how you go about building clamav, followed by how you go about running it? Thanks. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On Fri, Aug 27, 2010 at 01:58:25PM -0400, Glen Barber wrote: On 8/27/10 1:32 PM, Jeremy Chadwick wrote: Of course. The new backtrace is here: http://gist.github.com/553734 I want to make sure I understand the environment -- on a native i386 (32-bit) FreeBSD host, the software works fine. But on a native amd64 (64-bit) FreeBSD host, the software segfaults. Correct? The clamav instance runs on a 64-bit host in a 32-bit jail. In a 32-bit host/32-bit jail environment, the software runs fine, as you suggest above. If so -- it appears as if the system you're providing the backtrace from is a 32-bit system, or within a 32-bit environment? I would expect to see 64-bit addresses in the backtrace, yet they're all 32-bit. I'm not familiar with jailed environments (or the concept/possibility of running a mixed-architecture jail (e.g. 64-bit host OS with 32-bit jails)). I don't use lib32 on my amd64 systems. To be honest, this is the first non-base software I've had an issue with in a mixed-arch environment. Okay, so it's sort of what I thought. Your system has a series of include files on it that are for amd64 (64-bit), but clamav, when built within a 32-bit jail on that system, is (probably -- no proof, but it's an educated guess based on what's happening) detecting some 64-bit pieces through include files and making some incorrect assumptions about the size of some types. I'd really need to set up a testbed system/VM and get full instructions from start to finish on how to set up a 32-bit jail and so on, given that I've never done it. Otherwise, you're probably going to need to find someone who has a similar setup and can reproduce the problem, or give a developer root-level access to your system. I did take a look at the clamav code itself (I'd have to spend a few hundred lines outlining it here and would rather not). My guess is that there's a conflict between what the running OS architecture is and what the build process determines the architecture is. Given that you have jails, and possibly a mixed architecture environment on a single host (e.g. 64-bit host OS with 32-bit jails), can you explain exactly how you go about building clamav, followed by how you go about running it? The build is done from ports with no special options excluding the latest build, being: make -DWITH_DEBUG DEBUG_FLAGS=-g The only make.conf entry is PERL_VERSION=5.10.1. The clamd service runs under djb's supervise (/usr/local/sbin/clamd). Additionally, port builds were done after setting UNAME_m and UNAME_p [1], but I haven't had luck with that overriding the machine hardware type. If this provides any clues, here's what file(1) sees, as well as ldd: % file /usr/local/sbin/clamd /usr/local/sbin/clamd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.1, not stripped % ldd /usr/local/sbin/clamd /usr/local/sbin/clamd: libclamav.so.7 = /usr/local/lib/libclamav.so.7 (0x280ac000) libz.so.5 = /lib/libz.so.5 (0x281f8000) libbz2.so.4 = /usr/lib/libbz2.so.4 (0x2820a000) libm.so.5 = /lib/libm.so.5 (0x2821b000) libthr.so.3 = /lib/libthr.so.3 (0x28235000) libc.so.7 = /lib/libc.so.7 (0x2824a000) [1] - http://www.mail-archive.com/freebsd-am...@freebsd.org/msg00248.html Right -- I understand the binary is 32-bit, but that's not where the problem lies (based on my guess). The binary obviously runs, or else you wouldn't be seeing a segfault or even get a remotely coherent backtrace in gdb. I'm not sure how to explain this in a way that's easily understandable (I'm assuming you're not a programmer. :-) ). My guess is that during compile-time, the compiler is kicking out some code that's based on sizeof(int) == 8 (64-bit), when that shouldn't be the case in a 32-bit environment. Include files could cause this problem too. There may be some black magic in the ports infrastructure (maybe even on a per-port basis) to work around this problem that the clamav port isn't making use of. I really don't know. Sorry I can't be of more help. I'm one of those guys who if he needs a 32-bit and 64-bit system, buys two physical systems. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host
On Fri, Aug 27, 2010 at 09:58:38PM +0300, Kostik Belousov wrote: On Fri, Aug 27, 2010 at 01:06:49PM -0400, Glen Barber wrote: On 8/27/10 12:54 PM, Jeremy Chadwick wrote: On Fri, Aug 27, 2010 at 12:46:48PM -0400, Glen Barber wrote: On 8/27/10 12:33 PM, Kurt Jaeger wrote: Hi! I have a few clamav instances running in jails on 32-bit hosts without any issues. A few days ago one of these jails was migrated to a 64-bit host (8.1-RELEASE), where I noticed clamd (0.96.2_1) segfaults when queried. The issue seems specific to 32bit/64bit compatibility. I have a gdb session available here: http://gist.github.com/549964 Any thoughts on if this is possible? Try Bytecode no in clamd.conf ? It was set to 'yes' initially. I thought it was disabled with building without JIT. At any rate, no, it still segfaults with the same backtrace. 1) Is clamd built with debugging symbols enabled? If not, you might want to rebuild it with such, else it might be difficult to debug the problem. It wasn't initially, but is now. Also, if the segfault happens after performing the above, can you provide output from bt full instead of just bt? Of course. The new backtrace is here: http://gist.github.com/553734 I suspect that this was fixed in r210796/HEAD and r211138/RELENG_8. Would that be these two? http://svn.freebsd.org/viewvc/base?view=revisionrevision=210796 http://svn.freebsd.org/viewvc/base/head/sys/compat/freebsd32/freebsd32_misc.c?r1=210796r2=210795pathrev=210796 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/freebsd32/freebsd32_misc.c.diff?r1=1.110;r2=1.111;f=h http://svn.freebsd.org/viewvc/base?view=revisionrevision=211138 http://svn.freebsd.org/viewvc/base/stable/8/sys/compat/freebsd32/freebsd32_misc.c?r1=211138r2=211137pathrev=211138 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/freebsd32/freebsd32_misc.c.diff?r1=1.93.2.13;r2=1.93.2.14;f=h Based on this PR? http://www.freebsd.org/cgi/query-pr.cgi?pr=149227 2) Was the software rebuilt from source after the upgrade from i386 to amd64, or are you expecting the software to work without any hitches running on amd64 with lib32 (32-bit compatibility libaries)? The latter is not always possible/the case. clamav was rebuilt from ports. I previously went as far as downgrading to the previous version, to rule out something between 0.96.1 and 0.96.2; same results there. Was clamav rebuilt in the 32-bit jail ? At least your backtrace shows 32-bit image being executed. I have no familiarity with the software or functions in question, but an initial guess would be that some piece of the code is making assumptions about the size of pointers (expecting 4 (32-bit) rather than 8 (64-bit)). Speculative on my part, but I ponder such when seeing code like somefunc(sizeof(int)). Absolute nonsense. Well, it's not really nonsense, but I'd rather not go to great lengths to show how it's possible. In this specific case it would end up depending on what CMSG_LEN() does. clamav does have some code where CMSG_LEN() can get overridden (supposedly for Solaris 8 only). This is why I said I'd rather not post hundreds of lines of code; it's one of those situations that's demonstrated when debugged in real-time and not entirely by source analysis. Anyway, as I said, I don't have familiarity with environments where 32-bit code is being run on 64-bit archs. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: shells/bash and the libiconv dependency mess
On Thu, Aug 26, 2010 at 10:23:56AM +0200, Emanuel Haupt wrote: Emanuel Haupt eha...@freebsd.org wrote: Jeremy Chadwick free...@jdc.parodius.com wrote: On Mon, Aug 16, 2010 at 11:01:14PM -0700, Jeremy Chadwick wrote: Let me explain what transpired in chronological order: On 2010/05/11, ehaupt committed the following patch: http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/files/patch-Makefile.in And bumped PORTREVISION (from 0 to 1) in the Makefile. This unconditionally made bash require libiconv, and the only justification is fix statically linked version. Those of us who use WITHOUT_NLS or who do not have libiconv already on their systems (from another port) immediately notice the problem (bash will no longer build): http://www.freebsd.org/cgi/query-pr.cgi?pr=147747 http://www.freebsd.org/cgi/query-pr.cgi?pr=148329 http://www.freebsd.org/cgi/query-pr.cgi?pr=149218 Three months goes by and finally something is committed to fix the problem on 2010/08/06. Except the fix doesn't make any sense; all it does is make libiconv a mandatory dependency (USE_ICONV): http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/Makefile#rev1.123 This, of course, means that WITHOUT_NLS is broken and doesn't work as it's supposed to, since libiconv is now a mandatory requirement (it doesn't need to be): # make WITHOUT_NLS=true all-depends-list /usr/ports/devel/bison /usr/ports/converters/libiconv /usr/ports/devel/m4 /usr/ports/devel/libtool22 Why was this done the way it was? patch-Makefile.in should be removed and instead replaced with a REINPLACE_CMD that handles the conditionals (WITH_STATIC_BASIC, WITHOUT_NLS, etc.) in a more clean manner. And where are the details of the supposed statically linked version problem? Sorry if I sound angry, but this whole situation is a mess, and shells/bash is a very important port. If someone wants me to put my money where my mouth is and go + clean it up I'll be happy to. Testing all the different quirk combinations really isn't that complex. Since I didn't really get any answers regarding this predicament, I went ahead and did the necessary effort. Below are my QA notes. The patch is available here: http://jdc.parodius.com/freebsd/bash-without-nls.patch The patch works for me. One minor thing, PORTREVISION should be bumped. Please note the required removal of files/patch-Makefile.in. I can file a PR for all this if need be, just let me know. Please do that, that way I can commit the patch after a 14 day maintainer timeout. I created: http://www.freebsd.org/cgi/query-pr.cgi?pr=149981 Thank you for doing this, and my apologies. I had a molar removed yesterday afternoon so I've pretty much been tending that + sleeping, otherwise I would've gotten to it. :-) Thanks again! -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: PHP warning after 5.3.3 - 5.3.3_1 bump
On Thu, Aug 26, 2010 at 08:41:42AM -0400, Greg Larkin wrote: Morgan Wesström wrote: Upgraded lang/php from port revision 5.3.3 to 5.3.3_1 yesterday to include the new native MySQL drivers. Now I get the following warning every time a php script is executed: PHP Warning: Module 'zlib' already loaded in Unknown on line 0 Even a simple php -v displays this warning. - I have rebuilt php and all ports depending on it. - I have verified that extensions.ini doesn't contain duplicates. - I have searched for any other references to zlib. This isn't critical I guess, but annoying. Any suggestions on how to solve this would be appreciated. Regards Morgan Hi Morgan, The only time that I've seen that error, it has been caused by duplicate extension loading. If you've already removed duplicates from your extensions.ini file, set up a page with the phpinfo() function so you can see what other .ini file directories might be in the search path. You might even get some good information from this command: truss -f -a -s 256 -o /tmp/php-cli.log php -v Once the process exits, check the /tmp/php-cli.log file and search for zlib in it. You might see the zlib extension loaded more than once and be able to determine what .ini file is causing the duplication. I should note there were zlib-like changes made within Makefile.ext during the commit. Let me explain what I mean by that, because there weren't any *actual changes* to the zlib extension itself: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php5/Makefile.ext.diff?r1=1.74;r2=1.75;f=h The change here introduces --with-zlib-dir to the configure arguments in the case that the standard MySQL extension (extension=mysql.so) or PDO-based MySQL extension (extension=pdo_mysql.so) is used. Please note the below is speculative on my part, but it wouldn't surprise me if it turned out to be the case. I wonder if the introduction of this configure variable causes PHP to automatically load the zlib extension on its own (think: PHP extension inheritance)? If this is true, then extension=zlib.so would be considered redundant and cause the warning seen. You could test the validity of my claim by commenting out (using semi-colon) extension=zlib.so in extensions.ini and then use php -i and see if zlib is listed as a loaded extension. Solving this, if true, is tricky. The only solution I can think of would be to remove the archivers/php5-zlib port altogether, and instead make lang/php5 include zlib support natively. FreeBSD's libz is quite small, so memory usage per PHP instance would not skyrocket assuming libz is included as a shared library (I hope PHP supports that vs. including it statically). Food for thought -- and as such, I'm CC'ing ale@ to partake in the discussion. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: shells/bash and the libiconv dependency mess
On Mon, Aug 16, 2010 at 11:01:14PM -0700, Jeremy Chadwick wrote: Let me explain what transpired in chronological order: On 2010/05/11, ehaupt committed the following patch: http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/files/patch-Makefile.in And bumped PORTREVISION (from 0 to 1) in the Makefile. This unconditionally made bash require libiconv, and the only justification is fix statically linked version. Those of us who use WITHOUT_NLS or who do not have libiconv already on their systems (from another port) immediately notice the problem (bash will no longer build): http://www.freebsd.org/cgi/query-pr.cgi?pr=147747 http://www.freebsd.org/cgi/query-pr.cgi?pr=148329 http://www.freebsd.org/cgi/query-pr.cgi?pr=149218 Three months goes by and finally something is committed to fix the problem on 2010/08/06. Except the fix doesn't make any sense; all it does is make libiconv a mandatory dependency (USE_ICONV): http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/Makefile#rev1.123 This, of course, means that WITHOUT_NLS is broken and doesn't work as it's supposed to, since libiconv is now a mandatory requirement (it doesn't need to be): # make WITHOUT_NLS=true all-depends-list /usr/ports/devel/bison /usr/ports/converters/libiconv /usr/ports/devel/m4 /usr/ports/devel/libtool22 Why was this done the way it was? patch-Makefile.in should be removed and instead replaced with a REINPLACE_CMD that handles the conditionals (WITH_STATIC_BASIC, WITHOUT_NLS, etc.) in a more clean manner. And where are the details of the supposed statically linked version problem? Sorry if I sound angry, but this whole situation is a mess, and shells/bash is a very important port. If someone wants me to put my money where my mouth is and go + clean it up I'll be happy to. Testing all the different quirk combinations really isn't that complex. Since I didn't really get any answers regarding this predicament, I went ahead and did the necessary effort. Below are my QA notes. The patch is available here: http://jdc.parodius.com/freebsd/bash-without-nls.patch Please note the required removal of files/patch-Makefile.in. I can file a PR for all this if need be, just let me know. Test phase A == System should NOT have libiconv and libintl (gettext) installed. A#1) make WITHOUT_NLS=true - SHOULD NOT: pull in libiconv and gettext as dependencies - SHOULD NOT: have symbols that reference libiconv/libintl (gettext) - SHOULD: REINPLACE_CMD patch Makefile.in and config.h A#2) make WITH_STATIC_BASH=true - internally forces WITHOUT_NLS=yes (so see A#1) - SHOULD: result in a non-dynamic ELF binary of larger size A#3) make - SHOULD: pull in libiconv and gettext as dependencies - SHOULD: link to libiconv and/or libintl (gettext) - SHOULD NOT: REINPLACE_CMD patch Makefile.in and config.h Note: make WITH_STATIC_BASH=true WITHOUT_NLS=true is effectively the same as A#2; no point in testing that condition. Test phase B == System SHOULD have libiconv and libintl (gettext) pre-installed. B#4) make WITHOUT_NLS=true - SHOULD NOT: pull in libiconv and gettext as dependencies - SHOULD NOT: have symbols that reference libiconv/libintl (gettext) - SHOULD: REINPLACE_CMD patch Makefile.in and config.h B#5) make WITH_STATIC_BASH=true - internally forces WITHOUT_NLS=yes (so see B#4) - SHOULD: result in a non-dynamic ELF binary of larger size B#6) make - SHOULD: make use of libiconv and gettext as dependencies - SHOULD: link to libiconv and/or libintl (gettext) - SHOULD NOT: REINPLACE_CMD patch Makefile.in and config.h Investigative notes = - The bash configure script contains comments that indicate automatically pulling in libiconv and libintl (gettext), with no deactivation mechanism (even if --disable-nls is defined -- yes really) is actually *intentional*. I strongly disagree with this non-minimalist mentality. - There is no easy way (aside from a very big patch in files/) to get the configure script to not detect libiconv.so if it exists on the system. REINPLACE_CMD fixups should be an effective workaround, but folks will still see the detection during the configure phase. Sad panda. - The combination of the post-patch and post-configure addition is what allows libiconv to not be pulled in during the build and link phase. This appears to be the only way to override configure's brain damage. Pre-modifications to shells/bash/Makefile === - Removed files/patch-Makefile.in - When WITHOUT_NLS **is not** defined, set USE_ICONV=yes - post-patch: remove @LIBICONV@ from in WRKSRC/Makefile.in when WITHOUT_NLS is defined - post-configure: remove #define HAVE_ICONV 1 from WRKSRC/config.h when WITHOUT_NLS is defined Test
Re: graphics/sane-backends: fails to build due to the collision in user group id number
On Fri, Aug 20, 2010 at 06:50:57PM -0700, Yuri wrote: Here is the message I get: === Creating users and/or groups. Creating group `saned' with gid `194'. pw: gid `194' has already been allocated *** Error code 65 My /etc/group file has this line: apache:*:194: Obviously there is a conflict. $ grep :194: /usr/ports/GIDs saned:*:194: Do you know what port, or what piece of software, decided that GID 194 should be apache on your system? That would be what needs to change. On FreeBSD 6.x or later, the www user (UID 80) and www group (GID 80) are used for Apache. These two UID/GIDs are part of the base system's /etc/passwd and /etc/group. So I'm not sure what apache is used for in your /etc/group. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Converting from jiffies to ticks
On Thu, Aug 19, 2010 at 04:15:39PM -0300, Jesse Smith wrote: I am currently trying to port a program from Linux to FreeBSD which detects how much processor time a process is using. The native Linux code does this (in part) by reading the number of jiffies a given process uses. This info is pulled from the /proc/PID/stat file. One function is failing on FreeBSD and it's obviously because FreeBSD does not have all the same files/data in the /proc directory. I've looked around and, as I understand it, FreeBSD uses ticks instead of jiffies to measure process usage. However, how to gather that data is a bit lost on me. This raises two questions for me: 1. Where can I find the equivalent information on FreeBSD? I assume there's a function call. Maybe in the kvm_* family? I need to be able to get the number of ticks a given PID is using. 2. Any idea on what the conversion rate between ticks and jiffies is? Are they the same thing, but with different names? Or is it a kilometres and miles issue? The rest of the program measures everything in jiffies, so it would be ideal for me to get the ticks used on FreeBSD (based on PID), convert it to jiffies and pass it back to the main program. I would recommend you re-ask this question on freebsd-hackers. freebsd-ports isn't really for this purpose. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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
shells/bash and the libiconv dependency mess
Let me explain what transpired in chronological order: On 2010/05/11, ehaupt committed the following patch: http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/files/patch-Makefile.in And bumped PORTREVISION (from 0 to 1) in the Makefile. This unconditionally made bash require libiconv, and the only justification is fix statically linked version. Those of us who use WITHOUT_NLS or who do not have libiconv already on their systems (from another port) immediately notice the problem (bash will no longer build): http://www.freebsd.org/cgi/query-pr.cgi?pr=147747 http://www.freebsd.org/cgi/query-pr.cgi?pr=148329 http://www.freebsd.org/cgi/query-pr.cgi?pr=149218 Three months goes by and finally something is committed to fix the problem on 2010/08/06. Except the fix doesn't make any sense; all it does is make libiconv a mandatory dependency (USE_ICONV): http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/Makefile#rev1.123 This, of course, means that WITHOUT_NLS is broken and doesn't work as it's supposed to, since libiconv is now a mandatory requirement (it doesn't need to be): # make WITHOUT_NLS=true all-depends-list /usr/ports/devel/bison /usr/ports/converters/libiconv /usr/ports/devel/m4 /usr/ports/devel/libtool22 Why was this done the way it was? patch-Makefile.in should be removed and instead replaced with a REINPLACE_CMD that handles the conditionals (WITH_STATIC_BASIC, WITHOUT_NLS, etc.) in a more clean manner. And where are the details of the supposed statically linked version problem? Sorry if I sound angry, but this whole situation is a mess, and shells/bash is a very important port. If someone wants me to put my money where my mouth is and go + clean it up I'll be happy to. Testing all the different quirk combinations really isn't that complex. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: MIMEDefang not starting on reboot
On Wed, Jul 07, 2010 at 08:35:28AM +0930, Daniel O'Connor wrote: Does anyone else see this? I have 2 (of 2) amd64 8.x systems which don't start MIMEDefang on reboot properly, I get this.. Jul 7 06:34:58 cain mimedefang-multiplexor[1747]: Starting slave 3 (pid 41198) (1 running): Bringing slaves up to minSlaves (2) Jul 7 06:34:58 cain mimedefang-multiplexor[1747]: Slave 3 stderr: Can't load '/usr/local/lib/perl5/5.10.1/mach/auto/File/Glob/Glob.so' for module File::Glob: /usr/local/lib/perl5/5.10.1/mach/auto/File/Glob/Glob.so: mmap of entire address space failed: Cannot allocate memory at /usr/local/lib/perl5/5.10.1/mach/XSLoader.pm line 70. at /usr/local/lib/perl5/5.10.1/mach/File/Glob.pm line 96 Compilation failed in require at /usr/local/bin/mimedefang.pl line 3239. BEGIN failed--compilation aborted at /usr/local/bin/mimedefang.pl line 3239. Restarting it manually (ie /usr/local/etc/rc.d/mimedefang.sh restart) after a reboot fixes it.. Also I think it would be nice if this patch were added to the port.. --- /usr/local/etc/rc.d/mimedefang.sh-dist 2010-04-07 10:30:46.586067014 +0930 +++ /usr/local/etc/rc.d/mimedefang.sh 2010-05-01 13:47:47.340517685 +0930 @@ -316,7 +319,7 @@ rm -f $MX_SOCKET /dev/null 21 rm -f $SOCKET /dev/null 21 -if [ $1 = wait ] ; then +if [ wait = wait ] ; then printf Waiting for daemons to exit. WAITPID= test -f $PID WAITPID=`cat $PID` Otherwise restart is useless because it starts MD without waiting for the old one to stop and it doesn't work :( This should probably go to freebsd-ports not -stable, since both mimedefang and perl are ports things. CC'ing. Also, that patch doesn't look correct, or you got your diff arguments backwards (e.g. change should be fixing the wait=wait comparison to use $1=wait). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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/lighttpd: lighttpd won't start anymore after SSL Update in 8.1-PRERELEASE (2010-05-27 09:34:56: (network.c.529) SSL: error:00000000:lib(0):func(0):reason(0))
On Thu, May 27, 2010 at 09:39:10AM +0200, O. Hartmann wrote: Since I performed a make buildworld and installed everything and after an update of the ports tree (with which lighttpd was updated from lighttpd-1.4.26 to lighttpd-1.4.26_1 I receive this error when trying to start lighttpd: 2010-05-27 09:34:56: (network.c.529) SSL: error::lib(0):func(0):reason(0) Are there any suggestions/known issues/workaround or is this a serious error and should be ready for a PR? I think you're correlating two things in correctly. The OpenSSL update was completely separate and unrelated to the update to ports/www/lighttpd. The version bump in ports/www/lighttpd was done for an unrelated reason (to add support for TCP_NODELAY): http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/lighttpd/Makefile http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/lighttpd/Makefile.diff?r1=1.77;r2=1.78;f=h Simply put: due to the OpenSSL upgrade, people should rebuild all ports that are dependent upon OpenSSL. If your problem persists after that, then I would recommend contacting the lighttpd folks to find out why their software doesn't work with OpenSSL 0.9.8n. I can tell you factually that Apache 2.2 (ports/www/apache22) works fine after the OpenSSL bump. I *did* rebuild Apache after seeing the OpenSSL change, however. rant This is what happens when there are library or include file semantic changes. I have to regularly remind folks that there is no guarantee a semantic change results in a bump of the shared library version number (e.g. libxxx.so.6 -- libxxx.so.7). /rant -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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/lighttpd: lighttpd won't start anymore after SSL Update in 8.1-PRERELEASE (2010-05-27 09:34:56: (network.c.529) SSL: error:00000000:lib(0):func(0):reason(0))
On Thu, May 27, 2010 at 01:29:19AM -0700, Jeremy Chadwick wrote: On Thu, May 27, 2010 at 09:39:10AM +0200, O. Hartmann wrote: Since I performed a make buildworld and installed everything and after an update of the ports tree (with which lighttpd was updated from lighttpd-1.4.26 to lighttpd-1.4.26_1 I receive this error when trying to start lighttpd: 2010-05-27 09:34:56: (network.c.529) SSL: error::lib(0):func(0):reason(0) Are there any suggestions/known issues/workaround or is this a serious error and should be ready for a PR? I think you're correlating two things in correctly. The OpenSSL update Not sure why I put a space there; this should read incorrectly. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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/lighttpd: lighttpd won't start anymore after SSL Update in 8.1-PRERELEASE (2010-05-27 09:34:56: (network.c.529) SSL: error:00000000:lib(0):func(0):reason(0))
On Thu, May 27, 2010 at 11:38:08AM +0300, Kostik Belousov wrote: On Thu, May 27, 2010 at 01:29:19AM -0700, Jeremy Chadwick wrote: On Thu, May 27, 2010 at 09:39:10AM +0200, O. Hartmann wrote: Since I performed a make buildworld and installed everything and after an update of the ports tree (with which lighttpd was updated from lighttpd-1.4.26 to lighttpd-1.4.26_1 I receive this error when trying to start lighttpd: 2010-05-27 09:34:56: (network.c.529) SSL: error::lib(0):func(0):reason(0) Are there any suggestions/known issues/workaround or is this a serious error and should be ready for a PR? I think you're correlating two things in correctly. The OpenSSL update was completely separate and unrelated to the update to ports/www/lighttpd. The version bump in ports/www/lighttpd was done for an unrelated reason (to add support for TCP_NODELAY): http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/lighttpd/Makefile http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/lighttpd/Makefile.diff?r1=1.77;r2=1.78;f=h Simply put: due to the OpenSSL upgrade, people should rebuild all ports that are dependent upon OpenSSL. If your problem persists after that, Do you have any factual support for your statement ? If it is, this is a show-stopper for the release. I believe OpenSSL upgrade kept ABI. The OP's report isn't sufficient? My thoughts, in no particular order: The error looks to be formatted by ERR_error_string(), but who knows if it's being populated correctly or if there isn't a bug within OpenSSL 0.9.8n itself. One would have to review the code in network.c (and very likely the rest of the software) to determine if SSL_get_error() is being used correctly and the string buffer is being populated with the correct SSL struct. I do admit it's a little strange to see error:, but if an underlying API function changes operationally (such as previously returning void but now returns an int), and the software previously built against those include headers + shared library, anything is possible. This is completely different than a function name going away or disappearing from an object/library (which would be caught either during link-time or run-time). One would have to examine, in real-time, the stack arguments during the call. RELENG_8 moved from 0.9.8k to 0.9.8n. Meaning, l and m were both skipped, so we have to keep that in mind when reviewing the official ChangeLog: http://www.openssl.org/source/exp/CHANGES I do see some changes between 0.9.8k and 0.9.8n which could warrant a version bump. That's my opinion anyway, but I don't know how the FreeBSD base system maintainers for OpenSSL test things prior to committing. I'm betting they don't test every single FreeBSD port. Furthermore, this wouldn't be the first time something like this has happened with OpenSSL. Finally, 0.9.8n came out on March 24th. Five days later, 1.0.0 came out and is now the official stable release: http://www.openssl.org/source/ The ChangeLog entries between 0.9.8n and 1.0.0 are massive; a bug could have been fixed there, which maybe only happens with lighttpd. Who knows. I think the best choice of action would be for the OP to rebuild the port and see if the problem persists. Otherwise, spending tons of time trying to track down the source of the problem (requiring the OP to rebuild all of his system libraries with debugging, lighttpd with debugging, and gain familiarity with gdb) is pointless. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On Thu, Apr 08, 2010 at 07:42:06AM -0500, Antonio Olivares wrote: On Wed, Apr 7, 2010 at 7:36 AM, Ion-Mihai Tetcu ite...@freebsd.org wrote: On Wed, 7 Apr 2010 07:20:47 -0500 Antonio Olivares olivares14...@gmail.com wrote:  [ .. ] === Port directory: /usr/ports/sysutils/fusefs-kmod     === This port is marked IGNORE     === requires the userland sources to be installed. Set SRC_BASE if it is not in /usr/src     === If you are sure you can build it, remove the         IGNORE line in the Makefile and try again. === Update for sysutils/fusefs-kmod failed === Aborting update  [ .. ] What should I do in this case? First, please don't top post. Second, you don't seem to have the base sources installed and that port, being a kernel module, needs them. See: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html -- IOnut - Un^d^dregistered ;) FreeBSD user  Intellectual Property is  nowhere near as valuable  as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B Dear Ion-Mihai, I have installed cvsup, but I don't really understand the page that I was refered to === SECURITY REPORT: This port has installed the following files which may act as network servers and may therefore pose a remote security risk to the system. /usr/local/sbin/cvsupd /usr/local/bin/cvsup /usr/local/bin/cvpasswd If there are vulnerabilities in these programs there may be a security risk to the system. FreeBSD makes no guarantee about the security of ports included in the Ports Collection. Please type 'make deinstall' to deinstall the port if this is a concern. For more information, and contact details about the security status of this software, see the following webpage: http://www.cvsup.org/ === Cleaning for ezm3-1.1_2 === Cleaning for cvsup-without-gui-16.1h_4 I have installed it using ports system, but still get same error as above. I try to use cvsup the file, I get nothing, I try to go to the port that refuses to update and make install clean and it says source not available or refused? I have used ports before and had no problems, I don't know what to do. Thank you and others who have provided help. *Sorry for top posting You didn't need to install cvsup from ports. csup in the base system will work just fine; it's the official replacement for cvsup. itetcu@ was pointing you to the documentation describing the procedure for using cvsup/csup. Based on the thread so far, my understanding is that you need to download the FreeBSD source repository (kernel, base system, etc.), because the port you're trying to build (which is a kernel module) requires it. There are two cvsup files associated with the source repo: /usr/share/examples/cvsup/standard-supfile /usr/share/examples/cvsup/stable-supfile Which you should use depends on if you're running -RELEASE or -STABLE. The most important part in those files is the *default release=cvs tag=XXX. Specifically the tag=XXX part. 8.0-RELEASE's tag is RELENG_8_0, while 8.0-STABLE's tag is RELENG_8. So which tag you use should be based on what version you wish to run. So at this point, you should: 1) pkg_delete ezm3-1.1_2 2) pkg_delete cvsup-without-gui-16.1h_4 3) csup -h some cvsup server -L 2 /usr/share/example/cvsup/stable-supfile or csup -h some cvsup server -L 2 /usr/share/example/cvsup/standard-supfile This will populate /usr/src on your system. From there, you should be able to build ports/sysutils/fusefs-kmod as normal without any problem. Does this help explain things better? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Recent mail/p5-Mail-SpamAssassin update -- dependency errors?
On Wed, Feb 10, 2010 at 09:47:41PM +0100, Gabor Kovesdan wrote:
El 2010. 02. 10. 14:59, Jeremy Chadwick escribió:
[..snip...]
If I do make rmconfig on either box, the dependency error goes away.
This should be sufficient, I think? :-)
Jeremy, could you please confirm that this update solves the problem?
http://www.freebsd.org/cgi/query-pr.cgi?pr=143729
I still couldn't reproduce the issue you reported, I used the same
options, though.
I suppose I should provide make.conf variables which would be relevant
as well.
NO_INET6=yes
USA_RESIDENT=yes
WITHOUT_X11=yes
WITH_APACHE=yes
WITHOUT_IPV6=true
WITHOUT_NLS=true
I can repro the problem on both a 7.2-STABLE and 8.0-STABLE box; both
have the same make.conf variables above.
I just csup'd both machines (I see some changes have been made to the
port since then), but the problem persists. Here's a session showing
the exact problem and how to repro it:
# make rmconfig
=== No user-specified options configured for p5-Mail-SpamAssassin-3.3.0_1
# make clean
=== Cleaning for p5-Mail-SpamAssassin-3.3.0_1
# make config
{...set flags like I described in my previous mails...}
# cat /var/db/ports/p5-Mail-SpamAssassin/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for p5-Mail-SpamAssassin-3.3.0_1
_OPTIONS_READ=p5-Mail-SpamAssassin-3.3.0_1
WITH_AS_ROOT=true
WITH_SPAMC=true
WITHOUT_SACOMPILE=true
WITHOUT_DKIM=true
WITHOUT_SSL=true
WITHOUT_GNUPG=true
WITHOUT_MYSQL=true
WITHOUT_PGSQL=true
WITHOUT_RAZOR=true
WITH_SPF_QUERY=true
WITHOUT_RELAY_COUNTRY=true
WITHOUT_DCC=true
# make clean
p5-Mail-SpamAssassin-3.3.0_1: + non-existent -- dependency list incomplete
=== Cleaning for p5-Mail-SpamAssassin-3.3.0_1
# make all-depends-list
/usr/ports/lang/perl5.8
/usr/ports/dns/p5-Net-DNS
/usr/ports/archivers/p5-IO-Zlib
/usr/ports/www/p5-HTML-Parser
/usr/ports/archivers/p5-IO-Compress-Zlib
/usr/ports/archivers/p5-Compress-Zlib
/usr/ports/mail/p5-Mail-Tools
/usr/ports/net-mgmt/p5-NetAddr-IP
p5-Mail-SpamAssassin-3.3.0_1: + non-existent -- dependency list incomplete
/usr/ports/security/p5-Digest-SHA1
/usr/ports/net-mgmt/p5-Net-IP
/usr/ports/security/p5-Digest-SHA
/usr/ports/security/p5-Digest-HMAC
/usr/ports/www/p5-HTML-Tagset
/usr/ports/archivers/p5-Compress-Raw-Zlib
/usr/ports/archivers/p5-IO-Compress-Base
/usr/ports/devel/p5-TimeDate
/usr/ports/math/p5-Math-BigInt
# make rmconfig
=== Removing user-configured options for p5-Mail-SpamAssassin-3.3.0_1
# make clean
=== Cleaning for p5-Mail-SpamAssassin-3.3.0_1
#
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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: Recent mail/p5-Mail-SpamAssassin update -- dependency errors?
On Thu, Feb 11, 2010 at 02:17:08AM -0800, Jeremy Chadwick wrote:
On Wed, Feb 10, 2010 at 09:47:41PM +0100, Gabor Kovesdan wrote:
El 2010. 02. 10. 14:59, Jeremy Chadwick escribió:
[..snip...]
If I do make rmconfig on either box, the dependency error goes away.
This should be sufficient, I think? :-)
Jeremy, could you please confirm that this update solves the problem?
http://www.freebsd.org/cgi/query-pr.cgi?pr=143729
I still couldn't reproduce the issue you reported, I used the same
options, though.
I suppose I should provide make.conf variables which would be relevant
as well.
NO_INET6=yes
USA_RESIDENT=yes
WITHOUT_X11=yes
WITH_APACHE=yes
WITHOUT_IPV6=true
WITHOUT_NLS=true
I can repro the problem on both a 7.2-STABLE and 8.0-STABLE box; both
have the same make.conf variables above.
I just csup'd both machines (I see some changes have been made to the
port since then), but the problem persists. Here's a session showing
the exact problem and how to repro it:
# make rmconfig
=== No user-specified options configured for p5-Mail-SpamAssassin-3.3.0_1
# make clean
=== Cleaning for p5-Mail-SpamAssassin-3.3.0_1
# make config
{...set flags like I described in my previous mails...}
# cat /var/db/ports/p5-Mail-SpamAssassin/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for p5-Mail-SpamAssassin-3.3.0_1
_OPTIONS_READ=p5-Mail-SpamAssassin-3.3.0_1
WITH_AS_ROOT=true
WITH_SPAMC=true
WITHOUT_SACOMPILE=true
WITHOUT_DKIM=true
WITHOUT_SSL=true
WITHOUT_GNUPG=true
WITHOUT_MYSQL=true
WITHOUT_PGSQL=true
WITHOUT_RAZOR=true
WITH_SPF_QUERY=true
WITHOUT_RELAY_COUNTRY=true
WITHOUT_DCC=true
# make clean
p5-Mail-SpamAssassin-3.3.0_1: + non-existent -- dependency list incomplete
=== Cleaning for p5-Mail-SpamAssassin-3.3.0_1
# make all-depends-list
/usr/ports/lang/perl5.8
/usr/ports/dns/p5-Net-DNS
/usr/ports/archivers/p5-IO-Zlib
/usr/ports/www/p5-HTML-Parser
/usr/ports/archivers/p5-IO-Compress-Zlib
/usr/ports/archivers/p5-Compress-Zlib
/usr/ports/mail/p5-Mail-Tools
/usr/ports/net-mgmt/p5-NetAddr-IP
p5-Mail-SpamAssassin-3.3.0_1: + non-existent -- dependency list incomplete
/usr/ports/security/p5-Digest-SHA1
/usr/ports/net-mgmt/p5-Net-IP
/usr/ports/security/p5-Digest-SHA
/usr/ports/security/p5-Digest-HMAC
/usr/ports/www/p5-HTML-Tagset
/usr/ports/archivers/p5-Compress-Raw-Zlib
/usr/ports/archivers/p5-IO-Compress-Base
/usr/ports/devel/p5-TimeDate
/usr/ports/math/p5-Math-BigInt
# make rmconfig
=== Removing user-configured options for p5-Mail-SpamAssassin-3.3.0_1
# make clean
=== Cleaning for p5-Mail-SpamAssassin-3.3.0_1
#
I've narrowed it down. The problem only happens when DKIM is disabled
and SPF_QUERY is enabled. Here's proof / trying combinations:
# make config
# egrep SPF|DKIM /var/db/ports/p5-Mail-SpamAssassin/options
WITH_DKIM=true
WITH_SPF_QUERY=true
# make clean
=== Cleaning for p5-Mail-SpamAssassin-3.3.0_1
# make config
# egrep SPF|DKIM /var/db/ports/p5-Mail-SpamAssassin/options
WITHOUT_DKIM=true
WITH_SPF_QUERY=true
# make clean
p5-Mail-SpamAssassin-3.3.0_1: + non-existent -- dependency list incomplete
=== Cleaning for p5-Mail-SpamAssassin-3.3.0_1
# make config
# egrep SPF|DKIM /var/db/ports/p5-Mail-SpamAssassin/options
WITH_DKIM=true
WITHOUT_SPF_QUERY=true
# make clean
=== Cleaning for p5-Mail-SpamAssassin-3.3.0_1
#
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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
Recent mail/p5-Mail-SpamAssassin update -- dependency errors?
Please CC me on responses, as I'm not subscribed to freebsd-ports. I'm afraid to upgrade this port to 3.3.0 as a result of the below: # cd /usr/ports/mail/p5-Mail-SpamAssassin # make all-depends-list /usr/ports/lang/perl5.8 /usr/ports/dns/p5-Net-DNS /usr/ports/archivers/p5-IO-Zlib /usr/ports/www/p5-HTML-Parser /usr/ports/archivers/p5-IO-Compress-Zlib /usr/ports/archivers/p5-Compress-Zlib /usr/ports/mail/p5-Mail-Tools p5-Mail-SpamAssassin-3.3.0: + non-existent -- dependency list incomplete /usr/ports/security/p5-Digest-SHA1 /usr/ports/net-mgmt/p5-Net-IP /usr/ports/security/p5-Digest-SHA /usr/ports/security/p5-Digest-HMAC /usr/ports/www/p5-HTML-Tagset /usr/ports/archivers/p5-Compress-Raw-Zlib /usr/ports/archivers/p5-IO-Compress-Base /usr/ports/devel/p5-TimeDate /usr/ports/math/p5-Math-BigInt Probably relevant: http://lists.freebsd.org/pipermail/freebsd-ports/2010-February/059485.html -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Recent mail/p5-Mail-SpamAssassin update -- dependency errors?
On Wed, Feb 10, 2010 at 02:40:48PM +0100, Gabor Kovesdan wrote: El 2010. 02. 10. 14:13, Jeremy Chadwick escribió: Please CC me on responses, as I'm not subscribed to freebsd-ports. I'm afraid to upgrade this port to 3.3.0 as a result of the below: I've just fixed two problems but I don't see this one here. The ASO tinderbox couldn't deal with this and didn't provide me any useful error log so I had to test this locally, that's why it didn't go smoothly. If someone could provide more information on this, that would be more than welcome. Here's /var/db/ports/p5-Mail-SpamAssassin/options: # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for p5-Mail-SpamAssassin-3.2.5_4 _OPTIONS_READ=p5-Mail-SpamAssassin-3.2.5_4 WITH_AS_ROOT=true WITH_SPAMC=true WITHOUT_SACOMPILE=true WITHOUT_DKIM=true WITHOUT_SSL=true WITHOUT_GNUPG=true WITHOUT_MYSQL=true WITHOUT_PGSQL=true WITHOUT_RAZOR=true WITH_SPF_QUERY=true WITHOUT_RELAY_COUNTRY=true On an 8.0-STABLE box with these options checked (using make config) to match the above, I can reproduce it. If I do make rmconfig on either box, the dependency error goes away. This should be sufficient, I think? :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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
Latest/perl.tbz symlink missing on FTP mirrors
I came across the below today while rebuilding one of my boxes. It
appears the perl.tbz symlink in Latest/ on the FTP mirrors has gone
missing:
gujoja# pkg_add -r perl
Error: FTP Unable to get
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-stable/Latest/perl.tbz:
File unavailable (e.g., file not found, no access)
pkg_add: unable to fetch
'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-stable/Latest/perl.tbz'
by URL
gujoja# ftp
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-stable/Latest/
Trying 204.152.184.73...
Connected to ftp.freebsd.org.
220 Welcome to freebsd.isc.org.
{snip}
ftp dir perl*
227 Entering Passive Mode (204,152,184,73,216,226)
150 Here comes the directory listing.
lrwxr-xr-x1 110 1002 26 Aug 03 14:39 perlconsole.tbz -
../All/perlconsole-0.4.tbz
lrwxr-xr-x1 110 1002 24 Aug 03 14:39 perldap.tbz -
../All/perldap-1.4.1.tbz
lrwxr-xr-x1 110 1002 24 Sep 07 05:21 perlftlib.tbz -
../All/perlftlib-1.2.tbz
lrwxr-xr-x1 110 1002 28 Sep 07 05:21 perltidy.tbz -
../All/perltidy-20090616.tbz
ftp cd ../All
250 Directory successfully changed.
ftp dir perl*
227 Entering Passive Mode (204,152,184,73,123,76)
150 Here comes the directory listing.
-rw-r--r--1 110 1002 13542336 Jul 12 06:04 perl-5.10.0_4.tbz
-rw-r--r--1 110 1002 12015615 Jun 14 20:59 perl-5.8.9_3.tbz
-rw-r--r--1 110 100241343 Jun 15 19:01 perl2html-0.9.2_1.tbz
-rw-r--r--1 110 1002 9633 Aug 01 11:34 perlconsole-0.4.tbz
-rw-r--r--1 110 1002 116249 Aug 19 07:03 perldap-1.4.1.tbz
-rw-r--r--1 110 100239772 Aug 19 09:57 perlftlib-1.2.tbz
-rw-r--r--1 110 1002 263681 Aug 17 07:52 perltidy-20090616.tbz
226 Directory send OK.
The workaround should be obvious, but here it is for users anyway:
gujoja# pkg_add -r
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-stable/All/perl-5.8.9_3.tbz
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-7-stable/All/perl-5.8.9_3.tbz...
Done.
{snip}
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
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: INDEX has lower version of ports than installed ones
On Mon, Nov 17, 2008 at 08:28:49PM +0100, Andre Wensing wrote: Does anyone know if INDEX has been updated recently? For some reason `pkg_version -IvL =` reports me that I've got newer ports than INDEX has: server# pkg_version -IvL = amavisd-new-2.6.1_1,1 succeeds index (index has 2.6.1,1) cyrus-sasl-2.1.22_2succeeds index (index has 2.1.22_1) cyrus-sasl-saslauthd-2.1.22_1 succeeds index (index has 2.1.22) dcraw-8.88 succeeds index (index has 8.86) dirmngr-1.0.2 succeeds index (index has 1.0.1_2) dovecot-1.1.3_1succeeds index (index has 1.1.3) mysql-client-5.0.67_1 succeeds index (index has 5.0.67) mysql-server-5.0.67_1 succeeds index (index has 5.0.67) pcre-7.8 succeeds index (index has 7.7_1) postfix-2.5.5,1succeeds index (index has 2.5.4,1) rrdtool-1.3.3 succeeds index (index has 1.3.1) squirrelmail-1.4.16succeeds index (index has 1.4.15_1) server# uname -a FreeBSD server.home.local 6.4-PRERELEASE FreeBSD 6.4-PRERELEASE #6: Wed Sep 24 06:04:20 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 How can this be? The ports-tree has thawed, right (at least, according to the release-schedule for 6.4)? When you update your ports via csup (not sure about portsnap), the INDEX file **is not** updated. You can either rebuild it yourself (make index), or you can fetch it by doing make fetchindex. I prefer the latter. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to build dovecot-1.1.6
On Sun, Nov 16, 2008 at 02:51:36PM +1100, andrew clarke wrote: Maybe this has been fixed by now but dovecot-1.1.6 is not building for me. It looks like there might be a stray carriage return in the Makefile or distinfo file? I wonder how that got in there? You're right, there is. Our (FreeBSD porters) automated build/tester application called QAT caught that: http://lists.freebsd.org/pipermail/cvs-ports/2008-November/159599.html http://lists.freebsd.org/pipermail/cvs-ports/2008-November/159603.html phase 1: make checksum = dovecot-1.1.6^M.tar.gz is not in /a/ports/mail/dovecot/distinfo. = Either /a/ports/mail/dovecot/distinfo is out of date, or = dovecot-1.1.6^M.tar.gz is spelled incorrectly. *** Error code 1 I'll take a look at it. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to build dovecot-1.1.6
On Sat, Nov 15, 2008 at 08:46:59PM -0800, Jeremy Chadwick wrote: On Sun, Nov 16, 2008 at 02:51:36PM +1100, andrew clarke wrote: Maybe this has been fixed by now but dovecot-1.1.6 is not building for me. It looks like there might be a stray carriage return in the Makefile or distinfo file? I wonder how that got in there? You're right, there is. Our (FreeBSD porters) automated build/tester application called QAT caught that: http://lists.freebsd.org/pipermail/cvs-ports/2008-November/159599.html http://lists.freebsd.org/pipermail/cvs-ports/2008-November/159603.html I've committed a fix for this. There were more files than just distinfo and Makefile affected. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cd // - bash is funny???
On Fri, Nov 14, 2008 at 02:32:20PM -0800, Maxim Sobolev wrote: [EMAIL PROTECTED] ~]$ cd // [EMAIL PROTECTED] //]$ pwd // [EMAIL PROTECTED] //] /bin/pwd / [EMAIL PROTECTED] //] What's that? Happens on bash 3.x, checked range of boxes from 6.x to 8.x and arches from powerpc to amd64. cd /// at the same time is OK: [EMAIL PROTECTED] //]$ cd /// [EMAIL PROTECTED] /]$ Is it off-by-one error? The Bash FAQ covers this, I think. See E10. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems building ports - Error code 2 when attempting to cd
On Wed, Nov 05, 2008 at 03:49:29PM -0400, Scott Ullrich wrote: All, I have a strange port problem that I am trying to figure out. Hopefully someone can shed a light on what is happening here: === rrdtool-1.2.26_1 depends on file: /usr/local/bin/libtool - found (but building it anyway) ===Verifying install for /usr/local/bin/libtool in /usr/ports/devel/libtool15 === Returning to build of rrdtool-1.2.26_1 === rrdtool-1.2.26_1 depends on shared library: freetype.9 - found (but building it anyway) ===Verifying install for freetype.9 in /usr/ports/print/freetype2 cd: can't cd to /usr/ports/print/freetype2/work/freetype-2.3.7 *** Error code 2 1 error *** Error code 2 1 error But as you can see here, it does exist: freebsd-nexus-computers# ls /usr/ports/print/freetype2/work/freetype-2.3.7 ChangeLog ChangeLog.22Makefileautogen.sh devel modules.cfg version.sed ChangeLog.20 Jamfile README builds docs objsvms_make.com ChangeLog.21 JamrulesREADME.CVS configure include src Does anyone have any idea what is happening here? This is happening randomly to a number of port builds and I am stumped. Please provide the output from the following commands: mount ls -ld / /usr /usr/ports /usr/ports/print /usr/ports/print/freetype2 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems building ports - Error code 2 when attempting to cd
On Wed, Nov 05, 2008 at 09:04:18PM -0500, Scott Ullrich wrote: On Wed, Nov 5, 2008 at 9:01 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote: Please provide the output from the following commands: mount ls -ld / /usr /usr/ports /usr/ports/print /usr/ports/print/freetype2 Here is mount: /dev/da0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/da0s1d on /usr (ufs, local, soft-updates) devfs on /usr/jails/sullrich/dev (devfs, local) fdescfs on /usr/jails/sullrich/dev/fd (fdescfs) procfs on /usr/jails/sullrich/proc (procfs, local) devfs on /usr/jails/ermal/dev (devfs, local) fdescfs on /usr/jails/ermal/dev/fd (fdescfs) procfs on /usr/jails/ermal/proc (procfs, local) devfs on /usr/jails/billm/dev (devfs, local) fdescfs on /usr/jails/billm/dev/fd (fdescfs) procfs on /usr/jails/billm/proc (procfs, local) devfs on /usr/jails/ondemand/dev (devfs, local) fdescfs on /usr/jails/ondemand/dev/fd (fdescfs) procfs on /usr/jails/ondemand/proc (procfs, local) devfs on /usr/local/pfsense-fs/dev (devfs, local) (Note that it is a jail host and this build was running within a jail) freebsd-nexus-computers# ls -ld / /usr /usr/ports /usr/ports/print /usr/ports/print/freetype2 drwxr-xr-x 20 root wheel 512 Nov 2 18:47 / drwxr-xr-x 18 root wheel 512 Nov 5 14:20 /usr drwxr-xr-x 70 root wheel 1536 Nov 5 15:15 /usr/ports drwxr-xr-x 331 root wheel 7168 Nov 5 15:16 /usr/ports/print drwxr-xr-x3 root wheel 512 Nov 5 15:16 /usr/ports/print/freetype2 They all exist. The error message is really strange. Anything else you can think to check? Does the problem happen outside of the jail? Other than that, I have no ideas. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fsck | repair and/or check?
On Fri, Oct 24, 2008 at 01:48:50PM +0200, Jos Chrispijn wrote: Can somebody explain in simple words what this nanslp and biord exactly represents? nanslp = nanosleep(2) biord = BIO_READ (kernel is reading data directly from the disk) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up ports install
On Sun, Oct 19, 2008 at 09:21:18AM -0400, Eitan Adler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a simple idea to make use the threads without any possibility of conflicts. I am sure there will be someone to point out a negative, but I don't see any. When you do make install launch a make fetch-recursive thread at the same time. That way you don't need to wait for the files to install-fetch the next one-install it-fetch the next one... For those who don't want that you could get the old behavior with make onlyinstall. I currently do this with a make wrapper script and I find installation to be faster. What about this scenario? # cd /usr/ports/friendly/apes # make install forked copy of 'make fetch-recursive' is launched in background fetch for friendly/apes finishes, make starts make finds a dependency which isn't installed, friendly/dogs make begins to build friendly/dogs, but friendly/dogs is still being downloaded from fetch-recursive, because the source is very large; say, 30MBytes make for friendly/dogs forks another fetch-recursive.. What I'm trying to say is, there would need to be mechanisms put in place to cause the entire build process to block (halt/pause) until the backgrounded fetch-recursive has completed. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up ports install
On Sun, Oct 19, 2008 at 06:39:34AM -0700, Jeremy Chadwick wrote: On Sun, Oct 19, 2008 at 09:21:18AM -0400, Eitan Adler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a simple idea to make use the threads without any possibility of conflicts. I am sure there will be someone to point out a negative, but I don't see any. When you do make install launch a make fetch-recursive thread at the same time. That way you don't need to wait for the files to install-fetch the next one-install it-fetch the next one... For those who don't want that you could get the old behavior with make onlyinstall. I currently do this with a make wrapper script and I find installation to be faster. What about this scenario? # cd /usr/ports/friendly/apes # make install forked copy of 'make fetch-recursive' is launched in background fetch for friendly/apes finishes, make starts make finds a dependency which isn't installed, friendly/dogs make begins to build friendly/dogs, but friendly/dogs is still being downloaded from fetch-recursive, because the source is very large; say, 30MBytes make for friendly/dogs forks another fetch-recursive.. What I'm trying to say is, there would need to be mechanisms put in place to cause the entire build process to block (halt/pause) until the backgrounded fetch-recursive has completed. And I forgot another scenario: Let's say you've added perl as a package, e.g. pkg_add -r perl, and now you're going to build a program that's dependent upon it. One of the known problems with ports/pkg stuff is that in the above scenario, fetch and fetch-recursive will download a copy of the source for perl (when detected as a dependency for something), which ultimately serves zero purpose. This doesn't happen when simply doing make or make install. More food for thought. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in OpenBSD spamd
On Thu, Oct 16, 2008 at 09:43:49PM -0700, Doug Hardie wrote: There is a bug in OpenBSD's spamd. The value for the whitelist expiration that can be set with the arguments to spamd is not used by spamlogd. It uses the hard-coded value of 36 days in grey.h. As a result if you think you are changing the time a whitelist entry is retained, you are actually not. It will always be 36 days. The easiest way to correct this is to add an argument to spamlogd with the desired value and overwrite the default. Have you reported this up-stream to the OpenBSD folks? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with www/mod_cband
On Fri, Oct 17, 2008 at 12:57:41PM -0400, David Karapetyan wrote: FreeBSD office19.resnet.nd.edu 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Wed Oct 1 10:10:12 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Hello everyone. Every time I try to use the mod_cband module in my apache22 webserver, apache segfaults upon restart. Things work fine when I disable the module from httpd.conf. Is this module broken, and if so, what comparable alternatives are there? Be aware that mod_cband has quite a horrible bug. This is a Debian bug report, but the same problem applies to FreeBSD. Be sure to read the entire bug, not just the original report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418645 Regarding alternatives: there aren't. Bandwidth limiting is a long-standing feature of Apache that's missing, which is a huge disappointment. The best solution I've found on FreeBSD is to use pf(4) with ALTQ, and give each VirtualHost its own IP address, then rate-limit the IP address using pf(4). Yes, I realise this is impractical for sites which have many vhosts and use name-based virtualhosts. Welcome to my world... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rrdtool12 missing from INDEX-7
On Fri, Oct 17, 2008 at 08:15:45PM +0200, Spil Oss wrote: Hi all, Recently I installed databases/rrdtool12 from ports, and now pkg_version is complaining # pkg_version -vIL\= rrdtool-1.2.26_1! Comparison failed checking /usr/ports/INDEX-7 I don't see rrdtool12 in there. # grep ^rrdtool /usr/ports/INDEX* | cut -c -70 /usr/ports/INDEX:rrdtool-1.2.18|/usr/ports/net/rrdtool|/usr/local|Roun /usr/ports/INDEX:rrdtool-1.0.50_1|/usr/ports/net/rrdtool10|/usr/local| /usr/ports/INDEX-5:rrdtool-1.2.26|/usr/ports/databases/rrdtool|/usr/lo /usr/ports/INDEX-5:rrdtool-1.0.50_1|/usr/ports/databases/rrdtool10|/us /usr/ports/INDEX-6:rrdtool-1.3.3|/usr/ports/databases/rrdtool|/usr/loc /usr/ports/INDEX-6:rrdtool-1.0.50_1|/usr/ports/databases/rrdtool10|/us /usr/ports/INDEX-7:rrdtool-1.3.3|/usr/ports/databases/rrdtool|/usr/loc /usr/ports/INDEX-7:rrdtool-1.0.50_1|/usr/ports/databases/rrdtool10|/us Tried a `make fetchindex` in /usr/ports, but bzgrepping the INDEX-7.tbz had only 1.3 and 1.0. Am I missing anything? I'm the port maintainer. I don't quite understand INDEX -- meaning I don't understand if there's something we're supposed to edit to add an entry or what. As far as I know, it's automatically generated? FWIW, I can confirm it doesn't exist in INDEX: eos# pkg_version -v | grep rrdtool rrdtool-1.2.28 = up-to-date with port eos# grep -i ^rrdtool12 /usr/ports/INDEX-6 eos# -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with www/mod_cband
On Fri, Oct 17, 2008 at 11:47:38AM -0700, mdh wrote: It seems possible, however, that mod_cband's functionality could be replicated by a simple script that watches the access log files and makes an update to a .htaccess file for the virtualhost when the virtualhost in question exceeds a given bandwidth limit which would be configured in the script. Well, that's assuming you want to use the maximum aggregate bandwidth per site every month concept. I, for one, do not, because all it takes is one prick wget -r'ing the site and pow, the site is down for everyone. You could block based on IP, but believe me, they'll find or get another. (I've personally seen this with Italian users, where they'd switch to another IP to get around pf(4) blocks I put in place.) I personally prefer to just bandwidth limit sites, only permitting XXX Kbyte/sec across *all visitors*. It's the only safe way to deal with 95th-percentile billing in co-locations. Also, don't forget that Apache only writes an entry to the log file *after* the transfer is finished, not when the request is submit. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rrdtool12 missing from INDEX-7
On Fri, Oct 17, 2008 at 08:16:31PM +0100, Matthew Seaman wrote: Jeremy Chadwick wrote: On Fri, Oct 17, 2008 at 08:15:45PM +0200, Spil Oss wrote: Hi all, Recently I installed databases/rrdtool12 from ports, and now pkg_version is complaining # pkg_version -vIL\= rrdtool-1.2.26_1! Comparison failed checking /usr/ports/INDEX-7 I don't see rrdtool12 in there. # grep ^rrdtool /usr/ports/INDEX* | cut -c -70 /usr/ports/INDEX:rrdtool-1.2.18|/usr/ports/net/rrdtool|/usr/local|Roun /usr/ports/INDEX:rrdtool-1.0.50_1|/usr/ports/net/rrdtool10|/usr/local| /usr/ports/INDEX-5:rrdtool-1.2.26|/usr/ports/databases/rrdtool|/usr/lo /usr/ports/INDEX-5:rrdtool-1.0.50_1|/usr/ports/databases/rrdtool10|/us /usr/ports/INDEX-6:rrdtool-1.3.3|/usr/ports/databases/rrdtool|/usr/loc /usr/ports/INDEX-6:rrdtool-1.0.50_1|/usr/ports/databases/rrdtool10|/us /usr/ports/INDEX-7:rrdtool-1.3.3|/usr/ports/databases/rrdtool|/usr/loc /usr/ports/INDEX-7:rrdtool-1.0.50_1|/usr/ports/databases/rrdtool10|/us Tried a `make fetchindex` in /usr/ports, but bzgrepping the INDEX-7.tbz had only 1.3 and 1.0. Am I missing anything? I'm the port maintainer. I don't quite understand INDEX -- meaning I don't understand if there's something we're supposed to edit to add an entry or what. As far as I know, it's automatically generated? FWIW, I can confirm it doesn't exist in INDEX: eos# pkg_version -v | grep rrdtool rrdtool-1.2.28 = up-to-date with port eos# grep -i ^rrdtool12 /usr/ports/INDEX-6 eos# rrdtool12 isn't referred to in /usr/ports/databases/Makefile: happy-idiot-talk:/usr/ports/databases:% grep rrdtool Makefile SUBDIR += php4-rrdtool SUBDIR += php5-rrdtool SUBDIR += py-rrdtool_lgpl SUBDIR += rrdtool SUBDIR += rrdtool10 SUBDIR += rubygem-rrdtool If it isn't hooked up to the ports tree, it won't be shown in the INDEX. Thanks much for the explanation! I've committed the fix. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MOVED file
On Wed, Oct 15, 2008 at 03:44:02PM +0200, Jos Chrispijn wrote: I recently had some problems with updating my ports because there was a problem with my MOVED file. Can you tell me if this is caused by the person that is adding the port to the update queue? Sometimes the problem can be solved by changing a single '|' to a '||', but not allways. The problem is solved now; does this indicate that the port maintainer checked it and replaced the faulty line/string by the right one? You can use cvsweb to answer this question. See the very bottom of the web page. http://www.freebsd.org/cgi/cvsweb.cgi/ports/ -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: DarwinStreamingServer-6.0.3
On Mon, Oct 13, 2008 at 08:25:34AM -0500, Jason wrote: Carlos, Thanks for the reply. I downloaded just the Streaming Server port from the FreeBSD web site, I haven't upgraded my entire ports tree. But, if I understand this particular problem, the only factors are the actual patch file and the file being patched, so as long as those are in sync, it should work. Is the port posted on the FreeBSD web the latest? The web access to cvs shows the port I am using at revision 1.35. Has something else fundamental changed like make itself or the patch utility since 6.0 was released? The problem is that your ports tree has been updated incorrectly or is broken somehow. The patch which is failing for you was removed from the files/ directory 4 months ago, when the 6.0.3 update got applied: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/DarwinStreamingServer/files/Attic/ The patch in question does not apply to 6.0.3, and that's what the problem here is. I don't know how you have 6.0.3 of the port, but still have old patch files in files/. I do not know how/why your ports tree is in this state. It's possible that when you installed FreeBSD you chose src and ports from the installation menu. The problem with this is that you have to adopt the src and ports trees to work with csup/cvsup: http://www.cvsup.org/faq.html#adopt I would highly recommend you start over from scratch by nuking your ports tree (rm -fr /usr/ports/*), and the files/dirs in /usr/sup/* and/or /var/db/sup/*, then updating your entire ports tree again. You should probably do the same thing with /usr/src as well. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: DarwinStreamingServer-6.0.3
On Mon, Oct 13, 2008 at 09:05:27AM -0500, Jason wrote: Jeremy, Thanks much! I am not exactly sure how that port got in this state either, but I *did* manually download just the port for the DarwinStreamingServer and plunk into my port tree, so I know I am not following protocol ;-) Yup, that would cause the problem. I'm willing to bet you downloaded the Makefile and distinfo and thought that would be all you needed; you very likely did not clean up the files/ directory to reflect the current state of the port. Consider this a reason for updating your ports tree properly. :-) If you want a tarball of just the net/DSS port, I can put one up somewhere for you as a convenience. My install did indeed start with ports and src installed (I have a hosted server where they do the initial install). I will use CVSUP and properly get my ports in order before I bug you guys again. I would recommend you use csup instead. I forget if it's available in the base system on 6.0, but if not, it's in net/csup. You can safely pkg_delete cvsup and ezm3/modula3 from your system and start using the pure C-based csup program (it functions 100% identically to cvsup, but lacks CVS mode, but you're not using that feature anyway). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: It is illogical layout of ports
On Sat, Oct 11, 2008 at 10:35:44AM +0300, Sokolov Alexey wrote: Hi! The location of some ports contradictory. They need all rank in the categories you want. There's a grey area with some that you need to keep in mind. I'll give you a perfect example: irc/bitlbee. bitlbee is an IM-to-IRC gateway. It acts as a stand-alone IRC server, but it bridges Windows Live/MSN, ICQ, AIM, Yahoo!, and Jabber to IRC so that you can talk with IM contacts using an IRC client. So -- does this program go under net-im or irc? You can see my point. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /sys/conf/kern.mk, line 114: Malformed conditional
On Wed, Oct 08, 2008 at 03:15:13PM +, JHutchinson wrote:
=== Building for nvidia-driver-173.14.12
=== src (all)
/sys/conf/kern.mk, line 114: Malformed conditional (${MK_SSP} != no
${CC} != icc ${MACHINE_ARCH} != ia64 ${MACHINE_ARCH} !=
arm ${MACHINE_ARCH} != mips)
/sys/conf/kern.mk, line 116: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Does this error go away if you update (via csup or cvsup) your src tree?
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [RELENG 6] imake-6 build failure
On Mon, Sep 29, 2008 at 09:54:56AM -0700, Sean Bruno wrote:
Anyone else seeing this on RELENG 6?
[EMAIL PROTECTED] /usr/ports/devel/imake-6]$ sudo make all
Makefile, line 58: Malformed conditional (${X_WINDOW_SYSTEM:L} != xorg)
Makefile, line 63: if-less endif
make: fatal errors encountered -- cannot continue
Note that ports/devel/imake-6 was migrated to devel/image 16 months ago.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/imake-6/Attic/Makefile
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [RELENG 6] imake-6 build failure
On Mon, Sep 29, 2008 at 07:47:21PM -0700, Sean Bruno wrote:
Jeremy Chadwick wrote:
On Mon, Sep 29, 2008 at 09:54:56AM -0700, Sean Bruno wrote:
Anyone else seeing this on RELENG 6?
[EMAIL PROTECTED] /usr/ports/devel/imake-6]$ sudo make all
Makefile, line 58: Malformed conditional (${X_WINDOW_SYSTEM:L} != xorg)
Makefile, line 63: if-less endif
make: fatal errors encountered -- cannot continue
Note that ports/devel/imake-6 was migrated to devel/image 16 months ago.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/imake-6/Attic/Makefile
Ok, I'm not sure what is going on then. Help?
[EMAIL PROTECTED] /usr/ports]$ sudo portupgrade -aP
** Port marked as IGNORE: devel/imake-6:
Makefile, line 63: if-less endif
** Proceeding anyway since NO_IGNORE is defined
/usr/local/lib/ruby/site_ruby/1.8/pkgversion.rb:41:in `initialize': :
Not in due form: 'version[_revision][,epoch]'. (ArgumentError)
from /usr/local/sbin/portupgrade:645:in `new'
from /usr/local/sbin/portupgrade:645:in `main'
from /usr/local/sbin/portupgrade:613:in `each'
from /usr/local/sbin/portupgrade:613:in `main'
from /usr/local/sbin/portupgrade:588:in `catch'
from /usr/local/sbin/portupgrade:588:in `main'
from /usr/local/lib/ruby/1.8/optparse.rb:1303:in `call'
from /usr/local/lib/ruby/1.8/optparse.rb:1303:in `parse_in_order'
... 7 levels...
from /usr/local/lib/ruby/1.8/optparse.rb:785:in `initialize'
from /usr/local/sbin/portupgrade:229:in `new'
from /usr/local/sbin/portupgrade:229:in `main'
from /usr/local/sbin/portupgrade:2208
I can't help with the portupgrade craziness that's going on there (I do
not use portupgrade), but it's obvious it's induced by the Makefile
being broken.
The fact you still have ports/devel/imake-6 indicates:
1) Outdated ports tree,
2) A corrupt or incorrect /var/db/sup/ports-all tree (if you remove
this directory, you will need to rm -fr /usr/ports/* as well)
3) When building the machine you chose ports from the list of things
to install (from CD/DVD/FTP/whatever), but never adopted them. The
adopted ordeal is explained in the cvsup documentation (in this
case, also applies to csup):
http://www.cvsup.org/faq.html#caniadopt
4) Read-only filesystem where /usr/ports resides (e.g. csup won't work),
5) Bizarre file flags on parts of the ports tree (e.g. schg set on
some ports for some reason; maybe some chflags -R script went crazy),
6) Corrupt filesystem (boot into single-user and do fsck -y. And yes,
the single-user part is important).
Item #3 is why I advocate folks do not choose src and ports from
their installation media unless absolutely forced to, and to simply do a
full csup once the system is up for the first time.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incorrect commandline history with bash
On Tue, Sep 23, 2008 at 11:45:07AM -0700, Jo Rhett wrote: On Sep 21, 2008, at 5:22 PM, Jeremy Chadwick wrote: Everyone lecturing me needs to read, slowly, the INVOCATION part of the bash man page. The method I described above should become apparent afterwards. I'm sorry if you feel I'm lecturing you -- I'm not. I was just trying to note that what you said seems to be backwards in my experience. Moreover, the section of the man page you quoted backed up my analysis: When bash is invoked as an interactive login shell, or as a non- interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior. It does not read ~/.bashrc. I have tested this and confirmed its behavior. Now, I will go farther and mention the obvious: When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. However, this file is only read when and if you type bash after you are already logged into the system in question. In general, because of the way bash works, it would suggest that putting variables you always want set in the .bashrc is correct, and sourcing it from .bash_profile is also correct. Variables (like terminal settings) which are only applied during login should be set in .bash_profile. Sourcing .bash_profile from .bashrc means you'd need some heft if/then code to avoid playing havoc with your terminal settings. IMHO of course. Thanks Jo. It looks like in my case I do have my files backwards (for lack of better phrasing), though I'm well aware of the difference between a login and non-login interactive shell. :-) I don't do any terminal tweaking in any of my dotfiles (I rely solely upon what PuTTY or SSH exports to the remote sshd via TERM). Switching the logic I have (.bashrc containing what my old .bash_profile did, and having .bash_profile source .bashrc) continues to work, as documented. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: Re: Incorrect commandline history with bash
Individual did not CC the mailing list on his response.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
- Forwarded message from manish jain [EMAIL PROTECTED] -
From: manish jain [EMAIL PROTECTED]
To: Jeremy Chadwick [EMAIL PROTECTED]
Date: Mon, 22 Sep 2008 01:54:46 +0530
Subject: Re: Incorrect commandline history with bash
Thanks Jeremy. Sourcing .bash_profile from .bashrc solved the problem. For
some reason, sourcing .bashrc from .bash_profile worked equally well with
the version of Linux I was previously using.
Regards
Manish Jain
On 9/21/08, Jeremy Chadwick [EMAIL PROTECTED] wrote:
On Sat, Sep 20, 2008 at 11:18:34PM +0530, manish jain wrote:
I just migrated from Linux and I am now using FreeBSD 6.3. My keyboard
layout is US-ISO and my TERM is con25. I am using bash#3 as my login
shell.
(I installed the bash package from the distribution media, not from
/usr/ports).
The problem is that bash does not remember my commands correctly. Almost
all
commands I enter in a login session are forgotten in the next session.
Using
the Up and Down arrow keys navigates a mangled and incomlete command
history. Even using Ctrl-r for a reverse find almost never fetches a
command
I had actually typed in previously.
The following are the contents of my .bash_profile and .bashrc:
#.bash_profile :
[ -f ~/.bashrc ] source ~/.bashrc
#end-of-file
You have this backwards. ~/.bashrc should contain something like this:
if [ -f ${HOME}/.bash_profile ]
then
source ${HOME}/.bash_profile
fi
And all of your applicable environment settings should go in
.bash_profile. This probably won't solve your problem, but I thought
I'd point it out.
#.bashrc :
export HISTFILESIZE=200
shopt -s cmdhist
shopt -s histappend
#end-of-file
I set none of these things (though I do use export HISTTIMEFORMAT=%T
but that should not affect your problem) and my .bash_history always
contains commands from past sessions, including timestamps too.
My options are defaults:
$ shopt | egrep 'cmdhist|histappend'
cmdhist on
histappend off
Can you please try pkg_delete'ing the bash you installed from the
installation media, and instead update your ports tree via csup (not
cvsup) and then build/install bash from /usr/ports/shells/bash?
Finally, please do not cross-post to multiple lists. It's shunned upon,
and generally pointless as not everyone is subscribed to both lists.
I've removed [EMAIL PROTECTED], as this could be a ports
issue rather than a generic question.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
- End forwarded message -
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incorrect commandline history with bash
On Sun, Sep 21, 2008 at 03:54:12PM -0700, Jo Rhett wrote:
On Sep 21, 2008, at 2:52 PM, Jeremy Chadwick wrote:
The following are the contents of my .bash_profile and .bashrc:
#.bash_profile :
[ -f ~/.bashrc ] source ~/.bashrc
#end-of-file
You have this backwards. ~/.bashrc should contain something like
this:
if [ -f ${HOME}/.bash_profile ]
then
source ${HOME}/.bash_profile
fi
Jeremy, I'm not sure what version of FreeBSD you are using but I'd like
to point out that in 6.2 and 6.3-REL his version is correct and yours
will not work.
That's funny, because mine does work. I spent quite a lot of time
looking at the bash man page over the years to determine how to properly
meet said needs. I use the exact same setup on Solaris 7/8/9/10 (bash
v2) and FreeBSD 4/5/6/7/8 (bash v3), and it works exactly how the man
page describes.
.bashrc is not sourced on login on any of my hosts. I have .
~/.bashrc in my .bash_profile. And I just commented it out, and
.bash_profile environment was set up, and the stuff in .bashrc was not.
Everyone lecturing me needs to read, slowly, the INVOCATION part of the
bash man page. The method I described above should become apparent
afterwards.
Is this perhaps an X versus SSH login sort of thing? I don't know. We
have no X environment, this is entirely logging in via SSH.
No, I do not use X anywhere. The OP may be using it.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incorrect commandline history with bash
On Sat, Sep 20, 2008 at 11:18:34PM +0530, manish jain wrote:
I just migrated from Linux and I am now using FreeBSD 6.3. My keyboard
layout is US-ISO and my TERM is con25. I am using bash#3 as my login shell.
(I installed the bash package from the distribution media, not from
/usr/ports).
The problem is that bash does not remember my commands correctly. Almost all
commands I enter in a login session are forgotten in the next session. Using
the Up and Down arrow keys navigates a mangled and incomlete command
history. Even using Ctrl-r for a reverse find almost never fetches a command
I had actually typed in previously.
The following are the contents of my .bash_profile and .bashrc:
#.bash_profile :
[ -f ~/.bashrc ] source ~/.bashrc
#end-of-file
You have this backwards. ~/.bashrc should contain something like this:
if [ -f ${HOME}/.bash_profile ]
then
source ${HOME}/.bash_profile
fi
And all of your applicable environment settings should go in
.bash_profile. This probably won't solve your problem, but I thought
I'd point it out.
#.bashrc :
export HISTFILESIZE=200
shopt -s cmdhist
shopt -s histappend
#end-of-file
I set none of these things (though I do use export HISTTIMEFORMAT=%T
but that should not affect your problem) and my .bash_history always
contains commands from past sessions, including timestamps too.
My options are defaults:
$ shopt | egrep 'cmdhist|histappend'
cmdhist on
histappend off
Can you please try pkg_delete'ing the bash you installed from the
installation media, and instead update your ports tree via csup (not
cvsup) and then build/install bash from /usr/ports/shells/bash?
Finally, please do not cross-post to multiple lists. It's shunned upon,
and generally pointless as not everyone is subscribed to both lists.
I've removed [EMAIL PROTECTED], as this could be a ports
issue rather than a generic question.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to upgrade ports that depend on openssl-stable?
On Fri, Sep 19, 2008 at 12:08:15AM -0500, David J Brooks wrote: I keep running into this error: === openssl-stable-0.9.7m_1 Conflicts with version in the base. *** Error code 1 OpenSSL is included in FreeBSD in the base system. The port you're trying to install requires a newer version of OpenSSL than what's in the base system. You need to define WITH_OPENSSL_BASE=yes in your /etc/make.conf. This should make the port build/install successfully, and will overwrite the OpenSSL installation in the base system. You will also need to set WITHOUT_OPENSSL=true in /etc/src.conf (assuming this is FreeBSD 7.x), to ensure the next time you build/install world, that you do not bother building the base version of OpenSSL, and instead continue to rely on the port version. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to upgrade ports that depend on openssl-stable?
On Thu, Sep 18, 2008 at 11:27:32PM -0700, Jeremy Chadwick wrote: On Fri, Sep 19, 2008 at 12:08:15AM -0500, David J Brooks wrote: I keep running into this error: === openssl-stable-0.9.7m_1 Conflicts with version in the base. *** Error code 1 OpenSSL is included in FreeBSD in the base system. The port you're trying to install requires a newer version of OpenSSL than what's in the base system. You need to define WITH_OPENSSL_BASE=yes in your /etc/make.conf. This should make the port build/install successfully, and will overwrite the OpenSSL installation in the base system. You will also need to set WITHOUT_OPENSSL=true in /etc/src.conf (assuming this is FreeBSD 7.x), to ensure the next time you build/install world, that you do not bother building the base version of OpenSSL, and instead continue to rely on the port version. One other thing I forgot to mention: You will need to rebuild all ports reliant on SSL (this may be hard to determine reliably), as well as all base system utilities reliant on SSL (make world will suffice for this), as there will very likely be a library version mismatch between the old base OpenSSL and the port version of OpenSSL. There's a chance you won't have to do this (I installed the port like you said and everything still works), but I would recommend you not take any chances. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: databases/mysql51-server and beginner's InnoDB questions
On Tue, Sep 16, 2008 at 08:50:54PM +0200, Morgan Wesström wrote: I have a few questions regarding enabling InnoDB but I'm not an expert on MySQL so I'm not even sure I know how to ask them correctly. But the only way to learn is to ask and hope nobody is offended by stupid questions. :-) I'm wondering why you're asking MySQL-specific questions on freebsd-ports. Questions I didn't answer should be punted to the MySQL folks, they're quite helpful. I realized today actually that there are different storage engines available for MySQL and that InnoDB seems to be preferred so I naturally First and foremost: I don't know where you got the idea that InnoDB is preferred. Whoever told you that is flat out wrong. You need to spend some more time reading up on the pros/cons to all of the MySQL storage engine types. InnoDB happens to be one of the most horrendous ones to deal with from an administrative point of view. It's always great when the InnoDB part is out of sync with /var/db/mysql/database/whatever.*, which can often happen during replication errors or bugs. My advice to people is to avoid InnoDB unless you *specifically* have engineered an application that will make use of it. MyISAM is a lot easier to deal with. wanted to use it. I can see with show create table sometable that Mediawiki's tables for example are already created with ENGINE=InnoDB. But in my MySQL config file, which is simply a copy of my-large.cnf, there is a whole section for InnoDB that is commented out. It begins with: # Uncomment the following if you are using InnoDB tables Ignore that. I can tell you're flailing around with config files. :-) You can look at the compile-time defaults of InnoDB by using SHOW VARIABLES, and performance using SHOW STATUS. Please read the MySQL docs. _First question:_ Is InnoDB enabled by default regardless of the settings in my.cnf and how can I verify it? It's enabled by default. Look at ports/databases/mysql51-server/Makefile; see WITHOUT_INNODB? If that's set (e.g. make WITHOUT_INNODB=true, or WITHOUT_INNODB=true in your /etc/make.conf), then the InnoDB storage engine will not be included. You can also disable InnoDB at runtime using mysqld --skip-innodb. If InnoDB stats are seen in SHOW STATUS, then InnoDB is enabled. You can also try creating a table using the InnoDB storage engine type. The CREATE TABLE will fail if the engine is disabled or unavailable. _Third question:_ Is this an issue with the FreeBSD port specifically? Should I report this to someone and how would I do that the correct way? None of what you've described (I snipped the portions out) are specific to the FreeBSD port. They are purely configuration issues, and are with MySQL. You should discuss your issues with the MySQL people. Cheers! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Balance - Port
On Sun, Sep 14, 2008 at 06:12:08PM +0300, Okalany Daniel wrote:
On Fri, Sep 12, 2008 at 5:03 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
On Fri, Sep 12, 2008 at 04:00:06PM +0300, Okalany Daniel wrote:
Im on freebsd current with ports current.
FreeBSD down.one2net.co.ug 8.0-CURRENT FreeBSD 8.0-CURRENT #7: Wed Sep
10
19:31:10 EAT 2008 [EMAIL PROTECTED]:
/usr/obj/usr/src/sys/IPFWKERNEL
i386
[EMAIL PROTECTED] /usr/home/oka]# /usr/local/etc/rc.d/balance start
setsockopt(IPV6_V6ONLY=0): Invalid argument
Is this a problem with balancer or my options?
It appears you've removed IPv6 support from your kernel, which is fine.
The bug in with the IPv6 detection method used by balancer. The logic
in balancer is if IPV6_V6ONLY is defined, call setsockopt() with
IPV6_V6ONLY. The definition is pulled in from one of many #include
files in /usr/include.
balancer assumes that if IPV6_V6ONLY is defined, that it should make
the setsockopt() call. This won't work for systems with IPv6 removed
from the kernel -- because the system #include files still define
IPV6_V6ONLY as an available bit.
Can you apply the following hackfix against ports/net/balancer/Makefile
and tell me if it works for you? Please note you'll need to build the
port either with make WITHOUT_IPV6=true or place WITHOUT_IPV6=true
in /etc/make.conf.
--- Makefile.orig 2008-07-09 00:15:46.0 -0700
+++ Makefile2008-09-12 07:00:44.0 -0700
@@ -20,6 +20,10 @@
MAN1= balance.1
+.if defined(WITHOUT_IPV6)
+CFLAGS+= -UIPV6_V6ONLY
+.endif
+
pre-build:
@${REINPLACE_CMD} -e 's|^CFLAGS|CFLAGS?|' \
-e 's|^CC|CC?|' ${WRKSRC}/Makefile
Thanks for the quick response, but that hasnt solved the issue, it stays the
same.
Interesting, since that resolved said problem on my IPv4-only machine,
but that's a RELENG_7 box. I wonder how the -U is getting overridden.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mod_python core dump
On Sun, Sep 14, 2008 at 05:45:59PM +0200, Matias Surdi wrote: Jeremy Chadwick escribió: On Fri, Sep 12, 2008 at 11:39:35AM +0200, Matias Surdi wrote: I've installed mod_python from the ports on a recently installed FreeBSD 7 box and, despite all the build process goes well, when I try to start apache I get a core dump. If I disable the Loadmodule directive for mod_python in httpd.conf, then apache starts perfectly. The versions I'm using are: # pkg_version -v apache-2.0.63_2 = up-to-date with port autoconf-2.62 = up-to-date with port autoconf-wrapper-20071109 = up-to-date with port bash-3.2.39_1 = up-to-date with port dovecot-1.1.3 = up-to-date with port expat-2.0.1 = up-to-date with port gettext-0.17_1 = up-to-date with port gmake-3.81_3= up-to-date with port help2man-1.36.4_2 = up-to-date with port libiconv-1.11_1 = up-to-date with port libtool-1.5.26 = up-to-date with port linux_base-fc-4_10 needs updating (port has 4_13) m4-1.4.11,1 = up-to-date with port mod_python-3.3.1_2 = up-to-date with port p5-gettext-1.05_2 = up-to-date with port pcre-7.7_1 = up-to-date with port perl-5.8.8_1= up-to-date with port pkg-config-0.23_1 = up-to-date with port postfix-2.5.4,1 = up-to-date with port py25-sqlite3-2.5.2_1= up-to-date with port python25-2.5.2_3= up-to-date with port sqlite3-3.5.6 = up-to-date with port Any help will be appreciated, thanks. You'll need to provide a gdb backtrace to determine the cause of the core, and provide any error messages shown in Apache's error log (default: /var/log/httpd-error.log). The above information doesn't provide enough detail. Please also be aware that, quite often, debugging Apache and Apache modules is a tedious and difficult task. It's rarely a simple thing. I've noticed that compiling python without threads support fixes the problem, but that's not a solution for me as I need threads. Any other ideas? Doesn't surprise me. I'd recommend first reporting your problem upstream to the mod_python authors, as this does not appear to be a FreeBSD or FreeBSD ports issue. As for solution, the solution here is to not use mod_python. Surely something like cgiwrap or FastCGI could be made to work with python. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mod_python core dump
On Fri, Sep 12, 2008 at 11:39:35AM +0200, Matias Surdi wrote: I've installed mod_python from the ports on a recently installed FreeBSD 7 box and, despite all the build process goes well, when I try to start apache I get a core dump. If I disable the Loadmodule directive for mod_python in httpd.conf, then apache starts perfectly. The versions I'm using are: # pkg_version -v apache-2.0.63_2 = up-to-date with port autoconf-2.62 = up-to-date with port autoconf-wrapper-20071109 = up-to-date with port bash-3.2.39_1 = up-to-date with port dovecot-1.1.3 = up-to-date with port expat-2.0.1 = up-to-date with port gettext-0.17_1 = up-to-date with port gmake-3.81_3= up-to-date with port help2man-1.36.4_2 = up-to-date with port libiconv-1.11_1 = up-to-date with port libtool-1.5.26 = up-to-date with port linux_base-fc-4_10 needs updating (port has 4_13) m4-1.4.11,1 = up-to-date with port mod_python-3.3.1_2 = up-to-date with port p5-gettext-1.05_2 = up-to-date with port pcre-7.7_1 = up-to-date with port perl-5.8.8_1= up-to-date with port pkg-config-0.23_1 = up-to-date with port postfix-2.5.4,1 = up-to-date with port py25-sqlite3-2.5.2_1= up-to-date with port python25-2.5.2_3= up-to-date with port sqlite3-3.5.6 = up-to-date with port Any help will be appreciated, thanks. You'll need to provide a gdb backtrace to determine the cause of the core, and provide any error messages shown in Apache's error log (default: /var/log/httpd-error.log). The above information doesn't provide enough detail. Please also be aware that, quite often, debugging Apache and Apache modules is a tedious and difficult task. It's rarely a simple thing. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Balance - Port
On Fri, Sep 12, 2008 at 04:00:06PM +0300, Okalany Daniel wrote:
Im on freebsd current with ports current.
FreeBSD down.one2net.co.ug 8.0-CURRENT FreeBSD 8.0-CURRENT #7: Wed Sep 10
19:31:10 EAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IPFWKERNEL
i386
[EMAIL PROTECTED] /usr/home/oka]# /usr/local/etc/rc.d/balance start
setsockopt(IPV6_V6ONLY=0): Invalid argument
Is this a problem with balancer or my options?
It appears you've removed IPv6 support from your kernel, which is fine.
The bug in with the IPv6 detection method used by balancer. The logic
in balancer is if IPV6_V6ONLY is defined, call setsockopt() with
IPV6_V6ONLY. The definition is pulled in from one of many #include
files in /usr/include.
balancer assumes that if IPV6_V6ONLY is defined, that it should make
the setsockopt() call. This won't work for systems with IPv6 removed
from the kernel -- because the system #include files still define
IPV6_V6ONLY as an available bit.
Can you apply the following hackfix against ports/net/balancer/Makefile
and tell me if it works for you? Please note you'll need to build the
port either with make WITHOUT_IPV6=true or place WITHOUT_IPV6=true
in /etc/make.conf.
--- Makefile.orig 2008-07-09 00:15:46.0 -0700
+++ Makefile2008-09-12 07:00:44.0 -0700
@@ -20,6 +20,10 @@
MAN1= balance.1
+.if defined(WITHOUT_IPV6)
+CFLAGS+= -UIPV6_V6ONLY
+.endif
+
pre-build:
@${REINPLACE_CMD} -e 's|^CFLAGS|CFLAGS?|' \
-e 's|^CC|CC?|' ${WRKSRC}/Makefile
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
