DEBIAN package about mscgen

[GoogleCodeExporter]

To integrate with Doxygen under Ubuntu / Linux:
 - download src tarball for `mscgen` & make
 - copy from `bin` the executable:  cp bin/mscgen /usr/bin

Original comment by [email protected] on 28 Apr 2009 at 1:25

[GoogleCodeExporter]

I've created a RFP (Request For Package) to Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528784

Original comment by [email protected] on 15 May 2009 at 6:12

[GoogleCodeExporter]

Hi

In relation to this, for the sake of trying I have created a sample debian 
package.
(download: http://www.student.dtu.dk/~s072425/mscgen_0.14-1_i386.deb)

Odds of this being accepted into the debian repositories in its current state: 
slim
to none. I am not just saying this because it is my first debian package, but 
because
according to: 

  http://www.debian.org/doc/manuals/maint-guide/ch-modify.en.html 

The package has to support "make DISTDIR=$path install" and then install the 
package
in "$path"/"$prefix". Considering that the Makefiles in this project does not 
even
support the "make install" target, the DISTDIR part is guaranteed to fail as 
well.

This could be resolved by using the autoconf/automake build system (which I have
offered to implement if there are interest:
http://code.google.com/p/mscgen/issues/detail?id=8). Alternatively the project
Makefiles could be rewritten to support the install target with the DISTDIR 
variable set.


This aside, there is probably a hundred of other reasons (missing source 
package?,
missing dependencies? etc.) as to why the package would not be accepted by the 
debian
repositories... but we will know that when the package meets a debian 
maintainer.

Also for reference, this debian package was built from the original sources of 
0.14.
That is, I have not included the patch that I posted for issue #8 (since it has 
not
been reviewed/accepted yet). 

~Niels

Original comment by [email protected] on 19 May 2009 at 11:07

[GoogleCodeExporter]

Why not just settle for a debian compatible channel?  

Eg. http://code.google.com/p/litm/

Original comment by [email protected] on 19 May 2009 at 12:28

[GoogleCodeExporter]

If you want an example of how it is done, have a look in 
http://code.google.com/p/litm/source/browse/#svn/trunk to the files 
_SConstruct_ and 
_do_release_ .

Original comment by [email protected] on 19 May 2009 at 12:31

[GoogleCodeExporter]

Right... in that case...

Here is the new makefile for the src/ dir plus two debian dirs (debian and
debian.in). (I haven't made a patch for this one - it is about 10 lines to copy 
if
you do not feel like overwriting the Makefile).

This enables the targets "deb", "deb-dir" and "deb-clean". "distclean" now 
depends on
"deb-clean" (but "clean" does not).

"deb-dir" will update src/debian/ and the tree below that to contain the binary,
updated control file + man-page. "deb" (depending on deb-dir) will create
src/mscgen_[version]_[arc].deb and "deb-clean" will (obviously) remove the 
generated
files from the src/debian tree.

So all that is missing with this, is to create the dist-tree, copy +modify their
script and upload it to the SVN. But most of this requires someone with SVN
write-access so have at it!

~Niels

Original comment by [email protected] on 19 May 2009 at 1:15

[GoogleCodeExporter]

Right... always check for issues before uploading. In regards to the debian 
package:

Fixed.
 * Added use of fakeroot (to create correct permissions).
 * removed executable bit on the man-page in the debian package.
 * removed "backup" of the control (control~) file from the debian package.

Still missing to do:
 * (control.in) Fix maintainer entry. I wrote my own name to write something...
 * (control.in) Check dependencies - currently only libc6 is listed, but ldd suggests
that a lot of other libraries are required.

Otherwise my previous post is still up to date.

~Niels

Original comment by [email protected] on 19 May 2009 at 1:25

[GoogleCodeExporter]

I have pulled this patch. First of all I sent the wrong file (the second time) 
and
secondly I have decided to try to package this for the Debian repositories and
package management advice against having/using upstream "package data" (for 
various
reasons). It is not that the project cannot have the "debian package"-creator, 
it
should just be done in a way that does not confuse debian package tools (e.g. 
by not
using a "debian" folder).

As much as settling is with a "compatible channel" would be far easier, I think 
this
program would be a good one to get a feel of the "minimum requirements" for 
becoming
a Debian Developer.

~Niels

Original comment by [email protected] on 23 May 2009 at 4:35

[GoogleCodeExporter]

If you are looking nice, fast, self-contained build system, I would recommend 
Waf
instead of Scons or autotools.

http://code.google.com/p/waf/

Just a suggestion =)

Original comment by [email protected] on 25 May 2009 at 1:25

[GoogleCodeExporter]

An Autoconf build would probably be nice, but I've tried it a couple of times 
and it
kinda killed all the fun.  

I would review and possibly accept an autoconf (+ maybe automake) setup which 
could
reasonably build for the following configurations:

 - Linux dynamic binary
 - Linux static binary
 - Cygwin
 - Cygwin/mingw (build/link with -mno-cygwin for native binaries)
 - Solaris/OSX/BSD

"make check" should also run the tests, and make install & uninstall should be
provided.  The setup must correctly check for and cionfigure against suitable
versions of libgd.

Ideally it would also allow for building of release packages (src, binary, 
binary
static etc...), although this could be automated through an external script.

Given such an autoconf, my guess is that packaging as conforming deb, rpm 
etc... is
made easier.  

Original comment by [email protected] on 25 May 2009 at 5:29

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I created a sample mscgen with autoconf based r18:

http://www.student.dtu.dk/~s072425/mscgen-0.14-autoconf.tar.gz
(it unpacks into mscgen-0.14)

And Autoconf might actually make it harder (for me at least), because now the 
parser
libary comes in a shared, so I might have to package separately... But that is 
okay,
then I will learn something new!

The sample does not run the tests, but it does built the parser lib both static 
and
shared.

~Niels

Original comment by [email protected] on 25 May 2009 at 7:16

[GoogleCodeExporter]

This looks promising.  It builds under Linux, but Cygwin doesn't like the 
configure
script.  I tried running autoreconf in Cygwin, but that still didn't work - not 
sure
what's going on there.

The shared/static looks good, but when building static, does it link everything
static?  One thing that struck me as odd was that libtool wrapped mscgen with a
script for some reason - I guess that is just my lack of familiarity with how 
that works.

Original comment by [email protected] on 25 May 2009 at 7:47

[GoogleCodeExporter]

Odd, autoconf should work on a cygwin; it should have a sh shell. I will see if 
I
can't find a Cygwin system to build on.

On the static part - it appears to only affect the libraries built. So static 
linking
would still make a dynamic linking against system libraries. That is mscgen 
would
link statically to libparser.a, but dynamically against say libgd. Though that 
can be
handled with a manual rule.

The wrapper script only happens during dynamic builds to handle the locations 
of the
libraries built by the same package (in our case libparser). The wrapper script 
will
not be included in the install. The real binary will usually be located in the
".libs/" folder, but will probably seg.fault if you do not set LD_LIBRARY_PATH
accordingly (which is what the wrapper script does).

~Niels

Original comment by [email protected] on 25 May 2009 at 8:03

[GoogleCodeExporter]

I have built 0.15 (r23) with autoconf and put it here: 

http://www.student.dtu.dk/~s072425/mscgen-0.15.tar.gz


Changes from last version and the original source (aside from adding the 
auto[stuff]
files):

 * Automake turns both X.l and X.y into X.c (and X.h in case of created header
files), so language.l was renamed to lang.l (and now includes language.h 
instead of
language.tab.h)

 * Files that depend on "PACKAGE_VERSION" being set now includes the auto-generated
config.h file (conditionally). This also fixes the issue from the previous 
package
where I had forgotten to "quote" the contents of PACKAGE_VERSION (causing the
compiler to believe it was a double and not a const char * - leading to seg. 
faults
when printing usages.). NB: all source files ought to conditionally include 
config.h,
but I was too lazy to do it.

 * renderer/main.c now conditionally includes unistd.h if autoconf determines it was
available.

 * Fixed wrong maintainer flags, so now -Wall and -Wextra are included.

 * Moved all test sources into src/test and enabled "make check". The sources were
moved because it simplifies creation of make rules. I had to modify the 
test-scripts
since "output" and "source" dir may not be the same anymore. 

 * Added the gdwin32 folder (+ contents) to the list of folders/files to be included
in a distribution.

 * Added check for gd.h. If missing and the "executable extension" is ".exe", extra
CPP and LD flags are added to the mscgen build process. I am not sure I got all 
the
flags, please check Makefile.am (in the bottom) or test it on a Windows (don't 
have
one of those, sorry)

~Niels

Original comment by [email protected] on 26 May 2009 at 10:57

[GoogleCodeExporter]

I have successfully cross built mscgen using the autoconf system (Linux->Win32).

Other than my first "extra flags for windows" were wrong (forgot to add include 
and
bin/lib) I also had to link against "bgd" and not "gd" (any reason it is named 
"bgd"
on Windows?). Anyhow, I assumed that the Cygwin linker will need to look for it 
as
bgd as well.

mscgen is linked dynamically to the gdwin32 library as well - libtool did not 
insert
wrapper scripts when cross building (not sure if was because it built ".exe" 
files or
because I am cross building), so you have to manually handle getting the 
library in
path. (e.g. run wine from the gdwin32/bin dir or set the correct env variable 
on Windows)

I re-uploaded the source to the same location - When configuring it will now 
emit a
warning if it is using the gdwin32 libraries and otherwise fail with an error 
if it
cannot find gd.h. You can tell if you have the right version by looking for the
AC_MSG_ERROR macro in configure.ac (e.g. grep "AC_MSG_ERROR" configure.ac) or 
you can
just re-download it.

There should be no changes to native builds on UNIX-based platforms.

BTW: If you still have issues with the configure script, try using sh to run 
it. e.g.
"/bin/sh configure". There is a space between "#!" and "/bin/sh" in the 
configure
script - I am not sure why, but I remember that it has caused me trouble in the 
past
when not explicitly invoking the shell.

There is a small page dedicated to why you would or would not include a blank 
after
the "#!" (though not directly related to autoconf) if you are curious:
http://www.in-ulm.de/~mascheck/various/shebang/

~Niels

Original comment by [email protected] on 26 May 2009 at 3:53

[GoogleCodeExporter]

Cool - I will test this at the weekend.

Original comment by [email protected] on 28 May 2009 at 8:15

[GoogleCodeExporter]

Sorry for the delay.  I've pulled your changes from your package into a branch:

http://code.google.com/p/mscgen/source/browse/#svn/branches/mscgen.autotools

I've had to make some changes to get the cygwin -mno-cygwin case to build, but 
it
appears to work.  Some more testing of each build scenario is needed, but then 
I'll
merge it back to trunk.

Original comment by [email protected] on 28 Jun 2009 at 8:26

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Looks great... while I read up on how to pack shared libraries I got some more
license issues you can look at:


src/renderer/utf8.c: GPL (v2 or later) (with incorrect FSF address)
src/renderer/utf8.h: GPL (v2 or later) (with incorrect FSF address)
src/test/renderercheck.sh: *No copyright* UNKNOWN
src/test/parsercheck.sh: *No copyright* UNKNOWN


I used the "licensecheck" script to find these (From the debian "devscripts"
package). If you are interested (and not running debian) I can send it to you.

~Niels

Original comment by [email protected] on 30 Jun 2009 at 8:26

[GoogleCodeExporter]

These are easy to fix.  I'll do that soon, and can get the licencecheck script 
under
Ubuntu.

Original comment by [email protected] on 1 Jul 2009 at 9:06

[GoogleCodeExporter]

By the way, I heard there is a "quick" solution to missing license statements. 
Quote
from IRC:

OdyX: nthykier: non-licensed file is strongly-copyrighted and 
non-distributable...
OdyX: nthykier: but a LICENSE file at the root of the tarball smartly written 
can
include non-headered files.

This could also save you from adding a license statement to test file (which
according to OdyX first statement is - strictly speaking - "non-distributable").


Nevertheless OdyX checked out the contents and said:

OdyX: nthykier: the important thing is that it is clear for anybody opening the
tarball under which licence each file is.
[...]
OdyX: at least he has "COPYING" files in some subdirectories
[...]
OdyX: I'd say it's enough.
[...]
OdyX: nthykier: I am no DD [Debian Developer], no FTP-Master [...]
OdyX: nthykier: take it as one external advice...

So I took the "external advice" and have uploaded a source package of mscgen to
mentors.debian.net
(http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=mscgen
) and
will try to get someone to review it. 

It is based on the trunk revision 31 (to include the fix issue #10) and its 
"version"
is 0.16~svn31.

~Niels

Original comment by [email protected] on 1 Jul 2009 at 12:47

[GoogleCodeExporter]

I've fixed up the licence check errors on trunk.  See r34.

Original comment by [email protected] on 5 Jul 2009 at 7:46

[GoogleCodeExporter]

Hi again...

I got in contact with Debian Developer, who was interested in sponsoring my 
package.
He/she recommended that the "msc"-files (in the test folder) got a license and a
copyright statement. 

Also I am considering to include some of them as examples; Personally I would 
choose
the tests 1, 2, 4 and 10. What do you feel about those?

I do not mind writing some inline documentations for the examples (provided you 
give
them a license that allows me to do so ^^ ).

~Niels

Original comment by [email protected] on 10 Jul 2009 at 12:16

[GoogleCodeExporter]

I'm happy to attach GPLv2 be acceptable on all the examples.  Would that work?

Original comment by [email protected] on 10 Jul 2009 at 12:40

[GoogleCodeExporter]

I believe it will. I think all we need is that there is no "doubt" about who 
owns the
copyright for file and under what license the file can be modified/distributed.

~Niels

Original comment by [email protected] on 10 Jul 2009 at 1:42

[GoogleCodeExporter]

r41 adds declarations to the test inputs.  I decided to place them in public 
domain
since that is most permissive.  This is on trunk, I'll update the autotools 
branch
shortly.

Original comment by [email protected] on 11 Jul 2009 at 12:51

[GoogleCodeExporter]

Note that I've refreshed the .autotools branch from trunk at r49.

Original comment by [email protected] on 11 Jul 2009 at 6:51

[GoogleCodeExporter]

Hi

mscgen has been uploaded to the queue and will hopefully soon be sync'ed to the 
mirrors.

I also noted my observations in comment 3 are wrong and have not been 
addressed, so I
will fix that now. Build systems are *not* required to unconditionally support a
'DESTDIR="" install' rule. The sample I used as comparison installed absolutely,
which was the reason it needed a DESTDIR install. Since mscgen installs 
relative to
the source folder, it need not support this.

I have used the build system from the trunk, because the only guide I could find
about packaging shared libraries (which the autotools build by default) was 
received
with frowns (it was apparently very outdated). However I am still interested in 
using
the autotools branch - I just have verify that it does every thing correctly in
regards to versioning the library (there are two "version" switches for 
libtool, a
-release and a -version [1]) and figure out which of them to increment when.
(Technically speaking the increment-part would probably be your job.)

I have not used the USE_FREETYPE macro in the build because it fails to find the
fonts, so the Debian version will probably suffer from the UTF-8 (issue 7) 
problem. I
will do some more asking around about this and see if I can prod some answers 
out. 

I added some comments to the mentioned test inputs, which will be installed as
examples - if you want them I can email them to you. Writing them made me to 
discover
issue 16.

"testinput9.msc" does not contain a license or terms under which it can be
distributed/modified. I chose to solve this in a pragmatic way - Debian's source
ships without testinput9.msc. 

It may not be possible for you to put things into "Public Domain" [2]. However 
the
files you have/wanted to put under into "Public Domain" did contain a long 
clause
about what we can and ... can do with them, so I wager they are okay (and my 
sponsor
did as well) for us to distribute. You may however want to consider adding a "No
Warranty", since some countries (the UK) still consider you the legal owner of 
those
files. 

As I understand it, in some countries the only way for something to be put into
"Public Domain" is if no one has the copyright on it. For works made by normal 
people
this happens:

 A) when the work does not justify having a copyright (e.g. compiling phone book).
- or -
 B) when the copyright expires - which is usually happens (a long time after)
"postmortem".

(Obviously when A or/and B is considered satisfied depends on the law in the 
given
country.)

~Niels

[1] More info on the switches can be found here:
http://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning
[2] http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html

Original comment by [email protected] on 14 Jul 2009 at 8:53

[GoogleCodeExporter]

Thanks for your hard work.

If you point me at the package, I'll try to merge back most of your changes to 
trunk
and the autotools branch to make packaging easier in future.

Regarding shared libs, I think it will be simplified if I fold the parser and
renderer together.  Then I believe libtool and the shared lib goes.

I'll add a no warranty clause to the msc's and take a look at testinput 9.

Original comment by [email protected] on 14 Jul 2009 at 9:28

[GoogleCodeExporter]

Glad to be able to help! Looking forward to packing 0.17 alright ^^.

The package can currently be downloaded from [1]:
http://mentors.debian.net/debian/pool/main/m/mscgen/


The only two changes made are the added examples and then I meddled with the
Makefiles to allow the build to be done without -O2.


If you do not want the shared library and want to keep the autotools system, 
you can
make it a "convenience" library - which would only require two minor changes. 
Then it
would be justifiable not to distribute the library - though you could also just
remove the library altogether then. Depends on what you want and what is 
easiest for
you. 

~Niels

[1] Example (requires "devscripts" and "dpkg-dev"):
mkdir debmscgen && cd debmscgen
dget http://mentors.debian.net/debian/pool/main/m/mscgen/mscgen_0.16+dfsg-1.dsc
dpkg-source -x mscgen_0.16+dfsg-1.dsc

Original comment by [email protected] on 14 Jul 2009 at 2:32

[GoogleCodeExporter]

I've added a warranty disclaimer to each sample msc now.

Original comment by [email protected] on 18 Jul 2009 at 3:17

[GoogleCodeExporter]

I have figured the libgd problem out on Debian - We have both a "xpm" and a 
"noxpm"
version of this library. Only the former appears to be compiled with "Freetype"
support [1].

~Niels

[1] The "build" file for libgd - look for lines with "DEB_CONFIGURE_FLAGS"
http://svn.debian.org/wsvn/pkg-gd/libgd2/trunk/debian/rules

Original comment by [email protected] on 26 Jul 2009 at 8:29

[GoogleCodeExporter]

I've just changed trunk to use pkg-config to get the gd library and cflags.  On
Debian do you know if this will pick the xpm or noxpm version?  Does this cause 
a
packaging problem there?

Original comment by [email protected] on 2 Aug 2009 at 5:43

[GoogleCodeExporter]

As far as I can tell libgd does not have a ".pc" file; even then libgd-xpm and
libgd-noxpm conflicts on each other, so only one can be installed at a given 
time, so
there will not be a problem in terms of packaging.

mscgen will just have to depend on libgd-xpm instead of "either" (unless mscgen 
can
determine whether fontconfig is available at run-time, in that case I could use
"either" of them). 

~Niels

Original comment by [email protected] on 2 Aug 2009 at 6:09

[GoogleCodeExporter]

Fedora has a gdlib.pc, but it looks like it is being added by their packagers 
since
it comes from a patch rather than the original source tar ball (it's also a .in 
and
hence processed by the autoconf/make setup to give the correct installation 
locations). 

It's a shame Debian doesn't also have a .pc as it makes it much easier to use 
the
lib.  This is the same problem as on Cygwin where that is also missing.  What 
I've
done on Cygwin is to pass the parameters direct and bipass pkg-config:

  export PKG_CONFIG=true
  export GDLIB_CFLAGS="-I`pwd`/../../gdwin32/include"
  export GDLIB_LIBS="-L`pwd`/../../gdwin32/lib -lbgd"

Setting PKG_CONFIG to true is a bit of a hack, but does prevent it causing any
problems (at least for as long as no other things are relying on pkg-config 
yet). 
I've asked the Cygwin mailing list about this:
http://cygwin.com/ml/cygwin/2009-08/msg00049.html

I guess the use of pkg-config causes a problem for Debian packaging - what 
should I
change?

Regarding fontconfig, it's broken on Cygwin and Win32, so it's not in by 
default. 
I'd really like to add it, especially for UTF8, but for the next release, I 
think it
is still out. 

Original comment by [email protected] on 2 Aug 2009 at 6:22

[GoogleCodeExporter]

Update - there is a .pc file in the original source tar, as well as a little 
program
called gdlib-config which does much the same.   Not sure why Debian aren't 
installing
the pkg-config file, do they install gdlib-config?

Original comment by [email protected] on 2 Aug 2009 at 6:49

[GoogleCodeExporter]

The Debian development packages of libgd ships with the gdlib-config program. 
Though
its "--libs" outputs all the libraries required for a static link (unlike
pkg-config), so I would prefer not using it.

As I understand it though, the pkg-config approach gives fewer problems than
libtool's ".la" files[1]. But I am unsure if this is the "official" view or 
just some
developers ranting on an IRC channel.

I think going with the pkg-config is just fine... I can just use the GDLIB_* 
flags
for now and if a later release of libgd ships with the .pc file, I will start 
using
pkg-config instead.

~Niels

[1] Among things because pkg-config have two "libs"-flags - one for shared and 
one
for static linking - the ".la" files doesn't (and neither does gdlib-config).

Original comment by [email protected] on 2 Aug 2009 at 7:42

[GoogleCodeExporter]

Hi

mscgen has been accepted[1] and is on its way to the mirrors.

~Niels
[1] http://packages.qa.debian.org/m/mscgen.html

Original comment by [email protected] on 11 Aug 2009 at 6:09

[GoogleCodeExporter]

That's great - excellent! 

Many thanks for your hard work!

Original comment by [email protected] on 11 Aug 2009 at 10:01

[GoogleCodeExporter]

Hi

I think we can close this one now. mscgen was accepted into testing and will be 
a
part of the next Debian stable. 

With about one and a half months to their next release, Ubuntu will probably 
not make
it a part of their 9.10 release. As I understand it, however, Ubuntu will
automatically include it in the following release (as a part of the "universe" 
section).

~Niels

PS: And by "we", I mean you (since I can't do it).

Original comment by [email protected] on 25 Aug 2009 at 6:49

[GoogleCodeExporter]

Many many thanks for your work on this Neils.
I'm also warming to the autobuild, which seems to be reasonably good now.

Original comment by [email protected] on 26 Aug 2009 at 7:39

• Changed state: Fixed

[GoogleCodeExporter]

PS: I've given you edit issue permission.

Original comment by [email protected] on 26 Aug 2009 at 7:54