Re: with the cvs history? trying to help INDEX builds.
On Thu, Jan 19, 2012 at 08:58:04AM +, Matthew Seaman wrote: By my calculations there are 28 ports that set 'BROKEN' because of architecture incompatibility on my amd64 system IMHO these Makefiles are broken and should be fixed. 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 Fri, Jan 20, 2012 at 10:20:05AM +, Matthew Seaman wrote: 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. A fair amount of effort has gone into trying to distinguish the two cases. I know, because I put in a lot of that effort :-) Unfortunately those two cases are already pretty confused. - many maintainers don't understand the distinction - some committers don't understand the distinction - some Makefiles predate this technology ./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 All 3 are wrong IMVHO. We should fix them. 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 Fri, Jan 20, 2012 at 12:53:23PM +, Chris Rees wrote: Occasionally someone runs an exp- for sparc64 (lol) etc. You're conflating two different ideas. The arch is orthogonal to TRYBROKEN. They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS sets IGNORE. This part is correct. These ports will never be tested on the build cluster no matter what the state of the toggle. It's a bit academic at the moment, as we haven't had enough horsepower to do a TRYBROKEN on any arch for a really long time. However, with the advent of the NYI machines, we are getting there. For a dummy load for debugging pointyhat-west, I have recently done a -trybroken run on amd64-8. Here is my fist-cut summary of the results: http://wiki.freebsd.org/Trybroken I don't have the cycles to investigate any further, so any and all help would be welcomed. My own theory is that for the tier-2s, since we don't have enough horsepower to do timely regular builds, that there's not much point representing that we can do -trybrokens. Thus, when I poke at sparc64 and powerpc every once in a while, I'm setting BROKEN or ONLY_FOR in the Makefiles just as a service to the users. (OK, and to make it so I have less results to look at after the next run :-) ) 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 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. When we switch to DougBBSD, you'll get to dictate to people how to spend their time. Until then, once a month or so, the sparc64 and powerpc runs will continue. As a data-point, I'm finding that ports that fail on either one also fail on clang (now that we're able to quickly turn clang -exps.) I would make the argument that the tier-2s can serve as canaries here. 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 21 Jan 2012 19:51, Mark Linimon lini...@lonesome.com wrote:
On Fri, Jan 20, 2012 at 12:53:23PM +, Chris Rees wrote:
Occasionally someone runs an exp- for sparc64 (lol) etc.
You're conflating two different ideas. The arch is orthogonal to
TRYBROKEN.
Perhaps I didn't phrase it clearly enough :)
This code:
.if ${ARCH} == sparc64
BROKEN= blargh
.ensign
will allow a TRYBROKEN run on sparc64 to show any that have miraculously
fixed. ONLY_FOR_ARCHS breaks that functionality.
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 21/01/2012 19:33, Mark Linimon wrote:
On Thu, Jan 19, 2012 at 08:58:04AM +, Matthew Seaman wrote:
By my calculations there are 28 ports that set 'BROKEN' because of
architecture incompatibility on my amd64 system
IMHO these Makefiles are broken and should be fixed.
Actually, collecting the data by another method, it seems that there are
359 ports that set BROKEN with the reason mentioning ${ARCH}, i386,
amd64, ia64, powerpc or sparc. Of course this doesn't pick up cases
where there's no clue about the architecture in the BROKEN message.
I have a patch adding a BROKEN_FOR_ARCHS variable, parallel to
ONLY_FOR_ARCHS, but I haven't managed to test it properly yet. I
thought I'd try applying it or {ONLY,NOT}_FOR_ARCHS (as I judge[*]
appropriate) to the 79 of those ports which haven't got a maintainer,
which should show well enough if it works properly.
Cheers,
Matthew
[*] well, more like guess really.
---
How I worked out those numbers:
i) Used my portindexdb stuff to get a list of all the Makefiles under
/usr/ports/*/*/:
select path from makefile where path ~ '^/usr/ports/[^/]+/[^/]+/'
ii) Grep through those makefiles for lines starting BROKEN= and
mentioning something to do with CPU architecture:
/tmp/ports-makefiles xargs grep -l
'^BROKEN=.*\(${ARCH}\|i386\|amd64\|ia64\|powerpc\|sparc\)'
/tmp/ports-BROKEN-for-arch
-- results in 359 matches
iii) Then grep through those 359 makefiles for ones containing
po...@freebsd.org
% /tmp/ports-BROKEN-for-arch xargs grep -l 'po...@freebsd.org'
/tmp/ports-BROKEN-for-arch-unmaintained
-- results in 79 matches.
MK/bsd.ports.mk patch:
cvs diff: Diffing .
Index: bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.702
diff -u -u -r1.702 bsd.port.mk
--- bsd.port.mk 15 Jan 2012 22:13:42 - 1.702
+++ bsd.port.mk 21 Jan 2012 19:36:50 -
@@ -222,6 +222,18 @@
# - Set this instead of ONLY_FOR_ARCHS if the
given port
#fetches and installs compiled i386 binaries.
#
+# Set these if your port temporarily does not work on certain
+# architectures due to programming errors, broken dependencies
+# etc. Values are lists of architecture names as above. (Defaults: not
+# set)
+#
+# BROKEN_FOR_ARCHS
+# - Declare port broken on ${ARCH} if the port is temporarily
+# unusable there
+# BROKEN_FOR_ARCHS_REASON
+# BROKEN_FOR_ARCHS_REASON_${ARCH}
+# - Reason why the port is broken on ${ARCH}
+#
# Dependency checking. Use these if your port requires another port
# not in the list below. (Default: empty.)
#
@@ -3156,6 +3168,26 @@
.endif
+.if defined(BROKEN_FOR_ARCHS)
+.for __BARCH in ${BROKEN_FOR_ARCHS}
+.if ${ARCH:M${__BARCH}} !=
+__ARCH_BROKEN?=1
+.endif
+.endfor
+
+.if defined(__ARCH_BROKEN)
+BROKEN=broken on ${BROKEN_FOR_ARCHS}, and you are running
${ARCH}
+
+.if defined(BROKEN_FOR_ARCHS_REASON_${ARCH})
+BROKEN+= (reason: ${BROKEN_FOR_ARCHS_REASON_${ARCH})
+.elif defined(BROKEN_FOR_ARCHS_REASON)
+BROKEN+= (reason: ${BROKEN_FOR_ARCHS_REASON})
+.endif
+
+.endif
+
+.endif
+
# Check the user interaction and legal issues
.if !defined(NO_IGNORE)
.if (defined(IS_INTERACTIVE) defined(BATCH))
As I said, not tested yet. I'll submit this and patches against those
79 ports as a PR once I've managed to do that.
--
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 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: 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: 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: 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: with the cvs history? trying to help INDEX builds.
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)
--
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 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 -- 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
