Bug 286851 - Review Request: kaya - A Statically typed, imperative programming-language
Review Request: kaya - A Statically typed, imperative programming-language
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-11 16:14 EDT by Jochen Schmitt
Modified: 2008-06-16 13:22 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 13:22:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
Proper patch for fixing build ID issues. (439 bytes, patch)
2007-11-07 14:57 EST, Jason Tibbitts
no flags Details | Diff

  None (edit)
Description Jochen Schmitt 2007-09-11 16:14:41 EDT
Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.2.6-1.fc7.src.rpm

Description:
Kaya is a compiled statically typed (ie, types are checked at compile time)
imperative programming language; unlike other such languages, however, types
are inferred rather than declared - there is no need for type declarations of
local variables. Kaya has "tagged union" data structures, a powerful feature 
more commonly found in functional languages such as Ocaml and Haskell.

Known Issues:
- Rpmlint complaints the *.h files in %{_libdir}/kaya. But they have to be
on this location for proper compilation of kaya programms.
- The package could not build on ppc64, because there is is ghc on this
platform. Please refe to BZ #239713
Comment 1 Jason Tibbitts 2007-09-29 12:10:09 EDT
A couple of comments:

kaya.x86_64: W: invalid-license LGPLv2.1
  The licensing page specifies "LGPLv2" even for 2.1.

The headers are OK, although it would probably be cleaner if they were grouped
together in a subdirectory instead of strewn through /usr/lib/kaya.

Binaries named /usr/bin/rekey and /usr/bin/xml2man seem destined to conflict
with something.  /usr/bin/xml2man is present on macos and some Linux distros but
doesn't actually seem to be in Fedora.  /usr/bin/rekey amazingly doesn't
conflict with anything.  Still, both names are awfully generic for binaries that
are specific to this package.  Is there any reasonable chance of getting them
renamed with a prefix like "kaya-"?
Comment 2 Jochen Schmitt 2007-10-09 10:30:21 EDT
(In reply to comment #1)
 
> kaya.x86_64: W: invalid-license LGPLv2.1
>   The licensing page specifies "LGPLv2" even for 2.1.
> 
> The headers are OK, although it would probably be cleaner if they were grouped
> together in a subdirectory instead of strewn through /usr/lib/kaya.

Done,

> Binaries named /usr/bin/rekey and /usr/bin/xml2man seem destined to conflict
> with something.  /usr/bin/xml2man is present on macos and some Linux distros but
> doesn't actually seem to be in Fedora.  /usr/bin/rekey amazingly doesn't
> conflict with anything.  Still, both names are awfully generic for binaries that
> are specific to this package.  Is there any reasonable chance of getting them
> renamed with a prefix like "kaya-"?

I think, this is a design issue from the upstream and I don't try to make a
rename, because I afraid to confused poeple who try to use the tutorials.

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.2.6-2.fc7.src.rpm

Comment 3 Jochen Schmitt 2007-10-30 12:55:04 EDT
(In reply to comment #2)
> (In reply to comment #1)

> > Binaries named /usr/bin/rekey and /usr/bin/xml2man seem destined to conflict
> > with something.  /usr/bin/xml2man is present on macos and some Linux distros but
> > doesn't actually seem to be in Fedora.  /usr/bin/rekey amazingly doesn't
> > conflict with anything.  Still, both names are awfully generic for binaries that
> > are specific to this package.  Is there any reasonable chance of getting them
> > renamed with a prefix like "kaya-"?

I have talk with the upstream author. xml2man should be renamed into kdoc2man
and rekey into kayarekey.

Because there is a new upstream relase, here the current package downloads:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.2.6-2.fc7.src.rpm


Comment 4 Jason Tibbitts 2007-11-06 12:40:20 EST
Something is very wrong with the SRPM URL:

Connecting to www.herr-schmitt.de|82.165.107.151|:80... connected.
HTTP request sent, awaiting response... 300 Multiple Choices

And the downloaded file is HTML.  Oh, it gives the proper location:

http://www.herr-schmitt.de/pub/kaya/kaya-0.2.7-1.fc7.src.rpm

Unfortunately it fails to build for me:

+ /usr/lib/rpm/find-debuginfo.sh /builddir/build/BUILD/kaya-0.2.7
extracting debug info from
/var/tmp/kaya-0.2.7-1.fc8-root-mockbuild/usr/lib64/kaya/imports/repl_glue.o
*** ERROR: No build ID note found in
/var/tmp/kaya-0.2.7-1.fc8-root-mockbuild/usr/lib64/kaya/imports/repl_glue.o

Unfortunately I have no idea at all what to do now.  The actual build process is
fine, but this build ID stuff makes it fail.
Comment 5 Jochen Schmitt 2007-11-07 13:51:59 EST
Thank you for your response. Unforatunatley due an error from me, you see what
the mod_spelling module of apache may do.

I have fixed the reported issue on the mock build and uploaded the fixed package.

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.2.7-2.fc7.src.rpm

Comment 6 Jason Tibbitts 2007-11-07 14:57:05 EST
Your patch does work, but could you pass the attached patch upstream as a more
proper fix (passed to me by Peter Jones on IRC).
Comment 7 Jason Tibbitts 2007-11-07 14:57:42 EST
Created attachment 250681 [details]
Proper patch for fixing build ID issues.
Comment 8 Jochen Schmitt 2007-11-07 16:10:27 EST
New release:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.2.7-3.fc7.src.rpm

Comment 9 Jason Tibbitts 2007-11-18 18:09:23 EST
Taking another look at this.  rpmlint complains only about
devel-file-in-non-devel-package for all of the .h and .a files in %_libdir/kaya
as you noted.  These should be OK for a compiler.

I note that the debuginfo package doesn't contain anything.  Part of this may be
the fact that the C++ compiler isn't being called with the proper set of options
(specifically no -g) which I'd view as a blocker unless someone can demonstrate
that they break things.  Another factor is that some of this is in Haskell, and
honestly I don't know enough about ghc or Haskell to know if it can compile in
any symbols that could be pulled into debuginfo packages.  I'd like for someone
who understands this to take a closer look before saying that it's OK to disable
the debuginfo package.

Could you document which parts are under GPL and which are under LGPL?  Just a
quick comment in the spec would be helpful.

Otherwise, though, I think this package looks OK.
Comment 10 Chris Morris 2007-11-19 04:44:38 EST
If you want a debug package, then ./configure --enable-debug will make one,
*but* the debug build is unoptimised (-O0 rather than -O2, when compiling the
run-time and standard library) so you lose a lot of performance. With a small
bit of obvious patching of configure.ac you could change this, though.

Also, there isn't a kaya debugger (yet!), and unless you're very familiar with
the language internals, gdb is not great either, so you're really not losing
much by not having debug symbols.
Comment 12 Thomas Moschny 2008-03-11 14:49:08 EDT
On f8/x86_64, the interactive kaya command doesn't work. It fails with:

/usr/bin/ld: /usr/lib64/kaya/imports/Reflect.o: relocation R_X86_64_32 against 
`a local symbol' can not be used when making a shared object; recompile 
with -fPIC
/usr/lib64/kaya/imports/Reflect.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
./__REPLMain.so: cannot open shared object file: No such file or directory

Also, it creates and leaves behind a file (__REPLMain.o) in the current 
working dir, which obviously fails if it can't write to cwd. Should probably 
be changed upstream to use a file under /tmp.

A related question: Is kayac able to emit 32bit executables on a 64bit 
platform (like gcc's -m32 option)?

Comment 13 Jochen Schmitt 2008-04-15 12:31:49 EDT
Meanwhile there is a new upstream release available which should solve the
reported issues.

I have uploa the new SPEC and source RPM at:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.4.0-1.fc8.src.rpm
Comment 14 Jason Tibbitts 2008-04-25 01:40:39 EDT
It took me way too long to get back to this.

A couple of rpmlint complaints which were not mentioned earlier:

  kaya.src: W: patch-not-applied Patch0: kaya-0.2.7-make.patch
This file can probably be removed now, although see below.

  kaya.src: W: strange-permission kaya-0.4.0-64bit-part2.patch 0775
  kaya.src: W: strange-permission kaya-0.4.0-64bit-part1.patch 0775
Not sure why these are executable.  They probably shouldn't be, but I don't
think it makes much difference.

Since the -make.patch isn't being applied, -g isn't getting passed, which
neuters the debuginfo package again.  But of course it doesn't apply at all
currently.  Really, I'm not sure what the point of having a functional debuginfo
package would be; I guess you could debug the portions of the compiler or
libraries which are written in C++, but of course it wouldn't help you with the
parts written in Haskell or Kaya itself.  Maybe it should just be disabled. 
Either way, there's no point in having it in the current state.

Ran out of time tonight; more tomorrow.
Comment 15 Jochen Schmitt 2008-04-27 15:58:38 EDT
Thak you for your comments. I have dicide to supproess the generation of the
debuginfo file, because I thing it's make no sense to generating one.

Updates files are uploaded on:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.4.0-2.fc8.src.rpm

Comment 16 Jochen Schmitt 2008-04-28 13:47:29 EDT
Aufter contacting upstream, I was able to integrate a patch which allow parallel
builds for kaya.

Updates files are uploaded on:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.4.0-3.fc8.src.rpm
Comment 17 Jason Tibbitts 2008-04-28 14:53:16 EDT
Unfortunately that package doesn't build for me; things progress for a while,
and then:

../compiler/kayac Set.k -noprelude -nochase -noenvlibs -I../rts -I./../rts
-nortchecks -L ../rts_opt -L ../rts -xmldocs -L . -L ./../rts -deprfail
../compiler/kayac Lazy.k -noprelude -nochase -noenvlibs -I../rts -I./../rts
-nortchecks -L ../rts_opt -L ../rts -xmldocs -L . -L ./../rts -deprfail
../compiler/kayac Queue.k -noprelude -nochase -noenvlibs -I../rts -I./../rts
-nortchecks -L ../rts_opt -L ../rts -xmldocs -L . -L ./../rts -deprfail
../compiler/kayac Reflect.k -noprelude -nochase -noenvlibs -I../rts -I./../rts
-nortchecks -L ../rts_opt -L ../rts -xmldocs -L . -L ./../rts -deprfail
../compiler/kayac Strings.k -noprelude -nochase -noenvlibs -I../rts -I./../rts
-nortchecks -L ../rts_opt -L ../rts -xmldocs -L . -L ./../rts -deprfail
../compiler/kayac Parse.k -noprelude -nochase -noenvlibs -I../rts -I./../rts
-nortchecks -L ../rts_opt -L ../rts -xmldocs -L . -L ./../rts -deprfail
Parse.k:515:Can't find module Strings
make[1]:
*** [Parse.o] Error 1
make[1]:
*** Waiting for unfinished jobs....

I guess something that needs the Strings module is building before Strings.k
finishes compiling.  I'm building on a 8-core machine; you might not see this
with less parallelism.
Comment 18 Jochen Schmitt 2008-04-28 15:19:23 EDT
I was able to fix your reported issue.

Updates files can be downloaded from:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.4.0-4.fc8.src.rpm

Comment 19 Jason Tibbitts 2008-04-29 16:12:31 EDT
Yes, that does build.  I believ this is very close now; just a few bits left.

First, some compiler flag issues:
Could you explain the CFLAGS bit in %build?  It seems to have no effect.

This package just seems to do its own random stuff with compiler flags, which is
troubling.  It ignores the ones we pass to the configure call, but that can at
least superficially be fixed with this hack at the end of %prep:
  sed -i -e 's/^\(EXTRAGCCOPTS=\).*$/\1"%optflags"/' \
         -e 's/^  EXTRAGCCOPTS.*stack-protector.*/  true/' configure.ac
Things still build with this hack (and the test suite passes) but it seems that
these options get passed through to the compiler itself and that causes a pile
of warnings (and the debuginfo package still comes out empty when enabled, which
strangely, means it has even less data than it would without this hack).

So, if the standard compiler flags don't work, could you document that
somewhere?  Could you also document the need to disable the debuginfo package
instead of just disabling it?  Random hacks like that need some sort of comment
in the specfile.

The documentation is about 60% of the size of the package.  Some basic manpages
are useful but I'm not sure it's worth putting all of the development
documentation in with the main package.  Have you considered splitting it out to
a subpackage?

* source files match upstream:
   1c8a817d6435475793e6d662c96c04d68b894b4602d3e65f25291938e955332e  
   kaya-0.4.0.tgz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
? compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
   kaya = 0.4.0-4.fc9
  =
   libgc.so.1()(64bit)
   libgcc_s.so.1()(64bit)
   libgcc_s.so.1(GCC_3.0)(64bit)
   libgcrypt.so.11()(64bit)
   libgcrypt.so.11(GCRYPT_1.2)(64bit)
   libgmp.so.3()(64bit)
   libncurses.so.5()(64bit)
   libpcre.so.0()(64bit)
   libreadline.so.5()(64bit)
   libstdc++.so.6()(64bit)
   libstdc++.so.6(CXXABI_1.3)(64bit)
   libstdc++.so.6(GLIBCXX_3.4)(64bit)
   libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
   libutil.so.1()(64bit)
   libz.so.1()(64bit)
* %check is present and all tests pass.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
? documentation is pretty large; maybe a separate -doc package would be useful.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.
Comment 20 Jochen Schmitt 2008-05-08 11:35:00 EDT
I have decide to not implement your offer patch, because its produced strange
warning if you are starting kaya in the interactive mode.

I have found another issue which I have reported to the upstream at

http://lists.kayalang.org/archives/kaya-devel/2008-May/000499.html

I may be interested on your mind about it.

Best Regards:

Jochen Schmitt


Updates files can be downloaded from:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.4.0-5.fc8.src.rpm

Comment 21 Jochen Schmitt 2008-05-26 13:58:44 EDT
Updates files can be downloaded from:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.5.0-1.fc8.src.rpm

Comment 22 Jason Tibbitts 2008-05-29 12:28:28 EDT
Thanks for splitting out the -doc package.  I am inclined to neglect the
compiler flags bit because of the difficulties involved, but I note that these
have cropped up with the latest package:
  kaya.x86_64: W: unstripped-binary-or-object /usr/bin/kayac
  kaya.x86_64: W: unstripped-binary-or-object /usr/bin/kaya-rekey
  kaya.x86_64: W: unstripped-binary-or-object /usr/bin/kayadoc2man
Indeed, these files contain plenty that would normally be stripped out if the
debuginfo package wasn't disabled.  I'm not sure how to best handle this other
than to just manually strip those binaries, but perhaps you know why this has
only recently started happening.
Comment 23 Jochen Schmitt 2008-05-29 12:59:39 EDT
Thank you for your feedback. I was aber to fix the reported issue.

Updates files can be downloaded from:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.5.0-2.fc8.src.rpm

Comment 24 Jason Tibbitts 2008-05-29 15:43:15 EDT
Odd; this one fails to build for me.  Parallel make makes the output a bit
confusing, but I think this is it:

mock.Root.build: ../compiler/kayac Threads.k -noprelude -nortchecks -nochase
-noenvlibs -I../rts -I../posix  -L ../
rts -L ../stdlib  -L../posix -xmldocs -L ./../rts -L . -deprfail
mock.Root.build: ../compiler/kayac Multicore.k -noprelude -nortchecks -nochase
-noenvlibs -I../rts -I../posix  -L .
./rts -L ../stdlib  -L../posix -xmldocs -L ./../rts -L . -deprfail
mock.Root.build: Threads.ki:1:Expected binding - before:  ...
mock.Root.build: make[1]:
mock.Root.build: *** [Multicore.o] Error 1
Comment 25 Jason Tibbitts 2008-05-29 16:40:42 EDT
And when I disabled parallel make, things built OK, and I just tried to rebuild
your -2 RPM again and it built OK.  I ran it twice more and it built then as
well, so I'm not sure what's up.  Maybe it was something odd with my build
machine, although it is usually quite reliable.  BTW, if you're going to leave
parallel make in, you might want to remove the comment about parallel make not
being supported. 

Also, I note that since I just updated my rawhide mirror, I see the following
additional rpmlint complaints:
  kaya.src:89: E: files-attr-not-set
  kaya.src:90: E: files-attr-not-set
which are trivially fixed by adding a %defattr line to the -doc package's %files
section.

Anyway, the above is an easy fix when you check in, and I'm inclined to dismiss
the above failure as something related to my build environment, so I have no
more complaints.

APPROVED
Comment 26 Chris Morris 2008-05-29 17:12:12 EDT
> mock.Root.build: Threads.ki:1:Expected binding - before:  ...
> mock.Root.build: make[1]:
> mock.Root.build: *** [Multicore.o] Error 1

Apologies, that's a bug from us upstream: there's a dependency missing that only
seems to be caught with parallel make (I suspect you have access to much broader
multicore machines than we do). This patch should fix it.

Thanks

diff -rN -u old-kaya/libs/Makefile.in new-kaya/libs/Makefile.in
--- old-kaya/libs/Makefile.in   2008-05-29 21:50:16.000000000 +0100
+++ new-kaya/libs/Makefile.in   2008-05-29 21:50:18.000000000 +0100
@@ -41,6 +41,8 @@
        rm -f *~ Makefile
        rm -rf autom4te.cache
 
+Multicore.o: Threads.ki
+Threads.o: thread_glue.h
 MyDB.o: my_inter.h ../stdlib/DB.ki
 PostgresDB.o: pg_inter.h ../stdlib/DB.ki
 SQLiteDB.o: sqlite_inter.h ../stdlib/DB.ki
Comment 27 Jason Tibbitts 2008-05-29 22:05:38 EDT
My builder has eight cores and the entire build happens in a chroot built in a
ramdisk, which I guess is a pretty tough test of parallelism.  Even then I
couldn't make it happen reliably.  I doubt this problem will even show up in the
distro's builders, but of course if the above patch fixes it then it would be
good to apply it until it gets into an upstream release.
Comment 28 Jochen Schmitt 2008-06-01 13:56:48 EDT
Updates files can be downloaded from:

Spec URL: http://www.herr-schmitt.de/pub/kaya/kaya.spec
SRPM URL: http://www.herr-schmitt.de/pub/kaya/kaya-0.5.0-3.fc8.src.rpm

Comment 29 Jason Tibbitts 2008-06-05 12:54:06 EDT
This package has already been approved; you can make your CVS request whenever
you like.  But I did build the -3 package and unfortunately it failed its tests:

Differences in test048:
1a2,5
> Test 1 (Sets) success
> Test 2 (Hash Sets) success
>
> All tests pass

so you'll have to deal with that before you can build.
Comment 30 Jochen Schmitt 2008-06-05 14:58:03 EDT
New Package CVS Request
=======================
Package Name: kaya
Short Description: A Statically typed, imperative programming-language
Owners:s4504kr
Branches: F-9 F-8
InitialCC:
Cvsextras Commits: yes
Comment 31 Kevin Fenzi 2008-06-06 11:37:45 EDT
cvs done.
Comment 32 Jochen Schmitt 2008-06-16 13:22:11 EDT
imported and built

Note You need to log in before you can comment on or make changes to this bug.