Debian Bug report logs - #482716
autotools-dev: Please recommend to replace config.sub/guess in configure and not in clean

version graph

Package: autotools-dev; Maintainer for autotools-dev is Henrique de Moraes Holschuh <hmh@debian.org>; Source for autotools-dev is src:autotools-dev.

Reported by: Raphael Hertzog <hertzog@debian.org>

Date: Sat, 24 May 2008 15:48:02 UTC

Severity: normal

Found in version autotools-dev/20080123.1

Fixed in version autotools-dev/20090427.1

Done: Henrique de Moraes Holschuh <hmh@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>:
Bug#482716; Package autotools-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
New Bug report received and forwarded. Copy sent to Henrique de Moraes Holschuh <hmh@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: autotools-dev: Please recommend to replace config.sub/guess in configure and not in clean
Date: Sat, 24 May 2008 17:44:59 +0200
Package: autotools-dev
Version: 20080123.1
Severity: normal
Usertags: 3.0-quilt-by-default

In /usr/share/doc/autotools-dev/README.Debian.gz you recommend:
| Just add:
|         -test -r /usr/share/misc/config.sub && \
|            cp -f /usr/share/misc/config.sub config.sub
|         -test -r /usr/share/misc/config.guess && \
|            cp -f /usr/share/misc/config.guess config.guess
| to the clean target of debian/rules.

However this is not a good advice because it will clutter the .diff.gz with changes
to those files and we don't care about those changes since the files will be replaced
at next build anyway.

The recommended procedure is to remove config.sub and config.guess in the clean target
and to copy the files (like above) just before the "./configure" call.

Note that the changes to config.guess/sub stored in the .diff.gz will create problems
for the migration[1] to the new source package format 3.0 (quilt) because those changes
will end up in a patch in debian/patches/ and those patches are applied _after_ the
clean rule. And since the clean rules changes the files, the new patch won't apply
and the build process will fail.

[1] http://lists.debian.org/debian-devel-announce/2008/04/msg00004.html

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>:
Bug#482716; Package autotools-dev. Full text and rfc822 format available.

Acknowledgement sent to 482716@bugs.debian.org, Adeodato Simó <dato@net.com.org.es>:
Extra info received and forwarded to list. Copy sent to Henrique de Moraes Holschuh <hmh@debian.org>. Full text and rfc822 format available.

Message #10 received at 482716@bugs.debian.org (full text, mbox):

From: Adeodato Simó <dato@net.com.org.es>
To: 482716@bugs.debian.org
Subject: Re: Bug#482716: autotools-dev: Please recommend to replace config.sub/guess in configure and not in clean
Date: Sun, 25 May 2008 22:05:10 +0200
* Raphael Hertzog [Sat, 24 May 2008 17:44:59 +0200]:

> However this is not a good advice because it will clutter the .diff.gz with changes
> to those files and we don't care about those changes since the files will be replaced
> at next build anyway.

> The recommended procedure is to remove config.sub and config.guess in the clean target
> and to copy the files (like above) just before the "./configure" call.

FWIW, I would vote for favouring this way from the README file too.

Cheers,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
            Listening to: Paolo Conte - Alle prese con una verde milonga





Information forwarded to debian-bugs-dist@lists.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>:
Bug#482716; Package autotools-dev. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Henrique de Moraes Holschuh <hmh@debian.org>. Full text and rfc822 format available.

Message #15 received at 482716@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 482716@bugs.debian.org
Cc: Debian Devel <debian-devel@lists.debian.org>, "debian-dpkg@lists.debian.org" <debian-dpkg@lists.debian.org>
Subject: Re: Generated changes and patch systems
Date: Wed, 28 May 2008 01:45:35 +0100
[Message part 1 (text/plain, inline)]
On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:
> Neil Williams <codehelp@debian.org> writes:
> > On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote:
> 
> >> If you run autotools at build time you should also ensure that the
> >> changes which autotools makes are reverted in the clean target.  This
> >> means that your diff doesn't get cluttered with automatically generated
> >> things and ensures that repeated builds of the package produce the same
> >> diff.gz.
> 
> > I haven't seen any other packages doing that - is there an example
> > involving aclocal.m4 somewhere?
> 
> Lots of other packages do this -- one of mine off the top of my head is
> xml-security-c.

Nope. No mention of aclocal.m4 in debian/rules for that package,
just /usr/share/misc/config.guess and config.sub.

I need to patch configure and configure.ac in this package, that means
that aclocal.m4 is constantly being changed and reverted. It shouldn't
matter - it really should not.

I see no purpose in lintian (or dpkg come to that) testing for changes
in aclocal.m4 - IMHO it should simply be exempt from this check. No
distro can risk patching aclocal.m4 - by it's nature it is transient and
volatile and subject to large changes entirely at the mercy of external
factors. Any build system that tries is simply going to break
constantly, AFAICT.

No matter how I wrap the cp foo foo.safe mv foo.safe foo in
debian/rules, the first build can be OK but all subsequent builds end up
with aclocal.m4 in the .diff.gz. Besides, replacing aclocal.m4 after it
has just been updated by ./configure is not a good idea to me.

> > I really don't want to do all that for the tmpl/* files as well - I
> > don't see the need, copying dozens of files into foo.safe or
> > foo.upstream and then moving them back?
> 
> Just delete them then.

??? That simply does not work. The problem is that running gtk-doc not
only requires tmpl/*.sgml files to exist but it *then modifies them*!
Even though I don't install these files into the package, I cannot
delete them and I cannot move them out of the way or the documentation
is not updated. Again, first build can be OK, second build generates a
dozen spurious warnings (because the files are modified after
the .diff.gz is created but cannot be reliably reverted before the next
build).

I don't see that I should provide out-dated documentation (by dropping
--enable-gtk-doc) just because it suits lintian - neither can I patch
the updates because the updates themselves are generated by a third
party tool so I can neither control the changes made nor maintain
"clean" patches. I suspect the issue arises because upstream happen to
prepare the release tarballs on Ubuntu or Fedora where the tool version
differs. The precise reason is inconsequential - the problem is that
Debian should not need to care about these modifications. It's taking
'divergence' one stage too far.

With these gtk-doc files, it's not so much that the tmpl/*.sgml files
are generated but that a tool essential to the build modifies them in a
way that cannot be patched because the results of the patches are
variable according to that third party tool. The changes then affect the
files that are packaged. Some of these are formatting changes -
whitespace changes, extra lines, comment changes. Other changes cause
sections or entire pages to migrate within the final files. The "sense"
of the docs doesn't appear to change, just the internal structure - as
determined by the differing versions of the tools used.

The CDBS build doesn't do anything different - it's just that lintian
doesn't produces any warnings for this check in CDBS packages, ever.

> The point is to not put mechanically generated changes in the diff, since
> it makes it much harder to review what the maintainer has actually done.

I don't see how it can be prevented. Take a look at the current .diff.gz
for libgpewidget 0.115-5 in the archive.

> I think most people take the approach of just deleting such files in the
> clean target, which will exclude their changes from the diff.

Sorry, it is not as simple as that - the package simply won't build if
tmpl/*.sgml are removed, no rule to make tmpl/*.sgml.

The tmpl/*.sgml files cannot be cleaned and removing aclocal.m4 is
simply pointless (and creates an even larger .diff.gz).

I still don't see what problem this test is trying to solve - AFAICT the
problem didn't exist in the first place and all this extra work appears
pointless.

I still think patch-system-but-direct-changes-in-diff should be
downgraded to info only, if kept at all.

I fail to see what I'm doing wrong - or even why it matters to lintian.

We risk swapping a minor problem that only occurs when the maintainer
upgrades from one version to another (and which could be fixed by
dpkg-source ignoring changes to generated files in the .diff.gz or not
applying generated changes that do exist in the .diff.gz) for a major
FTBFS error every time some random third party package is updated by
erroneously patching files that contain generated changes outside the
control of the maintainer.

dpkg already detects whether files have been deleted or modified and
whether those changes can be ignored.

It is impossible to maintain clean patches if those patches must include
generated changes.

A possible solution is to invert this lintian check and say that if a
patch system is in use, dpkg-source refuses to unpack/apply anything
from the .diff.gz that is not in the debian/ directory.

make distclean is fine for compiled object files and .libs stuff but
sometimes it just isn't enough - but equally, I don't see that returning
to some mystical pristine source is valid either.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>:
Bug#482716; Package autotools-dev. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Henrique de Moraes Holschuh <hmh@debian.org>. Full text and rfc822 format available.

Message #20 received at 482716@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Neil Williams <codehelp@debian.org>
Cc: 482716@bugs.debian.org, Debian Devel <debian-devel@lists.debian.org>, "debian-dpkg\@lists.debian.org" <debian-dpkg@lists.debian.org>
Subject: Re: Generated changes and patch systems
Date: Tue, 27 May 2008 18:06:28 -0700
Neil Williams <codehelp@debian.org> writes:
> On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:

>> Lots of other packages do this -- one of mine off the top of my head is
>> xml-security-c.

> Nope. No mention of aclocal.m4 in debian/rules for that package,
> just /usr/share/misc/config.guess and config.sub.

Uh, it's the same problem.  Surely the generalization is obvious?

I guess look at shibboleth-sp if it's not....

> I need to patch configure and configure.ac in this package, that means
> that aclocal.m4 is constantly being changed and reverted. It shouldn't
> matter - it really should not.

Right, so delete it in the clean rule.

> I see no purpose in lintian (or dpkg come to that) testing for changes
> in aclocal.m4 - IMHO it should simply be exempt from this check.

Absolutely not -- you're introducing unexpected changes to the packaging
diff file, and that's exactly the point of this check.  Delete the
modified and regenerated files in the clean rule and then you won't have
this problem.

> No distro can risk patching aclocal.m4 - by it's nature it is transient
> and volatile and subject to large changes entirely at the mercy of
> external factors. Any build system that tries is simply going to break
> constantly, AFAICT.

Exactly, which is why lintian is making sure that you don't introduce
patches to it in your *.diff.gz inadvertantly, since it's not a sane thing
to do when you're using a patch system.  The preferred method to handle it
as far as I'm concerned is doing what you're doing -- running autotools at
build time.  In that case, you need to remove the regenerated files in
your clean rule.  The other way to do it, particularly if you need a very
specific version of autotools, is to run them yourself and save them as a
patch, but I think that's a bad idea except in very specific situations.

>>> I really don't want to do all that for the tmpl/* files as well - I
>>> don't see the need, copying dozens of files into foo.safe or
>>> foo.upstream and then moving them back?

>> Just delete them then.

> ??? That simply does not work. The problem is that running gtk-doc not
> only requires tmpl/*.sgml files to exist but it *then modifies them*!

This is extremely unusual.  Are you *sure* that it does an inplace edit of
the files during the build process?  This is almost never what build
systems do; instead, they generate files from other files using templating
systems.  They may ship the results of that operation and then redo it
during the build, in which case you need to delete the regenerated files
in your clean rule.

If they really expect the files to exist and to edit them in-place during
the build, upstream is doing something insane, and it's really something
that should be fixed upstream; a lintian warning is drawing your attention
to a very broken behavior.

> Even though I don't install these files into the package, I cannot
> delete them and I cannot move them out of the way or the documentation
> is not updated. Again, first build can be OK, second build generates a
> dozen spurious warnings (because the files are modified after the
> .diff.gz is created but cannot be reliably reverted before the next
> build).

Right, lintian is diagnosing build system brokenness.  I'm fairly happy
with lintian's behavior here; what it's drawing attention to is exactly
the kind of thing that breaks repeated package builds or causes NMUs to
introduce spurious package diffs, and is something that should really
ideally be fixed.

> With these gtk-doc files, it's not so much that the tmpl/*.sgml files
> are generated but that a tool essential to the build modifies them in a
> way that cannot be patched because the results of the patches are
> variable according to that third party tool.

If the tool behaves and only behaves in that way (I haven't checked), that
tool is broken and we should fix that tool.

> The CDBS build doesn't do anything different - it's just that lintian
> doesn't produces any warnings for this check in CDBS packages, ever.

Well, yes, it does, if CDBS uses a recognized patch system, but the list
of patch systems that lintian recognizes is fairly limited at this point.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>:
Bug#482716; Package autotools-dev. Full text and rfc822 format available.

Acknowledgement sent to Mark Brown <broonie@debian.org>:
Extra info received and forwarded to list. Copy sent to Henrique de Moraes Holschuh <hmh@debian.org>. Full text and rfc822 format available.

Message #25 received at 482716@bugs.debian.org (full text, mbox):

From: Mark Brown <broonie@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Neil Williams <codehelp@debian.org>, 482716@bugs.debian.org, Debian Devel <debian-devel@lists.debian.org>, "debian-dpkg@lists.debian.org" <debian-dpkg@lists.debian.org>
Subject: Re: Generated changes and patch systems
Date: Wed, 28 May 2008 11:02:05 +0100
On Tue, May 27, 2008 at 06:06:28PM -0700, Russ Allbery wrote:
> Neil Williams <codehelp@debian.org> writes:

> > With these gtk-doc files, it's not so much that the tmpl/*.sgml files
> > are generated but that a tool essential to the build modifies them in a
> > way that cannot be patched because the results of the patches are
> > variable according to that third party tool.

> If the tool behaves and only behaves in that way (I haven't checked), that
> tool is broken and we should fix that tool.

I've run into a similar situation before with a vaugely borked upstream
build system - it was straightforward enough to work around the problem
by moving the files out of the way and then replacing them if there was
a backup present when clean was run.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."




Information forwarded to debian-bugs-dist@lists.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>:
Bug#482716; Package autotools-dev. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Henrique de Moraes Holschuh <hmh@debian.org>. Full text and rfc822 format available.

Message #30 received at 482716@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: 482716@bugs.debian.org, Debian Devel <debian-devel@lists.debian.org>
Subject: Re: Generated changes and patch systems
Date: Wed, 28 May 2008 11:45:44 +0100
[Message part 1 (text/plain, inline)]
On Tue, 2008-05-27 at 18:06 -0700, Russ Allbery wrote:
> Neil Williams <codehelp@debian.org> writes:
> > On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:
> 
> >> Lots of other packages do this -- one of mine off the top of my head is
> >> xml-security-c.
> 
> > Nope. No mention of aclocal.m4 in debian/rules for that package,
> > just /usr/share/misc/config.guess and config.sub.
> 
> Uh, it's the same problem.  Surely the generalization is obvious?

It's not quite the same problem because aclocal.m4 is regenerated in the
clean rule itself because changing it causes ./configure --recheck to
recreate the (modified) file. So instead of copying it around, it has to
be deleted - merely because a patch system is in use. Seems crazy to me.

> > I need to patch configure and configure.ac in this package, that means
> > that aclocal.m4 is constantly being changed and reverted. It shouldn't
> > matter - it really should not.
> 
> Right, so delete it in the clean rule.

OK. It's a bit like collateral damage - need a patch to configure,
patching causes configure --recheck which modifies aclocal.m4 so delete
aclocal.m4. Hmmm. I don't like it but I'll do it anyway.

> > I see no purpose in lintian (or dpkg come to that) testing for changes
> > in aclocal.m4 - IMHO it should simply be exempt from this check.
> 
> Absolutely not -- you're introducing unexpected changes to the packaging
> diff file, 

Well my point is that the change is entirely expected (because the
patch modifies a file that is involved in generating the changes) - the
changes are merely a consequence of the patch. It feels wrong to have to
add a clean rule for aclocal.m4 as a direct result of patching
configure.ac when aclocal.m4 was not a problem before the patch. 

Anyway, the "problem" of the tmpl/* files is far more resistant.

> >>> I really don't want to do all that for the tmpl/* files as well - I
> >>> don't see the need, copying dozens of files into foo.safe or
> >>> foo.upstream and then moving them back?
> 
> >> Just delete them then.
> 
> > ??? That simply does not work. The problem is that running gtk-doc not
> > only requires tmpl/*.sgml files to exist but it *then modifies them*!
> 
> This is extremely unusual.  Are you *sure* that it does an inplace edit of
> the files during the build process? 

$ ls libgpewidget-0.115.orig/doc/tmpl/ -1
colordialog.sgml
color-slider.sgml
dirbrowser.sgml
errorbox.sgml
gpeclockface.sgml
gpehelp.sgml
gpeiconlistitem.sgml
gpe-iconlist.sgml
gpeiconlistview.sgml
gpetimesel.sgml
gpewindowlist.sgml
gtkdatecombo.sgml
gtksimplemenu.sgml
infoprint.sgml
init.sgml
libgpewidget-unused.sgml
picturebutton.sgml
pixmaps.sgml
popup_menu.sgml
popup.sgml
question.sgml
smallbox.sgml
spacing.sgml
stylus.sgml
translabel.sgml
tray.sgml
windows.sgml

From the build log:
 gtkdoc-mkdb --module=libgpewidget --source-dir=.. --output-format=xml
--sgml-mode --output-format=xml --tmpl-dir=tmpl

Now running lintian...
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/color-slider.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/colordialog.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/colorrenderer.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpeclockface.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpedialog.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpehelp.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gtkdatecombo.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gtksimplemenu.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/libgpewidget-unused.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/link-warning.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/pixmaps.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/smallbox.sgml
W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/spacing.sgml
Finished running lintian.

13 out of 27 files modified by gtk-doc.

Copy those files back into doc/tmpl/ from the upstream source and they
are still modified at the next build.

Add a rm -f doc/tmpl/*.sgml to clean:: and the build fails: No rule to
make doc/tmp/*.sgml

So, yes, --enable-gtkdoc is modifying files included upstream and which
are essential to the build process.

If I drop --enable-gtkdoc I get different contents in the
libgpewidget-doc package.

>  This is almost never what build
> systems do; instead, they generate files from other files using templating
> systems.  They may ship the results of that operation and then redo it
> during the build, in which case you need to delete the regenerated files
> in your clean rule.

Yes, that is what we might expect from build systems - unfortunately it
doesn't always work that way. 

The way gtk-doc works is that it adds a pre-defined gtk-doc.make file
into the upstream source and it is this file that determines everything
about how gtk-doc works. If upstream are using a different version, I
don't see what can be done. --enable-gtkdoc will update the .make file
according to the installed version on the build system. Disabling gtkdoc
means packaging outdated documentation.

It seems to me you're expecting gtk-doc-tools to implement something
like AM_MAINTAINER_MODE where upstream gtk-doc-tools is allowed to make
changes to doc/tmpl/*.sgml but Debian gtk-doc-tools is not. (I always
thought that AM_MAINTAINER_MODE was considered harmful for precisely
this reason.)

> If they really expect the files to exist and to edit them in-place during
> the build, upstream is doing something insane, and it's really something
> that should be fixed upstream; a lintian warning is drawing your attention
> to a very broken behavior.

AFAICT this is not a fault upstream - the tmpl/*.sgml files need to be
included. I suspect it is merely because upstream don't happen to use
the same version of gtk-doc-tools. The "they" in the quoted paragraph
refers to the gtk-doc-tools upstream, not libgpewidget upstream.

It is not at all insane - every package using gtk-doc-tools has the same
process. I'm not sure why only libgpewidget is currently showing this
problem but it is wrong to call it "insane".

gtk-doc-tools is, in essence, an upstream tool. It is meant to modify
upstream files during the build, that is the reason it exists. The need
to run it in the build arises, I'm presuming, from a difference in the
version of gtk-doc-tools between Debian and the libgpewidget upstream
team. Debian simply cannot stipulate that a certain version must be used
upstream. I don't see the bug.

> Right, lintian is diagnosing build system brokenness.  I'm fairly happy
> with lintian's behavior here; what it's drawing attention to is exactly
> the kind of thing that breaks repeated package builds or causes NMUs to
> introduce spurious package diffs, and is something that should really
> ideally be fixed.

Well, I'm not sure that it can be fixed - other than requiring upstream
to use the same version of gtk-doc-tools as Debian which is frankly,
absurd.

> > With these gtk-doc files, it's not so much that the tmpl/*.sgml files
> > are generated but that a tool essential to the build modifies them in a
> > way that cannot be patched because the results of the patches are
> > variable according to that third party tool.
> 
> If the tool behaves and only behaves in that way (I haven't checked), that
> tool is broken and we should fix that tool.

It probably is behaving that way but there's no accounting for changes
between versions - or for changes that may yet be made that also tweak
the output. I simply cannot risk patching these tmpl/*.sgml files and
having the patches fail at some point in the future, turning a bug in
lintian into a FTBFS in libgpewidget (which has 40 reverse
dependencies).

I still think that lintian is out of line here - this is not a problem
for the maintainer and it is only the maintainer who needs to worry
about updating the package from 0.115 to 0.116 and 0.117 etc.

These files are in the .diff.gz because of the behaviour of a third
party tool which updates a data source within the upstream source
according to internal rules for that tool. OK, maybe that tool could be
improved but that is not necessarily trivial - especially when Debian
cannot stipulate that any particular upstream team must use a particular
version or configuration for that tool.

I haven't been able to identify the supposed bug in gtk-doc-tools and I
don't see that it is up to me to do that - AFAICT this is something that
is not a problem in the real world and lintian is imposing unrealistic
expectations on libgpewidget.

I'm perfectly happy with the behaviour of gtk-doc-tools in libgpewidget
(I'd like gtk-doc-tools to be workable in a cross-build environment but
that's minor because cross-builds rarely care for API documentation
anyway and it is fairly easy to disable gtk-doc if the docs are not
wanted.). If others disagree, it is up to them to file a bug in
gtk-doc-tools and work out just how it should be improved. The mere fact
of a spurious lintian warning is an annoyance, not a problem but I would
still like lintian to be more intelligent about these things, accept
that the world is not 100% perfect and not blame the messenger.

If this is a bug in libgpewidget that I've missed, please let me know in
the usual manner, but for now I'm just going to ignore lintian for this
check.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>:
Bug#482716; Package autotools-dev. Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Henrique de Moraes Holschuh <hmh@debian.org>. Full text and rfc822 format available.

Message #35 received at 482716@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 482716@bugs.debian.org
Subject: wrong CC
Date: Wed, 28 May 2008 12:00:14 +0100
[Message part 1 (text/plain, inline)]
Ignore the extra comments, these were intended for #471263.

Sorry.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>:
Bug#482716; Package autotools-dev. Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Henrique de Moraes Holschuh <hmh@debian.org>. Full text and rfc822 format available.

Message #40 received at 482716@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Neil Williams <codehelp@debian.org>
Cc: 482716@bugs.debian.org, Debian Devel <debian-devel@lists.debian.org>
Subject: Re: Generated changes and patch systems
Date: Wed, 28 May 2008 10:19:07 -0700
Neil Williams <codehelp@debian.org> writes:
> On Tue, 2008-05-27 at 18:06 -0700, Russ Allbery wrote:

>> Uh, it's the same problem.  Surely the generalization is obvious?

> It's not quite the same problem because aclocal.m4 is regenerated in the
> clean rule itself because changing it causes ./configure --recheck to
> recreate the (modified) file.  So instead of copying it around, it has
> to be deleted - merely because a patch system is in use. Seems crazy to
> me.

Yes, deleting it is what I've been trying to tell you to do from the
start.  :)  Moving it around is generally a waste of time.  The examples
that I've been pointing you to just delete such files.

And no, lintian only happens to *detect* this problem because a patch
system is in use, since otherwise it doesn't know enough.  However, you
should *always* have been doing this for exactly the reasons that you
explained in your last message -- patching aclocal.m4 is not sane.
lintian has detected a latent bug in your package now that it has more
information about what's going on.

> OK. It's a bit like collateral damage - need a patch to configure,
> patching causes configure --recheck which modifies aclocal.m4 so delete
> aclocal.m4. Hmmm. I don't like it but I'll do it anyway.

Well, if I were patching configure, I'd run the full autotools suite
myself before running configure rather than relying on configure
--recheck.

>> Absolutely not -- you're introducing unexpected changes to the packaging
>> diff file, 

> Well my point is that the change is entirely expected (because the patch
> modifies a file that is involved in generating the changes) - the
> changes are merely a consequence of the patch.

You expect to have a giant patch to generated files in your *.diff.gz of
your source package?  I wouldn't -- that's what I meant by unexpected.

> It feels wrong to have to add a clean rule for aclocal.m4 as a direct
> result of patching configure.ac when aclocal.m4 was not a problem before
> the patch.

Well, this is just how autotools work.

> 13 out of 27 files modified by gtk-doc.

What's the diff?  What is it doing to the files at build time?

> The way gtk-doc works is that it adds a pre-defined gtk-doc.make file
> into the upstream source and it is this file that determines everything
> about how gtk-doc works. If upstream are using a different version, I
> don't see what can be done. --enable-gtkdoc will update the .make file
> according to the installed version on the build system. Disabling gtkdoc
> means packaging outdated documentation.

I'm not sure how this is related.  Is the update of the .make file somehow
causing the changes to the SGML file?

> It seems to me you're expecting gtk-doc-tools to implement something
> like AM_MAINTAINER_MODE where upstream gtk-doc-tools is allowed to make
> changes to doc/tmpl/*.sgml but Debian gtk-doc-tools is not. (I always
> thought that AM_MAINTAINER_MODE was considered harmful for precisely
> this reason.)

No, no, no.  I'm expecting something much more simple: any file in a build
tree should be either a generated file or a source file.  Surely not both!
A normal build of an upstream package should not modify upstream source
files that have no other origin.

> AFAICT this is not a fault upstream - the tmpl/*.sgml files need to be
> included. I suspect it is merely because upstream don't happen to use
> the same version of gtk-doc-tools. The "they" in the quoted paragraph
> refers to the gtk-doc-tools upstream, not libgpewidget upstream.

Changing the version of a tool should not result in an in-place edit of a
file with no other source.  That's just nuts.  If those are generated
files that come from some other origin, you should be able to delete them
and regenerate them from scratch.  Otherwise, if upstream is shipping
them, it doesn't make sense for a normal build to modify them.

I suspect that there's some way to generate those files that just isn't
part of a normal build, and deleting them really is the right thing to do;
you just need to be more aggressive about regenerating them.  But
hopefully someone who knows how gtk-doc-tools work can weigh in here.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#482716; Package autotools-dev. (Sat, 02 May 2009 20:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Henrique de Moraes Holschuh <hmh@debian.org>:
Extra info received and forwarded to list. (Sat, 02 May 2009 20:39:03 GMT) Full text and rfc822 format available.

Message #45 received at 482716@bugs.debian.org (full text, mbox):

From: Henrique de Moraes Holschuh <hmh@debian.org>
To: 482716@bugs.debian.org, Adeodato Simó <dato@net.com.org.es>, Raphael Hertzog <hertzog@debian.org>
Subject: Re: Bug#482716: autotools-dev: Please recommend to replace config.sub/guess in configure and not in clean
Date: Sat, 2 May 2009 17:35:55 -0300
I am updating autotools-dev to strongly deprecate anything but the
"remove everything auto-generated, and re-autotoolize everything on
build time".

One question: is *removing* the files on clean (and adding them back
on depencencies of the build target) also a problem for format 3.0?

I am sure some DDs will not want to autotoolize and will try to get
away with just updating config.sub and config.guess, so I better
provide good instructions for that case.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh




Reply sent to Henrique de Moraes Holschuh <hmh@debian.org>:
You have taken responsibility. (Mon, 04 May 2009 03:57:05 GMT) Full text and rfc822 format available.

Notification sent to Raphael Hertzog <hertzog@debian.org>:
Bug acknowledged by developer. (Mon, 04 May 2009 03:57:05 GMT) Full text and rfc822 format available.

Message #50 received at 482716-close@bugs.debian.org (full text, mbox):

From: Henrique de Moraes Holschuh <hmh@debian.org>
To: 482716-close@bugs.debian.org
Subject: Bug#482716: fixed in autotools-dev 20090427.1
Date: Mon, 04 May 2009 03:32:04 +0000
Source: autotools-dev
Source-Version: 20090427.1

We believe that the bug you reported is fixed in the latest version of
autotools-dev, which is due to be installed in the Debian FTP archive:

autotools-dev_20090427.1.dsc
  to pool/main/a/autotools-dev/autotools-dev_20090427.1.dsc
autotools-dev_20090427.1.tar.gz
  to pool/main/a/autotools-dev/autotools-dev_20090427.1.tar.gz
autotools-dev_20090427.1_all.deb
  to pool/main/a/autotools-dev/autotools-dev_20090427.1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 482716@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Henrique de Moraes Holschuh <hmh@debian.org> (supplier of updated autotools-dev package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 03 May 2009 20:23:53 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20090427.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh <hmh@debian.org>
Changed-By: Henrique de Moraes Holschuh <hmh@debian.org>
Description: 
 autotools-dev - Update infrastructure for config.{guess,sub} files
Closes: 482716
Changes: 
 autotools-dev (20090427.1) unstable; urgency=low
 .
   * Sync to upstream git 2009-04-27 [93b5037172b15ad2]
   * debian/control:
     + Update the package description to not mention CVS
     + Add homepage field
     + Update to standards version 3.8.0
   * debian/copyright: add upstream's copyright line, and update for the
     git repository location
   * README.Debian: switch to the current best practice, which is to
     rebuild the build system completely on every build. Also, make it
     clear that config.sub and config.guess are to be refreshed on the
     build target prerequisites, and not on the clean target.
     (Closes: #482716)
   * debian/*: move some files to match a newer style of debhelper file
     naming.
Checksums-Sha1: 
 ceb45593ced4092e27347b510e91884094bbb519 1096 autotools-dev_20090427.1.dsc
 d6bd57071edf9a27f2b7ad335298da62c9e4739a 64140 autotools-dev_20090427.1.tar.gz
 c23b1801888da84f6276088a22402c15b19014b5 64620 autotools-dev_20090427.1_all.deb
Checksums-Sha256: 
 33990f4d8ac0b249104ffecfbd2f85b029b3bbf6319af9362bfbdc9c81fb84ad 1096 autotools-dev_20090427.1.dsc
 2d092d62f6269d6ae02b2774c16e03137ea1bc5834e13bea75e4c14fe1eabee2 64140 autotools-dev_20090427.1.tar.gz
 a4f23ef2df6ca78d2b8356807efdd51af7a3633388bf6d58282a8341ae967a1c 64620 autotools-dev_20090427.1_all.deb
Files: 
 9ac1226bcb1693cab35f153e9bbce3b7 1096 devel optional autotools-dev_20090427.1.dsc
 a61e34a9c8bcee3cea3a080094d649fa 64140 devel optional autotools-dev_20090427.1.tar.gz
 f1be7027cd67923a73c532d1e52f2f3c 64620 devel optional autotools-dev_20090427.1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJJ/i8TAAoJEG99OTV/EEh0BR0H/RT314fKxxdB9gpO9rualAo1
82Z3zT4rU79yOvJjsA55MyzUvdUtug5ULt2kDoEp+imnT5heXxHm178Uup8Iy97W
K4MX9oxsCDEK4YxghRe9Q1ktpESdR4j4XGpdMnTONtVWgPFC8Vu6+I++5OhJb0pA
HB5iOMUa9bHpcdavh7BubKBDPAH9c3kG/5TLx2D1tVRR1KFRpvhjDMdbUPF4wfdg
Lo3HXeEt0I/R0b11UyAUpwWA7ZvWmlad14pL2O253la1qcVTmO7jOb3+PI9ZNS3d
09GCiGXreu+uFp4UJ/eqAvYwzfjPjGgp+QnnfLFzC1aAt1mrUwBgMuSrqG1v2ls=
=u+0q
-----END PGP SIGNATURE-----





Information forwarded to debian-bugs-dist@lists.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>:
Bug#482716; Package autotools-dev. (Mon, 04 May 2009 15:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Henrique de Moraes Holschuh <hmh@debian.org>. (Mon, 04 May 2009 15:54:14 GMT) Full text and rfc822 format available.

Message #55 received at 482716@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Henrique de Moraes Holschuh <hmh@debian.org>
Cc: 482716@bugs.debian.org, Adeodato Simó <dato@net.com.org.es>
Subject: Re: Bug#482716: autotools-dev: Please recommend to replace config.sub/guess in configure and not in clean
Date: Mon, 4 May 2009 17:50:34 +0200
On Sat, 02 May 2009, Henrique de Moraes Holschuh wrote:
> One question: is *removing* the files on clean (and adding them back
> on depencencies of the build target) also a problem for format 3.0?

It should not be a problem since dpkg-source doesn't create a diff for
removed files (it just spits out a warning).

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 11 Jun 2009 07:26:26 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 00:32:17 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.