libtool: link: ( cd ".libs" && rm -f "libroxterm.la" && ln -s "../libroxterm.la" "libroxterm.la" )
x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..    -D_REENTRANT -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12   -Wall -g -O2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -MT roxterm-about.o -MD -MP -MF .deps/roxterm-about.Tpo -c -o roxterm-about.o `test -f 'about.c' || echo './'`about.c
about.c: In function ‘about_dialog_create’:
about.c:75: error: ‘ROXTERM_VERSION’ undeclared (first use in this function)
about.c:75: error: (Each undeclared identifier is reported only once
about.c:75: error: for each function it appears in.)
make[4]: *** [roxterm-about.o] Error 1
make[4]: Leaving directory `/usr/local/src/roxterm/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/local/src/roxterm/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/roxterm'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/roxterm'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1334:
dpkg-buildpackage -rfakeroot -D -us -uc failed

I tried tags/roxterm-1.18.2/ and got:

 dpkg-source -b roxterm
dpkg-source: warning: source directory 'roxterm' is not <sourcepackage>-<upstreamversion> 'roxterm-1.18.2'
dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found
dpkg-source: info: using source format `1.0'
dpkg-source: info: building roxterm in roxterm_1.18.2-1.tar.gz
dpkg-source: info: building roxterm in roxterm_1.18.2-1.dsc
 debian/rules build
make: *** No rule to make target `configure', needed by `config.status'.  Stop.
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1334:
dpkg-buildpackage -rfakeroot -D -us -uc failed

Tried rebuilding from the 1.18.2-1 tar files from here https://launchpad.net/
ubuntu/+source/roxterm/1.18.2-1 and got a different set of errors:

 dpkg-source -b roxterm-1.18.2
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building roxterm using existing ./roxterm_1.18.2.orig.tar.gz
dpkg-source: error: cannot represent change to roxterm-1.18.2/roxterm_1.18.2-1.tar.gz: binary file contents changed
dpkg-source: error: add roxterm_1.18.2-1.tar.gz in debian/source/include-binaries if you want to store the modified binary in the debian tarball
dpkg-source: warning: executable mode 0755 of 'roxterm/debtag' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'roxterm/upload' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'roxterm/AppRun' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'roxterm/update-locales' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'roxterm/upload_docs.sh' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'roxterm/bootstrap.sh' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'roxterm/update-tags' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'roxterm/debian/rules' will not be represented in diff
dpkg-source: error: cannot represent change to roxterm-1.18.2/roxterm/Help/imgs/sflogo.png: binary file contents changed
dpkg-source: error: add roxterm/Help/imgs/sflogo.png in debian/source/include-binaries if you want to store the modified binary in the debian tarball
dpkg-source: error: cannot represent change to roxterm-1.18.2/roxterm/Help/imgs/roxterm_logo.png: binary file contents changed
dpkg-source: error: add roxterm/Help/imgs/roxterm_logo.png in debian/source/include-binaries if you want to store the modified binary in the debian tarball
dpkg-source: error: cannot represent change to roxterm-1.18.2/roxterm/Help/imgs/project-support.jpg: binary file contents changed
dpkg-source: error: add roxterm/Help/imgs/project-support.jpg in debian/source/include-binaries if you want to store the modified binary in the debian tarball
dpkg-source: warning: ignoring deletion of file config.sub
dpkg-source: warning: ignoring deletion of file config.guess
dpkg-source: error: unrepresentable changes to source
dpkg-buildpackage: error: dpkg-source -b roxterm-1.18.2 gave error exit status 2
debuild: fatal error at line 1334:
dpkg-buildpackage -rfakeroot -D -us -uc failed

This looks more like a procedural error on my end, though I'm no so sure.
Moving the tar files out of the way that I thought it was diffing against
seemed to make no difference.

I tried:

debuild -us -uc -i'.png|.jpg'

to have it ignore the binary image files, and that seem to finally let the
build run.

Preliminary run of 1.18.2 seem to work.

-Tom

I'm not sure what caused the first problem. 2 looks like it was caused by
forgetting to run bootstrap.sh, or because dpkg-source was confused before and
deleted some files it shouldn't have. The upgrade to source format 3.0 (quilt)
has made it more fussy about having a matching directory and tarball so I've
described how to deal with that in the new INSTALL.Debian file. Unfortunately
it's more long-winded, but getting it to fall back to source format 1.0
instead of stopping dead doesn't seem to be as dependable.

2 looks like it was caused by forgetting to run bootstrap.sh

I had not done that, so likely.

I've described how to deal with that in the new INSTALL.Debian file...

I noticed that INSTALL.Debian didn't get copied into the generated tarball.

A bit tricky to follow the post-processing steps for the tarball. Maybe I'll
create a make target for it. Or tweak

make dist

to produce a tarball with the required file name.

Showing a full set of command line steps using example file names would be
helpful.

I ran though the build and ended up with roxterm-1.18.2+svn.tar.gz, which is
missing the SVN version number, which appears here:

% head roxterm/debian/changelog 
roxterm (1.18.2+svn751-1) unstable; urgency=low

Expected?

With root privileges run:

apt-get build-dep roxterm

Shouldn't that be done before they run

make dist

?

...rename the unpacked directory to match the version and replace the

underscore with a hyphen...

The underscore/hyphen swap is not needed, as

make dist

produces a tarball containing a directory that already uses a hyphen.

Making the version match in the directory name is optional. debuild apparently
isn't that strict. As long as the directory looks like it has some version
number, it's happen, and if not, it just produces an ignorable warning.

On completion you will have several new files in the parent directory,
including

the package itself with a .deb suffix.

You should conclude with the

sudo dpkg -i ...

command.

Otherwise the Debian instructions worked well. Thanks.

-Tom

I noticed that INSTALL.Debian didn't get copied into the generated tarball.

I forgot to add it to Makefile.am. But I'll probably delete it instead,
because:

A bit tricky to follow the post-processing steps for the tarball. Maybe I'll
create a make target for it.

That occurred to me last night too, I'll do that.

I ran though the build and ended up with roxterm-1.18.2+svn.tar.gz, which is
missing the SVN version number...

Expected?

Yes, INSTALL.Debian does say that will happen. The trouble is the svn revision
number is added by the configure script and automake doesn't really support
on-the-fly versioning AFAIK. I think I'll have to make bootstrap.sh tweak the
version number in configure.ac instead of doing it when configure is run.

Quote:

With root privileges run:

apt-get build-dep roxterm

Shouldn't that be done before they run

Code:

make dist

?

Not really necessary unless you don't even have build-essential installed,
because make install doesn't compile anything, it just packs the files into a
tarball. But there's no harm in doing the apt-get before make dist, so I might
as well swap the order.

I've now added a make deb target and moved the now much shorter instructions
into index.html.

I've now added a make deb target...

Sounds terrific. But...

% svn up
D    INSTALL.Debian
D    configure.ac
D    debian/changelog
U    debian/copyright
A    debian/changelog.in
U    bootstrap.sh
U    src/about.c
U    src/Makefile.am
U    Help/index.html
A    configure.ac.in
U    Makefile.am
A    builddeb
Conflict discovered in 'po/en.po'.
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options: tf
G    po/en.po
Skipped 'po/en_GB.po'
Updated to revision 755.
Summary of conflicts:
  Skipped paths: 1

% make deb
make: *** No rule to make target `deb'.  Stop.

I thought this would be resolved by doing:

% ./configure
[...]
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
[...]

% make deb
make: *** No rule to make target `deb'.  Stop.

But apparently not.

Ah, here we go...

% ./bootstrap.sh 
At revision 755.
Cleaning autotools files...
Running autoreconf...
Copying file intl/Makefile.in
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./config.guess'
libtoolize: copying file `./config.sub'
libtoolize: copying file `./install-sh'
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:6: installing `./missing'
src/Makefile.am: installing `./depcomp'
Emptying list of files that should be deleted...

% ./configure
[...]

% make deb
cd . && ./builddeb
make[1]: Entering directory `/usr/local/src/roxterm/svn-trunk'
[...]
dpkg-deb: building package `roxterm' in `../roxterm_1.18.2+svn755-1_amd64.deb'.
 dpkg-genchanges  >../roxterm_1.18.2+svn755-1_amd64.changes
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: full upload (original source is included)
Now running lintian...
Finished running lintian.
Now signing changes and any dsc files...
 signfile roxterm_1.18.2+svn755-1.dsc Tony Houghton <h@realh.co.uk>
gpg: skipped "Tony Houghton <h@realh.co.uk>": secret key not available
gpg: /tmp/debsign.RchUIpz0/roxterm_1.18.2+svn755-1.dsc: clearsign failed: secret key not available
debsign: gpg error occurred!  Aborting....
debuild: fatal error at line 1255:
running debsign failed
make: *** [deb] Error 29

I forgot about bootstrap.sh.

(On a site note, it is almost universal now to have build instructions require
running "./configure; make; ..." or some other pre-processing command to
generate the make file. In my option, developers should have stuck with 'make'
as the universal command to start a build (even if make ultimately isn't
used), and used a stub Makefile which runs the pre-processing command to
generate the real Makefile, and then calls "make -f real_makefile ..." or some
other build automation tool. The rules in the stub could then deal with things
like the real_makefile needing to be regenerated if 'configure' is newer.)

...and moved the now much shorter instructions into index.html.

OK. I don't know whether this is common convention or just me, but I pretty
much never look at a project's HTML files when I'm looking for build/packaging
help. Only post-install operational help. Given that you use this HTML file as
ROXTerm's project home page, it makes sense to have it there, but I'd still
include the instructions or a link to them in INSTALL.

Help/index.html

Also run ./boostrap.sh now.

Typo in "bootstrap.sh."

Help/index.html

Ignore any messages about signing failing...

Can that step or debuild flag be made conditional on the presence of the
signature file, so the build doesn't end with a fatal error?

Help/index.html

...you will still be left with a usable unsigned package.

Doesn't look like it...

% cd ..
% sudo dpkg -i roxterm_1.18.2+svn755-1_amd64.deb
dpkg: error processing roxterm_1.18.2+svn755-1_amd64.deb (--install):
 cannot access archive: No such file or directory

It's not a name mismatch, as there are no new files in that directory.

On a related note, I'm wondering if it would make sense to build
roxterm-<ver>.tar.gz in ../ instead of the build directory. More consistent
with the Debian approach, though I guess that file isn't Debian-specific.

Thanks for the automation work. I'm sure with a few minor tweaks it'll be
working, and this is a substantial improvement over the previous process. So
easy that it almost eliminates the need for PPA builds.

-Tom

Conflict discovered in 'po/en.po'.

Select: (p) postpone, (df) diff-full, (e) edit,

        (mc) mine-conflict, (tc) theirs-conflict,

        (s) show all options: tf

It's difficult to deal with that because the .po files have to have the
translations edited by hand so they have to be checked in, but they're also
automatically generated/updated during the build, confusing svn. I suppose the
best thing to do is answer mc.

OK. I don't know whether this is common convention or just me, but I pretty

much never look at a project's HTML files when I'm looking for build/packaging

help. Only post-install operational help. Given that you use this HTML file

as ROXTerm's project home page, it makes sense to have it there, but I'd still

include the instructions or a link to them in INSTALL.

I think it would be best to have a README.Debian or something, because I doubt
most people bother to look at INSTALL, which is usually a copy of the generic
automake/conf instructions.

Help/index.html

...you will still be left with a usable unsigned

package.

Doesn't look like it...

% cd ..

% sudo dpkg -i roxterm_1.18.2+svn755-1_amd64.deb

dpkg: error processing roxterm_1.18.2+svn755-1_amd64.deb (--install):

 cannot access archive: No such file or directory

It's not a name mismatch, as there are no new files in that directory.

It's always worked for me even though the error message looks fatal. Did you
look in the right directory? I would have thought you should use

cd debtmp

instead of

cd ..

.

On a related note, I'm wondering if it would make sense to build
roxterm-<ver>.tar.gz

in ../ instead of the build directory. More consistent with the Debian
approach,

though I guess that file isn't Debian-specific.

There's a standard automake

dist

target which creates the tarball in the working directory.

builddeb

links it to

debtmp/roxterm_<version>.orig.tar.gz

, unpacks it in

debtmp

(as

debtmp/roxterm-<version>

, copies/fetches the debian subdirectory there and builds the package from
there.

I oveused code tags and Sourceforge butchered the last bit some more, it
should read:

There's a standard automake dist target which creates the tarball in the
working directory. builddeb links it to debtmp/roxterm_<version>.orig.tar.gz,
unpacks it in debtmp (as debtmp/roxterm-<version>, copies/fetches the debian
subdirectory there and builds the package from there.

I oveused code tags and Sourceforge butchered the last bit some more...

The forum software seem to be pretty buggy. It fails to render the close tag
properly on quote and code half the time, and the way the editor inserts
the tags it implies an inline format, rather than block format. Should
probably file a bug with SF...

-Tom

And complain about the ridiculously small text entry box.

Also, the reply box is a joke. I had to resort to creating a Greasemonkey
script to expand the hight and
boost the font size to make it usable.

-Tom

Should probably file a bug with SF...

There are a bunch of existing tickets covering the code rendering bug:

Ticket #9642

Ticket #8117

Ticket #8034

Apparently it is due to sloppy PHP code in the forum software's parser.
They've marked the tickets "wont fix" and expect the reporters to monitor
their general site announcement page for when the fix is implemented. (Not the
best bug management.)

The problems with the "Add a Reply" box didn't seem to be reported, so I filed
a ticket.

-Tom

Did you look in the right directory? I would have thought you should use

cd debtmp instead of cd ..

Correct, the package did get placed in debtmp, but how was I supposed to know
about debtmp? :-) It wasn't mentioned in your documentation, or the debuild
output (at least not near the end).

That worked:

% sudo dpkg -i debtmp/roxterm_1.18.2+svn755-1_amd64.deb
(Reading database ... 420385 files and directories currently installed.)
Preparing to replace roxterm 1.18.2+svn751-1 (using .../roxterm_1.18.2+svn755-1_amd64.deb) ...
Unpacking replacement roxterm ...
Setting up roxterm (1.18.2+svn755-1) ...
...

I think it would be best to have a README.Debian or something, because I
doubt most people bother to look at INSTALL...

I guess I'd look at README.Debian if I noticed it, but I expect those files to
contain notes on Debian-specific patches and operational differences, not
package building instructions. I don't know if there is a right place for
packaging instructions in the traditional model, but it feels like INSTALL is
the appropriate spot, given that packaging is part of the installation prep
work.

It's difficult to deal with that because the .po files have to have the
translations edited by hand so they have to be checked in, but they're also
automatically generated/updated during the build, confusing svn. I suppose the
best thing to do is answer mc.

That warning didn't bother me. I knew it wasn't something that was locally
modified, so I answered "tf" to fully overwrite my copy with the repository
version. I assumed any local modification made by the build process would get
re-applied.

To avoid this you could always split the files so there is a source version
that's under version control and a processed version that is the product of
the build, perhaps using different extensions.

-Tom

Correct, the package did get placed in debtmp, but how was I supposed to
know about debtmp? :-) It wasn't mentioned in your documentation, or the
debuild output (at least not near the end).

index.html

Run ./configure then make deb which will build the package in a subdirectory
called debtmp.

I guess I'd look at README.Debian if I noticed it, but I expect those files
to contain notes on Debian-specific patches and operational differences, not
package building instructions. I don't know if there is a right place for
packaging instructions in the traditional model, but it feels like INSTALL is
the appropriate spot, given that packaging is part of the installation prep
work.

Maybe I'll call it INSTALL.Debian then, and I might as well add a link to the
plain INSTALL file.

It's difficult to deal with that because the .po files have to have the
translations edited by hand so they have to be checked in, but they're also
automatically generated/updated during the build, confusing svn. I suppose the
best thing to do is answer mc.

That warning didn't bother me. I knew it wasn't something that was locally
modified, so I answered "tf" to fully overwrite my copy with the repository
version. I assumed any local modification made by the build process would get
re-applied.

To avoid this you could always split the files so there is a source version
that's under version control and a processed version that is the product of
the build, perhaps using different extensions.

That would basically mean reimplementing what that part of gettext does, which
is too complicated. There might be a way to get gettext to be more VCS-
friendly, otherwise I'll just stick a note about it in the instructions.

Surprise, the forum can't handle nested quoting properly either. I've
installed your GreaseMonkey script BTW :).

It wasn't mentioned in your documentation...

Run ./configure then make deb which will build the package in a subdirectory
called debtmp.

I had a feeling you probably mentioned it, but was too lazy to go back and
check. What I should have said is that if it was mentioned, it was easily
overlooked.

As the automation increases and things like the signing failure get tweaked
out, the amount of information the users needs to pay attention to goes down,
and it'll be harder to overlook details like this.

-Tom

Yes, I suppose it's quite easy really to add -uc -us to the debuild command if
$EMAIL != h@realh.co.uk.

I forgot to update here I guess. What do you think of it now?