Bugzilla Bug 125258

There are two ebuilds for icon

icon-9.40.ebuild

and 

icon-9.4.2.ebuild

The 9.4.2 is the latest version however the 9.40 (which is really 9.4.0) gets
pulled in instead.

Either mask or remove the icon-9.40.ebuild, or rename icon-9.40.ebuild to
icon-9.4.0.ebuild

-- also ---
there is a 9.4.3 version that was released in November.

Created an attachment (id=81575) [details]
ebuild for icon 9.4.3

Here is the ebuild for Icon 9.4.3 

The release information is available here:

http://www.cs.arizona.edu/icon/v943/relnotes.htm

one additional note..

Becareful of the naming "conflict" of the new ebuild to avoid the same problem
when dealing with the icon-9.40.ebuild

so either call this ebuild icon-9.43 -or- fix the icon-9.40.ebuild name

Created an attachment (id=81579) [details]
"enhanced" ebuild for icon 9.4.3

This ebuild installs Icon into the suggested directory structure suggested by
the Icon documentation.  This removes a lot of clutter in the /usr/lib
directory as well as addressing a /usr/bin conflict (xgamma)

the files are installed into the /opt/icon directory structure.  4 files
symlinked into /usr/bin

Additionally, some optional experimental features can be enabled via USE flags.
 Specifically:

MT-Icon - enabled by mticon
Eve - enabled by eve
EventMon - enabled by eventmon

And finally, the source code for the Icon Programming Library can be included.

I reviewed the ebuild with a couple of people on the IRC gentoo-dev-help
channel

(From update of attachment 81579 [details])
changed final install location to /usr/lib/icon -- after reviewing some other
packages

Created an attachment (id=81679) [details]
"enhanced" icon-9.4.3 ebuild 

After review of other packages, determined that the "best" location to install
into would be /usr/lib/icon and then symlink the 4 executables out.

note -- that Icon uses the physical location of the binaries to determine the
default location for setting IPATH, LPATH and FPATH directories (LPATH location
for $include, IPATH location for link and FPATH is loadable runtime .so files) 

Created an attachment (id=82367) [details]
the reworked ebuild

Hi Cheyenne.

Thanks for keeping this updated!
I cleaned up the last ebuild and reworked src_install, so that it puts docs in
a proper place. Since the package is compiled it indeed should not go under
/opt and since it feels itself much better in his own organizaition it indeed
should be put under /usr/lib/pkgname. So that arrangement is fine + thanks for
pointing at the necessary binaries (that need to be visible).

I have attached the new ebuild, which should be a base for any further
modifications if such will be necessary. It is pretty much ready to go in,
except or the following issue I wanted to ask you about:

How essential it is to have these additional use flags? While in general it is
nice to have more flexibility, but I am afraid this package is not used that
much as to warrant creating four more useflags, even if local. Are the extra
parts that big?

More specifically:
X should stay, plus it was already used,
mticon - why not use global "threads" flag?
eve and eventmon - do you think many people would not want this? 
iplsrc - this one may be valid, after all it install an significant extra part,
from what I can see. On the other hand the whole package is quite small, so I
am not sure it is worth the bother, but I am open about creating this (local)
flag..

Otherwise this seems fine and I'll add this version when we decide on
useflags..

George

9.4.3 is in the tree, please test. 
I retained only iplsrc use flag (in addition to X), the #define injections are
made unconditional, as I do not see much benefit worthy 3 extra useflags, as I
mentioned in previous comment. The modular X deps are updated to incorporate
both Cheyenne's and Caleb's. 

George

I would like to request ahead-of-schedule stabilization of dev-lang/icon-9.4.3
on x86 and sparc.

The presently stable 9.40 version causes collisions with x11-apps/xgamma, in
general installs files in bad locations and does not follow upstream
versioning, plus it does not play well with modular X. I would like to remove
it from the tree when 9.4.3 is stabilized on these two arches.

George

Sparc is done, for reasons noted in the Changelog.  That is to say, because:

+  27 Mar 2006; Ferris McCormick <fmccor@gentoo.org> icon-9.4.3.ebuild:
+  Add sparc keyword (Bug #114944).  This seems the least bad of several
options:
+  For me, the "stable" version 9.40 flat out won't build; instead, it goes
into
+  a '/bin/sh: line 0: cd: gpacks/README: Not a directory' loop.  The requested
+  version --- 9.4.3 --- builds and installs, but a couple of its tests fail
with
+  FEATURES=test enabled.  But in this case, I'll mark it stable, just to help
+  get rid of 9.40.  (Note that my system is x11-base/xorg-x11-7.0-r1.)

Argh, sorry about the tests. Apparently I forgot to reenable them after
rebuilding my system recently :(. Anyway, this is the best working version so
far, so I'd like to get it stabilized on x86 as well and then get rid of 9.40..

Cheyenne: The failing test is sieve:
Testing sieve
1,27c1,7
< There are 25 primes in the first 100 integers.
< The primes are:
[skipped the list of primes]
<   97
---
>
> Run-time error 302
> File sieve.icn; Line 12
> memory violation
> Traceback:
> main()
> insert(set_1(81),81,&null) from line 12 in sieve.icn

Disabling "experimental features" or X does not effect, so this is apparently a
problem in the compiler itself..

George

Hello..

Not a problem relocating to /usr/lib/pkgname

There are a couple of the supplied sample packages that require some of the
experimental features, but they are not critical overall (though I do use
them).

The "threading model" used by Icon  (MTICON) is not real threads, but an
internal way of dynamically loading additional Icon code during runtime.

For the problem with the sparc, you might want to try changing the ebuild where
the CFLAGS are "reset".  Icon can break C compilers and might be sensitive to
certain optimizations

woops -- ment the problem with sieve failing.

I did run the tests okay.  My CFLAGS are -O2 -march=pentium4
-fomit-frame-pointer

Hi Cheyenne.

Thanks for getting back and for your input!
I will reply to the bug, to make the conversation traceable.

Indeed the sieve test problem was caused by CFLAGS on my side, I have:
CFLAGS="-march=athlon64 -O3 -pipe -ftracer -fomit-frame-pointer"

This is on amd64 as you can see. I simply removed the src_unpack section in the
ebuild that is in the tree and this resolves the sieve issue. However now I am
hitting other test failures. I am posting below the tail of the build. I
removed all the echoed test names, which, as I understand, means test completed
successfully, leaving only the output that was spit out..

George

make[2]: Entering directory
`/var/tmp/portage/icon-9.4.3-r1/work/icon.v943src/tests/general'
IC=icont sh Test-icon

Linux aldar 2.6.15-gentoo-r7 #6 PREEMPT Sun Mar 26 09:24:53 UTC 2006 x86_64 AMD
Athlon(tm) 64 Processor 3200+ GNU/Linux
icont:  Icon Version 9.4.3, November 14, 2005  (linux, pthreads.c, Mar 31 2006)
iconx:  Icon Version 9.4.3, November 14, 2005  (linux, pthreads.c, Mar 31 2006)

Testing args
[...]
Testing io
1,125c1
< file: &errout
< file: &input
< file: &output
< file: file(/dev/null)
< file: file(/etc/motd)
<
< aaa
< bbbb
< ccccc
< dddddd
< eeeeeee
< ffffffff
< ggggggggg
< hhhhhhhhhh
<
< flush /etc/motd: file(/etc/motd)
< close /etc/motd: file(/etc/motd)
< close /etc/motd: file(/etc/motd)
< flush /etc/motd: file(/etc/motd)
<
< flush /dev/null: file(/dev/null)
< close /dev/null: file(/dev/null)
< close /dev/null: file(/dev/null)
< flush /dev/null: file(/dev/null)
<
< read  /dev/null:
<    !f:
<    read/!f:
<    reads():
<
< write tmp1,w:  follow the yellow brick road : 30
< read  tmp1:    follow the yellow brick road
<    !f:                 follow the yellow brick road
<    read/!f:    follow the yellow brick road
<    reads():    follo w.the .yell ow.br ick.r oad.
<
< write tmp1,w:  shorter file : 14
< read  tmp1:    shorter file
<    !f:                 shorter file
<    read/!f:    shorter file
<    reads():    short er.fi le.
<
< write tmp1,a:  gets extended : 28
< read  tmp1:    shorter file gets extended
<    !f:                 shorter file gets extended
<    read/!f:    shorter file gets extended
<    reads():    short er.fi le.ge ts.ex tende d.
<
< write tmp1,rw:         changed : 9
< read  tmp1:    changed file gets extended
<    !f:                 changed file gets extended
<    read/!f:    changed file gets extended
<    reads():    chang ed.fi le.ge ts.ex tende d.
<
< write tmp1,b:  mode b  : 8
< read  tmp1:    mode b  file gets extended
<    !f:                 mode b  file gets extended
<    read/!f:    mode b  file gets extended
<    reads():    mode. b..fi le.ge ts.ex tende d.
<
< write tmp1,crw:        cleared anew : 14
< read  tmp1:    cleared anew
<    !f:                 cleared anew
<    read/!f:    cleared anew
<    reads():    clear ed.an ew.
< read  tmp2:    cleared anew
<    !f:                 cleared anew
<    read/!f:    cleared anew
<    reads():    clear ed.an ew.
<
< file(tmp1)
< file(tmp2)
< >stdout>stdout>stdout
<
< >stdout
<
< read  tmp1:    >1a>1b>1c  >1d  >1e>1f
<    !f:                 >1a>1b>1c  >1d  >1e>1f
<    read/!f:    >1a>1b>1c  >1d  >1e>1f
<    reads():    >1a>1 b>1c. .>1d. .>1e> 1f.
< read  tmp2:    >2a>2b >2c >2d  >2e>2f
<    !f:                 >2a>2b >2c >2d  >2e>2f
<    read/!f:    >2a>2b >2c >2d  >2e>2f
<    reads():    >2a>2 b.>2c .>2d. .>2e> 2f.
<
< abcdef
< ghi
< jklmno
< pqr
< stu
< vwxyz
<
< $ echo hello world
< hello world
< $ ls io.[ids][tca][dnt]
< io.dat
< io.icn
< io.std
<
< file(echo hello world)
< > hello world
<
< file(sed 's/^/=()= /' io.icn)
< > =()= #SRC: JCON
< > =()=
< > =()= #  I/O test -- writes ./tmp1 and ./tmp2 as well as stdout
< > =()=
< > =()= procedure main()
< > =()=    local L, f, m, n, t1, t2
< > =()=
< > =()=    L := [&input, &output, &errout,
< > =()=        m := open("/etc/motd") | stop("no /etc/motd"),
< > =()=        n := open("/dev/null", "w") | stop("no /dev/null")]
<
< file(ls io.i?n io.d?t io.s?d)
< > io.dat
< > io.icn
< > io.std
<
< file(tr aeiou oaeui)
< --- closing output pipe
< unca ipun o medneght draory
< twu ruods devargad en o yalluw wuud
< ond tha muma roths uitgroba
< --- done closing output pipe
---
> no /etc/motd
Testing kross
Testing kwds
22a23
>    &features: event monitoring
24a26
>    &features: multiple programs
Testing large
[...]
Testing nargs
18c18
<   2 display
---
>   3 display
46c46
<   1 name
---
>   2 name
51c51
<   2 proc
---
>   3 proc
82c82
<   1 variable
---
>   3 variable
Testing numeric
[...]
Testing wordcnt

Tests failed:  io kwds nargs

make[2]: *** [Test-programs] Error 1
make[2]: Leaving directory
`/var/tmp/portage/icon-9.4.3-r1/work/icon.v943src/tests/general'
make[1]: *** [Test] Error 2
make[1]: Leaving directory
`/var/tmp/portage/icon-9.4.3-r1/work/icon.v943src/tests'
make: *** [Test] Error 2

In looking through the errors that you just got..

io - is simply missing a /etc/motd file.  Create a /etc/motd and it should be
happy

kwds - the experimental values are what is kicking this out (event monitoring
and multiple programs)

nargs - again because of the above, a couple of the built in functions take
additional parameters.  Nothing that I would be worried about.

possible "solutions" for the last two (kwds/nargs) -- remove the experimental
features -or- I can create modify the ebuild to "correct" the "standard" which
kwds and nargs is looking for.  -- or -- create a note in the ebuild saying
that the three errors are okay.  Personally -- the third option may be the
easiest

As for the optimization problem.  I would simple remove the code in the ebuild
that changes the CFLAGS. -- and leave a note saying to not muck with the CFLAGS
due to sensitivity

Oh -- the reason why kwds is kicking out is that all the kwds test does is list
what features have been included.  Two new features were added -- thus those
are "new"

And the amount of difference for io is a simple "alignment" issue with diff
kicks out a lot of output.

I'm not worried about any of the errors that got kicked out.  Looks like it
passed the tests.

I issued the 9.4.3-r1 that removes src_unpack (and so forces the hardset
CFLAGS) and disables experimental features (with a comment above, that they may
be enabled as needed. I understand from your post that the failures they
produce are not critical, but it would be nice to have some resolution so that
I could enable them again:

(In reply to comment #14)
> io - is simply missing a /etc/motd file.  Create a /etc/motd and it should be
> happy
Unfortunately this is not a good option. We are dealing with  the ebuild, so
this should be automatically taken care off. The only way to do this is to test
the presence of /etc/motd in pkg_setup and create it if absent. However this is
really a hack and not everybody will be happy about some extra file under /etc
for the reason of some failing test. Much better option is to do something to
the test or even selectively disable it..

> kwds - the experimental values are what is kicking this out (event monitoring
..
> nargs - again because of the above, a couple of the built in functions take
..
> possible "solutions" for the last two (kwds/nargs) -- remove the experimental
> features 
This is what I have done for now.

>-or- I can create modify the ebuild to "correct" the "standard" which
> kwds and nargs is looking for.  
This would be ideal.

>-- or -- create a note in the ebuild saying
> that the three errors are okay.  Personally -- the third option may be the
> easiest
Well, the note is not sufficient, because the test failures are causing the
whole build to fail, so we get complaints and bug reports..
In fact, all these tests altogether are more usefull during the ebuild
preparation stage rather then when everybody uses it to install icon. Therefore
I think we can simply remove the src_test function or at least remove || die
after them.. 
I will do just that if we do not come up with another resolution, but if you
would like to keep the tests in the ebuild, it would be good if you could act
on your proposal in the previous option.

George

Okay here it is...

I created a patch file that updates the following files in tests/general

io.icn - change /etc/motd to /etc/gentoo-release 
       - this test is basically looking for any file.  Let me know if this file
         was a "bad" choice
The rest of the changes are to the "standard" output files
io.std - again just change /etc/motd to /etc/gentoo-release
kwds.std - added two new lines for the two new keywords
nargs.std - changed a couple of entries because the functions now have
additional parameters.

Created an attachment (id=83625) [details]
New ebuild that applies patches for the test phase

Here is the ebuild that fixes the problem with running tests

Created an attachment (id=83627) [details]
patch file

patches the tests so that 1) it passes if there is not an /etc/motd file
present and 2) handles the new experimental features that are enabled

(From update of attachment 83627 [details])
ack.. wrong file

Created an attachment (id=83628) [details]
the correct patch file

the correct patch file..

Oh .. one more thing.. if you would like to remove the || die out of the tests
phase that would be okay as well.  As you stated the tests are probably more
important from building and QAing the initial packages then really for when the
packages are installed on the systems belonging to the general masses

Hi Cheyenne.

Thanks for the fixes!
I have committed the -r2, everything seems to be fine now.

Correspondingly, I would like to request stabilization of the
dev-lang/icon-9.4.3-r2, at least on x86 and sparc (again,so I am readding the
sparc alias), as the most stable version and to be able to remove the no longer
working -9.40..

George

x86 stable

Sparc stable (still fails general/table test, but that's an improvement;
everything else seems fine).  I note, though, that for the build it chooses
absolutely horrible CFLAGS {CFLAGS = -O), which sort of optimizes for a
completely obsolete sparc architecture (sparc-v7 == SS2).  Please see
https://bugs.gentoo.org/show_bug.cgi?id=59506

(In reply to comment #25)
> Sparc stable (still fails general/table test, but that's an improvement;

Can you give me the specific test(s) and the outputs that are failing?  The
outputs are in the tests/.../ directory

> everything else seems fine).  I note, though, that for the build it chooses
> absolutely horrible CFLAGS {CFLAGS = -O), which sort of optimizes for a
> completely obsolete sparc architecture (sparc-v7 == SS2).

Understand.. 

However, there have been problems with compiling Icon with some forms of
optimization.  The "problem" is usually related to how Icon implements
coexpressions.  It plays games with the C stack frame and certain optimizations
can break that.  In fact I was just looking at rswitch.c for the Linux Sparc
configuration and there is a warning to not even use CFLAGS = -O

There could be other problems.  I know that when I was doing some of the early
porting work for Icon, I would find all sorts of C compiler bugs.  It got so
bad that I ended up as a beta tester for one compiler manufacture, and I know
of another compiler manufacture that actually used Icon as part of their C
compiler verification suite


You might also may want to try in the src_compile do 

   emake X-Configure name=${mytarget} csw=pthreads -j1 || die

this will configure (hopefully) the coexpression code to use a pthread model
instead of swaping C stack frames around.  The note is that the pthread code is
slower then the the native rswitch code, but is more portable.  (try manually
running the make X-Configure name=linux csw=pthreads -- the output should say
something like:

make Pure >/dev/null
cd config; sh setup.sh linux Graphics custom
   configured linux
   with Graphics
   using pthreads.c

I've added myself to the CC list; if you need anything, catch me next week. 
But sparc is stable, so I'm not sure what you want done.

(In reply to comment #27)
> I've added myself to the CC list; if you need anything, catch me next week. 
> But sparc is stable, so I'm not sure what you want done.
> 

Well.. you were indicating that one of the tests failed, and I was trying to
figure out why.

If the tests ran okay, that I would say that this problem can be closed

The versions issue has been fixed -> closing. Please move failed tests/horrible
CFLAGS and whatever else to a separate bug. Thanks.