build fails for r741 from SVN
Brought to you by:
realh
Menu
▾
▴
I tried tags/roxterm-1.18.2/ and got:
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:
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.
I had not done that, so likely.
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
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:
Expected?
apt-get build-dep roxterm
Shouldn't that be done before they run
?
underscore with a hyphen...
The underscore/hyphen swap is not needed, as
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.
the package itself with a .deb suffix.
You should conclude with the
command.
Otherwise the Debian instructions worked well. Thanks.
-Tom
I forgot to add it to Makefile.am. But I'll probably delete it instead,
because:
That occurred to me last night too, I'll do that.
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.
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.
Sounds terrific. But...
I thought this would be resolved by doing:
But apparently not.
Ah, here we go...
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.)
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.
Also run ./boostrap.sh now.
Typo in "bootstrap.sh."
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?
...you will still be left with a usable unsigned package.
Doesn't look like it...
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.</ver>
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
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.
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.
...you will still be left with a usable unsigned
package.
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
instead of
.
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
target which creates the tarball in the working directory.
links it to
, unpacks it in
(as
, 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.</version></version>
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
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:
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.
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
Run ./configure then make deb which will build the package in a subdirectory
called debtmp.
Maybe I'll call it INSTALL.Debian then, and I might as well add a link to the
plain INSTALL file.
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 :).
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?