Re: with the cvs history? trying to help INDEX builds.
On 19 Jan 2012 08:58, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 19/01/2012 01:31, Michael Scheidell wrote:
in manually trying to build an index for a tinderbox/binary/portmaster
distribution, I started to look at some of the things that slow these
down.
and, being a former real-time, robotics guy... I figure, take ONE line
of code out, and you make things faster.
anyway, worth the cycles?
take out -.include bsd.port.pre.mk; -.if ${ARCH} == sparc64
-BROKEN=Does not install on sparc64
-.endif
and replace it with NOT_FOR_ARCHS=sparc64 ?
without bsd.port.PRE, you won't (try) to pull in lots of other things,
optional things (options,perl, mysql, etc)
worth the cvs history cycles to do this?
I'd say worth it to standardize on NOT_FOR_ARCHS / ONLY_FOR_ARCHS to
handle this sort of thing. By my calculations there are 28 ports that
set 'BROKEN' because of architecture incompatibility on my amd64
system[*], whereas there are 904 ports that set either ONLY_FOR_ARCHS or
NOT_FOR_ARCHS.
Cheers,
Matthew
[*] there would be more on sparc64 or other tier-2 architectures, but
the way I counted didn't pick those cases up, just the ones that set
BROKEN on the current architecture.
portindex= SELECT
p.parent || '/' || p.name as port
FROM
caveat NATURAL JOIN ports_by_name p
WHERE
caveat_type='BROKEN'
AND caveat ~ 'sparc|i386|amd64|ia64|pc'
ORDER BY
port
;
port
devel/ruby-avl
devel/ustl
games/xbloody
graphics/gmt
graphics/ruby-tgif
irc/eggdrop
japanese/ne
lang/oorexx
lang/py-prolog
lang/qscheme
lang/rscheme
lang/scsh
lang/sr
math/matrix
net-im/gyach
net-mgmt/docsis
net/cnet
net/hawknl-devel
net/ngrep-lib
net/py-libnet
net/tridiavnc
science/elmerpost
sysutils/freecolor
sysutils/hpacucli
textproc/coco
textproc/rtfx
x11-toolkits/fox17
x11/decurs
(28 rows)
No, it's not worth it :)
This means we won't be able to differentiate between BROKEN and IGNORE.
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: with the cvs history? trying to help INDEX builds.
On Thu, Jan 19, 2012 at 05:40:09PM -0800, Doug Barton wrote: On 01/18/2012 17:31, Michael Scheidell wrote: in manually trying to build an index for a tinderbox/binary/portmaster distribution I highly recommend looking at ports-mgmt/p5-FreeBSD-Portindex for this purpose. After the initial set up incremental changes take seconds, instead of 30+ minutes. Doug, thanks for the hint. I was trying to compare the timings on ia64 9.9-CURRENT #10:, and see this warning: # /usr/bin/time -hl make index Generating INDEX-10 - please wait..Makefile, line 41: warning: /sbin/sysctl -n hw.instruction_sse 2 /dev/null returned non-zero status Which Makefile does the warning refer to? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-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: with the cvs history? trying to help INDEX builds.
On 20/01/2012 09:18, Chris Rees wrote:
On 19 Jan 2012 08:58, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 19/01/2012 01:31, Michael Scheidell wrote:
anyway, worth the cycles?
take out -.include bsd.port.pre.mk; -.if ${ARCH} == sparc64
-BROKEN=Does not install on sparc64
-.endif
and replace it with NOT_FOR_ARCHS=sparc64 ?
I'd say worth it to standardize on NOT_FOR_ARCHS / ONLY_FOR_ARCHS to
handle this sort of thing. By my calculations there are 28 ports that
set 'BROKEN' because of architecture incompatibility on my amd64
system[*], whereas there are 904 ports that set either ONLY_FOR_ARCHS or
NOT_FOR_ARCHS.
No, it's not worth it :)
This means we won't be able to differentiate between BROKEN and IGNORE.
Not even if people make use of the {NOT,ONLY}_FOR_ARCHS_REASON or
{NOT,ONLY}_FOR_ARCHS_REASON_${ARCH} variables?
Actually I take your point, that it should be possible to distinguish
between ports that permanently won't work on some architectures by
design, and ports that temporarily don't work because of mistakes or
broken dependencies or so forth, and that are expected to be fixed
sooner rather than later. Unfortunately those two cases are already
pretty confused. For instance (arbitrarily picking out a few grep hits):
./audio/amarok-kde4/Makefile:NOT_FOR_ARCHS_REASON_sparc64= GCC-related
build error
./audio/openal/Makefile:NOT_FOR_ARCHS_REASON_ia64= does not compile
./biology/migrate/Makefile:ONLY_FOR_ARCHS_REASON= Does not compile
Where 'does not compile' or 'fails to install' are similarly the most
popular reasons given for arch-related brokenness using the BROKEN
variable. Given the banal and uninformative nature of such reasons,
there's no easy way to tell if this is a temporary condition or not.
Hmm... Perhaps if there was a BROKEN_FOR_ARCH{,_REASON{,${ARCH}}} set of
variables documented alongside the other ..FOR_ARCH variables?
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: with the cvs history? trying to help INDEX builds.
On 20/01/2012 09:30, Anton Shterenlikht wrote:
# /usr/bin/time -hl make index
Generating INDEX-10 - please wait..Makefile, line 41: warning:
/sbin/sysctl -n hw.instruction_sse 2 /dev/null returned non-zero status
Which Makefile does the warning refer to?
lucid-nonsense:/usr/ports:% grep -r hw.instruction_sse .
./games/gnubg/files/patch-lib_neuralnet.c:+int error =
sysctlbyname(hw.instruction_sse, result, length, NULL, 0);
./audio/beast/Makefile:HAS_SSE!=${SYSCTL} -n hw.instruction_sse 2
/dev/null ** This one
That's a systematic problem: callying sysctl like that will return a
non-zero status if you ask it about a non-existent sysctl, but doing
that is basically the point of the test. One fix would be:
HAS_SSE!= ${SYSCTL} -i -n hw.instruction_sse 2/dev/null
It's only a warning though, so INDEX generation should still work.
Cheers,
Matthew
cvs diff: Diffing .
Index: Makefile
===
RCS file: /home/ncvs/ports/audio/beast/Makefile,v
retrieving revision 1.46
diff -u -u -r1.46 Makefile
--- Makefile28 Dec 2011 03:21:23 - 1.46
+++ Makefile20 Jan 2012 10:39:08 -
@@ -38,7 +38,7 @@
BROKEN=Does not compile on powerpc: array bound is not an
integer
constant
.endif
-HAS_SSE!= ${SYSCTL} -n hw.instruction_sse 2 /dev/null
+HAS_SSE!= ${SYSCTL} -i -n hw.instruction_sse 2 /dev/null
.if ${HAS_SSE} == 1
PLIST_SUB+=SSE=
.else
--
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: with the cvs history? trying to help INDEX builds.
On Fri, Jan 20, 2012 at 5:44 AM, Matthew Seaman
m.sea...@infracaninophile.co.uk wrote:
That's a systematic problem: callying sysctl like that will return a
non-zero status if you ask it about a non-existent sysctl, but doing
that is basically the point of the test. One fix would be:
HAS_SSE!= ${SYSCTL} -i -n hw.instruction_sse 2/dev/null
Why is this in a port? This should be based on an OPTION.
It's only a warning though, so INDEX generation should still work.
--
Eitan Adler
___
freebsd-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: with the cvs history? trying to help INDEX builds.
On 20 Jan 2012 10:20, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 20/01/2012 09:18, Chris Rees wrote:
On 19 Jan 2012 08:58, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 19/01/2012 01:31, Michael Scheidell wrote:
anyway, worth the cycles?
take out -.include bsd.port.pre.mk; -.if ${ARCH} == sparc64
-BROKEN=Does not install on sparc64
-.endif
and replace it with NOT_FOR_ARCHS=sparc64 ?
I'd say worth it to standardize on NOT_FOR_ARCHS / ONLY_FOR_ARCHS to
handle this sort of thing. By my calculations there are 28 ports that
set 'BROKEN' because of architecture incompatibility on my amd64
system[*], whereas there are 904 ports that set either ONLY_FOR_ARCHS
or
NOT_FOR_ARCHS.
No, it's not worth it :)
This means we won't be able to differentiate between BROKEN and IGNORE.
Not even if people make use of the {NOT,ONLY}_FOR_ARCHS_REASON or
{NOT,ONLY}_FOR_ARCHS_REASON_${ARCH} variables?
Actually I take your point, that it should be possible to distinguish
between ports that permanently won't work on some architectures by
design, and ports that temporarily don't work because of mistakes or
broken dependencies or so forth, and that are expected to be fixed
sooner rather than later. Unfortunately those two cases are already
pretty confused. For instance (arbitrarily picking out a few grep hits):
./audio/amarok-kde4/Makefile:NOT_FOR_ARCHS_REASON_sparc64=
GCC-related
build error
./audio/openal/Makefile:NOT_FOR_ARCHS_REASON_ia64= does not compile
./biology/migrate/Makefile:ONLY_FOR_ARCHS_REASON= Does not compile
Where 'does not compile' or 'fails to install' are similarly the most
popular reasons given for arch-related brokenness using the BROKEN
variable. Given the banal and uninformative nature of such reasons,
there's no easy way to tell if this is a temporary condition or not.
Hmm... Perhaps if there was a BROKEN_FOR_ARCH{,_REASON{,${ARCH}}} set of
variables documented alongside the other ..FOR_ARCH variables?
Occasionally someone runs an exp- for sparc64 (lol) etc.
They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS sets
IGNORE.
Ports marked this way (incorrectly) will never be tested, and thus never
marked fixed.
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: with the cvs history? trying to help INDEX builds.
On 20/01/2012 12:53, Chris Rees wrote:
On 20 Jan 2012 10:20, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 20/01/2012 09:18, Chris Rees wrote:
On 19 Jan 2012 08:58, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 19/01/2012 01:31, Michael Scheidell wrote:
anyway, worth the cycles?
take out -.include bsd.port.pre.mk; -.if ${ARCH} == sparc64
-BROKEN=Does not install on sparc64
-.endif
and replace it with NOT_FOR_ARCHS=sparc64 ?
I'd say worth it to standardize on NOT_FOR_ARCHS / ONLY_FOR_ARCHS to
handle this sort of thing. By my calculations there are 28 ports that
set 'BROKEN' because of architecture incompatibility on my amd64
system[*], whereas there are 904 ports that set either ONLY_FOR_ARCHS
or
NOT_FOR_ARCHS.
No, it's not worth it :)
This means we won't be able to differentiate between BROKEN and IGNORE.
Not even if people make use of the {NOT,ONLY}_FOR_ARCHS_REASON or
{NOT,ONLY}_FOR_ARCHS_REASON_${ARCH} variables?
Actually I take your point, that it should be possible to distinguish
between ports that permanently won't work on some architectures by
design, and ports that temporarily don't work because of mistakes or
broken dependencies or so forth, and that are expected to be fixed
sooner rather than later. Unfortunately those two cases are already
pretty confused. For instance (arbitrarily picking out a few grep hits):
./audio/amarok-kde4/Makefile:NOT_FOR_ARCHS_REASON_sparc64=
GCC-related
build error
./audio/openal/Makefile:NOT_FOR_ARCHS_REASON_ia64= does not compile
./biology/migrate/Makefile:ONLY_FOR_ARCHS_REASON= Does not compile
Where 'does not compile' or 'fails to install' are similarly the most
popular reasons given for arch-related brokenness using the BROKEN
variable. Given the banal and uninformative nature of such reasons,
there's no easy way to tell if this is a temporary condition or not.
Hmm... Perhaps if there was a BROKEN_FOR_ARCH{,_REASON{,${ARCH}}} set of
variables documented alongside the other ..FOR_ARCH variables?
Occasionally someone runs an exp- for sparc64 (lol) etc.
They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS sets
IGNORE.
Ports marked this way (incorrectly) will never be tested, and thus never
marked fixed.
Yes, I understand thae distinction between BROKEN and IGNORE, thank you
very much. So the BROKEN_FOR_ARCH variable family should ultimately set
BROKEN rather than IGNORE. Obviously.
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: with the cvs history? trying to help INDEX builds.
On 20 Jan 2012 13:06, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 20/01/2012 12:53, Chris Rees wrote:
On 20 Jan 2012 10:20, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 20/01/2012 09:18, Chris Rees wrote:
On 19 Jan 2012 08:58, Matthew Seaman
m.sea...@infracaninophile.co.uk
wrote:
On 19/01/2012 01:31, Michael Scheidell wrote:
anyway, worth the cycles?
take out -.include bsd.port.pre.mk; -.if ${ARCH} == sparc64
-BROKEN=Does not install on sparc64
-.endif
and replace it with NOT_FOR_ARCHS=sparc64 ?
I'd say worth it to standardize on NOT_FOR_ARCHS / ONLY_FOR_ARCHS to
handle this sort of thing. By my calculations there are 28 ports
that
set 'BROKEN' because of architecture incompatibility on my amd64
system[*], whereas there are 904 ports that set either ONLY_FOR_ARCHS
or
NOT_FOR_ARCHS.
No, it's not worth it :)
This means we won't be able to differentiate between BROKEN and
IGNORE.
Not even if people make use of the {NOT,ONLY}_FOR_ARCHS_REASON or
{NOT,ONLY}_FOR_ARCHS_REASON_${ARCH} variables?
Actually I take your point, that it should be possible to distinguish
between ports that permanently won't work on some architectures by
design, and ports that temporarily don't work because of mistakes or
broken dependencies or so forth, and that are expected to be fixed
sooner rather than later. Unfortunately those two cases are already
pretty confused. For instance (arbitrarily picking out a few grep
hits):
./audio/amarok-kde4/Makefile:NOT_FOR_ARCHS_REASON_sparc64=
GCC-related
build error
./audio/openal/Makefile:NOT_FOR_ARCHS_REASON_ia64= does not
compile
./biology/migrate/Makefile:ONLY_FOR_ARCHS_REASON= Does not
compile
Where 'does not compile' or 'fails to install' are similarly the most
popular reasons given for arch-related brokenness using the BROKEN
variable. Given the banal and uninformative nature of such reasons,
there's no easy way to tell if this is a temporary condition or not.
Hmm... Perhaps if there was a BROKEN_FOR_ARCH{,_REASON{,${ARCH}}} set
of
variables documented alongside the other ..FOR_ARCH variables?
Occasionally someone runs an exp- for sparc64 (lol) etc.
They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS
sets
IGNORE.
Ports marked this way (incorrectly) will never be tested, and thus never
marked fixed.
Yes, I understand thae distinction between BROKEN and IGNORE, thank you
very much. So the BROKEN_FOR_ARCH variable family should ultimately set
BROKEN rather than IGNORE. Obviously.
Sorry, missed that bit.
Thing is... adding this change to bsd.port.mk will actually mean that
instead of each BROKEN Makefile testing for it, *every* port's Makefile
then tests for it.
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: with the cvs history? trying to help INDEX builds.
On 01/20/2012 04:53, Chris Rees wrote: Occasionally someone runs an exp- for sparc64 (lol) etc. ... which given the overwhelming lack of users for this platform is almost certainly a waste of resources. They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS sets IGNORE. Ports marked this way (incorrectly) will never be tested, and thus never marked fixed. I think this is a red herring. Users who want to see those ports work on those platforms are either going to put the effort in, or not. They aren't going to be deterred by what make options we choose. OTOH, not using BROKEN for this purpose makes it much easier to grep for stuff that's actually BROKEN in order to take action on it (speaking from experience). Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: with the cvs history? trying to help INDEX builds.
On Fri, Jan 20, 2012 at 05:16:08AM -0800, Doug Barton wrote: On 01/20/2012 04:53, Chris Rees wrote: Occasionally someone runs an exp- for sparc64 (lol) etc. ... which given the overwhelming lack of users for this platform is almost certainly a waste of resources. how about ia64? They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS sets IGNORE. Ports marked this way (incorrectly) will never be tested, and thus never marked fixed. I think this is a red herring. Users who want to see those ports work on those platforms are either going to put the effort in, or not. They aren't going to be deterred by what make options we choose. this is true. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-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: Encoding question
On Thu, Jan 19, 2012 at 08:43:14AM -0900, rfl...@acsalaska.net wrote: Hi, I'm trying to compile a C++ software on FreeBSD. While compiling, this error shows up: error: stray '\357' in program error: stray '\273' in program error: stray '\277' in program This file is reported (by file[1]) to be UTF-8 Unicode (with BOM) C program text, with CRLF line terminators while the rest of the files in the package are ASCII C program text, with CRLF line terminators. While I can convert the file with iconv -c -f utf-8 -t ascii file new_file in the post extract stage, I wonder if there is a more suitable way for achieving the same thing. Also I would like to avoid this software from depending on iconv. You have three options: - have it fixed upstream; - post process on extract like above; - post process releases and roll your own tarball which you host yourself. Be careful doing this third one. Often times (but not always) upstream locations use mirrors to make sure the distfile is always available. If you roll your own, just to fix something which can be so easily patched, and you don't provide similar mirror functionality then you are introducing a single point of failure we should try to avoid. Not to mention you're now going to have to do extra work everytime there is a new release. Either fix it upstream or patch it. -- WXS ___ freebsd-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: with the cvs history? trying to help INDEX builds.
On 20/01/2012 13:14, Chris Rees wrote:
On 20 Jan 2012 13:06, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 20/01/2012 12:53, Chris Rees wrote:
On 20 Jan 2012 10:20, Matthew Seaman m.sea...@infracaninophile.co.uk
wrote:
On 20/01/2012 09:18, Chris Rees wrote:
On 19 Jan 2012 08:58, Matthew Seaman
m.sea...@infracaninophile.co.uk
wrote:
On 19/01/2012 01:31, Michael Scheidell wrote:
anyway, worth the cycles?
take out -.include bsd.port.pre.mk; -.if ${ARCH} == sparc64
-BROKEN=Does not install on sparc64
-.endif
and replace it with NOT_FOR_ARCHS=sparc64 ?
I'd say worth it to standardize on NOT_FOR_ARCHS / ONLY_FOR_ARCHS to
handle this sort of thing. By my calculations there are 28 ports
that
set 'BROKEN' because of architecture incompatibility on my amd64
system[*], whereas there are 904 ports that set either ONLY_FOR_ARCHS
or
NOT_FOR_ARCHS.
No, it's not worth it :)
This means we won't be able to differentiate between BROKEN and
IGNORE.
Not even if people make use of the {NOT,ONLY}_FOR_ARCHS_REASON or
{NOT,ONLY}_FOR_ARCHS_REASON_${ARCH} variables?
Actually I take your point, that it should be possible to distinguish
between ports that permanently won't work on some architectures by
design, and ports that temporarily don't work because of mistakes or
broken dependencies or so forth, and that are expected to be fixed
sooner rather than later. Unfortunately those two cases are already
pretty confused. For instance (arbitrarily picking out a few grep
hits):
./audio/amarok-kde4/Makefile:NOT_FOR_ARCHS_REASON_sparc64=
GCC-related
build error
./audio/openal/Makefile:NOT_FOR_ARCHS_REASON_ia64= does not
compile
./biology/migrate/Makefile:ONLY_FOR_ARCHS_REASON= Does not
compile
Where 'does not compile' or 'fails to install' are similarly the most
popular reasons given for arch-related brokenness using the BROKEN
variable. Given the banal and uninformative nature of such reasons,
there's no easy way to tell if this is a temporary condition or not.
Hmm... Perhaps if there was a BROKEN_FOR_ARCH{,_REASON{,${ARCH}}} set
of
variables documented alongside the other ..FOR_ARCH variables?
Occasionally someone runs an exp- for sparc64 (lol) etc.
They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS
sets
IGNORE.
Ports marked this way (incorrectly) will never be tested, and thus never
marked fixed.
Yes, I understand thae distinction between BROKEN and IGNORE, thank you
very much. So the BROKEN_FOR_ARCH variable family should ultimately set
BROKEN rather than IGNORE. Obviously.
Sorry, missed that bit.
Thing is... adding this change to bsd.port.mk will actually mean that
instead of each BROKEN Makefile testing for it, *every* port's Makefile
then tests for it.
But that argument applies equally to the {NOT,ONLY}_FOR_ARCHS variables,
which I'd guess are two amongst dozens of other variables that get
manipulated in some form or other every time you invoke 'make' in any
port directory. Is that really going to cause a significant extra load?
Actually, going back to the original question -- if this means not
having to .include bsd.port.pre.mk in a reasonable number of cases,
then it might even be a win overall when generating an index. (At a
guess. Have to do some experiments to confirm that.)
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: with the cvs history? trying to help INDEX builds.
On 1/20/12 8:33 AM, Matthew Seaman wrote: Actually, going back to the original question -- if this means not having to .includebsd.port.pre.mk in a reasonable number of cases, then it might even be a win overall when generating an index. (At a guess. Have to do some experiments to confirm that.) Cheers, and in my dozens of days of ports pr/committing experience, I find/found, several ports that needed portlint fixed, and initially started to put in pre/post to get things to work, only to find that the python stuff dragged in played fast and furious with 'eggs', which messed up pkg-plist, which left eggs all over the place. Dragging in pre when all you needed to do was drag in 'options'. Either case, from a pure theoretical case study, taking out one byte would speed things up. (in theory, theory and practice are the same.. but in practice, it is often different) -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 *| *SECNAP Network Security Corporation * Best Mobile Solutions Product of 2011 * Best Intrusion Prevention Product * Hot Company Finalist 2011 * Best Email Security Product * Certified SNORT Integrator ___ freebsd-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: Any plans to update salt to 0.9.5?
On Thu, Jan 19, 2012 at 8:12 PM, Doug Barton do...@freebsd.org wrote: I've been evaluating salt, and would prefer not to deploy prior to the msgpack update in 0.9.5. I am hoping to get the port updated today, yes. Thanks for the additional nudge to get it finished :) christer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: couchdb-1.1.0_2,1
Can you send me a unified diff and a PR. I'll take a look.
I tested this prior to the commit. Which version of FreeBSD are you using?
On Thu, Jan 19, 2012 at 4:39 PM, Herby Vojčík he...@mailbox.sk wrote:
Hello,
the latest change made rc.d script not working. When run from the cli as
/usr/local/etc/rc.d/couchdb start, it begins writing to the terminal and
hangs there, not returning to the prompt. Ctrl+C must be issued to stop it
and return to the prompt.
While hanged, ps ax run in parallel session shows couchdb is started, but
with no flags whatsoever (sh -c /usr/local/bin/couchdb ).
The couchdb_prestart function gets run (I put echos in there), but its
couchdb_flags is not taken into account.
I had to make this change:
60c60,61
start_precmd=${name}_prestart
---
#start_precmd=${name}_prestart
case $1 in *start) couchdb_prestart;; esac
to make it work. When run during boot, it has the same symptoms (runs the
couchdb without flags) and also needs the change above.
Herby
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: couchdb-1.1.0_2,1
till wrote:
Can you send me a unified diff and a PR. I'll take a look.
--- /usr/local/etc/couchdb.old 2012-01-20 16:16:58.0 +0100
+++ /usr/local/etc/rc.d/couchdb 2012-01-19 16:35:09.0 +0100
@@ -57,7 +57,8 @@
couchdb_flags=-b -a ${couchdb_etcdir}/default.ini -a
${couchdb_etcdir}/local.ini ${respawn} -o ${logfile} -e ${errfile} -p
${pidfile}
}
-start_precmd=${name}_prestart
+#start_precmd=${name}_prestart
+case $1 in *start) couchdb_prestart;; esac
stop_cmd=${command} -d
status_cmd=${command} -s
I don't know that is PR.
I tested this prior to the commit. Which version of FreeBSD are you using?
[herby@k143 ~]$ uname -a
FreeBSD k143 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27
18:45:57 UTC 2011
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
[herby@k143 ~]$ sudo cat /var/db/freebsd-update/tag
freebsd-update|amd64|8.2-RELEASE|6|5b20869b7b0307cbcffa42fc4316559afd3a58a54ca174ab2db1ba973817c17e|1343779200
On Thu, Jan 19, 2012 at 4:39 PM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
Hello,
the latest change made rc.d script not working. When run from the
cli as /usr/local/etc/rc.d/couchdb start, it begins writing to the
terminal and hangs there, not returning to the prompt. Ctrl+C must
be issued to stop it and return to the prompt.
While hanged, ps ax run in parallel session shows couchdb is
started, but with no flags whatsoever (sh -c /usr/local/bin/couchdb ).
The couchdb_prestart function gets run (I put echos in there), but
its couchdb_flags is not taken into account.
I had to make this change:
60c60,61
start_precmd=${name}_prestart
---
#start_precmd=${name}_prestart
case $1 in *start) couchdb_prestart;; esac
to make it work. When run during boot, it has the same symptoms
(runs the couchdb without flags) and also needs the change above.
Herby
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
port Inkscape 0.48.2 problem
Hi list ! I am having trouble compiling inkscape 0.48.2 on freebsd 9, see the following error: gmake[2]: ** [extension/internal/wpg-input.o] Erro 1 gmake[2]: *** Esperando que os outros processos terminem extension/internal/bitmap/imagemagick.cpp: In constructor 'Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache::ImageMagickDocCa che(Inkscape::UI::View::View*)': extension/internal/bitmap/imagemagick.cpp:85: warning: deprecated conversion from string constant to 'char*' gmake[2]: Saindo do diretório `/usr/ports/graphics/inkscape/work/inkscape-0.48.2/src' gmake[1]: ** [all-recursive] Erro 1 gmake[1]: Saindo do diretório `/usr/ports/graphics/inkscape/work/inkscape-0.48.2' gmake: ** [all] Erro 2 *** Error code 1 Stop in /usr/ports/graphics/inkscape. *** Error code 1 Stop in /usr/ports/graphics/inkscape. === make failed for graphics/inkscape === Aborting update My config: [root@desktop] /usr/ports/graphics/inkscape# uname -a FreeBSD desktop.luizgustavo.pro.br 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 [root@desktop] /usr/ports/graphics/inkscape# make showconfig === The following configuration options are available for inkscape-0.48.2_1: POPPLER=on Enable libpoppler-cairo for rendering PDF preview === Use 'make config' to modify these settings What could be happening to create this error with the imagemagick? has updated the package imagemagick: [root@desktop] /usr/ports/graphics/inkscape# pkg_info | grep ImageMagic ImageMagick-6.7.4.4 Image processing tools [root@desktop] /usr/ports/graphics/inkscape# cd ../ImageMagick [root@desktop] /usr/ports/graphics/ImageMagick# make showconfig === The following configuration options are available for ImageMagick-6.7.4.4: IMAGEMAGICK_16BIT_PIXEL=on 16bit pixel support IMAGEMAGICK_BZLIB=on Bzlib support IMAGEMAGICK_DJVU=off DJVU format support (needs threads) IMAGEMAGICK_DOT=off GraphViz dot graphs support IMAGEMAGICK_FFTW=on Discrete Fourier Transform support IMAGEMAGICK_FONTCONFIG=on Fontconfig support IMAGEMAGICK_FPX=on FPX format support IMAGEMAGICK_GSLIB=off libgs (Postscript SHLIB) support IMAGEMAGICK_JBIG=on JBIG format support IMAGEMAGICK_JPEG=on JPG format support IMAGEMAGICK_JPEG2000=on JPEG2000 format support IMAGEMAGICK_LCMS2=on LCMS version 2 support IMAGEMAGICK_LCMS=off LCMS version 1 support IMAGEMAGICK_LZMA=on LZMA support IMAGEMAGICK_LQR=on Liquid Rescale support IMAGEMAGICK_MODULES=on Modules support IMAGEMAGICK_OPENEXR=off OpenEXR support (needs threads) IMAGEMAGICK_OPENMP=off OpenMP for SMP (needs threads) IMAGEMAGICK_PANGO=off Pango support IMAGEMAGICK_PDF=on PDF format support IMAGEMAGICK_PERL=on Perl support IMAGEMAGICK_PNG=on PNG format support IMAGEMAGICK_SVG=on SVG format support (requires X11) IMAGEMAGICK_TESTS=off Run bundled self-tests after build IMAGEMAGICK_TIFF=on TIFF format support IMAGEMAGICK_TTF=on Freetype support IMAGEMAGICK_WEBP=on WEBP support IMAGEMAGICK_WMF=on WMF format support THREADS=off Threads support === Use 'make config' to modify these settings Thanks -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Doing SQL to the FreeBSD ports index
Dear all, Apropos nothing much at all, but congruent with some of the discussion going on in this list at the moment, I've been playing around loading ports index related data into a RDBMS and querying that to pull out interesting factoids, or indeed a complete INDEX file. I didn't start doing this with any idea other than my own edification but now it seems it might be vaguely useful here and there, so I've stuck a copy on my website: http://www.infracaninophile.co.uk/articles/portindexdb/ I'd be happy to hear from anyone using this, or receive bug reports / feature requests. 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: port Inkscape 0.48.2 problem
Hi All, 20.01.2012 19:20, Luiz Gustavo S. Costa пишет: I am having trouble compiling inkscape 0.48.2 There is an entry at /usr/ports/UPDATING. Have you followed one? -- 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On 19/01/12 22:21, Doug Barton wrote: On Thu, 19 Jan 2012, Kaya Saman wrote: not sure where this thread started as searching my mail archives yielded nothing apart from this excerpt. -hackers. If this is an attack on FreeBSD It's not. as the title suggests; It doesn't. In any case I forgot to change the subject line, mea culpa. Meanwhile it would be great if dinoex could reply to the substance of the question. Doug Just thought I'd start getting all defensive to protoct the OS and the communities integrity but if there's no issue I'll do the right thing and butt out before people start attacking me for either being over-agressive or not knowing what I'm talking about. Regards, Kaya ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port Inkscape 0.48.2 problem
this ? 70 Before updating graphics/inkscape to version 0.48.2 one should deinstall 71 the port graphics/libwpg01. strange, I've done it and this: 34 AFFECTS: users of x11/xcb-util 35 AUTHOR: ga...@freebsd.org 36 37 x11/xcb-util was updated to 0.3.8 and was split in new modules. 38 Dependencies were adjusted but main port symbols were moved to a single 39 library, xcb-util.so. For this reason, all dependent ports must be 40 recompiled.If you use portmaster, run: 2012/1/20 Boris Samorodov b...@passap.ru: Hi All, 20.01.2012 19:20, Luiz Gustavo S. Costa пишет: I am having trouble compiling inkscape 0.48.2 There is an entry at /usr/ports/UPDATING. Have you followed one? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br ___ freebsd-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: Doing SQL to the FreeBSD ports index
Hi! it might be vaguely useful here and there, so I've stuck a copy on my website: http://www.infracaninophile.co.uk/articles/portindexdb/ http://www.infracaninophile.co.uk/articles/portindexdb.html works better 8-) -- p...@opsec.eu+49 171 3101372 8 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Doing SQL to the FreeBSD ports index
On 20/01/2012 18:20, Kurt Jaeger wrote: Hi! it might be vaguely useful here and there, so I've stuck a copy on my website: http://www.infracaninophile.co.uk/articles/portindexdb/ http://www.infracaninophile.co.uk/articles/portindexdb.html works better 8-) D'Oh! -- 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
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: Test-DBIx-Class-0.28: no entry for /usr/ports/databases/p5-DBIx-Class-Schema-PopulateMore make_index: Test-DBIx-Class-0.28: no entry for /usr/ports/databases/p5-DBIx-Class-Schema-PopulateMore Committers on the hook: bf brooks danfe delphij glarkin nobutaka swills Most recent CVS update was: U devel/Makefile U devel/llvm29/Makefile U devel/llvm29/pkg-plist U devel/p5-SVN-Look/Makefile U devel/p5-SVN-Look/distinfo U devel/p5-SVN-Notify-Filter-Markdown/Makefile U devel/p5-SVN-Notify-Filter-Markdown/distinfo U devel/p5-Test-DBIx-Class/Makefile U devel/p5-Test-DBIx-Class/distinfo U devel/p5-Test-DBIx-Class/pkg-descr U devel/p5-Test-DBIx-Class/pkg-plist U devel/pear-VersionControl_SVN/Makefile U devel/pear-VersionControl_SVN/distinfo U graphics/opengtl/Makefile U graphics/p5-PGPLOT/Makefile U lang/p5-ExtUtils-F77/Makefile U security/vuxml/vuln.xml U textproc/uim/Makefile U textproc/uim/distinfo U x11/pixman/Makefile ___ freebsd-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: Doing SQL to the FreeBSD ports index
You've probably reimplemented part of ports tinderbox (and, separately, portsmon and FreshPorts) :) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port Inkscape 0.48.2 problem
with portmaster, he reinstalled this version
[root@desktop] /usr/ports/graphics/inkscape# pkg_info |grep libwpg
libwpg-0.2.0_1 Library for importing and converting Corel WordPerfect(tm)
from Makefile, in LIB_DEPENDS:
wpg-0.2:${PORTSDIR}/graphics/libwpg
2012/1/20 Boris Samorodov b...@passap.ru:
Hi All,
20.01.2012 20:51, Luiz Gustavo S. Costa пишет:
this ?
70 Before updating graphics/inkscape to version 0.48.2 one should
deinstall
71 the port graphics/libwpg01.
strange, I've done it
Yep. Sorry, I'm out of ideas. :-(
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
--
Luiz Gustavo Costa (Powered by BSD)
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
mundoUnix - Consultoria em Software Livre
http://www.mundounix.com.br
ICQ: 2890831 / MSN: cont...@mundounix.com.br
Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407
Blog: http://www.luizgustavo.pro.br
___
freebsd-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: with the cvs history? trying to help INDEX builds.
On Fri, Jan 20, 2012 at 10:44:23AM +, Matthew Seaman wrote:
HAS_SSE!= ${SYSCTL} -i -n hw.instruction_sse 2/dev/null
It's only a warning though, so INDEX generation should still work.
Yes, but the warning makes portmgrs sad. It leaves 'junk' in the
output of the file that's used to document why certain packages were
skipped during a build.
Someone(TM) should write this up as a hint for the Dos-And-Donts in
the Porter's Handbook.
(This particular thing is even worse on clang, where other, non-sysctl,
tests have this same annoying side-effect.)
mcl
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: with the cvs history? trying to help INDEX builds.
On 1/20/12 2:38 PM, Mark Linimon wrote:
On Fri, Jan 20, 2012 at 10:44:23AM +, Matthew Seaman wrote:
HAS_SSE!= ${SYSCTL} -i -n hw.instruction_sse 2/dev/null
It's only a warning though, so INDEX generation should still work.
and, there are lots of these around also.
LIBNET_CONFIG?= ${LOCALBASE}/bin/libnet11-config
.if exists(${LIBNET_CONFIG})
LIBNET_CFLAGS!= ${LIBNET_CONFIG} --cflags
LIBNET_LIBS!= ${LIBNET_CONFIG} --libs
.else
LIBNET_CFLAGS= -I${LOCALBASE}/include/libnet11
LIBNET_LIBS=-L${LOCALBASE}/lib/libnet11 -lnet
.endif
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
*| *SECNAP Network Security Corporation
* Best Mobile Solutions Product of 2011
* Best Intrusion Prevention Product
* Hot Company Finalist 2011
* Best Email Security Product
* Certified SNORT Integrator
___
freebsd-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: with the cvs history? trying to help INDEX builds.
On Fri, Jan 20, 2012 at 2:38 PM, Mark Linimon lini...@lonesome.com wrote:
On Fri, Jan 20, 2012 at 10:44:23AM +, Matthew Seaman wrote:
HAS_SSE!= ${SYSCTL} -i -n hw.instruction_sse 2/dev/null
It's only a warning though, so INDEX generation should still work.
Yes, but the warning makes portmgrs sad. It leaves 'junk' in the
output of the file that's used to document why certain packages were
skipped during a build.
Someone(TM) should write this up as a hint for the Dos-And-Donts in
the Porter's Handbook.
You mean like this ?
http://www.freebsd.org/doc/en/books/porters-handbook/dads-sysctl.html
--
Eitan Adler
___
freebsd-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: with the cvs history? trying to help INDEX builds.
On Fri, Jan 20, 2012 at 2:38 PM, Mark Linimon lini...@lonesome.com wrote:
On Fri, Jan 20, 2012 at 10:44:23AM +, Matthew Seaman wrote:
HAS_SSE!= ${SYSCTL} -i -n hw.instruction_sse 2/dev/null
It's only a warning though, so INDEX generation should still work.
Yes, but the warning makes portmgrs sad. It leaves 'junk' in the
output of the file that's used to document why certain packages were
skipped during a build.
Also - it makes ports dependent on the machine they are built on which
isn't a good thing either.
--
Eitan Adler
___
freebsd-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: Doing SQL to the FreeBSD ports index
On 20/01/2012 19:25, Mark Linimon wrote: You've probably reimplemented part of ports tinderbox (and, separately, portsmon and FreshPorts) :) I have this other invention I've been calling 'a rotationally symmetrical device designed to facilitate travel.' 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
[Fwd: 7.x make_index FAILURE]
Sorry, should be fixed now. Steve Original Message Subject: 7.x make_index FAILURE From:Portsnap buildbox cperc...@freebsd.org Date:Fri, January 20, 2012 1:23 pm To: Colin Percival cperc...@daemonology.net Simon Nielsen si...@freebsd.org Cc: swi...@freebsd.org -- make_index: /usr/ports/devel/p5-Test-DBIx-Class: no entry for /usr/ports/databases/p5-DBIx-Class-Schema-PopulateMore Committers on the hook (CCed): brooks swills Latest cvsup history: Edit ports/devel/Makefile,v Add delta 1.4809 2012.01.20.18.06.32 swills Mkdir ports/devel/p5-Test-DBIx-Class Create ports/devel/p5-Test-DBIx-Class/Makefile,v Create ports/devel/p5-Test-DBIx-Class/distinfo,v Create ports/devel/p5-Test-DBIx-Class/pkg-descr,v Create ports/devel/p5-Test-DBIx-Class/pkg-plist,v SetAttrs ports/devel/p5-Test-DBIx-Class Edit ports/graphics/opengtl/Makefile,v Add delta 1.14 2012.01.20.18.05.28 brooks Mkdir ports/x11-fonts/linuxlibertine/files SetAttrs ports/x11-fonts/linuxlibertine/files There may be different errors exposed by INDEX builds on other branches, but no further emails will be sent until after the INDEX next builds successfully on all branches. ___ freebsd-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: with the cvs history? trying to help INDEX builds.
On Fri, Jan 20, 2012 at 02:48:24PM -0500, Eitan Adler wrote: You mean like this ? http://www.freebsd.org/doc/en/books/porters-handbook/dads-sysctl.html Yeah, but that's missing the 2 /dev/null corollary. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: with the cvs history? trying to help INDEX builds.
On 20/01/2012 20:26, Mark Linimon wrote: On Fri, Jan 20, 2012 at 02:48:24PM -0500, Eitan Adler wrote: You mean like this ? http://www.freebsd.org/doc/en/books/porters-handbook/dads-sysctl.html Yeah, but that's missing the 2 /dev/null corollary. Or the mustn't return non-zero exit code in routine usage bit, which is what was biting in this particular case. 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: Doing SQL to the FreeBSD ports index
On Friday 20 January 2012, Matthew Seaman wrote: On 20/01/2012 19:25, Mark Linimon wrote: You've probably reimplemented part of ports tinderbox (and, separately, portsmon and FreshPorts) :) I have this other invention I've been calling 'a rotationally symmetrical device designed to facilitate travel.' If it has rounded corners, Apple already has it patented. -- Dave ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
INDEX now builds successfully on 7.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Any plans to update salt to 0.9.5?
On 01/20/2012 07:09, Christer Edwards wrote:
On Thu, Jan 19, 2012 at 8:12 PM, Doug Barton do...@freebsd.org wrote:
I've been evaluating salt, and would prefer not to deploy prior to the
msgpack update in 0.9.5.
I am hoping to get the port updated today, yes. Thanks for the
additional nudge to get it finished :)
Awesome, thanks!
I've attached a small patch I came up with to brute-force the PREFIX.
The change in patch-setup.py doesn't do it for me for some reason. What
happens is that the daemon starts up because the path to the config is
included in the command line. But all of the command line tools
subsequently need the -c option to tell them where it is. While not
particularly elegant, doing it this way has 2 additional benefits. First
it updates the documentation as well as the binaries, and second it
means less to edit when a new user is setting it up for the first time
because the defaults already work.
When you get your update ready feel free to cc me on the PR.
Doug
--
It's always a long day; 86400 doesn't fit into a short.
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
Index: Makefile
===
RCS file: /home/pcvs/ports/sysutils/salt/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- Makefile9 Jan 2012 15:41:04 - 1.2
+++ Makefile20 Jan 2012 23:43:16 -
@@ -49,9 +49,16 @@
RUN_DEPENDS:= ${BUILD_DEPENDS}
post-patch:
+.for file in conf/minion conf/master doc/man/salt-key.1 doc/man/salt-cp.1 \
+doc/man/salt-minion.1 doc/man/salt-syndic.1 doc/man/salt-master.1 \
+doc/man/salt-run.1 doc/man/salt.7 doc/man/salt.1 salt/cli/__init__.py \
+salt/__init__.py salt/config.py salt/client.py salt/modules/mysql.py
+ @${REINPLACE_CMD} -e 's|/etc/salt|${PREFIX}/etc/salt|' \
+ -e 's|/srv/salt|${PREFIX}/etc/salt/states|' ${WRKSRC}/${file}
+.endfor
@${REINPLACE_CMD} -e 's|%%PREFIX%%|${PREFIX}|' ${WRKSRC}/setup.py
- ${MV} ${WRKSRC}/conf/master ${WRKSRC}/conf/master.sample
- ${MV} ${WRKSRC}/conf/minion ${WRKSRC}/conf/minion.sample
+ @${MV} ${WRKSRC}/conf/master ${WRKSRC}/conf/master.sample
+ @${MV} ${WRKSRC}/conf/minion ${WRKSRC}/conf/minion.sample
post-install:
@${CAT} ${PKGMESSAGE}
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: couchdb-1.1.0_2,1
On 01/19/2012 07:39, Herby Vojčík wrote: The couchdb_prestart function gets run (I put echos in there), but its couchdb_flags is not taken into account. The proper solution here is almost certainly to change couchdb_flags to commands_args in couchdb_prestart(). I had to make this change: That patch is definitely not the right solution. hth, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
