Bug 247417

Rpmlint complains about the absense of any documentation in this package.
However since there are separate upstream tarballs for reference and
documentation (http://bouml.free.fr/download.html), I am planning to submit a
separate -doc sub-package for them.

Spec URL: http://rishi.fedorapeople.org/bouml.spec
SRPM URL: http://rishi.fedorapeople.org/bouml-2.29.1-1.fc8.src.rpm

There has been a new upstream release, version 2.29.1.

I have submitted a review request for the bouml-doc package here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249892

Only glanced at your spec file but perhaps

pushd $RPM_BUILD_ROOT%{_bindir}
ln -s ../lib/bouml/projectControl projectControl
ln -s ../lib/bouml/projectSynchro projectSynchro
popd

and
%dir %{_libdir}/%{name}
%{_libdir}/%{name}/*

causes a problem on 64 bit machine (I have only i386)

Spec file: http://rishi.fedorapeople.org/bouml-2.spec

I have replaced 'lib' with '_lib' in the first case.

https://fedoraproject.org/wiki/Packaging/RPMMacros says %{_libdir} is
%{_exec_prefix}/%{_lib}, so the second case should not be an issue.

However I do not have a 64 bit Fedora system to check this.

SRPM: http://rishi.fedorapeople.org/bouml-2.29.1-2.fc8.src.rpm

It takes quite sometime to rpmbuild the package, so could not post it earlier.

(In reply to comment #6)
> It takes quite sometime to rpmbuild the package, so could not post it earlier.

Actually this package has >7000 files, which is the largest in the
packages I have reviewed (second is grass, which has >5000 files)...

http://rishi.fedorapeople.org/bouml-2.29.1-2.fc8.src.rpm seems to fail to build.
Koji taskinfo: http://koji.fedoraproject.org/koji/taskinfo?taskID=80231

(In reply to comment #8)
> http://rishi.fedorapeople.org/bouml-2.29.1-2.fc8.src.rpm seems to fail to build.
> Koji taskinfo: http://koji.fedoraproject.org/koji/taskinfo?taskID=80231

* Umm? Does this mean that we can try to rebuild srpm by koji
  which is not yet approved?

* For build failure itself:
  Anyway on 64bit arch, arch-dependent files must be installed 
  under /usr/lib64, not under /usr/lib and this must be fixed.

Yes, it is possible to have koji build arbitrary SRPMs:
  koji build --scratch target blah-1-1.src.rpm

> * For build failure itself:
>   Anyway on 64bit arch, arch-dependent files must be installed 
>   under /usr/lib64, not under /usr/lib and this must be fixed.

Should this be fixed for both x86_64 and ppc64 or only the former?

(In reply to comment #10)
> Yes, it is possible to have koji build arbitrary SRPMs:
>   koji build --scratch target blah-1-1.src.rpm
Oh, that is wonderful!! This makes reviewing easier.
Thank you.

(In reply to comment #11)
> > * For build failure itself:
> >   Anyway on 64bit arch, arch-dependent files must be installed 
> >   under /usr/lib64, not under /usr/lib and this must be fixed.
> 
> Should this be fixed for both x86_64 and ppc64 or only the former?
For both, however the needed fix is the same, I guess (although
I have not investigated where to fix)

I have figured out the problem.

This program does not use a Autoconf/Automake generated Makefile. In the
top-most Makefile it sets BOUML_LIB = /usr/lib/bouml and thus irrespective of
the host machine it puts everything in /usr/lib and not /usr/lib64, where that
is applicable. Hence using %{_lib} and %{_libdir} leads to the failure.

One more thing which concerns me are the following lines in src/Makefile :
CFLAGS   = -pipe -Wall -W -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
-mtune=generic -fasynchronous-unwind-tables  -DQT_NO_DEBUG -DQT_SHARED
-DQT_TABLET_SUPPORT -DQT_THREAD_SUPPORT
CXXFLAGS = -pipe -Wall -W -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
-mtune=generic -fasynchronous-unwind-tables  -DQT_NO_DEBUG -DQT_SHARED
-DQT_TABLET_SUPPORT -DQT_THREAD_SUPPORT

Will the use of -march=i386 in the C and C++ compiler flags also lead to problems?

For your reference I had tried a build by prepending the following line to the
SPEC file:
%define _lib lib
...and it successfully built. See
http://koji.fedoraproject.org/koji/taskinfo?taskID=80288

(In reply to comment #13)
> One more thing which concerns me are the following lines in src/Makefile :
> CFLAGS   = <snip>
> 
> Will the use of -march=i386 in the C and C++ compiler 
> flags also lead to problems?
Perhaps no. For example, x86_64 compilation log shows no -march=i386
option.


Well, for some reason I will reboot my system...

Would it be alright if I change the value of BOUML_LIB by checking whether value
of `uname -m` indicates x86_64 or ppc64?

(In reply to comment #15)
> Would it be alright if I change the value of BOUML_LIB by checking whether value
> of `uname -m` indicates x86_64 or ppc64?

If you want to change something on some arch, you may want to
use
--------------------------------------
%ifarch x86_64 ppc64
<something>
%endif
--------------------------------------

(Well, now we can use koji scratch build, however still please
 write the URL of spec/srpm to be checked <when you think they
 are okay> so that we can review them easily)

The correct (tm) approach to your issues would be to propagate rpm's values into
the Makefile.

One approach would be to apply sed to replace the hard-coded values inside of
the Makefile with the contents of %{_bindir}, %{_libdir} etc.

I.e. the BOUML_LIB issue could be remedied by using
sed -i -e "s,^BOUML_LIB = .*$,BOUML_LIB = %{_libdir}/bouml," Makefile
in %prep

Hi,

I see that you already have a reviewer, so your request for one to the
mailinglist is a bit strange. I know Mamoru as a good and quick reviewer, I
guess he is just waiting for you to fix the libdir and cflag issues.

Anyways now I'm here I've taken a quick look, so here are some things to work on
for starters. Mamoru, I assume you will still do the full review once these are
addressed?

Must FIX
----------
* use %{_libdir} for arch specific files, you can do this by invoking make as
  follows in %build:
  make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name}
  and like this in %install:
  make install DESTDIR=$RPM_BUILD_ROOT BOUML_LIB=%{_libdir}/%{name}
* the .desktop files do not contain mimetypes, so there is no reason to run
  update-desktop-database in %post[un]
* the %post[un] icon-cache scriptlets are wrong, the touch line misses || :
  and the gtk-update-icon-cache line must only be executed if 
  gtk-update-icon-cache is present, see:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda
* Add: "Requires: hicolor-icon-theme" for /usr/share/icons/hicolor/*/* dirs
  ownership

Should FIX
----------
The CFLAGS are not really an issue as bouml uses qmake to generate the makefile
and qmake puts the right flags into the generated makefiles itself. However to
be _really_ sure the right flags get used, for example when RPM_OPT_FLAGS get
changed (qmake uses RPM_OPT_FLAGS as defined when it was build), use the
following in %build:
make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name} CFLAGS="$RPM_OPT_FLAGS" \
  CXXFLAGS="$RPM_OPT_FLAGS"

Hello, Hans.

(In reply to comment #19)
> Hi,

> Mamoru, I assume you will still do the full review once these are
> addressed?

Yes. I am just waiting for a new srpm anyway so that I want to
make it sure that Debarshi and I and you are watching the same
spec/srpm.

(In reply to comment #19)

> I see that you already have a reviewer, so your request for one to the
> mailinglist is a bit strange.

That happened only after I posted on the list. :-)

> Must FIX
> ----------
> * use %{_libdir} for arch specific files, you can do this by invoking make as
>   follows in %build:
>   make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name}
>   and like this in %install:
>   make install DESTDIR=$RPM_BUILD_ROOT BOUML_LIB=%{_libdir}/%{name}

Fixed.

> * the .desktop files do not contain mimetypes, so there is no reason to run
>   update-desktop-database in %post[un]

Fixed.

> * the %post[un] icon-cache scriptlets are wrong, the touch line misses || :

Fixed. I don't see it at
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets -- maybe the Wiki
needs to be updated.

>   and the gtk-update-icon-cache line must only be executed if 
>   gtk-update-icon-cache is present, see:
>
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda

Fixed. I had taken the snippet from that page itself, but seems that the page
has been updated since. :-)

> * Add: "Requires: hicolor-icon-theme" for /usr/share/icons/hicolor/*/* dirs
>   ownership

Fixed.

> Should FIX
> ----------
> The CFLAGS are not really an issue as bouml uses qmake to generate the makefile
> and qmake puts the right flags into the generated makefiles itself. However to
> be _really_ sure the right flags get used, for example when RPM_OPT_FLAGS get
> changed (qmake uses RPM_OPT_FLAGS as defined when it was build), use the
> following in %build:
> make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name} CFLAGS="$RPM_OPT_FLAGS" \
>   CXXFLAGS="$RPM_OPT_FLAGS"

Fixed.

Spec: http://rishi.fedorapeople.org/bouml-3.spec

I shall upload the SRPM once I finish building it, which takes quite some time. :-)

(Well, I want to recheck after you upload the new srpm)

> > make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name} CFLAGS="$RPM_OPT_FLAGS" \
> >   CXXFLAGS="$RPM_OPT_FLAGS"
> 
> Fixed.
> 
> Spec: http://rishi.fedorapeople.org/bouml-3.spec

This spec file fails to build on i386. However it succeeds on replacing...
make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name} \
  CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS"
...with...
make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name}

Comments?

Well, I don't have rebuild bouml with using spec file in comment 21,
however would you attach how it failed?

(Note: Perhaps I will go to bed because it is 2 AM in Japan. Maybe someone
       will resolve your problem while I am sleeping...)

Since it is failing to build, I have nothing other than the spec file for it.
:-( All you need to build are the spec file
(http://rishi.fedorapeople.org/bouml-3.spec) and the upstream source.

My bad, okay, this one should work:

make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name} \
  CFLAGS="$RPM_OPT_FLAGS `pkg-config --cflags qt-mt`" \
  CXXFLAGS="$RPM_OPT_FLAGS `pkg-config --cflags qt-mt`"

(In reply to comment #26)
> My bad, okay, this one should work:
> 
> make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name} \
>   CFLAGS="$RPM_OPT_FLAGS `pkg-config --cflags qt-mt`" \
>   CXXFLAGS="$RPM_OPT_FLAGS `pkg-config --cflags qt-mt`"
> 

It still fails to build on i386.

g++ -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG
-DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/lib/qt-3.3/include  
-I/usr/lib/qt-3.3/mkspecs/default -I. -I../Tools -I../CppGenerator
-I/usr/lib/qt-3.3/include -o CppRefType.o CppRefType.cpp
g++ -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG
-DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/lib/qt-3.3/include  
-I/usr/lib/qt-3.3/mkspecs/default -I. -I../Tools -I../CppGenerator
-I/usr/lib/qt-3.3/include -o UmlAttribute.o UmlAttribute.cpp
g++ -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG
-DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/lib/qt-3.3/include  
-I/usr/lib/qt-3.3/mkspecs/default -I. -I../Tools -I../CppGenerator
-I/usr/lib/qt-3.3/include -o UmlClass.o UmlClass.cpp
UmlAttribute.cpp: In member function 'virtual void
UmlAttribute::compute_dependency(QPtrList<CppRefType>&, const QCString&, bool)':
UmlAttribute.cpp:41: error: 'cppDecl' was not declared in this scope
UmlAttribute.cpp: In member function 'virtual void
UmlAttribute::generate_decl(aVisibility&, QTextOStream&, const QCString&,
QCString, bool&, bool)':
UmlAttribute.cpp:76: error: 'cppDecl' was not declared in this scope
UmlAttribute.cpp:115: error: 'CppSettings' has not been declared
UmlAttribute.cpp:165: error: 'isCppMutable' was not declared in this scope
UmlAttribute.cpp: In member function 'virtual void
UmlAttribute::generate_def(QTextOStream&, QCString, bool, QCString, QCString,
QCString, QCString)':
UmlAttribute.cpp:184: error: 'cppDecl' was not declared in this scope
UmlAttribute.cpp:233: error: 'CppSettings' has not been declared
make[1]: *** [UmlAttribute.o] Error 1
make[1]: *** Waiting for unfinished jobs....
CppRefType.cpp: In static member function 'static void
CppRefType::compute(QPtrList<CppRefType>&, const QCString&, const QCString&,
QCString&, QCString&, QCString&, UmlArtifact*)':
CppRefType.cpp:160: error: 'CppSettings' has not been declared
CppRefType.cpp:166: error: 'CppSettings' has not been declared
CppRefType.cpp:171: error: 'CppSettings' has not been declared
CppRefType.cpp:176: error: 'CppSettings' has not been declared
CppRefType.cpp:193: error: 'CppSettings' has not been declared
CppRefType.cpp:201: error: 'class UmlClass' has no member named 'isCppExternal'
CppRefType.cpp:202: error: 'class UmlClass' has no member named 'cppDecl'
CppRefType.cpp:236: error: 'CppSettings' has not been declared
UmlClass.cpp: In member function 'QCString UmlClass::cpp_stereotype()':
UmlClass.cpp:49: error: 'CppSettings' has not been declared
UmlClass.cpp: In member function 'virtual void UmlClass::generate()':
UmlClass.cpp:59: error: 'isCppExternal' was not declared in this scope
UmlClass.cpp:59: error: 'cppDecl' was not declared in this scope
CppRefType.cpp:244: error: 'CppSettings' has not been declared
CppRefType.cpp:260: error: 'class UmlClass' has no member named 'isCppExternal'
UmlClass.cpp: In member function 'virtual void
UmlClass::compute_dependency(QPtrList<CppRefType>&, const QCString&, bool)':
UmlClass.cpp:96: error: 'class UmlClassItem' has no member named 'cppDecl'
UmlClass.cpp:122: error: 'cppDecl' was not declared in this scope
UmlClass.cpp: In member function 'void UmlClass::generate_decl(QTextOStream&,
QCString)':
UmlClass.cpp:154: error: 'cppDecl' was not declared in this scope
UmlClass.cpp:192: error: 'CppSettings' has not been declared
UmlClass.cpp:238: error: 'class UmlClassItem' has no member named 'cppDecl'
UmlClass.cpp:284: error: 'class UmlRelation' has no member named
'cppDecl'make[1]: *** [CppRefType.o] Error 1

UmlClass.cpp:304: error: 'class UmlClassItem' has no member named 'cppDecl'
UmlClass.cpp: In member function 'void UmlClass::generate_def(QTextOStream&,
QCString, bool)':
UmlClass.cpp:359: error: 'cppDecl' was not declared in this scope
UmlClass.cpp: In member function 'virtual void
UmlClass::generate_def(QTextOStream&, QCString, bool, QCString, QCString,
QCString, QCString)':
UmlClass.cpp:379: error: 'cppDecl' was not declared in this scope
UmlClass.cpp: In member function 'QCString UmlClass::decl()':
UmlClass.cpp:457: error: 'class UmlPackage' has no member named 'cppNamespace'
UmlClass.cpp: In static member function 'static void
UmlClass::write(QTextOStream&, const UmlTypeSpec&, bool)':
UmlClass.cpp:491: error: 'CppSettings' has not been declared
UmlClass.cpp: In member function 'void UmlClass::write(QTextOStream&, bool,
const QValueList<UmlActualParameter>&)':
UmlClass.cpp:508: error: 'class UmlPackage' has no member named 'cppNamespace'
UmlClass.cpp:510: error: 'CppSettings' has not been declared
UmlClass.cpp:511: error: 'class UmlPackage' has no member named 'cppNamespace'
UmlClass.cpp:516: error: 'isCppExternal' was not declared in this scope
UmlClass.cpp:517: error: 'cppDecl' was not declared in this scope
make[1]: *** [UmlClass.o] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/bouml_2.29.1/src/CppGenerator'
make: *** [compile] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.95841 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.95841 (%build)

This is the spec that I was using: http://rishi.fedorapeople.org/bouml-3.spec

ARGHHH

Okay, after further digging I've found out that this piece of #$$^%$ (makefile
wise) compiles some files several times into different libs / binaries, with
different defines used, so overriding CFLAGS is not possible easily.

Since qmake already puts RPM_OPT_FLAGS in there (albeit RPM_OPT_FLAGS as they
were when qt was build), I say lets forget about this hypothetical problem of
RPM_OPT_FLAGS changing and just use:
make %{?_smp_mflags} BOUML_LIB=%{_libdir}/%{name}

Spec: http://rishi.fedorapeople.org/bouml-3.spec
SRPM: http://rishi.fedorapeople.org/bouml-2.29.1-3.fc8.src.rpm

Koji info: http://koji.fedoraproject.org/koji/taskinfo?taskID=81066

For bouml-2.29.1-3

* Desktop file
  - Category "Application" is deprecated and should be removed.

  - Well, when I launch projectControl or projectSynchro,
    a dialog appears that shows "BOUML_ID is not defined" and then
    immediately the program exits. 
    This behavior is not expected for programs launched by 
    desktop files.

* Source
  - Ah.. 2.30 is released...

I am in office and I don't have access to my machine now. In the meantime could
you have a look at the bouml-doc package. Ofcourse that would also need a
version bump now that 2.30 is out.

Hi,

I am Bruno Pagès, author of Bouml

I see you have many problems to compile Bouml and this is a big surprise : the
other distributions made images without problem nor changes from the source
distribution I give, except changing definition of BOUML_LIB and other variables
in the toplevel Makefile.

Note : in all the cases qmake is used to produce the Makefiles (except the
toplevel one written by hand) like the toplevel Makefile ask for

I am also able to compile Bouml without any changes under a (old !) red hat
2.6.9-42 (i686 athlon) using Qt 3.3

On the download page of the site (http://bouml.free.fr/download.html) I point to
several Bouml distributions, can I add a pointer to yours ?
Do you have a page associated to Bouml, or a constant link to the rpm
(http://rishi.fedorapeople.org/bouml-2.29.1-1.fc8.src.rpm depend on the release
and may be more because I don't know the meaning of 'fc8'), or a way to find it
through a query (like for FreeBSD) ?

Best regards and thank you to compile Bouml for Fedora users

Bruno

(In reply to comment #32)

> I am Bruno Pagès, author of Bouml

Hello. Nice to see you here.
 
> I see you have many problems to compile Bouml and this is a big surprise

Not many problems really. The issue was handling the value of BOUML_LIB for
ppc64 and x86_64 systems. We tried to fiddle with the CFLAGS and CXXFLAGS used
by qmake, which complicated things a bit, and we finally gave up trying to do that.

> On the download page of the site (http://bouml.free.fr/download.html) I point to
> several Bouml distributions, can I add a pointer to yours ?

Sure. I will let you know the links to the RPMs for various architectures and
distribution versions once this review is approved.

> Do you have a page associated to Bouml, or a constant link to the rpm
> (http://rishi.fedorapeople.org/bouml-2.29.1-1.fc8.src.rpm depend on the release
> and may be more because I don't know the meaning of 'fc8'), or a way to find it
> through a query (like for FreeBSD) ?

Once the package is approved, it will become part of Fedora and be available
from the official Fedora repositories.  Whether it will be in the CD-ROMs or
DVDs is something I can not tell, yet.

Therefore all users need to do is:
# yum install bouml
...to install it. However this behaviour will be restricted to users of Fedora
Core 6 (if demanded), Fedora 7 and Rawhide (ie. Fedora development snapshot).

http://rishi.fedorapeople.org/bouml-2.29.1-1.fc8.src.rpm is only a temporary URI
being used for the purposes of this review request.

"fc8" stands for "Fedora Collection 8", which refers to the   version of the
package built for Rawhide (Fedora 8 is going to be the next Fedora release).

> Best regards and thank you to compile Bouml for Fedora users

Thanks for creating such a wonderful tool. Folks at my workplace make extensive
use of it.

There are a few things which need fixing at your end, though.

1. The file src/diagram/DiagramWindow.cpp  has the executable bit set. I think
it should have 644 as the mode.

2. The projectControl and projectSynchro  symlinks should be relative (targets
should be ../lib/bouml/projectControl and ../lib/bouml/projectSynchro) and not
absolute as they are now. This is helpful if the prefix is not '/usr' but
something else.

3. Remove  Applications from Categories in the .desktop files.

(In reply to comment #30)

>   - Well, when I launch projectControl or projectSynchro,
>     a dialog appears that shows "BOUML_ID is not defined" and then
>     immediately the program exits. 
>     This behavior is not expected for programs launched by 
>     desktop files.

That is because one needs to define an environment variable named "BOUML_ID", so
that many users can simultaneously work on same project, with each user having
his own "BOUML_ID". http://fedoraproject.org/wiki/Packaging/Guidelines did not
reveal much information about setting environment variables at installation time.

I am looking for a solution in the meanwhile.

(In reply to comment #33)
> There are a few things which need fixing at your end, though.
> 
> 1. The file src/diagram/DiagramWindow.cpp  has the executable bit set. I think
> it should have 644 as the mode.

done

> 2. The projectControl and projectSynchro  symlinks should be relative (targets
> should be ../lib/bouml/projectControl and ../lib/bouml/projectSynchro) and not
> absolute as they are now. This is helpful if the prefix is not '/usr' but
> something else.

I don't understand : the symlinks are made by "ln -s $(BOUML_LIB)/projectXXX",
so they follow BOUML_LIB. Furthermore BOUML_LIB and BOUML_DIR may not have the
same prefix (except '/')

> 3. Remove  Applications from Categories in the .desktop files.

done
 

(In reply to comment #34)
> (In reply to comment #30)
> 
> >   - Well, when I launch projectControl or projectSynchro,
> >     a dialog appears that shows "BOUML_ID is not defined" and then
> >     immediately the program exits. 
> >     This behavior is not expected for programs launched by 
> >     desktop files.
> 
> That is because one needs to define an environment variable named "BOUML_ID", so
> that many users can simultaneously work on same project, with each user having
> his own "BOUML_ID".

yes, and because it is a personal environment variable not linked to a specific
release of Bouml, to set it at installation time seems a very complicated way.
Users just have to define this variable (and may be BOUML_EDITOR,
BOUML_LIMIT_DESKTOP, BOUML_TEMPLATE and BOUML_CHARSET !) modifying *one* time
their .login or .cshrc or .bashrc or ...

(In reply to comment #36)
 
> yes, and because it is a personal environment variable not linked to a
> specific release of Bouml, to set it at installation time seems a very
> complicated way. Users just have to define this variable (and may be
> BOUML_EDITOR, BOUML_LIMIT_DESKTOP, BOUML_TEMPLATE and BOUML_CHARSET !)
> modifying *one* time their .login or .cshrc or .bashrc or ...

It would have been more elegant if the programs concerned had a provision for
supplying the values, atleast the absolutely necessary ones, instead of just
erroring out.

Just my own view, though. :-)

(In reply to comment #37)

> It would have been more elegant if the programs concerned had a provision for
> supplying the values, atleast the absolutely necessary ones, instead of just
> erroring out.

the problem only concern BOUML_ID, if it is not defined, I search for a value
compatible with the current use of the project, this means a value not used at
the same time *on the current project image*, but I can't know if a user work on
a separate (copy) view of the same project on an other disk. So after the error
message appears, you can continue with the temporary value, even this is not a
good way because you can't retry shortcuts, session etc ...

Concerning the other variables :

- BOUML_EDITOR allows to specify an external editor for multi-lines edition, I
can't decide for the user to use Xcoral, Emacs etc ... In case this variable is
not defined the edition is made with a Qt internal editor

- BOUML_LIMIT_DESKTOP is dedicated to users having several monitors. Qt doesn't
allow me to detect this case, if the user use several monitors without defining
this variable, all will be displayed supposing he has a large monitor. Because
many dialogs are centered this is not very practical, but this works.

- BOUML_TEMPLATE allows to define a given project as a template, this allows to
retrieve a blank project with the desired 'generation settings' etc.

- BOUML_CHARSET is for users using non latin-1 charset, for instance using
Cyrillic. An other time I can't detect this case

As you can see, it is not mandatory to define these variables, they help users
but and I can't define them myself for the users

best regards

Sorry, I did not make myself clear.

I meant: "It would have been more elegant if the programs concerned had a
provision for asking the user to interactively set the values, atleast the
absolutely necessary ones, instead of just erroring out."

I did not want the program to provide the value by itself.

Um, one quick solution is to install wrapper script as /usr/bin/projectControl
which contains like:
----------------------------------------------------------------
#!/bin/bash

xterm -e /bin/bash -c 'if [ -z "$BOUML_ID" ] ; then echo "Input BOUML_ID" ; read
BOUML_ID ; export BOUML_ID ; fi ; exec /usr/lib/bouml/projectControl'
----------------------------------------------------------------

(In reply to comment #40)
> Um, one quick solution is to install wrapper script as /usr/bin/projectControl
> which contains like:
> ...

oh no ! 
1) BOUML_ID is not only necessary to projectControl,
2) for a given user, BOUML_ID *must* be the same for bouml, projectControl and
projectSynchro
3) I can't image to ask for the value each time the user call one of the 3 tools ;-)

The definition of the variable is a false problem, it is the responsibility of
the user to define the variables he needs, and he will do that *one* time
modifying its .bachrc or similar file. Do not make nodes with the brain for that ;-)

Then the only solution is to remove desktop files of
projectControl and so on.

What about using the real user ID ('id --real --user `whoami`') as the BOUML_ID?
The real user ID would always be a unique number on the same system.

(In reply to comment #42)
> Then the only solution is to remove desktop files of
> projectControl and so on.

?

I don't understand, what is the goal or the reason to do that ?

(In reply to comment #43)
> What about using the real user ID ('id --real --user `whoami`') as the BOUML_ID?
> The real user ID would always be a unique number on the same system.

this is possible under a Linux (Bouml work also under Windows) but this is
restrictive. A user may want to work on a project at work and at home with the
same right (projectControl) => with the same BOUML_ID, but with two user IDs

Please, I insist : the environment variables is NOT a problem, don't try to
solve it yourself for the users, else you will introduce problems and/or
restrictions

(In reply to comment #45)
> Please, I insist : the environment variables is NOT a problem, don't try to
> solve it yourself for the users, else you will introduce problems and/or
> restrictions

So again the only solution is to remove the desktop files of
projectControl and so on. For desktop files the state that the application
cannot be launched by default is not acceptable.

(In reply to comment #46)
> So again the only solution is to remove the desktop files of
> projectControl and so on. For desktop files the state that the application
> cannot be launched by default is not acceptable.

There is a misunderstanding / quiproquo

The application CAN be launched in any case, calling it without defining
BOUML_ID the user will have the message and will understand and know he has to
define the environment variable. Please reread my respons #41
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247417#c41).

These applications are *graphical*, I can't imagine they can't be called through
a menu or using an icon (even it is possible to start them through a shell), it
is not g++

Frankly you are fixed on a non-problem, but *you* decide for *your* distribution ;-)

Well, you are upstream and if you say it is as expected, I won't
oppose anymore.

Note : the reference manual is not up of date, the update will be available
Monday in the worst case.

(In reply to comment #49)
> Note : the reference manual is not up of date, the update will be available
> Monday in the worst case.

I would appreciate it if you number manuals (in the way you like)

I am building BOUML 2.30, and will upload the spec and SRPM once it is done.

> I would appreciate it if you number manuals (in the way you like)

do you want I number the files available in the download page, or to add a
number in the text inside the manual ?

(In reply to comment #51)
> I am building BOUML 2.30, and will upload the spec and SRPM once it is done.

ok, good

I will made the 2.30.1 at worse for Monday, mainly to fixe a crash when a "class
instance" is duplicated in the browser, I detected this bug updating the manual ;-(

(In reply to comment #52)
> > I would appreciate it if you number manuals (in the way you like)
> 
> do you want I number the files available in the download page, or to add a
> number in the text inside the manual ?
> 

The name of the files (please check the discussion of bug 249892)

Spec: http://rishi.fedorapeople.org/bouml.spec
SRPM: http://rishi.fedorapeople.org/bouml-2.30-1.fc8.src.rpm

Koji info: http://koji.fedoraproject.org/koji/taskinfo?taskID=86998

Mamoru, I have not changed the License tag according to the new licensing
guidelines, yet. This is because:
a. I had started the build before I read the announcement. It takes so long to
build completely freezes my 256MB RAM machine.
b. The updated rpmlint is not yet there in the repositories.

I plan to update the tag, when I bump the version to 2.30.1, which according to
Bruno, is just around the corner.

Well, I will check srpm in comment 55 "today" (note: in Japan it
is 1:17 on Saturday now)

Well. for 2.30-1:
* License
  - Well I checked all files (7300+). Some sources are explicitly licensed
    under GPLv2+ and all others does not have any license declaration.

    Bruno, can we regard this as licensed under GPLv2+? or you want to
    license this as strict GPLv2?

to be frank I don't really know the response

on the legal-mentions I write "either version 2, or (at your option) any later
version", you '+' is linked to the second part of the sentence ?

I write a licence in the header of file written by hand, I don't write any
licence/header in the generated files

is it a problem ?

additional comment : the up to date reference manual is also available on the
site  and the tar.gz/7z files are numbered with the corresponding release of
bouml (2.30 in this case, 2.30.1 doesn't have impact on the doc)

(In reply to comment #58)
> I write a licence in the header of file written by hand, I don't write any
> licence/header in the generated files

Okay, then the license is "GPLv2+" (version 2 and <if you want> any
later).

Debarshi, please update the license field as "GPLv2+"
-----------------------------------------------------------------
   This package (bouml) is APPROVED by me
-----------------------------------------------------------------

(In reply to comment #60)

> Okay, then the license is "GPLv2+" (version 2 and <if you want> any
> later).
> 
> Debarshi, please update the license field as "GPLv2+"

Fine. I am building the package. In the meantime I shall ask for CVS access.

New Package CVS Request
=======================
Package Name: bouml
Short Description: UML2 tool box to specify and generate code in C++, Java and IDL.
Owners: debarshi.ray
Branches: FC-6, F-7
InitialCC:

cvs done.

Package Change Request
======================
Package Name: bouml
New Branches: F-8

cvs done.