Bug 523715

Just some comments after a quick look at your spec file:

- You should a disttag to 'Release'  -> Release: 1%{?dist}
  https://fedoraproject.org/wiki/How_to_create_an_RPM_package#Spec_file_pieces_explained 

- The license is GPLv2+. The source header says 'or (at your option) any later version.'

- Source0 should point to the upstream location of the source tarball
  https://fedoraproject.org/wiki/Packaging/SourceURL

- About the Buildroot : https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag

- Is there a reason why you don't use 'make %{?_smp_mflags}'
  https://fedoraproject.org/wiki/Packaging:Guidelines#Parallel_make

- You must use macros in the %file section
  https://fedoraproject.org/wiki/How_to_create_an_RPM_package#Macros

- '%defattr(-,root,root)' should be '%defattr(-,root,root,-)'

- Preserve the Timestamps when possible in the install section

Please reread the Fedora Packaging Guidelines (https://fedoraproject.org/wiki/Packaging:Guidelines) for more details.

By accident, I placed a template, not a spec file at
http://logiweb.eu/0.2/0.2.2/download/rpmspec
Sorry.

Now
http://logiweb.eu/0.2/0.2.2/download/rpmspec
contains the real spec file.

I will update according to #1 as soon as possible.

Thanks to Fabian Affolter for comment #1. I have updated the package accordingly. The new version is here:

Spec URL: http://logiweb.eu/0.2/0.2.3/download/logiweb.spec
SRPM URL: http://logiweb.eu/0.2/0.2.3/download/logiweb-0.2.3-1.fc11.src.rpm

HTML URL: http://logiweb.eu/0.2/0.2.3/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/0.2/0.2.3/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/0.2/0.2.3/download/rpm.html

> Please reread ... https://fedoraproject.org/wiki/Packaging:Guidelines ...

Thanks for the pointer. That version is clearer than any version I have read.

It took a while to do everything stated in the guidelines. I hope I did it right.

I was in doubt whether or not the build system transferred %{optflags} to CFLAGS automatically. So in %build I wrote

  make %{?_smp_mflags} CFLAGS="%{optflags}"

I hope that is the right way to do it.

Section 1.4 of https://fedoraproject.org/wiki/Packaging:Guidelines says:

> No inclusion of pre-built binaries or libraries
> ...
> Exceptions
> * Some software (usually related to compilers or cross-compiler
> environments) cannot be built without the use of a previous
> toolchain or development environment (open source). If you have
> a package which meets this criteria, contact the Fedora Packaging
> Committee for approval.

The exception above exactly fits the logiweb package. The logiweb package contains a file named src/pages.c which is a binary file sent through 'xxd -i'. The binary file is the lgc-compiler compiled by the lgc-compiler. The 'previous toolchain' is Logiweb version 0.1 which is implemented in clisp.

Shall I contact the Fedora Packaging Committee at this point or is that too early?

Well, I have not checked how this package needs bootstrap (because
this package does not build, see below), if this package needs it
would you post a mail on fedora-packaging mailing list?

By the way even koji (which is the buildsystem we are using on Fedora)
cannot build this package due to memory shortage:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1742489
cc1: out of memory allocating 524284 bytes after a total of 1577832448 bytes

And I cannot try to build this package either because my system
does not have such large memory....

> even koji...cannot build this package due to memory shortage:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1742489
> cc1: out of memory allocating 524284 bytes after a total of 1577832448 bytes

I am new to the terminology, sorry. Does this mean that building from the source package causes a memory overflow? Is it correct that 'cc1: out of memory' comes from the C compiler?

I tried following http://koji.fedoraproject.org/koji/taskinfo?taskID=1742489, but it says: Result: BuildError: error building package (arch i686), mock exited with status 1; see build.log for more information. I tried looking for build.log but could not find it, so I am guessing:

The only thing that requires resources when building from source is compilation of lgwam.c. That, however, may take resources and even kills some versions of gcc (c.f. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448).

If the problem is connected to compilation of lgwam.c, I will make a new release which solves the problem.

After building, running the program requires a machine with 2GB. I hope that is not a problem.

(In reply to comment #5)
> > even koji...cannot build this package due to memory shortage:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1742489
> > cc1: out of memory allocating 524284 bytes after a total of 1577832448 bytes
> 
> I am new to the terminology, sorry. Does this mean that building from the
> source package causes a memory overflow? Is it correct that 'cc1: out of
> memory' comes from the C compiler?

This means that koji build server got out of memory when compiling
lgwam.c (in other words, koji build server does not have enough
memory to compile lgwam.c)

> After building, running the program requires a machine with 2GB. I hope that is
> not a problem.  

Umm... then I cannot review this ticket (my machine does not have such
large memory), I hope that some other reviewers have such machine.

Now I have made a new version which does not provoke
gcc bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
and which compiles on a 64-bit machine with 1GB RAM.

I hope that allows to build on koji.

The new version is here:

Spec URL: http://logiweb.eu/1.0/doc/download/logiweb.spec
SRPM URL: http://logiweb.eu/1.0/doc/download/logiweb-0.2.5-1.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

Version 0.2.6 is out. The new version is here:

Spec URL: http://logiweb.eu/1.0/doc/download/logiweb.spec
SRPM URL: http://logiweb.eu/1.0/doc/download/logiweb-0.2.6-1.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

Furthermore, Version 0.1.10 is out. Version 0.1.10 is here:
HTML URL: http://logiweb.eu/0.1/index.html
Tar ball: http://logiweb.eu/0.1/logiweb-0.1.10.tar.gz

Version 0.2.6 contains the lgc compiler expressed in the compilers own language. Version 0.1.10 contains the lgc compiler expressed in CLISP. Thus, Version 0.1.10 can be used for bootstrapping.

Version 0.1.10 addresses the issue in
https://fedoraproject.org/wiki/Packaging:Guidelines
Section 1.4: No inclusion of pre-built binaries or libraries
Section 1.4.1: Exceptions

Umm... I don't know if we can say src/pages.c is actually a
source code... It seems it is very hard to modify this file manually.
If this file generated by some other program or so?

> Umm... I don't know if we can say src/pages.c is
> actually a source code... It seems it is very hard
> to modify this file manually.

src/pages.c is not source code. It is compiled code
which has been run through xxd so it is, in effect,
a pre-built binary. That is not allowable according
to https://fedoraproject.org/wiki/Packaging:Guidelines :
Section 1.4: No inclusion of pre-built binaries or libraries
was it not for the exceptions in Section 1.4.1.

> If this file generated by some other program or so?

Yes.
pages.c of Logiweb-0.2.6 is generated by Logiweb-0.2.5
pages.c of Logiweb-0.2.5 is generated by Logiweb-0.2.4
pages.c of Logiweb-0.2.4 is generated by Logiweb-0.2.3
and so on.

However, generating pages.c of Logiweb-0.2.6 by
compiling and installing all previous versions of
Logiweb one by one could be tedious. For that reason,
I have made a backport in the form of Logiweb-0.1.10.
Logiweb-0.1.10 contains no pre-built binaries. It can
be compiled using the open source CLISP system.

pages.c of Logiweb-0.2.6 can be generated by Logiweb-0.1.10.

Finally, pages.c of Logiweb-0.2.6 can be generated by
Logiweb-0.2.6 itself. The versions of pages.c generated
by Logiweb-0.1.10, Logiweb-0.2.5, and Logiweb-0.2.6
are byte identical.

The problem here is that the Logiweb compiler lgc is
written in the Logiweb programming language lgs. So one
needs a Logiweb compiler in order to compile the
Logiweb compiler.

The gcc compiler has the same problem: gcc is written in C.
To compile gcc, one needs a C-compiler. Typically, gcc
is compiled using the previous version of gcc.

Now, what is src/pages.c? That is quite simple. It is
a compiled version of the Logiweb compiler version 0.2.6.
That compiled version is able to run on the Logiweb abstract
machine (lgwam) and it is able to compile itself.

So why can Logiweb-0.2.6 claim to be open source? Well,
my claim is that since Logiweb-0.1.10 is open source
and can be compiled by the open source CLISP system and is
able to generate pages.c of Logiweb-0.2.6, then Logiweb-0.2.6
is open source. I think that is what is covered by
Section 1.4.1 of https://fedoraproject.org/wiki/Packaging:Guidelines

So it means that compiling logiweb needs bootstrapping?

If so, please do bootstrap during rpmbuild. When you enable
bootstrap in the spec file, I can ask spot if your method
is acceptable on Fedora. By the way at least gcc/mono (and perhaps also
ghc) does bootstrap during rpmbuild.

> So it means that compiling logiweb needs bootstrapping?

Yes. Here is the procedure for bootstrapping:

mkdir ~/foo
cd ~/foo
Download logiweb-0.1.10.tar.gz
tar zxf logiweb-0.1.10.tar.gz
cd logiweb-0.1.10/
make build

The 'make build' target first compiles the lgc compiler using
CLISP and then makes the lgc compiler compile itself.
Furthermore, 'make build' generates a complete Version 0.2.6
with changelogs and everything. The result of 'make build'
is in ~/foo/logiweb-0.1.10/lgc/build/self. 'make build' takes
15 minutes on my 3GHz machine. Ignore the
  diff: ../lgc: No such file or directory
error message at the end of 'make build'. Running 'make build'
includes running a testsuite. Running that testsuite could
be omitted, reducing the run time to about 10 minutes.

Here is the procedure for verifying that Version 0.2.6 is
what it claims to be:

cd ~/foo
Download logiweb-0.2.6.tar.gz
tar zxf logiweb-0.2.6.tar.gz
diff -r logiweb-0.1.10/lgc/build/self/ logiweb-0.2.6/

The output from diff shall be empty.

> If so, please do bootstrap during rpmbuild.

Does that mean that you prefer rpmbuild to run 'make build'
of logiweb-0.1.10 instead of the present solution which
uses a pre-built pages.c ?

I made Logiweb-0.2.x to become independent of CLISP so that
it became easier to port Logiweb to other platforms. And it
was my hope that the procedure above for verifying that
Version 0.2.6 is what it claims to be would allow to
include the pre-built pages.c in the source RPM rather than
including the whole collection of CLISP sources.

But it is of course not up to me to decide what Fedora prefers.
If you want, I can make a new version in which CLISP is included
in the build requirements and in which the source RPM contains
no pre-built binaries like pages.c.

> When you enable bootstrap in the spec file, I can ask spot
> if your method is acceptable on Fedora.

Thanks. Just to be sure, is it correct that
spot=Tom 'spot' Callaway or is spot some Fedora committee?

Once setting FE-Regal to ask spot how to package this software.
spot, would you comment on this?

Given that the components necessary to generate the pages.c code from the CLISP source are available in Fedora, I would say that this package doesn't qualify for the bootstrapping exception, and that the CLISP should be included and binaries like pages.c generated from source.

I apologize for the inconvenience here. We have traditionally only permitted the bootstrapping exception in cases where a package is dependent on pre-built binaries to get an initial build done, but future builds are generated from pure source. In this case, without the CLISP binaries, every build would be dependent on pre-built binaries.

Lifting FE-Legal, but please be sure to include and use the CLISP sources before approving/importing.

Version 0.2.7 is out. The new version is here:

Spec URL: http://logiweb.eu/1.0/doc/download/logiweb.spec
SRPM URL: http://logiweb.eu/1.0/doc/download/logiweb-0.2.7-1.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html



> I apologize for the inconvenience here.

No problem. Including CLISP sources could end up being very convenient anyway.

Version 0.2.7 builds from source using CLISP as required.

The package still includes pages.c, but if one deletes pages.c, then
the make files regenerate pages.c from source using CLISP.

%build in rpmspec deletes pages.c and then invokes make. Thus, %build
builds from source using CLISP as required.

Well, would you examine this build failure?

http://koji.fedoraproject.org/koji/taskinfo?taskID=1966660

I am sorry my package gives rise so many problems.

The problem seems to be:

The current CLISP (the one used by Fedora) dies if stdout is redirected.

Koji obviously redirects stdout (e.g. to produce build.log).

I do not redirect stdout, so I did no notice the problem.

I will now search for a solution so that the build process survives redirection.

Version 0.2.8 is out. The new version is here:

Spec URL: http://logiweb.eu/1.0/doc/download/logiweb.spec
SRPM URL: http://logiweb.eu/1.0/doc/download/logiweb-0.2.8-1.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

Now the build process survives redirection of stdout.

Hopefully, that prevents this build failure:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1966660

Well, this time build fails with the reason I don't know...
Would you debug again?

http://koji.fedoraproject.org/koji/taskinfo?taskID=1980267

OK. Unfortunately, the "Program stack overflow" error is one I have seen often. It is one of the reasons I wanted to get rid of CLISP. The countermeasure to the program stack overflow is to allocate more stack without exhausting the memory of the computer and to ensure that the shell does not limit stacksize (ulimit -s unlimited in bash). I will try to guess why the stack overflow occurs despite the measures in the makefiles and make a new version. Once again sorry for the inconvenience.

In all likelihood, the problem with
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1980267
is that bash stack size is limited.

The only way I have managed to provoke a "Program stack overflow" is to issue
  ulimit -s 10000
and then build the RPM. That makes my build fail at the same step as the Koji build above.

"ulimit -s 100000" works. I use "ulimit -s unlimited".

Forget Comment 20 where I spoke about allocating more stack. The makefiles allocate plenty Lisp stack, which is unrelated to the program stack problem.

All this happens to be in line with CLISP documentation:
http://clisp.cons.org/impnotes/faq.html#faq-stack

Googling for koji and ulimit I found no more than
http://koji.rutgers.edu/koji/buildinfo?buildID=1671

---

Now I have two questions:

Do you happen to know if koji limits the bash stack size
(i.e. the number printed by "ulimit -s").

If yes, do you know a way that I can increase the bash stack size under Koji?

Well, explicitly calling $ ulimit -s unlimited makes build
proceed a bit longer:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1992518

This time observes a different build failure. Would you look
into this?
By the way it seems "Requires: texlive-latex, dvipdfm" should be
"BuildRequires".

> Well, explicitly calling $ ulimit -s unlimited makes build
> proceed a bit longer:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1992518

Thanks.

I can include a 'ulimit -s unlimited' in the makefile. That
may fail if stack is limited because as far as I know,
bash can only reduce stack size. But at least a build error
from ulimit will tell what was wrong.

> This time observes a different build failure. Would you look
> into this?

Yes. I will produce a new package which BuildRequires vim-common
to get xxd (VIM is a rather large system to BuildRequire just to
get the small xxd program, but VIM seems to be the place to get
xxd. This is in line with Cygwin build requirements, by the way).

> By the way it seems "Requires: texlive-latex, dvipdfm" should be
> "BuildRequires".

You are right. texlive-latex and dvipdfm are not *needed*, but
BuildRequiring them would avoid lots of warnings.

Thanks for the help.

Version 0.2.8-2 is out. The new version is here:

Spec URL: http://logiweb.eu/1.0/doc/download/logiweb.spec
SRPM URL: http://logiweb.eu/1.0/doc/download/logiweb-0.2.8-2.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

Now the build process does 'ulimit -s unlimited' and
BuildRequires vim-common, texlive-latex, and dvipdfm.

Hopefully, that prevents these build failures:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1980267 ulimit problem
http://koji.fedoraproject.org/koji/taskinfo?taskID=1992518 BuildRequires problem

Well, I cannot see where ulimit -s unlimited is called:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1995766

By the way when I explicitly call ulimit -s unlimited, build
dies on another point.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1995837

> Well, I cannot see where ulimit -s unlimited is called:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1995766

Sorry. I can see I made a mistake when building the package.
I will build it again.

> By the way when I explicitly call ulimit -s unlimited, build
> dies on another point.
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1995837

The
  lgwam: Heap too small, goodbye.
message indicates that the lgwam abstract machine has malloced
more than 90 percent of the physical RAM of the machine. When
that happens, lgwam gives up since otherwise lgwam would malloc
virtual memory and the moment lgwam mallocs virtual memory, it
will make the host machine start trashing.

lgwam uses sysinfo to find out how much physical RAM the machine
has.

My guess would be that either the host machine has less than
2 gigabyte physical RAM or that sysinfo returns a wrong RAM size.

In any case, I will repackage so that ulimit is included
properly.

Version 0.2.8-3 is out. The new version is here:

Spec URL: http://logiweb.eu/1.0/doc/download/logiweb.spec
SRPM URL: http://logiweb.eu/1.0/doc/download/logiweb-0.2.8-3.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

Version 0.2.8-3 is a temporary version which prints debugging
information at each garbage collection.

Furthermore, the build error I made when compiling 0.2.8-2 should
be corrected so that ulimit is called.

Hopefully, that prevents this build failure:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1980267 ulimit problem

Furthermore, it may narrow down the cause of 
http://koji.fedoraproject.org/koji/taskinfo?taskID=1995837 Heap too small

Scratch build result here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1999525

> Scratch build result here:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1999525

Thanks. That reveals a bug in my computation of memory size.
I have only tested on machines where sysinfo counts memory
in bytes. Sorry. I will correct the bug now.

Version 0.2.8-4 is out. The new version is here:

Spec URL: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb.spec
SRPM URL: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb-0.2.8-4.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

Version 0.2.8-4 is a temporary version which prints debugging
information at each garbage collection.

Computation of amount of physical RAM has been corrected.

'Heap too small, goodbye' error message has been changed to
'Ran out of physical RAM, giving up'.

Hopefully, that prevents this build failure:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1995837

This time:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2001323

Once again sorry the package does not just build smoothly.

I will look into this problem. I noticed one thing, however, in
http://koji.fedoraproject.org/koji/taskinfo?taskID=2001323

> In bytes:
> info.totalram      2044669
> info.mem_unit      4096
> In cells:
> info.totalram      170389
> info.mem_unit      4096

Since 2044669/170389=12 it means that type 'cell' in lgwam.c
is 12 bytes. A 'cell' consists of three pointers, so one
pointer is 4 bytes or 32 bits which is bad when the computer
has 8 gigabyte.

For pointers I do not use 'real' pointers. Rather, I use
uintptr_t from stdint.h, where a uintptr_t is the type of
an unsigned integer large enough to hold a pointer.

So the problem could be in stdint.h.

I will make a new version which makes a sanity check on
uintptr_t.

Version 0.2.8-5 is out. The new version is here:

Spec URL: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb.spec
SRPM URL:
http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb-0.2.8-5.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

0.2.8-5 prints some extra debug information (sizes of various
pointer and integer types). Furthermore, all debug output now goes
to stderr.

I have two questions:

---

In the build logs pointed to by
http://koji.fedoraproject.org/koji/taskinfo?taskID=1995837
when a command is executed, the output to stderr is printed
before the output to stdout.

Furthermore, when the Segmentation fault occurs, stdout
is discarded. That makes it difficult to see exactly when
the fault occurs.

The behaviour to print stderr and stdout separately seems
to be mock behaviour. At least I see the same behaviour
when I use mock to build the package in a clean chroot.

Do you happen to know a way to tell mock to put stdout
directly into the build log so that one can see what happens
up to the Segfault? Otherwise I will just try to find
a work-around.

---

Another question:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1995837
points to
  buildArch (logiweb-0.2.8-4.fc11.src.rpm, x86_64)
and
  buildArch (logiweb-0.2.8-4.fc11.src.rpm, i686)
where the latter dies on a Segmentation fault and the former
seems to be killed by a Sigint.

Does the Sigint come from a manual ctrl-C to cancel the x86_64
build or is it something I should look into?

This time:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2003115

(In reply to comment #33)
> Do you happen to know a way to tell mock to put stdout
> directly into the build log so that one can see what happens
> up to the Segfault? 

I really don't know ....
 
> Does the Sigint come from a manual ctrl-C to cancel the x86_64
> build or is it something I should look into?    

When build fails in one architecture, build processes on other
architectures are actumatically killed if they are still in
progress so you don't have to look into.

Unfortunately (for me) stdint.h seems perfectly sound.

So here is yet another try. Sorry.

I have directed output to stderr and increased verbosity in the
hope that the cause of the segfault will show up in the build log.



Spec URL: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb.spec
SRPM URL:
http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb-0.2.8-6.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

Hi, this time:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2005834

> Hi, this time:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2005834

The build log is bad news. Contrary to the issues that have
been solved thanks to your help, this bug may be difficult to
locate. So I need to reproduce the bug on my own machine.

Could I ask you for one more favour: to try to build for x86_64
without building for i686? It would be a great help to know if
the problem is related to the i686 build.

Using mock, I have built the following on my fc11 machine:
  fc11/x86_64
  fc11/i586
  fc12/x86_64
  fc12/i686
Unfortunately, they all build without errors, so I have not
managed to reproduce the bug that way.

My fc11 has no mock config file for fc11/i686, so I have not
tried that.

From http://fedoraproject.org/wiki/Features/F12X86Support it
looks as if fc11 supports i586 and fc12 supports i686.

But http://koji.fedoraproject.org/koji/taskinfo?taskID=2005834
points to these architectures:
    * buildArch (logiweb-0.2.8-6.fc11.src.rpm, x86_64) (canceled)
    * buildArch (logiweb-0.2.8-6.fc11.src.rpm, i686)   (failed)
So it seems that one can build for i686 on fc11 somehow.

Do you happen to know where to get a fc11/i686 mock config file?

Well, there is no f11/i686 mock config file.

Now I tried to use --override option to koji so as to once complete
x86_64 build, and actually it seems that x86_64 builds are all
successful on F-11/12/13:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2011696
http://koji.fedoraproject.org/koji/taskinfo?taskID=2011721
http://koji.fedoraproject.org/koji/taskinfo?taskID=2011765

However i586/i686 build fails on F-11/12/13:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2011719
http://koji.fedoraproject.org/koji/taskinfo?taskID=2011767
http://koji.fedoraproject.org/koji/taskinfo?taskID=2011813

Note that as listed on
http://koji.fedoraproject.org/koji/hosts
we builds i586/i686 rpms on 64 bits machine, which may be related
to this issue????

> ... it seems that x86_64 builds are all successful on F-11/12/13
> ... However i586/i686 build fails on F-11/12/13:

Great! That narrows down the problem.

> Note that as listed on
> http://koji.fedoraproject.org/koji/hosts
> we builds i586/i686 rpms on 64 bits machine, which may be related
> to this issue????

Probably. But I suppose Koji builds i586/i686 rpms on 64 bit machines
every day without problems, so there must be more to it. My build
does massive amounts of malloc/free. Since the koji hosts have 8GB I
wonder if malloc would allocate memory in the upper half of the 8GB
and truncate the address to 32 bit or something like that. Or my
program could do something equivalent.

Like Koji, I also build i586/i686 on a 64 bit machine, but my machine
has 4GB.

I will now try to build i586/i686 rpms using mock on an 8GB F-11, and
also try to install a Koji server to see if I can reproduce the problem
that way.

For information: Now I have reproduced the 32 bit build problem
using mock on an 8 gigabyte x86_64 machine. I have not been able
to reproduce the problem on a 4 gigabyte x86_64 machine. I now
continue searching for the cause.

Version 0.2.8-7 is out. The new version is here:

Spec: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb.spec
SRPM: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb-0.2.8-7.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

The new version seems to solve the i586/i686 build problem.

It seems the problem was painfully trivial: I just had to add
'ulimit -s unlimited' two more places in the makefiles.

I have used printf to confirm that the stack was close to overflow
right before the segfault. The connection to architecture and
amount of RAM seems to have been accidental.

In an attempt to avoid repetition, the main makefile of the system
now has an rpmtest4 target which builds i586/i686 using mock
(rpmtest1 runs lint on the x86_64 rpm, rpmtest2 runs lint on source
rpm, and rpmtest3 builds x86_64 using mock).

Okay, now it seems that your latest srpm builds on F-12/13/14 i{5,6}86/x86_64.

Now before proceeding review process:
* Build issue
  - On F-12 clisp is not available on ppc64
  - On F-12 build fails on ppc:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=2049176
    Is logiweb supposed to support ppc?

* src/boot/lgc/fingerprint.lisp
  - This is actually text file, however it does not seem to be
    a "source code". Can this file be regenerated during build
    process?

> Okay, now it seems that your latest srpm builds on F-12/13/14 i{5,6}86/x86_64.

Great. Thanks for your help !

> Now before proceeding review process:
> * Build issue
>   - On F-12 clisp is not available on ppc64
>   - On F-12 build fails on ppc:...
>     Is logiweb supposed to support ppc?

It may be overkill to support ppc at this point. But I will take a look
at the ppc build anyway since, as an ideal, Logiweb should build anywhere
and programs compiled by the Logiweb compiler should run anywhere
(compile once, run anywhere, like Java). The build issue looks like yet
another ulimit issue. I will try to see if I can set ulimit globally.

> * src/boot/lgc/fingerprint.lisp
>   - This is actually text file, however it does not seem to be
>     a "source code". Can this file be regenerated during build
>     process?

OK. I will eliminate the need for fingerprint.lisp. Regenerating it would
take ages. I need a few days for eliminating fingerprint.lisp.

Version 0.2.8-8 is out. The new version is here:

Spec: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb.spec
SRPM: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb-0.2.8-8.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

fingerprint.lisp is now an empty file. When fingerprint.lisp is empty,
the system uses reasonable defaults.

'ulimit -s unlimited' is now stated once and for all in %build in rpmspec.
It seems that subshells inherit 'ulimit -s unlimited' as intended.
ulimit has been removed from individual makefiles.

> On F-12 build fails on ppc...
> Is logiweb supposed to support ppc?

It would be nice to know if the build succeeds now, but I think ppc
should remain unsupported for now since I do not have access to ppc
hardware for debugging.

Okay, now 0.2.8-2 compiles at least on
- F-13 i686/x86_64
- F-12 i686/x86_64/ppc
- F-11 i586/x86_64/ppc

Some notes:

* ExclusiveArch
  - As currently clisp is not available on ppc64, you
    should add
-----------------------------------------------------------------
ExclusiveArch: %{ix86} x86_64 ppc
-----------------------------------------------------------------
    or
-----------------------------------------------------------------
ExcludeArch:  ppc64
-----------------------------------------------------------------
    ! The latter form does not exclude s390, sparc or so.
      The former form limits the supported architecure to
      %{ix86} x86_64 and ppc.

? src/lgc
  - Well, what does the "string" on line 3 mean? Is this an arbitrary
    string or is this string generated by some other process?
  ! This string seem to appear on
    * ./src/lgc
    * ./src/lgc.lgs
    * ./src/boot/lgc/lgc.lgs
  - Some other files (like ./src/testsuite/auto/autobase1.lgs or so)
    also has some seemingly-random string. Would you explain how
    these strings are generated?

? Requires
  - I don't know this software well, however is "texlive-latex, dvipdfm"
    needed for "Requires"? (from your comment 23, these don't seem
    to be needed for Requires)

! rpmlint
------------------------------------------------------------------------
logiweb.i686: W: spurious-executable-perm /usr/share/doc/logiweb/examples/compile.sh
logiweb.i686: W: doc-file-dependency /usr/share/doc/logiweb/examples/compile.sh /bin/bash
------------------------------------------------------------------------
  - rpmbuild automatically checks shebang related dependency for installed
    files when the files have executable permission.
    For this package as compile.sh has executable permission its shebang dependency
    "/bin/bash" is automatically added to the rebuilt binary, which is perhaps
    not needed.

    You can supress these warnings by removing executable permission from compile.sh
    (i.e. chmod to 0644)

* Directory ownership issue
  https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership
  https://fedoraproject.org/wiki/Packaging/UnownedDirectories#Common_Mistakes
  - Currently the following directories themselves are not owned
    by any packages.
----------------------------------------------------------------
%{_docdir}/%{name}/
----------------------------------------------------------------

> Okay, now 0.2.8-2 compiles at least on ...
> - F-13 i686/x86_64
> - F-12 i686/x86_64/ppc
> - F-11 i586/x86_64/ppc

Great. Thanks!

> ExclusiveArch: %{ix86} x86_64 ppc
>     or
> ExcludeArch:  ppc64

I will think about this. I fear I would be unable to respond
to a bug report against one of the other architectures, but
I will see if I can dig up hardware or something. In any case,
I shall include an ExcludeArch statement.

> ? src/lgc
>   - Well, what does the "string" on line 3 mean? Is this an arbitrary
>     string or is this string generated by some other process?

Sorry for the giving a long response:

It is a RIPEMD-160 global hash key. The "MD" in "RIPEMD" is the same
as the "MD" in "MD5". The purpose of RIPEMD-160 is the same as the
purpose of MD5. RIPEMD-160 is just *much* safer:

   @inproceedings{ripemd,
       author    = {Hans Dobbertin and Antoon Bosselaers and Bart Preneel},
       title     = {{RIPEMD}-160: A Strengthened Version of {RIPEMD}},
       booktitle = {Fast Software Encryption},
       pages     = {71-82},
       year      = {1996}}

Or, more precisely, the string is a "Logiweb reference" which
comprises a one byte version number, a 20 byte RIPEMD-160 key,
and a timestamp of around 9 bytes. There is something on the
structure of such references at 
http://logiweb.eu/1.0/doc/lgs/syntax/vectorize/reference.html

When the Logiweb abstract machine (lgwam) executes a program
(such as src/lgc and /usr/bin/lgc), it uses the Logiweb
reference to look up the real bytes of the program. Lgwam may
find those bytes inside itself (compiled in via pages.c) or
other places like $HOME/.logiweb/REF/rack.lgr where REF
is the Logiweb reference.

Even though the present lgwam does not implement it, the
system has the ability to fetch the real bytes of a program
from an untrusted repository across an untrusted network
like the Internet, in which case the RIPEMD-160 hash key
can be used for verifying that no-one has tampered with the
bytes. For more on that, see:
http://logiweb.eu/1.0/doc/man/man1/lgc.1.html
http://logiweb.eu/1.0/doc/lgs/syntax/vectorize/authenticity.html
http://logiweb.eu/1.0/doc/compare/java.html

The present version of Logiweb does use the reference for
other kinds of authentication. As an example, if a
mathematician references a theorem in an untrusted repository
across an untrusted network, the system will fetch the
theorem and verify that it is the right theorem using
RIPEMD-160.

>  ! This string seem to appear on
>    * ./src/lgc
>    * ./src/lgc.lgs
>    * ./src/boot/lgc/lgc.lgs
>  - Some other files (like ./src/testsuite/auto/autobase1.lgs or so)
>    also has some seemingly-random string. Would you explain how
>    these strings are generated?

The header in the *.lgs files are also Logiweb references. One can
ask lgc to write the reference of a page back to the source file c.f. 
http://logiweb.eu/1.0/doc/intro/header.html

> ? Requires
> - I don't know this software well, however is "texlive-latex, dvipdfm"
>   needed for "Requires"? (from your comment 23, these don't seem
>   to be needed for Requires)

It may seem peculiar, but texline-latex and dvipdfm are needed both
as 'requires' and 'build-requires'. That is because Logiweb is a
literate programming language:
http://logiweb.eu/1.0/doc/intro/literate.html
As an example, if the programmer writes this program:
http://logiweb.eu/1.0/doc/pages/combinations/source.lgs
Then the Logiweb compiler generates this 'printer friendly' format:
http://logiweb.eu/1.0/doc/pages/combinations/page/page.pdf
That is done using texlive-latex and dvipdfm, so they are required.

The lgc compiler is written in its own language. That is why
texlive-latex and dvipdfm are also build-required.

> ! rpmlint
> logiweb.i686: W: spurious-executable-perm ...
>    For this package as compile.sh has executable permission
>    its shebang dependency "/bin/bash" is automatically added
>    to the rebuilt binary, which is perhaps not needed.

Aha! Thanks for the explanation. I did not understand the warning.
Now I understand it is /bin/bash that gets required.
I will either remove the executable permission or move
/usr/share/doc/logiweb/examples/compile.sh
into
/usr/share/doc/logiweb/examples/makefile

> * Directory ownership issue
> https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership
>  https://fedoraproject.org/wiki/Packaging/UnownedDirectories#Common_Mistakes
>  - Currently the following directories themselves are not owned
>    by any packages.
> %{_docdir}/%{name}/

I shall take a look at that.

Okay, thank you for the explanation for "string"s.
Now I will wait for the updated srpm.

> Now I will wait for the updated srpm.
It may take a few days. I experiment with qemu to get
  ExcludeArch:  ppc64
rather than
  ExclusiveArch: %{ix86} x86_64 ppc

Version 0.2.8-9 is out. The new version is here:

Spec: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb.spec
SRPM: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb-0.2.8-9.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

Changes:

/usr/share/doc/logiweb/examples/compile.sh no longer has execute permissions

The package now owns %{_docdir}/%{name}/

Following Section 1.6.2 of
http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures
I have added
  ExcludeArch: ppc64
  # ppc64 excluded because clisp is not available on ppc64
to rpmspec rather than using ExclusiveArch. Following
http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures,
if bugs are reported against logiweb on secondary architectures I
will try to handle them and otherwise ExcludeArch on a case by
case basis. I hope that is a sensible interpretation of the status
of secondary architectures.

For -9:

Almost okay
* BR for texlive related pkgs
  - For texlive related pkgs, please use virtual provides name for
    Requires/BuildRequires like (i.e. use "BuildRequires: tex(latex)")
    or so.

Now as this blocks NEEDSPONSOR:

-------------------------------------------------------------
NOTE: Before being sponsored:

This package will be accepted with another few (or no) work. 
But before I accept this package, someone (I am a candidate) 
must sponsor you.

Once you are sponsored, you have the right to review other 
submitters' review requests and approve the packages formally. 
For this reason, the person who want to be sponsored (like you) 
are required to "show that you have an understanding 
of the process and of the packaging guidelines" as is described
on :
http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored

Usually there are two ways to show this.
A. submit other review requests with enough quality.
B. Do a "pre-review" of other person's review request
   (at the time you are not sponsored, you cannot do
   a formal review)

When you have submitted a new review request or have pre-reviewed other 
person's review request, please write the bug number on this bug report 
so that I can check your comments or review request.

Fedora package collection review requests which are waiting for someone to
review can be checked on my wiki page:
http://fedoraproject.org/wiki/User:Mtasaka#B._Review_request_tickets
(Check "No one is reviewing")

Review guidelines are described mainly on:
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
http://fedoraproject.org/wiki/Packaging/Guidelines
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
------------------------------------------------------------

You are the upstream of this software so maybe you are not interested
in other pkgs on Fedora, however please at try to do a pre-review
of at least one package of other person, or submit another review
request.

> But before I accept this package, someone ... must sponsor you.

OK

> ... (I am a candidate) ...

Thanks

> ... For this reason, the person who want to be sponsored (like you) 
> are required to "show that you have an understanding 
> of the process and of the packaging guidelines" ...

I'm not sure I know the packaging guidelines well enough yet, but I
will make a try and hope I will learn while doing.

> You are the upstream of this software so maybe you are not interested
> in other pkgs on Fedora, however please at try to do a pre-review
> of at least one package of other person, or submit another review
> request.   

Maybe I should do both.

I happen to have another candidate for packaging: the 'Logiweb demon'
which, given a 'string' (a Logiweb reference) returns an http url for
retrieving the bytes associated to the reference. The demon is in
Logiweb-0.1.x but I took it out of Logiweb-0.2.x because only users
who run their own Apache web-server can use the demon. The demon has
these properties:
- It must run as root.
- It is invoked from an init script.
- After initial setup, it drops privileges and runs as user 'logiweb'.
- It does a chroot to protect its surroundings.
- It interacts with the Apache web-server.
- It communicates with logiweb demons on other machines via UDP.
In the Fedora documentation I have read a warning somewhere that
one should not package something like that in ones first rpm. But I
could give it a try now.

Concerning a package review, I have picked this one at random:

Bug 575502 - Review Request: scponly - Limited shell for secure file transfers  

I have put myself on the CC List of that bug but otherwise done
nothing. Do you think it would be reasonable if I go through that
package, following the checklists? Or is there some other package
you would suggest me to look upon?

Unfortunately scponly is already in Fedora and bug 575502 was
closed as a duplicate. So please try another package (or submit
another review request)

> So please try another package (or submit
> another review request)

OK. We have Easter here next week, but I will return after after that.

Version 0.2.8-10 is out. The new version is here:

Spec: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb.spec
SRPM: http://logiweb.imm.dtu.dk/1.0/doc/download/logiweb-0.2.8-10.fc11.src.rpm

HTML URL: http://logiweb.eu/1.0/doc/download/rpm.html
Mirror:   http://logiweb.imm.dtu.dk/1.0/doc/download/rpm.html
Mirror:   http://topps.diku.dk/logiweb/1.0/doc/download/rpm.html

Change: Requires and BuildRequires tex(latex) instead of texlive

I will return when I have done a package review after Easter.

> So please try another package (or submit another review request)

I now take a look at these:

506567 acl2        - Automated reasoning system based on Common Lisp 
537694 texmakerx   - LaTex Editor 
570803 crawl       - Dungeon Crawl Stone Soup - a rogue-like game of exploration 
543718 wxmacmolplt - A graphics program for plotting 3-D molecular structures
                     and normal modes 
576685 pekwm       - A small and flexible window manager 
578990 nimrod      - A new statically typed, imperative programming Language 
565251 coan        - A commandline tool for simplifying the preprocessor
                     conditionals in source code 
578290 mj          - Mah-Jong program with network option 

I picked nine packages yesterday evening (local time) more or less at random.
One was taken this morning. I hope at least some of the packages above will
stay open until I have had a chance to look at them.

Okay, when you have done one pre-review, please let me know it.

Now I have done a pre-review of Bug 578290 : mj (mahjong)

I have built the source RPM for x86_64 and i386.
Running rpmlint on the binary packages causes no complaints.
Below I go through
  http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
step by step (rather mechanical - sorry - but I hape that
is a reasonable way to start).

Below, "you" means "the packager".

For each comment I make below I have added one of the
following attributes after the comment:
ACTION   The packager must do or say something
QUESTION I am in doubt what to do here
OK       Selfexplanatory



MUST: rpmlint must be run on every package. The output
should be posted in the review.

> I should mention that if you run rpmlint on the SRPM,
> you will get several warnings about spelling errors
> in the Swedish description, referring to words from
> the English description.  From what I can tell, this
> is because of some bug in rpm, see bug 578299.

I only get two erros from rpmlint:

> mj.src: W: no-cleaning-of-buildroot %install
> You should clean $RPM_BUILD_ROOT in the %clean
> section and in the beginning of the %install section.
> Use "rm -rf $RPM_BUILD_ROOT". Some rpm configurations
> do this automatically; if your package is only going
> to be built in such configurations, you can ignore
> this warning for the section(s) where your rpm
> takes care of it.

> mj.src: W: no-buildroot-tag
> The BuildRoot tag isn't used in your spec. It must
> be used in order to allow building the package as
> non root on some systems. For some rpm versions (e.g.
> rpm.org >= 4.6) the BuildRoot tag is not necessary
> in specfiles and is ignored by rpmbuild; if your
> package is only going to be built with such rpm
> versions you can ignore this warning.

Could you take a look at that?

[[NOTE: "you" means the *packager* in the line above]]

ACTION



MUST: The package must be named according to the
Package Naming Guidelines.

Naming guidelines are met.

But 'mj' is a *very* short name. There are only
26^2=676 package names which consist of two, small
letters, so I suppose such names are reserved.

The name matches the upstream tar-ball
(mj-1.10-src.tar.gz). Do you think upstream would
be willing to change name to e.g. mahjong-1.10
or mahjongg-1.10? Those names do not appear to be
taken yet. In particular, /usr/bin/mahjongg belongs
to gnome-games-2.26.3-1.fc11.x86_64.

ACTION



MUST: The spec file name must match the base package
%{name}, in the format %{name}.spec unless your
package has an exemption.

OK



MUST: The package must meet the Packaging Guidelines.

The application is written in C but uses neither
$RPM_OPT_FLAGS nor %{optflags}

ACTION

http://fedoraproject.org/wiki/Packaging/Guidelines#desktop-file-install_usage
says that one should use desktop-file-install (mj.spec does that)
and should also BuildRequire desktop-file-utils (mj.spec doesn't)

ACTION

http://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
says that you should use %global instead of %define, unless
you really need only locally defined submacros within other
macro definitions (a very rare case). mj.spec contains
two instances of %define. Is that needed?

ACTION

Consider using
  cp -p ../tiles-v1/tong* .
rather than
  cp ../tiles-v1/tong* .
c.f. http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps

ACTION



MUST: The package must be licensed with a Fedora
approved license and meet the Licensing Guidelines.

License in upstream tar file:
> The programs are distributed under the GNU General
> Public License, version 2, or at your discretion
> any later version.

Part of the upstream tar file, however, is non-GNU.
The mj.spec file says:

# The bundled tiles have a non-commercial-use license.  So instead we
# use GPL tiles from kdegames instead.  The solution was suggested by
# Tom 'spot' Callaway in:
# http://lists.fedoraproject.org/pipermail/legal/2010-February/001109.html

As mentioned in tiles-v1/README it is questionable whether or
not the bundled tiles have a non-commercial-use license. Thus
it is questionable whether or not the tiles can be GNU GPL.

Tom 'spot' Callaway says the tiles are not GNU GPL.

Using GPL tiles from kdegames as indicated above seems like a
good idea. That guarantees that the tiles used are GPL.

But then I suppose the tiles-v1/ directory should be removed from
the source package since otherwise the source package will contain
tiles which are not GNU GPL.

ACTION

The upstream .c and .h files refer to the LICENSE file for license
information except lazyfixed.c, lazyfixed.h, vlazyfixed.c, and
vlazyfixed.h which refer to
  GNU Lesser General Public License (any version).
Is that a problem?

QUESTION

In upstream .c and .h files, the author claims moral rights.
Does that have any effect? I found something here:
http://www.sun.com/software/opensource/contributor_agreement.jsp#r_3

3.
Q:
The SCA requires that I agree not to assert my "moral rights." What are moral rights?
A:
Moral rights are additional rights of the creators of copyrighted works recognized in some jurisdictions, and intended to protect the relationship between an artist and his or her work. These rights remain in place even after ownership of the work is shared or transferred. Moral rights typically only apply to visual or artistic works, and not to utilitarian works such as software. They may prohibit the alteration or mutilation of a work, may protect the author's right of attribution or anonymous publication, and in general govern the artistic integrity of a creative work. It would be unusual for moral rights to apply to an open-source contribution, but in the event they do and you live in a jurisdiction that recognizes moral rights, when you sign the SCA you agree not to assert them with respect to your contributions.

QUESTION



MUST: The License field in the package spec file must
match the actual license.

Spec file license:
> License:     GPLv2+

OK



MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.

File LICENSE is included in %doc

OK



MUST: The spec file must be written in American English.

It is. Description and summary are provided in Swedish also.
The Swedish description and summary matches the American
English ones.

OK



MUST: The spec file for the package MUST be legible.

It is.

OK



MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this.

Downloaded from
http://mahjong.julianbradfield.org/Source/mj-1.10-src.tar.gz:
f9bacf9fd6743d5e3a2fd86863607ce2  mj-1.10-src.tar.gz

In source rpm:
f9bacf9fd6743d5e3a2fd86863607ce2  mj-1.10-src.tar.gz

OK



MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture.

Compiles and builds successfully for fc11/x86_64 and fc11/i586.

OK



MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line.

I am unable to test PPC. What shall I do?

QUESTION



MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.

Must be OK since it builds in a chroot jail using mock.

OK



MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.

The spec file does not handle locales at all.

OK



MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.

The RPM package defines no shared libraries.

OK



MUST: Packages must NOT bundle copies of system libraries.

OK



MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [12]

%prep replaces non-GNU-GPL tiles with tiles found at
/usr/share/kde4/apps/kmahjongglib/tilesets/default.svgz
Apart from that, /usr is neither hardcoded in mj.spec
nor in the Makefiles.

OK



MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.

The package uses these directories without creating them:

Directory                            Owner

/usr/bin/                            filesystem-2.4.21-1.fc11.x86_64
/usr/share/applications/             filesystem-2.4.21-1.fc11.x86_64
/usr/share/doc/                      filesystem-2.4.21-1.fc11.x86_64
/usr/share/icons/hicolor/32x32/apps/ hicolor-icon-theme-0.10-6.noarch
/usr/share/man/man1/                 policycoreutils-2.0.62-12.14.fc11.x86_64

How can I find out if one needs to require
hicolor-icon-theme-0.10-6.noarch and
policycoreutils-2.0.62-12.14.fc11.x86_64 ?

QUESTION



MUST: A Fedora package must not list a file more than once in the spec file's %files listings.

OK



MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.

rpm -qlv mj
-rwxr-xr-x root root /usr/bin/mj-player
-rwxr-xr-x root root /usr/bin/mj-server
-rwxr-xr-x root root /usr/bin/xmj
-rw-r--r-- root root /usr/share/applications/mj.desktop
drwxr-xr-x root root /usr/share/doc/mj-1.10
-rw-r--r-- root root /usr/share/doc/mj-1.10/CHANGES
-rw-r--r-- root root /usr/share/doc/mj-1.10/ChangeLog
-rw-r--r-- root root /usr/share/doc/mj-1.10/LICENCE
-rw-r--r-- root root /usr/share/doc/mj-1.10/README
-rw-r--r-- root root /usr/share/doc/mj-1.10/rules.txt
-rw-r--r-- root root /usr/share/doc/mj-1.10/use.txt
-rw-r--r-- root root /usr/share/icons/hicolor/32x32/apps/mj.png
-r--r--r-- root root /usr/share/man/man1/mj-player.1.gz
-r--r--r-- root root /usr/share/man/man1/mj-server.1.gz
-r--r--r-- root root /usr/share/man/man1/xmj.1.gz

Why are man pages not user writable?

ACTION



MUST: Each package must consistently use macros.

As far as I can see, mj.spec uses macros consistently.
Is that what is asked for here? Is there something
particular to look for?

Is this a question of using either $RPM_OPT_FLAGS
or %{optflags}? In that case, mj.spec uses the
%{optflags} style consistently and '$RPM' does not
occur anywhere in mj.spec.

QUESTION



MUST: The package must contain code, or permissable content.

OK



MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity).

Documentation consists of
25653 bytes rules.txt
41244 bytes use.txt
22311 bytes xmj.1.gz

OK



MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.

OK



MUST: Header files must be in a -devel package.

The package installs no .h files.

OK



MUST: Static libraries must be in a -static package.

The package installs no static libraries.

OK



MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.

The package installs no .so files.

OK



MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}

OK



MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.

OK



MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.

OK



MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.

OK



MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT).

It does not. As mentioned previously, rpmlint complains about it.

ACTION



MUST: All filenames in rpm packages must be valid UTF-8.

OK



SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.

The source package has a LICENSE file. The LICENSE file contains
license info followed by the GNU GPL license.

OK



SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.

Description and summary is available in English and Swedish. The Mahjong
program itself seems to support English only.

OK



SHOULD: The reviewer should test that the package builds in mock.

Done for x86_64 and i386.

OK



SHOULD: The package should compile and build into binary rpms on all supported architectures.

I cannot test PPC.

QUESTION



SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.

The x86_64 version seems to run fine.

OK



SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.

OK



SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.

There are no subpackages.

OK



SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.

There are no such files.

OK



SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.

The package only BuildRequire packages.

OK



SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.

Man pages are included for all three binaries (xmj, mj-player, and mj-server).

OK

Please post pre-review results for mj on mj review request bug,
not on this review request.

By the way I will check your pre-review later.

> Please post pre-review results for mj on mj review request bug

Done

> By the way I will check your pre-review later.

Thanks.

There were five points where I was in doubt what to do.
They are marked QUESTION in the prereview. Two are
license questions. One is what I should do when I cannot
test building on PPC. And two are details.

Okay. Your pre-review seems good to some extent for initial comments.
I will keep taking care of mj review request.

-----------------------------------------------------------
    This package (logiweb) is APPROVED by mtasaka
-----------------------------------------------------------

Please follow the procedure written on:
http://fedoraproject.org/wiki/PackageMaintainers/Join
from "Install the Client Tools (Koji)".

Now I am sponsoring you.

If you want to import this package into Fedora 11/12/13, you also have
to look at
http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT
(after once you rebuilt this package on koji Fedora rebuilding system).

If you have questions, please ask me.

Removing NEEDSPONSOR.

> This package (logiweb) is APPROVED by mtasaka
> Please follow the procedure written on:...
> Now I am sponsoring you.

Great. Thanks!

Created attachment 406420 [details]
Where to set fedora-cvs flag

Would you check if the place marked in the attached
png appear after you login to bugzilla?

Aha!
Yes, it does. It works.
Thanks.

New Package CVS Request
=======================
Package Name: logiweb
Short Description: a system for electronic distribution of mathematics
Owners: grue
Branches: F-11 F-12 F-13
InitialCC: grue

CVS done (by process-cvs-requests.py).

For F-11/12/13, when rebuild is done, please visit bodhi:
https://admin.fedoraproject.org/updates/
and submit push requests.

logiweb-0.2.8-10.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/logiweb-0.2.8-10.fc12

logiweb-0.2.8-10.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/logiweb-0.2.8-10.fc11

logiweb-0.2.8-10.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/logiweb-0.2.8-10.fc13

Thank you. NOw closing.

> NOw closing.
Thanks for you help

logiweb-0.2.8-10.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

logiweb-0.2.8-10.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

logiweb-0.2.8-10.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Bug 584729 (logiweb must require gcc) solved in logiweb-0.2.8-11 (gcc has been added to Requires in rpmspec). logiweb-0.2.8-11 has been submitted to Bodhi. I took the liberty to request "stable" rather than "testing". Hope that is ok.