horde4-base www moved
Hi, I did a make deinstall/reinstall of horde4-base and to my surprise the installation placed the web accessible files in /usr/local/lib/php/pear/www/horde/ and they used to be in /usr/local/www/horde Is this intentional or did I mess anything up somewhere? I have no special options set anywhere. Thanks, ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: "postfix-current" broken on amd64 platform
On Tue, 2011-11-15 at 17:55:57 +0100, Pav Lucistnik wrote: > Jase Thew píše v út 15. 11. 2011 v 16:31 +: > > > What networking/DNS configuration is Pointyhat lacking (or have > > sufficiently different to break the socket code inside of postconf)? > > It is a purposefully no-networking sandbox jail. What networking > activity postconf wants to run? Wietse, in a post[1] on the Postfix mailing list, lends further credence to a suspicion that this issue is particular to pointyhat: Postconf opens a socket to determine the mynetworks value (it determines the local interfaces and their netmasks). I have heard about bizarre errors on FreeBSD (jail) systems where the user-land library was out of sync with kernel-land, resulting in data structure mis-matches and system calls returning nonsensical results. [1] http://archives.neohapsis.com/archives/postfix/2011-11/0385.html -- Sahil Tandon pgptIjjuej4zI.pgp Description: PGP signature
Re: Plan to add a bsd.pure.mk
Currently, 12. Plus 3 committed, 1 unsubmitted, 3~4 planning to port. The
total existing addons are listed here:
http://code.google.com/p/pure-lang/wiki/Addons
I probably not going to port all of them, but this list is growing.
On Tue, Nov 15, 2011 at 3:36 PM, Ion-Mihai Tetcu wrote:
> On Thu, 10 Nov 2011 13:02:38 -0600
> Zhihao Yuan wrote:
>
> > Hi,
> >
> > The PR which updates all pure-* ports was passed to portmgr for a long
> > time, since it seem that to put a
> >
> > .if defined(USE_PURE)
> > .include "${PORTSDIR}/Mk/bsd.pure.mk"
> > .endif
> >
> > In bsd.port.mk may a be better choice. Though Pure is not as popular
> > as some languages like PHP or Python, but it does and it will have
> > more ports than like Go. To include bsd.pure.mk under Mk/ can lower 2
> > lines in ~20 ports (or I have to leave it under lang/pure's private
> > directory).
>
> How many pure ports are there ATM?
>
> --
> IOnut - Un^d^dregistered ;) FreeBSD "user"
> "Intellectual Property" is nowhere near as valuable as "Intellect"
> FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B
>
--
Zhihao Yuan, nickname lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
freebsd-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: Plan to add a bsd.pure.mk
On Thu, 10 Nov 2011 13:02:38 -0600
Zhihao Yuan wrote:
> Hi,
>
> The PR which updates all pure-* ports was passed to portmgr for a long
> time, since it seem that to put a
>
> .if defined(USE_PURE)
> .include "${PORTSDIR}/Mk/bsd.pure.mk"
> .endif
>
> In bsd.port.mk may a be better choice. Though Pure is not as popular
> as some languages like PHP or Python, but it does and it will have
> more ports than like Go. To include bsd.pure.mk under Mk/ can lower 2
> lines in ~20 ports (or I have to leave it under lang/pure's private
> directory).
How many pure ports are there ATM?
--
IOnut - Un^d^dregistered ;) FreeBSD "user"
"Intellectual Property" is nowhere near as valuable as "Intellect"
FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B
signature.asc
Description: PGP signature
Re: multimedia/phonon: CMake Error at CMakeLists.txt:58 (if):
15.11.2011 01:29, Raphael Kubo da Costa пишет: > Thanks, I've just fixed this upstream and added my fix to area51 > (r7826). I'll commit it to ports as soon as I get an OK from avilla or > makc. Great, the port compiles now. Thanks! > BTW, you were supposed to get a warning instead of an error too, do you > have some special setting that raises the severity of warnings? Strange, but I don't have one. The only non-default option is that the system was built by clang. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-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 ports removal
On 15/11/2011 19:25, Chris Rees wrote: > On 15 November 2011 19:19, Matthew Seaman > wrote: >> On 15/11/2011 19:01, Matthew Seaman wrote: >>> On 11/11/2011 22:23, Doug Barton wrote: > By its >> nature, deprecated ports tends not to be updated for long time, port >> tools like portmaster, portupgrade will not even see it because no >> PORTREVISION bump happen. >>> portmaster -L will warn you about ports marked DEPRECATED/FORBIDDEN/IGNORE/BROKEN if you run it against an updated ports tree. One area where we actually can improve here is to also put this information in the INDEX. I have an idea for that, just haven't been able to put the time into making it happen. >>> >>> How about something like the attached? >> >> Ooops. Wrong diff. Like this: > > Why have you included IGNOREd? > > Just curious A pedantic desire to cover all possibilities. It probably doesn't need to be there, but my (admittedly cursory) reading of the code suggests that by defining NO_IGNORE it could still be possible to build a pkg. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Recent ports removal
On 15 November 2011 19:19, Matthew Seaman wrote: > On 15/11/2011 19:01, Matthew Seaman wrote: >> On 11/11/2011 22:23, Doug Barton wrote: By its > nature, deprecated ports tends not to be updated for long time, port > tools like portmaster, portupgrade will not even see it because no > PORTREVISION bump happen. >> >>> portmaster -L will warn you about ports marked >>> DEPRECATED/FORBIDDEN/IGNORE/BROKEN if you run it against an updated >>> ports tree. One area where we actually can improve here is to also put >>> this information in the INDEX. I have an idea for that, just haven't >>> been able to put the time into making it happen. >> >> How about something like the attached? > > Ooops. Wrong diff. Like this: Why have you included IGNOREd? Just curious Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Recent ports removal
On 15/11/2011 19:01, Matthew Seaman wrote:
> On 11/11/2011 22:23, Doug Barton wrote:
>>> By its
nature, deprecated ports tends not to be updated for long time, port
tools like portmaster, portupgrade will not even see it because no
PORTREVISION bump happen.
>
>> portmaster -L will warn you about ports marked
>> DEPRECATED/FORBIDDEN/IGNORE/BROKEN if you run it against an updated
>> ports tree. One area where we actually can improve here is to also put
>> this information in the INDEX. I have an idea for that, just haven't
>> been able to put the time into making it happen.
>
> How about something like the attached?
Ooops. Wrong diff. Like this:
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
Index: bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.699
diff -u -u -r1.699 bsd.port.mk
--- bsd.port.mk 9 Nov 2011 08:53:12 - 1.699
+++ bsd.port.mk 15 Nov 2011 18:59:49 -
@@ -4293,8 +4293,9 @@
_BUILD_SEQ=build-message pre-build pre-build-script do-build \
post-build post-build-script
_INSTALL_DEP= build
-_INSTALL_SEQ= install-message check-install-conflicts run-depends lib-depends
apply-slist pre-install \
- pre-install-script generate-plist
check-already-installed
+_INSTALL_SEQ= install-message check-install-conflicts run-depends lib-depends
\
+ apply-slist deprecate-and-expire pre-install
pre-install-script \
+ generate-plist check-already-installed
_INSTALL_SUSEQ= check-umask install-mtree pre-su-install \
pre-su-install-script create-users-groups
do-install \
install-desktop-entries install-license
install-rc-script \
@@ -5615,6 +5616,34 @@
.endif
.endif
+.if !target(deprecate-and-expire)
+deprecate-and-expire:
+.if defined(DEPRECATED) || defined(FORBIDDEN) || defined(BROKEN) || \
+ defined(IGNORE) || defined(EXPIRATION_DATE)
+ @if [ -f ${_PKGMESSAGE_SAVE} -a ! -f ${PKGMESSAGE} ] ; then \
+${CP} ${_PKGMESSAGE_SAVE} ${PKGMESSAGE} ; \
+ fi
+.for i in DEPRECATED FORBIDDEN BROKEN
+.if defined(${i})
+ @${ECHO_MSG} "===> This port is ${i}: ${${i}}"
+ @${ECHO_CMD} "===> This port is ${i}: ${${i}}" >> ${PKGMESSAGE}
+.endif
+.endfor
+.if defined(IGNORE)
+ @${ECHO_MSG} "===> This port should have been IGNORED: ${IGNORE}"
+ @${ECHO_CMD} "===> This port should have been IGNORED: ${IGNORE}" >> \
+ ${PKGMESSAGE}
+.endif
+.if defined(EXPIRATION_DATE)
+ @${ECHO_MSG} "===> EXPIRATION DATE is set to: ${EXPIRATION_DATE}"
+ @${ECHO_CMD} "===> EXPIRATION DATE is set to: ${EXPIRATION_DATE}" >> \
+ ${PKGMESSAGE}
+.endif
+_PKGMESSAGE_SAVE :=${PKGMESSAGE}
+PKGMESSAGE = ${WRKDIR}/${_PKGMESSAGE_SAVE:T}
+.endif
+.endif
+
# Generate packing list. Also tests to make sure all required package
# files exist.
signature.asc
Description: OpenPGP digital signature
Re: Recent ports removal
On 11/11/2011 22:23, Doug Barton wrote:
>> By its
>> > nature, deprecated ports tends not to be updated for long time, port
>> > tools like portmaster, portupgrade will not even see it because no
>> > PORTREVISION bump happen.
> portmaster -L will warn you about ports marked
> DEPRECATED/FORBIDDEN/IGNORE/BROKEN if you run it against an updated
> ports tree. One area where we actually can improve here is to also put
> this information in the INDEX. I have an idea for that, just haven't
> been able to put the time into making it happen.
How about something like the attached? Rather than adding to the INDEX,
this appends DEPRECATED, FORBIDDEN, IGNORE, BROKEN and EXPIRATION_DATE
values to pkg-message, creating one if the port doesn't already have it.
The duplication of echoing messages to STDOUT as well as the pkg-message
file is not ideal, but displaying pkg-message at install time is not
automatic when installing from ports. It might be an idea to have a
standard port-install target to display ${PKGMESSAGE} if the file exists.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
Index: Makefile
===
RCS file: /home/ncvs/ports/ports-mgmt/p5-FreeBSD-Portindex/Makefile,v
retrieving revision 1.20
diff -u -u -r1.20 Makefile
--- Makefile29 Aug 2011 04:43:56 - 1.20
+++ Makefile26 Oct 2011 08:14:43 -
@@ -5,7 +5,7 @@
# $FreeBSD: ports/ports-mgmt/p5-FreeBSD-Portindex/Makefile,v 1.20 2011/08/29
04:43:56 dougb Exp $
PORTNAME= FreeBSD-Portindex
-PORTVERSION= 2.4
+PORTVERSION= 2.6
CATEGORIES=ports-mgmt perl5
MASTER_SITES= http://www.infracaninophile.co.uk/portindex/
PKGNAMEPREFIX= p5-
@@ -15,9 +15,20 @@
LICENSE= BSD
+# GraphViz not required for portindex to run or generate GraphViz
+# format output: this is only needed to render the output on the same
+# machine.
+OPTIONS= GRAPHVIZ "Add GraphViz run-time dependency" off
+
BUILD_DEPENDS=
${SITE_PERL}/${PERL_ARCH}/BerkeleyDB.pm:${PORTSDIR}/databases/p5-BerkeleyDB
RUN_DEPENDS:= ${BUILD_DEPENDS}
+.include
+
+.if defined(WITH_GRAPHVIZ) && !defined(WITHOUT_GRAPHVIZ)
+RUN_DEPENDS+= dot:${PORTSDIR}/graphics/graphviz
+.endif
+
USE_XZ=yes
PERL_CONFIGURE=yes
Index: distinfo
===
RCS file: /home/ncvs/ports/ports-mgmt/p5-FreeBSD-Portindex/distinfo,v
retrieving revision 1.15
diff -u -u -r1.15 distinfo
--- distinfo29 Aug 2011 04:43:56 - 1.15
+++ distinfo26 Oct 2011 08:14:43 -
@@ -1,2 +1,2 @@
-SHA256 (FreeBSD-Portindex-2.4.tar.xz) =
78f461e35dcadb9fb79665c698825fd54e081030858cf023bedfeb47b73891d0
-SIZE (FreeBSD-Portindex-2.4.tar.xz) = 50724
+SHA256 (FreeBSD-Portindex-2.6.tar.xz) =
909ea1b4ff67ea08617a54452b6ed9e999787d6ff3458cb59fb6aa81ecc67c13
+SIZE (FreeBSD-Portindex-2.6.tar.xz) = 51828
Index: pkg-plist
===
RCS file: /home/ncvs/ports/ports-mgmt/p5-FreeBSD-Portindex/pkg-plist,v
retrieving revision 1.5
diff -u -u -r1.5 pkg-plist
--- pkg-plist 14 Mar 2011 16:05:35 - 1.5
+++ pkg-plist 26 Oct 2011 08:14:43 -
@@ -8,6 +8,7 @@
@exec [ ! -f %B/portindex.cfg ] && cp -p %B/%f %B/portindex.cfg || true
%%SITE_PERL%%/FreeBSD/Portindex/Config.pm
%%SITE_PERL%%/FreeBSD/Portindex/Category.pm
+%%SITE_PERL%%/FreeBSD/Portindex/GraphViz.pm
%%SITE_PERL%%/FreeBSD/Portindex/Port.pm
%%SITE_PERL%%/FreeBSD/Portindex/Tree.pm
%%SITE_PERL%%/FreeBSD/Portindex/TreeObject.pm
signature.asc
Description: OpenPGP digital signature
Re: "postfix-current" broken on amd64 platform
On Nov 15, 2011, at 11:55 AM, Pav Lucistnik wrote: > Jase Thew píše v út 15. 11. 2011 v 16:31 +: > >> What networking/DNS configuration is Pointyhat lacking (or have >> sufficiently different to break the socket code inside of postconf)? > > It is a purposefully no-networking sandbox jail. I have an idea; unless someone else figures it out before then, I'll take a look in a few hours when I'm back in front of a computer. Thanks all for the 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"
Re: [removed ports] sysutils/cpuburn
on 15/11/2011 18:04 Chris Rees said the following:
> On 15 November 2011 14:34, Andriy Gapon wrote:
>>
>> Does anyone know good any alternative(s) for cpuburn?
>> If not, then I would like to request that this port be restored.
>> I am prepared to be designated as its maintainer and to host its distfile
>> (via my
>> FreeBSD account).
>>
>> Maintaining the port should be rather easy as it can not have any security
>> issues
>> by definition and at the moment there is no active upstream, so no code
>> changes
>> are expected.
>
> If you can host it and maintain it, fantastic.
>
> I notice you're not a ports guy, so if if you like, feel free to send
> me a new url for the MASTER_SITES and I'll do the dirty work for you
> (no patronising intended)
It should be
MASTER_SITES= ${MASTER_SITE_LOCAL}
MASTER_SITE_SUBDIR= avg
once the directory is picked up by ftp-master from freefall and propagated to
the
mirrors (may take a while, it seems).
>> P.S. Sorry that I've missed its deprecation. I haven't noticed the activity
>> until
>> I needed to use it at yet another system.
>
> Resurrection is easy :) Thanks for helping to keep the tree in good shape.
Thank you for your help!
--
Andriy Gapon
___
freebsd-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: [removed ports] sysutils/cpuburn
on 15/11/2011 17:07 Baptiste Daroussin said the following: > On Tue, Nov 15, 2011 at 04:34:22PM +0200, Andriy Gapon wrote: >> >> Does anyone know good any alternative(s) for cpuburn? >> If not, then I would like to request that this port be restored. >> I am prepared to be designated as its maintainer and to host its distfile >> (via my >> FreeBSD account). >> >> Maintaining the port should be rather easy as it can not have any security >> issues >> by definition and at the moment there is no active upstream, so no code >> changes >> are expected. >> >> P.S. Sorry that I've missed its deprecation. I haven't noticed the activity >> until >> I needed to use it at yet another system. >> > > I often use sysutils/stress don't know if that fits your needs? I didn't know about this tool before... Unfortunately I do not see a detailed description of how exactly it loads CPU and if it does any validation/verification. cpuburn is more explicit about this and is kind of proven. Besides it has additional stuff like e.g. burnBX/burnMMX. So, I would I love to still have it. Thank you for pointing me to sysutils/stress in any case. -- Andriy Gapon ___ freebsd-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: cvs checkout ./. csup
Quoth Daniel Nebdal on Tuesday, 15 November 2011: > On Tue, Nov 15, 2011 at 12:00 PM, Matthew Seaman > wrote: > > On 15/11/2011 09:48, Matthias Apitz wrote: > >> Since many years I'm fetching or updating /usr/ports with > >> > >> # cd /usr > >> # setenv CVSROOT :pserver:anon...@anoncvs.fr.freebsd.org:/home/ncvs > >> # cvs checkout ports > >> > >> and later do the updating just with: > >> > >> # cd /usr/ports > >> # cvs update > >> # portupgrade -ai > >> > >> The FreeBSD handbook describes (or recommends?) using 'csup' for > >> updating ports tree... What is the advantage (or reason, if any)? > > > > Efficiency, basically. csup should require less bandwidth and put less > > load on servers than using cvs directly. It works like rsync, only > > transferring the parts of the files that changed but exploiting the cvs > > revision history to produce more specific and minimal deltas than you > > can get just by using the standard rsync algorithm. > > > > However csup(1) doesn't give you any of the VCS features you'ld get by > > doing a cvs checkout -- so no simple way to diff a local copy against > > the repo, etc. etc. 'cvs checkout' of all or parts of the ports is still > > frequently preferable for developing rather than just using the ports. > > > > There are also many more cvsup servers worldwide than there are anon-cvs > > servers. > > > > There's also portsnap, which has been in the base system for a while > now. It has some of the same drawbacks as csup/cvsup (no VCS > features), but is in my experience faster than them. In short, you can > use "portsnap fetch extract" to download a complete compressed tarball > of current ports and extract it, and after doing that you can use > "portsnap fetch update" to update to the current state. Read the > manpage; there are some important details. > > It uses a binary patch system that's quite efficient, so if you just > want an updated /usr/ports , it's probably the fastest solution. (I > think the exact method is that "fetch" grabs a tarball if it doesn't > exist. If it does exist, it gets the binary patches required to update > it to the current state. With it in place, "extract" unpacks the > entire thing, and "update" only extracts the files touched by the last > "fetch"-command.) > > It has a handbook page: http://www.freebsd.org/doc/handbook/portsnap.html > In my experience, portsnap is much faster than csup for updating ports. I've tried both (at different times) updating almost daily for months at a time. -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com pgpZX4UD0cPH1.pgp Description: PGP signature
Re: "postfix-current" broken on amd64 platform
Jase Thew píše v út 15. 11. 2011 v 16:31 +: > What networking/DNS configuration is Pointyhat lacking (or have > sufficiently different to break the socket code inside of postconf)? It is a purposefully no-networking sandbox jail. What networking activity postconf wants to run? -- -- Pav Lucistnik You have acquired a scroll entitled 'irk gleknow mizk' (n). This is an IBM Manual scroll. You are permanently confused. signature.asc Description: This is a digitally signed message part
Re: ports/16254: New port: www/cronolog
Synopsis: New port: www/cronolog State-Changed-From-To: open->closed State-Changed-By: miwi State-Changed-When: Tue Nov 15 16:51:48 UTC 2011 State-Changed-Why: close again was a mistake http://www.freebsd.org/cgi/query-pr.cgi?pr=16254 ___ freebsd-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: "postfix-current" broken on amd64 platform
On 15/11/2011 14:31, Sahil Tandon wrote: It was marked broken on a particular architecture, hence the genesis of this thread. I appreciate that diagnosis is difficult; perhaps Olli's suggestion is helpful in isolating the issue. I do not know how else to troubleshoot since these pointyhat errors are not - AFAIK - reproducible by others, on either i386 or amd64 platforms. Hi all, The install is failing during a call to $wrksrc/conf/post-install. Taken from the pointyhat logs : ./postconf -d) |egrep -v '^(myhostname|mydomain|mynetworks) ' >../../conf/main.cf.default ./postconf: fatal: socket: Protocol not supported Postconf is dying with a fatal socket error. This binary is used in various places, including $wrksrc/conf/post-install. There are various tests in this post-install script that will exit with 1 should executing postconf fail for any reason. Therefore, fixing the reason for postconf throwing a fatal error will fix the build/install. What networking/DNS configuration is Pointyhat lacking (or have sufficiently different to break the socket code inside of postconf)? Regards, Jase Thew. ___ freebsd-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/16254: New port: www/cronolog
Synopsis: New port: www/cronolog State-Changed-From-To: closed->open State-Changed-By: miwi State-Changed-When: Tue Nov 15 16:26:29 UTC 2011 State-Changed-Why: Maintainer has approved. http://www.freebsd.org/cgi/query-pr.cgi?pr=16254 ___ freebsd-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: [removed ports] sysutils/cpuburn
On 15 November 2011 14:34, Andriy Gapon wrote: > > Does anyone know good any alternative(s) for cpuburn? > If not, then I would like to request that this port be restored. > I am prepared to be designated as its maintainer and to host its distfile > (via my > FreeBSD account). > > Maintaining the port should be rather easy as it can not have any security > issues > by definition and at the moment there is no active upstream, so no code > changes > are expected. If you can host it and maintain it, fantastic. I notice you're not a ports guy, so if if you like, feel free to send me a new url for the MASTER_SITES and I'll do the dirty work for you (no patronising intended) > P.S. Sorry that I've missed its deprecation. I haven't noticed the activity > until > I needed to use it at yet another system. Resurrection is easy :) Thanks for helping to keep the tree in good shape. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [removed ports] sysutils/cpuburn
On 15.11.2011 16:07, Baptiste Daroussin wrote: On Tue, Nov 15, 2011 at 04:34:22PM +0200, Andriy Gapon wrote: Does anyone know good any alternative(s) for cpuburn? If not, then I would like to request that this port be restored. I am prepared to be designated as its maintainer and to host its distfile (via my FreeBSD account). Maintaining the port should be rather easy as it can not have any security issues by definition and at the moment there is no active upstream, so no code changes are expected. P.S. Sorry that I've missed its deprecation. I haven't noticed the activity until I needed to use it at yet another system. I often use sysutils/stress don't know if that fits your needs? I've just noticed that cpuburn is gone and stress is not an alternative for my task. Why? Because I use cpuburn to verify the undervolting capabilities of AMD cpus's for sysutils/cpupowerd which needs to explicitly hammer the CPU with MMX instructions and parallel with normal CPU instructions while lowering vcore. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-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: "postfix-current" broken on amd64 platform
On Tue, 15 Nov 2011 09:31:49 -0500 Sahil Tandon articulated: > It was marked broken on a particular architecture, hence the genesis > of this thread. I appreciate that diagnosis is difficult; perhaps > Olli's suggestion is helpful in isolating the issue. I do not know > how else to troubleshoot since these pointyhat errors are not - AFAIK > - reproducible by others, on either i386 or amd64 platforms. It would seem to me, and please correct me if my logic is faulty here, that if the problem is ONLY reproducible on "pointyhat" and not on other systems that the problem would therefore reside with "pointyhat". Sahil, I know from time to time that you post on the "Postfix" forum. Have you tried contacting Wietse, aka "Mr Grumpy" personally and asking him for his take on the problem? -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ If you don't know the difference between a 'burro' and a 'burrow', then you don't know your ass from a hole in the ground. ___ freebsd-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: [removed ports] sysutils/cpuburn
On Tue, Nov 15, 2011 at 04:34:22PM +0200, Andriy Gapon wrote: > > Does anyone know good any alternative(s) for cpuburn? > If not, then I would like to request that this port be restored. > I am prepared to be designated as its maintainer and to host its distfile > (via my > FreeBSD account). > > Maintaining the port should be rather easy as it can not have any security > issues > by definition and at the moment there is no active upstream, so no code > changes > are expected. > > P.S. Sorry that I've missed its deprecation. I haven't noticed the activity > until > I needed to use it at yet another system. > I often use sysutils/stress don't know if that fits your needs? regards, Bapt pgpao2G3oNygl.pgp Description: PGP signature
[removed ports] sysutils/cpuburn
Does anyone know good any alternative(s) for cpuburn? If not, then I would like to request that this port be restored. I am prepared to be designated as its maintainer and to host its distfile (via my FreeBSD account). Maintaining the port should be rather easy as it can not have any security issues by definition and at the moment there is no active upstream, so no code changes are expected. P.S. Sorry that I've missed its deprecation. I haven't noticed the activity until I needed to use it at yet another system. -- Andriy Gapon ___ freebsd-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: "postfix-current" broken on amd64 platform
It was marked broken on a particular architecture, hence the genesis of this
thread. I appreciate that diagnosis is difficult; perhaps Olli's suggestion is
helpful in isolating the issue. I do not know how else to troubleshoot since
these pointyhat errors are not - AFAIK - reproducible by others, on either i386
or amd64 platforms.
On Nov 15, 2011, at 4:45 AM, Pav Lucistnik wrote:
> 1) The problem is not amd64 specific
>
> 2) No point unmarking BROKEN, it currently fails on i386 pointyhat nodes
> too
>
> 3) Diagnosis is hard because the postfix-install shell script prints no
> useful progress messages
>
> Example failure log:
> http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.2003071512/postfix-current-2.9.20111012,4.log
>
> Sahil Tandon píše v po 14. 11. 2011 v 21:24 -0500:
>> [ pav@ and those who tested mail/postifx-current on amd64 added to Cc: ]
>>
>> On Mon, 2011-11-14 at 08:37:13 -0500, Jerry wrote:
>>
>>> The "postfix-current" port is still marked as broken:
>>>
>>> .if ${ARCH} == "amd64"
>>> BROKEN= fails during installation
>>> .endif
>>>
>>> Since all previous releases of Postfix worked on FreeBSD, and since
>>> Postfix is/was developed on FreeBSD, I was wondering what the problem
>>> is with this release. Is there a possibility that this phenomena might
>>> be rectified in the near future?
>>
>> Thanks for your report, Jerry. You are correct that FreeBSD is the main
>> development platform for Postfix. It seems that pointyhat's amd64
>> machine throws an error during the install phase. Pav noticed this and
>> marked the port BROKEN; however, neither I nor a few others I've
>> enlisted can reproduce the error. Would you mind removing the
>> conditional that marks this port BROKEN, try to build/install in your
>> amd64 environment, and report the results?
>>
>> Pav, if nobody else can reproduce the error seen on pointyhat, can
>> portmgr look into whether there is something quirky with the amd64
>> pointyhat machine?
>>
>
> --
> --
> Pav Lucistnik
>
> Two sausages are in a frying pan. One says, "Geez, it's hot in here
> isn't it?" And the other one says, "Aah! A talking sausage!"
___
freebsd-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: cvs checkout ./. csup
On Tue, Nov 15, 2011 at 12:00 PM, Matthew Seaman wrote: > On 15/11/2011 09:48, Matthias Apitz wrote: >> Since many years I'm fetching or updating /usr/ports with >> >> # cd /usr >> # setenv CVSROOT :pserver:anon...@anoncvs.fr.freebsd.org:/home/ncvs >> # cvs checkout ports >> >> and later do the updating just with: >> >> # cd /usr/ports >> # cvs update >> # portupgrade -ai >> >> The FreeBSD handbook describes (or recommends?) using 'csup' for >> updating ports tree... What is the advantage (or reason, if any)? > > Efficiency, basically. csup should require less bandwidth and put less > load on servers than using cvs directly. It works like rsync, only > transferring the parts of the files that changed but exploiting the cvs > revision history to produce more specific and minimal deltas than you > can get just by using the standard rsync algorithm. > > However csup(1) doesn't give you any of the VCS features you'ld get by > doing a cvs checkout -- so no simple way to diff a local copy against > the repo, etc. etc. 'cvs checkout' of all or parts of the ports is still > frequently preferable for developing rather than just using the ports. > > There are also many more cvsup servers worldwide than there are anon-cvs > servers. > There's also portsnap, which has been in the base system for a while now. It has some of the same drawbacks as csup/cvsup (no VCS features), but is in my experience faster than them. In short, you can use "portsnap fetch extract" to download a complete compressed tarball of current ports and extract it, and after doing that you can use "portsnap fetch update" to update to the current state. Read the manpage; there are some important details. It uses a binary patch system that's quite efficient, so if you just want an updated /usr/ports , it's probably the fastest solution. (I think the exact method is that "fetch" grabs a tarball if it doesn't exist. If it does exist, it gets the binary patches required to update it to the current state. With it in place, "extract" unpacks the entire thing, and "update" only extracts the files touched by the last "fetch"-command.) It has a handbook page: http://www.freebsd.org/doc/handbook/portsnap.html -- Daniel Nebdal ___ freebsd-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: "postfix-current" broken on amd64 platform
On 2011-11-15 10:45, Pav Lucistnik wrote:
> 1) The problem is not amd64 specific
>
> 2) No point unmarking BROKEN, it currently fails on i386 pointyhat nodes
> too
>
> 3) Diagnosis is hard because the postfix-install shell script prints no
> useful progress messages
>
> Example failure log:
> http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.2003071512/postfix-current-2.9.20111012,4.log
Seems It stops at the point where the ${WRKSRC}/conf/post-install script is
executed
pointyhat:
...
Updating /usr/local/share/doc/postfix/scache.8.html...
Updating /usr/local/share/doc/postfix/tlsmgr.8.html...
*** Error code 1
Stop in /a/ports/mail/postfix-current.
*** Error code 1
tinderbox:
...
Updating /usr/local/share/doc/postfix/scache.8.html...
Updating /usr/local/share/doc/postfix/tlsmgr.8.html...
Warning: you still need to edit myorigin/mydestination/mynetworks
parameter settings in /usr/local/etc/postfix/main.cf.
Can you test this silly patch?
--- Makefile.orig 2011-11-15 11:26:05.0 +0100
+++ Makefile2011-11-15 12:07:33.0 +0100
@@ -321,6 +321,7 @@
@${ECHO} '$$html_directory/$f:f:root:-:644' \
>> ${WRKSRC}/conf/postfix-files
.endfor
+ ${ECHO} '#!/bin/sh' > ${WRKSRC}/conf/post-install && ${CHMOD} 755
${WRKSRC}/conf/post-install
do-configure:
(cd ${WRKSRC} && ${MAKE} -f Makefile.init makefiles ${MAKEFILEFLAGS} \
--
Regards,
olli
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: cvs checkout ./. csup
On 15/11/2011 09:48, Matthias Apitz wrote: > Since many years I'm fetching or updating /usr/ports with > > # cd /usr > # setenv CVSROOT :pserver:anon...@anoncvs.fr.freebsd.org:/home/ncvs > # cvs checkout ports > > and later do the updating just with: > > # cd /usr/ports > # cvs update > # portupgrade -ai > > The FreeBSD handbook describes (or recommends?) using 'csup' for > updating ports tree... What is the advantage (or reason, if any)? Efficiency, basically. csup should require less bandwidth and put less load on servers than using cvs directly. It works like rsync, only transferring the parts of the files that changed but exploiting the cvs revision history to produce more specific and minimal deltas than you can get just by using the standard rsync algorithm. However csup(1) doesn't give you any of the VCS features you'ld get by doing a cvs checkout -- so no simple way to diff a local copy against the repo, etc. etc. 'cvs checkout' of all or parts of the ports is still frequently preferable for developing rather than just using the ports. There are also many more cvsup servers worldwide than there are anon-cvs servers. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: "postfix-current" broken on amd64 platform
1) The problem is not amd64 specific
2) No point unmarking BROKEN, it currently fails on i386 pointyhat nodes
too
3) Diagnosis is hard because the postfix-install shell script prints no
useful progress messages
Example failure log:
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.2003071512/postfix-current-2.9.20111012,4.log
Sahil Tandon píše v po 14. 11. 2011 v 21:24 -0500:
> [ pav@ and those who tested mail/postifx-current on amd64 added to Cc: ]
>
> On Mon, 2011-11-14 at 08:37:13 -0500, Jerry wrote:
>
> > The "postfix-current" port is still marked as broken:
> >
> > .if ${ARCH} == "amd64"
> > BROKEN= fails during installation
> > .endif
> >
> > Since all previous releases of Postfix worked on FreeBSD, and since
> > Postfix is/was developed on FreeBSD, I was wondering what the problem
> > is with this release. Is there a possibility that this phenomena might
> > be rectified in the near future?
>
> Thanks for your report, Jerry. You are correct that FreeBSD is the main
> development platform for Postfix. It seems that pointyhat's amd64
> machine throws an error during the install phase. Pav noticed this and
> marked the port BROKEN; however, neither I nor a few others I've
> enlisted can reproduce the error. Would you mind removing the
> conditional that marks this port BROKEN, try to build/install in your
> amd64 environment, and report the results?
>
> Pav, if nobody else can reproduce the error seen on pointyhat, can
> portmgr look into whether there is something quirky with the amd64
> pointyhat machine?
>
--
--
Pav Lucistnik
Two sausages are in a frying pan. One says, "Geez, it's hot in here
isn't it?" And the other one says, "Aah! A talking sausage!"
signature.asc
Description: This is a digitally signed message part
cvs checkout ./. csup
Hello, Since many years I'm fetching or updating /usr/ports with # cd /usr # setenv CVSROOT :pserver:anon...@anoncvs.fr.freebsd.org:/home/ncvs # cvs checkout ports and later do the updating just with: # cd /usr/ports # cvs update # portupgrade -ai The FreeBSD handbook describes (or recommends?) using 'csup' for updating ports tree... What is the advantage (or reason, if any)? Thanks in advance matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
