Re: NOT_FOR_ARCHS considered harmful [was: with the cvs history? trying to help INDEX builds.]

[perryh]

Matthew Seaman  wrote:

> Finally, all this testing the CPU architecture and the OS version
> makes no sense at all for ports that don't install any compiled
> binaries, such as shell scripts.

Unless said script runs something CPU- or OSversion-specific, e.g.
to perform operations that are supported only in recent geom, or to
report on the configuration of ACPI or the new USB subsystem.
___
freebsd-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: NOT_FOR_ARCHS considered harmful [was: with the cvs history? trying to help INDEX builds.]

[Matthew Seaman]

On 22/01/2012 10:40, Matthew Seaman wrote:
> On 21/01/2012 20:46, Mark Linimon wrote:
>> tl;dr: I want to switch the default assumption we're making.
>>
>> IMHO when new ports come into the tree, we should make our default
>> assumption that we will try to build them on amd64 and i386.  For cases
>> that this does not hold, we consider this Bad and committer-must-fix.
>> For the tier-2s, we shift the default assumption to "only set it to
>> buildable once it has been shown to be so".  So, the burden of proof
>> shifts the other way: to a user of a tier-2 to claim "I tried this and
>> it works", rather than portmgr saying "we tried this and it doesn't work".
> 
> Doesn't your proposed change in semantics of the 'FOR_ARCHS' stuff mean
> that over time, as other architectures become more popular, most ports
> will have to have an explicit 'ONLY_FOR_ARCHS' setting?  If the default
> effectively becomes 'ONLY_FOR_ARCHS= i386 amd64' then as ports are shown
> to work on different platforms they will need an ONLY_FOR_ARCHS line in
> their Makefiles listing where they are known to work?  Or else the ports
> becomes effectively i386 / amd64 only?
> 
>> (Of course, for things like p5-* it doesn't really matter; if perl
>> builds, to a first approximation they'll build as well.  I'm talking
>> about the things like biology/, deskutils/, games/, math/, science,
>> x11*/, and so forth.)
>>
>> What do people think?
> 
> There are a lot of ports where the distinction between CPU architectures
> is pretty much irrelevant.  I can't see portmaster(8) (for example)
> failing to work anywhere the base system works.
> 
> I was thinking about this a while back.  Test the contents of packages
> to see if they install any object code -- ports/129210 -- and mark the
> ones that don't as arch-independent in some way (CATEGORIES+= arch-indep
> perhaps?)

So, apropos Mark's comments earlier, and after a few false starts and a
lot of head-scratching here is a patch to address many of his points.

It does basically three things:

  * Removes the NOT_FOR_ARCHS variable and associate functionality.

  * Creates a new BROKEN_OSARCHS variable.  This is largely syntactic
sugar, meaning that it is no longer necessary to use
.include  in order to test ${ARCH} or ${OSVERSION}

  * Creates a new SUPPORTED_OSARCHS variable.  This allows maintainers
to indicate which architectures they will support, and whether the
package build cluster should routinely build packages for that port.

A full patch removing NOT_FOR_ARCHS from the ports is at:

   http://www.infracaninophile.co.uk/not_for_archs.diff

Comments? Critiques?

Now for the more long-winded explanation bit

NOT_FOR_ARCHS is frequently misused to indicate temporary build or
installation failures on particular architectures.  The _FOR_ARCHS stuff
should be really only be used to indicate ports designed to work on
specific CPU architectures.  ONLY_FOR_ARCHS exists for this purpose.
The problem with extending it to cover temporary failures is that the
package build cluster will never retry building that port, so there's no
way to tell if changes to the toolchain or updates to the port have
subsequently fixed the problem.

This is where the BROKEN_OSARCHS variable is useful.  This is a list of
achitecture-OS version pairs corresponding to the different environments
used in the package build cluster.  Thus you can easily mark a port as
broken on sparc64-7, rather than having to use a construction like this:

.include 

.if ${ARCH} == "sparc64" && ${OSVERSION} < 80
BROKEN= compiler dumps core
.endif

.include 

(Not using bsd.port.{pre,post}.mk so much should help a bit with index
building times too.)

It's also rather easier to grep for BROKEN_OSARCHS than it is for a
construct like the above.

As BROKEN_OSARCHS ultimately uses the pre-existing BROKEN variable,
setting TRY_BROKEN will allow these ports to be retested.

Finally there is SUPPORTED_OSARCHS, which can be used to indicate policy
about where a port is known to usable.  For regular users it doesn't do
anything except print a warning message if an attempt is made to compile
a port on an unsupported architecture/OS combination.
For the ports build cluster, conditional on PACKAGE_BUILDING being set,
it turns off building on unsupported environments by setting IGNORE.

As the patch stands at the moment, every port will be using the default,
which is to support these architecture/OS combinations:

i386-7 i386-8 i386-9 amd64-7 amd64-8 amd64-9

but the defaults can be modified easily or port-specific settings can be
added.   There is also a TRY_UNSUPPORTED knob to turn on building
packages on all architectures / OS versions.

Finally, all this testing the CPU architecture and the OS version makes
no sense at all for ports that don't install any compiled binaries, such
as shell scripts.  Those ports can define a variable ARCH_INDEP to opt
out of the SUPPORTED_OSARCHS thing altogether.

Cheers,

Matthew

-

Re: NOT_FOR_ARCHS considered harmful [was: with the cvs history? trying to help INDEX builds.]

[Matthew Seaman]

On 21/01/2012 20:46, Mark Linimon wrote:
> tl;dr: I want to switch the default assumption we're making.
> 
> IMHO when new ports come into the tree, we should make our default
> assumption that we will try to build them on amd64 and i386.  For cases
> that this does not hold, we consider this Bad and committer-must-fix.
> For the tier-2s, we shift the default assumption to "only set it to
> buildable once it has been shown to be so".  So, the burden of proof
> shifts the other way: to a user of a tier-2 to claim "I tried this and
> it works", rather than portmgr saying "we tried this and it doesn't work".

Doesn't your proposed change in semantics of the 'FOR_ARCHS' stuff mean
that over time, as other architectures become more popular, most ports
will have to have an explicit 'ONLY_FOR_ARCHS' setting?  If the default
effectively becomes 'ONLY_FOR_ARCHS= i386 amd64' then as ports are shown
to work on different platforms they will need an ONLY_FOR_ARCHS line in
their Makefiles listing where they are known to work?  Or else the ports
becomes effectively i386 / amd64 only?

> (Of course, for things like p5-* it doesn't really matter; if perl
> builds, to a first approximation they'll build as well.  I'm talking
> about the things like biology/, deskutils/, games/, math/, science,
> x11*/, and so forth.)
> 
> What do people think?

There are a lot of ports where the distinction between CPU architectures
is pretty much irrelevant.  I can't see portmaster(8) (for example)
failing to work anywhere the base system works.

I was thinking about this a while back.  Test the contents of packages
to see if they install any object code -- ports/129210 -- and mark the
ones that don't as arch-independent in some way (CATEGORIES+= arch-indep
perhaps?)

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: NOT_FOR_ARCHS considered harmful [was: with the cvs history? trying to help INDEX builds.]

[Chris Rees]

On 21 Jan 2012 20:46, "Mark Linimon"  wrote:
>
> 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.
>
> There's a secondary problem which I keep meaning to write up a rant
> on.  This thread seems as good a place as any.
>
> Warning: the following is only my own opinion, not portmgr's.
>
> We made a design mistake by allowing in NOT_FOR_ARCHS as an alternative
> to ONLY_FOR_ARCHS.  This has always been a shortcut to say "doesn't
> build on !(amd64!i386)".  As long as the archs were (alpha|amd64|i386|
> sparc64) this was merely annoying.
>
> The problem comes when we start up package builds on new archs.   The
> primary utility of package builds for tier-2s has arguably been to QA
> whether the ports build at all.  The secondary utility, in order:
>
>  - test that the arch's srcbase has't regressed to the point where it's
>   too unstable to build packages
>
>  - flag ports (and infrastructure) with bad assumptions about wordlength
>   and endianness
>
>  - create usable packages (really, only the most fundamental ports will
>   have packages that are timely, due to the > 1 month cycle times)
>
> In general, I claim if a port already has some kind of NOT_FOR_ARCH
> entry, it's unlikely to build on a new arch.  This was clearly demonstrated
> a couple of years ago when I first started powerpc builds once we had a
> machine donated (note: powerpc = 32-bit).  The errors were correlated to
> sparc64, but only roughly.
>
> sparc64 builds tend to trip up on the following, in order of which I
> think we should care:
>
>  - 64-bit issues (which have a high correlation to amd64 build failures),
>
>  - lack of arch-specific build stanzas (which have a high correlation to
>   powerpc),
>
>  - endianness issues.
>
> The powerpc build also pointed out that many ports assumed that 32bit <> i386.
> On occasion, I fix notable occurences of this (e.g. python).
>
> So, why does this matter?  Surely our sparc64 and powerpc/Mac userbases
> are tiny.
>
> The reason to do this work is that there is demand for arm and mips builds
> for embedded systems[1], and once these are turned on, we're going to have
> a bazillion build errors to sort through.
>
> To the extent that our first attempts include only ports that don't have
> the NOT_FOR stanzas, IMHO we're going to make more progress more quickly.
>
> Now, for mips, only the "fundamental" ports are ever going to matter,
> since there are no viable mips desktops to worry about.  But, for
> embedded, getting a subset of things in net/ and sysutils/ (and to
> some extent things like lang/perl) is going to be useful -- again, not
> so much for uploadable packages, but to ensure buildability when vendors
> try to use these in their products.
>
> (I'm told that people are speculating about running desktop stuff on
> native arm, so that's why I picked mips for the use-case.  I have no
> idea if that's anything but blue-sky.)
>
> So IMHO we should do a sweep:
>
>  - move all the true cases of NOT_FOR_ARCHS to ONLY_FOR_ARCHS
>
>  - move all the false cases of NOT_FOR_ARCHS to BROKEN
>
> and then drop support for NOT_FOR_ARCHS.
>
> If anyone is interested in coming up with patches, I'll do the -exp
> run (on amd64 :-) ) to prove that there are no regressions on that
> arch at least.
>
> Finally, for those willing to investigate how messed-up the metadata
> currently are, pull up the following page:
>
>  http://pointyhat.freebsd.org/errorlogs/packagestats.html
>
> You'll find a column marked "skipped".  That contains URLs to files
> called "duds.verbose" for each buildenv.  This file is the output of
> 'make ignorelist-verbose' called from the top of the tree.
>
> The reason that we decided to archive these per-pointyhat-run is so
> that you can tell _exactly_ why pointyhat believed that it did not have
> to try to build that package at that exact point in time.  In the past,
> you had to impute it from whatever the state of the tree was.  Since
> the tree evolves so quickly, it was impossible to tell.  (There are
> also a very small handful of degenerate cases where things don't
> build on pointyhat due to its build environment.  I've worked on getting
> these down to < 10 over the past few years.)
>
> tl;dr: I want to switch the default assumption we're making.
>
> IMHO when new ports come into the tree, we should make our default
> assumption that we will try to build them on amd64 and i386.  For cases
> that this does not hold, we consider this Bad and committer-must-fix.
> For the tier-2s, we shift the default assumption to "only set it to
> buildable once it has been shown to be so".  So, the burden of proof
> shifts the other way: to a user of a tier-2 to c

NOT_FOR_ARCHS considered harmful [was: with the cvs history? trying to help INDEX builds.]

[Mark Linimon]

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.

There's a secondary problem which I keep meaning to write up a rant
on.  This thread seems as good a place as any.

Warning: the following is only my own opinion, not portmgr's.

We made a design mistake by allowing in NOT_FOR_ARCHS as an alternative
to ONLY_FOR_ARCHS.  This has always been a shortcut to say "doesn't
build on !(amd64!i386)".  As long as the archs were (alpha|amd64|i386|
sparc64) this was merely annoying.

The problem comes when we start up package builds on new archs.   The
primary utility of package builds for tier-2s has arguably been to QA
whether the ports build at all.  The secondary utility, in order:

 - test that the arch's srcbase has't regressed to the point where it's
   too unstable to build packages

 - flag ports (and infrastructure) with bad assumptions about wordlength
   and endianness

 - create usable packages (really, only the most fundamental ports will
   have packages that are timely, due to the > 1 month cycle times)

In general, I claim if a port already has some kind of NOT_FOR_ARCH
entry, it's unlikely to build on a new arch.  This was clearly demonstrated
a couple of years ago when I first started powerpc builds once we had a
machine donated (note: powerpc = 32-bit).  The errors were correlated to
sparc64, but only roughly.

sparc64 builds tend to trip up on the following, in order of which I
think we should care:

 - 64-bit issues (which have a high correlation to amd64 build failures),

 - lack of arch-specific build stanzas (which have a high correlation to
   powerpc),

 - endianness issues.

The powerpc build also pointed out that many ports assumed that 32bit <> i386.
On occasion, I fix notable occurences of this (e.g. python).

So, why does this matter?  Surely our sparc64 and powerpc/Mac userbases
are tiny.

The reason to do this work is that there is demand for arm and mips builds
for embedded systems[1], and once these are turned on, we're going to have
a bazillion build errors to sort through.

To the extent that our first attempts include only ports that don't have
the NOT_FOR stanzas, IMHO we're going to make more progress more quickly.

Now, for mips, only the "fundamental" ports are ever going to matter,
since there are no viable mips desktops to worry about.  But, for
embedded, getting a subset of things in net/ and sysutils/ (and to
some extent things like lang/perl) is going to be useful -- again, not
so much for uploadable packages, but to ensure buildability when vendors
try to use these in their products.

(I'm told that people are speculating about running desktop stuff on
native arm, so that's why I picked mips for the use-case.  I have no
idea if that's anything but blue-sky.)

So IMHO we should do a sweep:

 - move all the true cases of NOT_FOR_ARCHS to ONLY_FOR_ARCHS

 - move all the false cases of NOT_FOR_ARCHS to BROKEN

and then drop support for NOT_FOR_ARCHS.

If anyone is interested in coming up with patches, I'll do the -exp
run (on amd64 :-) ) to prove that there are no regressions on that
arch at least.

Finally, for those willing to investigate how messed-up the metadata
currently are, pull up the following page:

  http://pointyhat.freebsd.org/errorlogs/packagestats.html

You'll find a column marked "skipped".  That contains URLs to files
called "duds.verbose" for each buildenv.  This file is the output of
'make ignorelist-verbose' called from the top of the tree.

The reason that we decided to archive these per-pointyhat-run is so
that you can tell _exactly_ why pointyhat believed that it did not have
to try to build that package at that exact point in time.  In the past,
you had to impute it from whatever the state of the tree was.  Since
the tree evolves so quickly, it was impossible to tell.  (There are
also a very small handful of degenerate cases where things don't
build on pointyhat due to its build environment.  I've worked on getting
these down to < 10 over the past few years.)

tl;dr: I want to switch the default assumption we're making.

IMHO when new ports come into the tree, we should make our default
assumption that we will try to build them on amd64 and i386.  For cases
that this does not hold, we consider this Bad and committer-must-fix.
For the tier-2s, we shift the default assumption to "only set it to
buildable once it has been shown to be so".  So, the burden of proof
shifts the other way: to a user of a tier-2 to claim "I tried this and
it works", rather than portmgr saying "we tried this and it doesn't work".

(Of course, for things like p5-* it doesn't really matter; if perl
builds, to a first approximation they'll build as well.  I'm ta

Re: with the cvs history? trying to help INDEX builds.

[Matthew Seaman]

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.

[Chris Rees]

On 21 Jan 2012 19:51, "Mark Linimon"  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.

[Mark Linimon]

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.

[Mark Linimon]

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.

[Mark Linimon]

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.

[Mark Linimon]

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.

[Matthew Seaman]

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.

[Mark Linimon]

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.

[Eitan Adler]

On Fri, Jan 20, 2012 at 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.
>
> 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.

[Eitan Adler]

On Fri, Jan 20, 2012 at 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.
>
> 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.

[Michael Scheidell]

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.

[Mark Linimon]

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.

[Michael Scheidell]

On 1/20/12 8:33 AM, Matthew Seaman wrote:

Actually, going back to the original question -- if this means not
having to .include  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  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  when all you needed to do was drag in '.

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.

[Matthew Seaman]

On 20/01/2012 13:14, Chris Rees wrote:
> On 20 Jan 2012 13:06, "Matthew Seaman" 
> wrote:
>>
>> On 20/01/2012 12:53, Chris Rees wrote:
>>> On 20 Jan 2012 10:20, "Matthew Seaman" 
>>> 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 ; -.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  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.

[Doug Barton]

On 01/20/2012 05:23, Anton Shterenlikht wrote:
> how about ia64?

The benefit of ONLY_FOR_ARCHS is that it eliminates exactly this kind of
guesswork. :)


-- 

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.

[Anton Shterenlikht]

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.

[Doug Barton]

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.

[Chris Rees]

On 20 Jan 2012 13:06, "Matthew Seaman" 
wrote:
>
> On 20/01/2012 12:53, Chris Rees wrote:
> > On 20 Jan 2012 10:20, "Matthew Seaman" 
> > 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 ; -.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.

[Matthew Seaman]

On 20/01/2012 12:53, Chris Rees wrote:
> On 20 Jan 2012 10:20, "Matthew Seaman" 
> wrote:
>>
>> On 20/01/2012 09:18, Chris Rees wrote:
>>> On 19 Jan 2012 08:58, "Matthew Seaman" 
>>> wrote:
>>
 On 19/01/2012 01:31, Michael Scheidell wrote:
>>
> anyway, worth the cycles?
> take out -.include ; -.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.

[Chris Rees]

On 20 Jan 2012 10:20, "Matthew Seaman" 
wrote:
>
> On 20/01/2012 09:18, Chris Rees wrote:
> > On 19 Jan 2012 08:58, "Matthew Seaman" 
> > wrote:
>
> >> On 19/01/2012 01:31, Michael Scheidell wrote:
>
> >>> anyway, worth the cycles?
> >>> take out -.include ; -.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.

[Eitan Adler]

On Fri, Jan 20, 2012 at 5:44 AM, Matthew Seaman
 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.

[Matthew Seaman]

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.

[Matthew Seaman]

On 20/01/2012 09:18, Chris Rees wrote:
> On 19 Jan 2012 08:58, "Matthew Seaman" 
> wrote:

>> On 19/01/2012 01:31, Michael Scheidell wrote:

>>> anyway, worth the cycles?
>>> take out -.include ; -.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.

[Anton Shterenlikht]

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.

[Chris Rees]

On 19 Jan 2012 08:58, "Matthew Seaman" 
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 ; -.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.

[Doug Barton]

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"

Re: with the cvs history? trying to help INDEX builds.

[Matthew Seaman]

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 ; -.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

with the cvs history? trying to help INDEX builds.

[Michael Scheidell]

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 ; -.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?




cvs diff: Diffing .
Index: Makefile
===
RCS file: /home/pcvs/ports/games/xarchon/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- Makefile10 Aug 2011 09:01:56 -1.16
+++ Makefile19 Jan 2012 01:27:56 -
@@ -29,10 +29,6 @@
 @${REINPLACE_CMD} -e 's|Xarchon_Evolution::||' \
 ${WRKSRC}/src/Xarchon_Genetic.hpp

-.include 
+NOT_FOR_ARCHS=sparc64

-.if ${ARCH} == "sparc64"
-BROKEN=Does not install on sparc64
-.endif
-
-.include 
+.include 
cvs diff: Diffing files

--
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"