Unblock request for dpkg 1.14.19

[Raphael Hertzog]

Hi,

On Sat, 26 Apr 2008, Luk Claes wrote:
> > - some bugfixes (example: #476113)
> >   (we can work with a RM/RA to see if a given bugfix is ok)
>
> Did see the diff of all the changes in the mean time. This one looks ok
> to include in the upload.
[...]
> > - and one particular design change in the way dpkg-source
> >   interprets the Format: field because otherwise we'll be stuck
> >   forever with something that I don't like much
> >   (see patch attached for the details)
> 
> I would appreciate if a succesful test scenario could be shown though
> looks fine in general.

dpkg 1.14.19 with those changes and a few others concerning the new source
packages have been in unstable since more than 10 days. I would suggest
hinting it into testing.

You can review here what else has gone into 1.14.19:
http://git.debian.org/?p=dpkg/dpkg.git;a=shortlog;h=refs/tags/1.14.19

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Remaining triggers changes in Ubuntu

[Colin Watson]

I recently finished off the merge of dpkg 1.14.18 into Ubuntu (yes, I
know, I should also merge 1.14.19, but I was already part-way through
this and it was easier to do that as a separate step). I went through
the entire merge line-by-line, with some assistance from Ian on IRC at
one point. Here are the remaining triggers-related changes in Ubuntu.

I also have an item on my to-do list to deal with
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432893, which showed up
at one point during the merge. The bulk of the fix for this seems to be
here:

  
http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=4b2bc864ce70972800e9995deb97b8ff936a61fe;hp=c372e7e8b203c2bc052f488960f078a5baac03b7

Is it possible that somebody could review this, as it seems to have
slipped through the cracks during the 1.15.0 argument?


  [ Ian Jackson ]
  * Rename triggers/Deferred to triggers/Unincorp to fix upgrades from
early versions of trigger support in Ubuntu.

I mention this solely for completeness; I doubt it's necessary in Debian
(and it probably isn't necessary in Ubuntu any more either, but it's not
difficult to retain and I generally only remove this kind of thing if it
actively causes a problem).

diff -Nru dpkg-1.14.18/debian/dpkg.postinst 
dpkg-1.14.18ubuntu1/debian/dpkg.postinst
--- dpkg-1.14.18/debian/dpkg.postinst   2008-04-09 07:35:16.0 +0100
+++ dpkg-1.14.18ubuntu1/debian/dpkg.postinst2008-05-01 13:47:54.0 
+0100
@@ -72,6 +72,14 @@
 
move_info_directory
remove_info_symlink
+
+   if test -f /var/lib/dpkg/triggers/Unincorp; then
+   # Upgrade from broken trigger interest recorder
+   #  (bugs.launchpad.net/133172).  We remove this
+   #  old stale file:
+   rm -f /var/lib/dpkg/triggers/Deferred
+   fi
+
;;
 
 abort-upgrade|abort-deconfigure|abort-remove)


  [ Ian Jackson ]
  * Avoid closing fsys tarfile pipe twice even in normal operation -
normally EBADF but might sometimes close some other desired fd and
cause hideous doom.
  * Avoid duplicate attempts to [f]close in obscure error situations which
might conceiveably close wrong fds.

This did actually show up as an Ubuntu bug report from somebody who
encountered it in real life, as I recall, so it's not theoretical.

diff -Nru dpkg-1.14.18/lib/cleanup.c dpkg-1.14.18ubuntu1/lib/cleanup.c
--- dpkg-1.14.18/lib/cleanup.c  2008-04-09 07:35:16.0 +0100
+++ dpkg-1.14.18ubuntu1/lib/cleanup.c   2008-05-01 00:43:45.0 +0100
@@ -29,8 +29,10 @@
 {
int *p1 = (int *)argv[0];
 
-   close(p1[0]);
-   close(p1[1]);
+   if (p1[0] >= 0)
+   close(p1[0]);
+   if (p1[1] >= 0)
+   close(p1[1]);
 }
 
 void
@@ -46,7 +48,8 @@
 {
DIR *d = (DIR *)(argv[0]);
 
-   closedir(d);
+   if (d)
+   closedir(d);
 }
 
 void
@@ -54,6 +57,17 @@
 {
int ip = *(int *)argv[0];
 
-   close(ip);
+   if (ip >= 0)
+   close(ip);
+}
+
+int
+ferror_fclose_pop_cleanup(FILE *f)
+{
+   int r1, r2;
+   r1 = ferror(f);
+   pop_cleanup(ehflag_normaltidy);
+   r2 = fclose(f);
+   return r1 ? r1 : r2;
 }
 
diff -Nru dpkg-1.14.18/lib/dpkg.h dpkg-1.14.18ubuntu1/lib/dpkg.h
--- dpkg-1.14.18/lib/dpkg.h 2008-04-09 07:35:16.0 +0100
+++ dpkg-1.14.18ubuntu1/lib/dpkg.h  2008-05-01 00:43:03.0 +0100
@@ -237,6 +237,15 @@
 void cu_closedir(int argc, void **argv);
 void cu_closefd(int argc, void **argv);
 
+int ferror_fclose_pop_cleanup(FILE *f);
+ /* calls ferror and fclose on f, and pop_cleanup
+  *   file= fopen
+  *   push_cleanup(cu_closefile,~ehflag_normaltidy, 0,0, 1,(void*)file
+  * return is 0 on success or EOF if fclose or ferror failed
+  * all three calls are always made regardless, and in the right order
+  * so you can just call ohshite if this returns EOF
+  */
+
 /*** lock.c ***/
 
 void lock_file(int *lockfd, const char *filename,
diff -Nru dpkg-1.14.18/lib/triglib.c dpkg-1.14.18ubuntu1/lib/triglib.c
--- dpkg-1.14.18/lib/triglib.c  2008-04-09 07:35:16.0 +0100
+++ dpkg-1.14.18ubuntu1/lib/triglib.c   2008-05-01 14:02:52.0 +0100
@@ -355,10 +355,9 @@
}
if (signum > 0)
fprintf(nf, "%s\n", pkg->name);
-   if (ferror(nf) || fclose(nf))
+   if (ferror_fclose_pop_cleanup(nf))
ohshite(_("unable to write new trigger interest file `%.250s'"),
newfn.buf);
-   pop_cleanup(ehflag_normaltidy);
 
if (rename(newfn.buf, trk_explicit_fn.buf))
ohshite(_("unable to install new trigger interest file 
`%.250s'"),
@@ -449,10 +448,9 @@
fprintf(nf, "%s %s\n", trigh.namenode_name(tfi->fnn),
tfi->pkg->name);
 
-   if (ferror(nf) || fclose(nf))
+   if (ferror_fclose_pop_cleanup(nf))
ohshite(_("unable to write new file triggers file `%.250s'"),
triggersnewfilefile);
-   p

Sentence handling in manual pages

[Colin Watson]

I happened to notice this chunk in the diff from 1.14.18 to 1.14.19:

  -Specifies that the package is interested in the named trigger.
  -All triggers in which a package is interested must be listed using
  -this directive in the triggers control file.
  +Specifies that the package is interested in the named trigger. All
  +triggers in which a package is interested must be listed using this
  +directive in the triggers control file.

I thought this might be a good time to point out that, in fact,
end-of-sentence punctuation in manual pages should always fall at the
end of a line. groff produces slightly better output (particularly when
producing PostScript) if you do this.

Here's the Sentences node in 'info groff', which goes into more detail:


 Although it is often debated, some typesetting rules say there
  should be different amounts of space after various punctuation marks.
  For example, the `Chicago typsetting manual' says that a period at the
  end of a sentence should have twice as much space following it as would
  a comma or a period as part of an abbreviation.
  
 `gtroff' does this by flagging certain characters (normally `!',
  `?', and `.') as "end-of-sentence" characters.  When `gtroff'
  encounters one of these characters at the end of a line, it appends a
  normal space followed by a "sentence space" in the formatted output.
  (This justifies one of the conventions mentioned in *Note Input
  Conventions::.)
  
 In addition, the following characters and symbols are treated
  transparently while handling end-of-sentence characters: `"', `'', `)',
  `]', `*', `\[dg]', and `\[rq]'.
  
 See the `cflags' request in *Note Using Symbols::, for more details.
  
 To prevent the insertion of extra space after an end-of-sentence
  character (at the end of a line), append `\&'.


Thanks,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Generated changes and patch systems

[Neil Williams]

On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:
> Neil Williams <[EMAIL PROTECTED]> 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
erron

Re: Generated changes and patch systems

[Russ Allbery]

Neil Williams <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]