Debian Bug report logs - #366555
dpkg-source: Timestamps on documentation advance artificially

version graph

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg.

Reported by: "A. Costa" <agcosta@gis.net>

Date: Sat, 15 Apr 2006 05:33:09 UTC

Severity: normal

Fixed in version dpkg/1.14.17

Done: Guillem Jover <guillem@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, Shaun Jackman <sjackman@debian.org>:
Bug#362699; Package freeguide. Full text and rfc822 format available.

Acknowledgement sent to "A. Costa" <agcosta@gis.net>:
New Bug report received and forwarded. Copy sent to Shaun Jackman <sjackman@debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: files in '/usr/share/doc/freeguide' all have same date.
Date: Sat, 15 Apr 2006 00:59:32 -0400
Package: freeguide
Version: 0.10.3-1
Severity: minor


The dates of the files in '/usr/share/doc' help readers
find what's new and different.  But:

    # how many files in '/usr/share/doc/freeguide'?
    % ls /usr/share/doc/freeguide | wc -l
    16

    # count repeats of the 16 file dates in '/usr/share/doc/freeguide'
    # first column is the count.
    % ls -l /usr/share/doc/freeguide | cut -b 30-41 | sed '/^$/d' | sort | uniq -c
          1 Apr 13 11:40
          1 Apr 13 11:58
          1 Apr 13 15:24
         13 Apr 13 15:48	# 13 of this one.

Something's needlessly advancing the dates, even though some files,
('README.Debain' for example), apparently haven't changed since 2004.  

User experience: I'd read the new changelog, it said there was a new upstream
version, so I was trying to learn what's new by looking at the dates
in '/usr/share/doc/freeguide'; that doesn't work when the dates are
the same.

It would be better if each file was dated by its most recent change of
content.

Hope this helps...


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Versions of packages freeguide depends on:
ii  gij [java-virtual-machine]    4:4.0.3-3  The GNU Java bytecode interpreter
ii  gij-4.0 [java-virtual-machine 4.0.3-1    The GNU Java bytecode interpreter
ii  j2re1.4 [java2-runtime]       1.4.2.03-1 Blackdown Java(TM) 2 Runtime Envir
ii  xmltv-gui                     0.5.42-4   Graphical user interface related t

Versions of packages freeguide recommends:
ii  xmltv-util                    0.5.42-4   Utilities related to the XMLTV fil

-- no debconf information



Information forwarded to debian-bugs-dist@lists.debian.org, Shaun Jackman <sjackman@debian.org>:
Bug#362699; Package freeguide. Full text and rfc822 format available.

Acknowledgement sent to "Shaun Jackman" <sjackman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Shaun Jackman <sjackman@debian.org>. Full text and rfc822 format available.

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

From: "Shaun Jackman" <sjackman@gmail.com>
To: "A. Costa" <agcosta@gis.net>, 362699@bugs.debian.org
Subject: Re: Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
Date: Sat, 15 Apr 2006 11:44:37 -0600
Although it's an admirable goal to have the timestamps of the
documents represent their most recent change, I'm not sure it's
feasible without a gross ammount of effort. The thirteen files with
the time stamp of 2006-04-13 13:48 are all upstream documentation. The
time stamps are munged by any number of processes, including
generating the HTML file from the DocBook XML file.

The Debian specific documentation is another matter. I should be able
to keep the time stamps of README.Debian, changelog.Debian and
copyright correct. I'll keep this in mind the next time I do a
maintenance release of FreeGuide.

Cheers,
Shaun

On 4/14/06, A. Costa <agcosta@gis.net> wrote:
> Package: freeguide
> Version: 0.10.3-1
> Severity: minor
>
>
> The dates of the files in '/usr/share/doc' help readers
> find what's new and different.  But:
>
>     # how many files in '/usr/share/doc/freeguide'?
>     % ls /usr/share/doc/freeguide | wc -l
>     16
>
>     # count repeats of the 16 file dates in '/usr/share/doc/freeguide'
>     # first column is the count.
>     % ls -l /usr/share/doc/freeguide | cut -b 30-41 | sed '/^$/d' | sort | uniq -c
>           1 Apr 13 11:40
>           1 Apr 13 11:58
>           1 Apr 13 15:24
>          13 Apr 13 15:48        # 13 of this one.
>
> Something's needlessly advancing the dates, even though some files,
> ('README.Debain' for example), apparently haven't changed since 2004.
>
> User experience: I'd read the new changelog, it said there was a new upstream
> version, so I was trying to learn what's new by looking at the dates
> in '/usr/share/doc/freeguide'; that doesn't work when the dates are
> the same.
>
> It would be better if each file was dated by its most recent change of
> content.
>
> Hope this helps...

Information forwarded to debian-bugs-dist@lists.debian.org, Shaun Jackman <sjackman@debian.org>:
Bug#362699; Package freeguide. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and forwarded to list. Copy sent to Shaun Jackman <sjackman@debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: 362699@bugs.debian.org
Subject: Re: Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
Date: Tue, 18 Apr 2006 01:01:50 -0400
On Sat, 15 Apr 2006 11:44:37 -0600
"Shaun Jackman" <sjackman@gmail.com> wrote:

> Although it's an admirable goal to have the timestamps of the
> documents represent their most recent change, I'm not sure it's
> feasible without a gross ammount of effort. The thirteen files with
> the time stamp of 2006-04-13 13:48 are all upstream documentation. The
> time stamps are munged by any number of processes, including
> generating the HTML file from the DocBook XML file.

I can imagine.  This might be considered an upstream bug, yet in cases
where upstream won't fix it the question is should Debian?  If so, how?

I'm thinking there could be some new util that would take care of this
for maintainers.  That is, as soon as a Debian package is first
created, that'd be Debian day #1, (we won't worry about upstream day
#1), so our util would:

	1) save a list of doc filenames, dates, and checksums.[1]

...then for the next package version it would:

	2) do step #1 again, then go through every file, 
	   compare the respective checksums, and backdate
	   anything that hadn't changed. [2]

This isn't hard to code, but not being a Debian developer I don't know
where in the DD's tool chain it ought to fit.  That is, would this
hypothetical util belong in a new package or an old one.

Another thing to decide would be for cases where Debian takes one doc
file and converts it to another format, should the converted file keep
the original file's date?  Note: if nothing has changed, the converted
file, if needlessly reconverted on every new Debian version, should at
least keep the date of the last differing conversion.

> The Debian specific documentation is another matter. I should be able
> to keep the time stamps of README.Debian, changelog.Debian and
> copyright correct. I'll keep this in mind the next time I do a
> maintenance release of FreeGuide.

That'd be good too.  Thanks for maintaining the package!

Notes (sample code, shell script):

[1]
	# print doc filenames, age in seconds since 1970, and a checksum
	% find /usr/share/doc/freeguide/ -type f -printf "%p %C@\n" | while read a b ; do c=`crc32 $a`; echo $a $b $c ; done
	/usr/share/doc/freeguide/changelog.Debian.gz 1145074130 c55a8f7b
	/usr/share/doc/freeguide/README.html 1145074130 8b7d21cd
	/usr/share/doc/freeguide/LookAndFeel.html 1145074130 2bd3a502
	/usr/share/doc/freeguide/FAQ.html 1145074130 450e8849
	/usr/share/doc/freeguide/developers-cvs.html 1145074130 02ff06ff
	/usr/share/doc/freeguide/design.html 1145074130 aff331b7
	/usr/share/doc/freeguide/timezone.html 1145074130 058339ae
	/usr/share/doc/freeguide/developers-translating.html 1145074130 ab97f4bb
	/usr/share/doc/freeguide/developers-compiling.html 1145074130 ce37dcdf
	/usr/share/doc/freeguide/copyright 1145074130 fa4238eb
	/usr/share/doc/freeguide/INSTALL-linux-noxmltv.html 1145074130 53f80ae8
	/usr/share/doc/freeguide/FreeGuide-0_7-Linux-MetalLookAndFeel.png 1145074130 685e90d7
	/usr/share/doc/freeguide/sflogo.png 1145074130 181d6e96
	/usr/share/doc/freeguide/README.Debian 1145074130 4677978f
	/usr/share/doc/freeguide/stylesheet.css 1145074130 cf321ee9
	/usr/share/doc/freeguide/TODO 1145074130 4c992358

(Seconds since 1970 are easiest to compare, being just one number.)

[2]
	# backdate a file to 'n' seconds, using 'date' and 'touch'.
	% f=/tmp/foo
	% echo > $f	# make a temporary file
	% ls -gG $f	# show its date is the present
	-rw-r--r-- 1 1 Apr 18 00:44 /tmp/foo
	% n=1145074130		# Apr 15, in seconds since 1970.
	% t=`date -d '1970-01-01 UTC '$n' seconds' +"%Y-%m-%d %T"`
	% touch -d "$t" $f
	% ls -gG $f	# show its been backdated
	-rw-r--r-- 1 1 Apr 15 00:08 /tmp/foo

Etc...  I haven't coded any of the main loops or Debian policy stuff,
but the above snippets should demonstrate the trickier parts as far as
file date I/O goes.



Information forwarded to debian-bugs-dist@lists.debian.org, Shaun Jackman <sjackman@debian.org>:
Bug#362699; Package freeguide. Full text and rfc822 format available.

Acknowledgement sent to "Shaun Jackman" <sjackman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Shaun Jackman <sjackman@debian.org>. Full text and rfc822 format available.

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

From: "Shaun Jackman" <sjackman@gmail.com>
To: agcosta@gis.net, 362699@bugs.debian.org
Subject: Re: Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
Date: Tue, 18 Apr 2006 07:40:59 -0600
On 4/17/06, A. Costa <agcosta@gis.net> wrote:
> On Sat, 15 Apr 2006 11:44:37 -0600
> "Shaun Jackman" <sjackman@gmail.com> wrote:
>
> > Although it's an admirable goal to have the timestamps of the
> > documents represent their most recent change, I'm not sure it's
> > feasible without a gross ammount of effort. The thirteen files with
> > the time stamp of 2006-04-13 13:48 are all upstream documentation. The
> > time stamps are munged by any number of processes, including
> > generating the HTML file from the DocBook XML file.
>
> I can imagine.  This might be considered an upstream bug, yet in cases
> where upstream won't fix it the question is should Debian?  If so, how?
>
> I'm thinking there could be some new util that would take care of this
> for maintainers.  That is, as soon as a Debian package is first
...
> This isn't hard to code, but not being a Debian developer I don't know
> where in the DD's tool chain it ought to fit.  That is, would this
> hypothetical util belong in a new package or an old one.

This hypothetical tool should belong to the debhelper tool suite. It
is most related to the dh_installdocs tool. At least, dh_installdocs
copies the documents into the package, and it could also possibly set
the time stamps. Where it gets the time stamp information from is
another matter. Alternatively, there is a tool dh_fixperms that goes
through the package fixing permission modes. A new utility,
dh_fixtimestamps, could operate in the same vein.

I'm going to reassign this bug as a wishlist item to the debhelper package.

> Another thing to decide would be for cases where Debian takes one doc
> file and converts it to another format, should the converted file keep
> the original file's date?  Note: if nothing has changed, the converted
> file, if needlessly reconverted on every new Debian version, should at
> least keep the date of the last differing conversion.

Preferably, the installed document should have the same time stamp as
the document's source file.

> > The Debian specific documentation is another matter. I should be able
> > to keep the time stamps of README.Debian, changelog.Debian and
> > copyright correct. I'll keep this in mind the next time I do a
> > maintenance release of FreeGuide.
>
> That'd be good too.  Thanks for maintaining the package!

I'm afraid fixing the time stamps of the Debian documentation is
actually *harder* than fixing the time stamps of the upstream
documentation. The Debian documentation is distributed in a patch
(.diff) file, which does not include any time stamp information -- or
any meta-data at all for that matter, such as file permissions! So,
every time one unpacks the source package, the time stamps of all the
Debian documentation take the time of the unpacking.

Cheers,
Shaun

Severity set to `wishlist'. Request was from "Shaun Jackman" <sjackman@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `freeguide' to `debhelper'. Request was from "Shaun Jackman" <sjackman@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from "Shaun Jackman" <sjackman@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to Joey Hess <joeyh@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to "A. Costa" <agcosta@gis.net>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #31 received at 362699-done@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 362699-done@bugs.debian.org
Subject: re: dh_fixtimestamps
Date: Tue, 18 Apr 2006 14:41:46 -0400
[Message part 1 (text/plain, inline)]
This bug report suggests going to too great lengths to preserve time stamps.
Debian policy has the following to say:

     Maintainers should preserve the modification times of the upstream
     source files in a package, as far as is reasonably possible.

This formulation was, IIRC, chosen because we want packages to preserve
timestamps of files, where possible, but not go to absurd lengths to do so.
Therefore, debhelper is careful to preserve timestamps while installing
dcumentation and other files, by using cp -a and install -p. 

Going any further, by trying to somehow preserve timestamps of files created
by the Debian diff just violates the KISS principle. Trying to make compiled
files have the same source timestamp as the source file goes a step further
and is just wrong.

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

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#362699; Package debhelper. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: 362699@bugs.debian.org
Cc: "Shaun Jackman" <sjackman@gmail.com>
Subject: Re: Bug#362699 acknowledged by developer (re: dh_fixtimestamps)
Date: Sat, 22 Apr 2006 01:49:56 -0400
On Tue, 18 Apr 2006 11:48:27 -0700
owner@bugs.debian.org (Debian Bug Tracking System) wrote:

> This bug report suggests going to too great lengths to preserve time
> stamps. Debian policy has the following to say:
> 
>      Maintainers should preserve the modification times of the
> upstream source files in a package, as far as is reasonably possible.
> 
> This formulation was, IIRC, chosen because we want packages to
> preserve timestamps of files, where possible, but not go to absurd
> lengths to do so. Therefore, debhelper is careful to preserve
> timestamps while installing dcumentation and other files, by using cp
> -a and install -p. 
> 
> Going any further, by trying to somehow preserve timestamps of files
> created by the Debian diff just violates the KISS principle. Trying
> to make compiled files have the same source timestamp as the source
> file goes a step further and is just wrong.

Your opinion might be correct; if so it deserves better support.
These phrases say the same thing: "too great lengths", "reasonably
possible", "absurd lengths", "KISS (=Keep It Simple Stupid)", "just
wrong".   All beg the question[1] of whether using an ad-hoc util to
correct spurious dates or timestamps is worthwhile. 

In the meantime I'd gladly reopen this bug, but fear of the wrath
of Joey!  Perhaps if the official methods are lacking, unofficial
methods can be arrived at elsewhere.

For the record, a few notes on simplicity and logical circularity:

Supposing a problem is complex or simple.  If the problem is complex,
then it might necessarily require a complex solution, and cherished
'KISS' principles don't apply.  If the problem is simple, the solution
might be complex even so, as with various mathematical chestnuts.  In
either case, a solution should be as simple as possible, and that's
the best we can do.

Is the solution offered for backdating unchanged doc files truly
complex?  I'm not sure, to me it seems too obvious to be called that.
Is it the simplest possible way?  Maybe not, there might be some better way.

Note that a top-down universal util that tries to fix all instances of
incorrect doc dates isn't the idea.  There are probably more
strange cases and exceptions than one method can handle.  But a
small util that reliably fixed a subset of the problem would be
progress.


[1] http://www.fallacyfiles.org/begquest.html
    http://www.nizkor.org/features/fallacies/begging-the-question.html  (better {borrowed} examples) 



Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#362699; Package debhelper. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: "Shaun Jackman" <sjackman@gmail.com>
Cc: 362699@bugs.debian.org
Subject: Re: Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
Date: Sat, 22 Apr 2006 02:00:31 -0400
On Tue, 18 Apr 2006 07:40:59 -0600
"Shaun Jackman" <sjackman@gmail.com> wrote:

> This hypothetical tool should belong to the debhelper tool suite. It
> is most related to the dh_installdocs tool. At least, dh_installdocs
> copies the documents into the package, and it could also possibly set
> the time stamps. Where it gets the time stamp information from is
> another matter. Alternatively, there is a tool dh_fixperms that goes
> through the package fixing permission modes. A new utility,
> dh_fixtimestamps, could operate in the same vein.
> 
> I'm going to reassign this bug as a wishlist item to the debhelper
> package.

Thanks for making the call, but just as the little bug was a symptom
of a bigger systemic bug, now the bigger bug closing is perhaps a
symptom of the biggest bug yet; the BTS makes it very easy for
overworked maintainers to forget what they're doing here, and
maintainers are their own guardians.  (And on the whole, they do a
great job, considering human nature...)

To elaborate, the maintainer of 'debhelper' sees that the wishlist
remedy seems to contradict his vision of packaging simplicity and
elegance; fair enough, but then he forgets that the origin of this bug was
a symptom, not a proposed remedy -- that is, closing the wishlist bug
neither solves the problem of useful date information being lost in
'/usr/share/doc' nor addresses the symptom in 'freeguide'.  Assuming
that a wishlist was indeed a bad idea, then to make the best use of the
BTS, the bug should be reclassified to wherever it best fits; or put
aside until it makes more sense.  For example, it might be reassigned
back to 'freeguide' and tagged 'upstream' or 'wontfix'.

> > Another thing to decide would be for cases where Debian takes one
> > doc file and converts it to another format, should the converted
> > file keep the original file's date?  Note: if nothing has changed,
> > the converted file, if needlessly reconverted on every new Debian
> > version, should at least keep the date of the last differing
> > conversion.
> 
> Preferably, the installed document should have the same time stamp as
> the document's source file.

Preferably, but I'm thinking of cases where the automated conversion
adds or subtracts enough data to make its revision noteworthy.  Suppose
a man2info converter deletes boilerplate paragraphs about "see the info
page" since those are redundant in the info page itself.  Would that be
different enough to deserve a new date?

> > > The Debian specific documentation is another matter. I should be
> > > able to keep the time stamps of README.Debian, changelog.Debian
> > > and copyright correct. I'll keep this in mind the next time I do a
> > > maintenance release of FreeGuide.
> >
> > That'd be good too.  Thanks for maintaining the package!
> 
> I'm afraid fixing the time stamps of the Debian documentation is
> actually *harder* than fixing the time stamps of the upstream
> documentation. The Debian documentation is distributed in a patch
> (.diff) file, which does not include any time stamp information -- or
> any meta-data at all for that matter, such as file permissions! So,
> every time one unpacks the source package, the time stamps of all the
> Debian documentation take the time of the unpacking.

I dunno, a patch, a doc, what's the difference?  If the patch is later
than the original doc, then the resulting patched doc should have the
date of the patch.  A patch is just an abbreviation for a whole new
file; think of a patch as a revised edition and it becomes
straightforward.  

Perhaps I've misunderstood what you're saying about Debian's patch
system.  Did you mean that all patches, old or new, are "born yesterday"
on unpacking?



Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#362699; Package debhelper. Full text and rfc822 format available.

Acknowledgement sent to "Shaun Jackman" <sjackman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. Full text and rfc822 format available.

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

From: "Shaun Jackman" <sjackman@gmail.com>
To: agcosta@gis.net
Cc: 362699@bugs.debian.org
Subject: Re: Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
Date: Sat, 22 Apr 2006 14:10:23 -0600
On 4/22/06, A. Costa <agcosta@gis.net> wrote:
...
> > I'm going to reassign this bug as a wishlist item to the debhelper
> > package.
>
> Thanks for making the call, but just as the little bug was a symptom
> of a bigger systemic bug, now the bigger bug closing is perhaps a
> symptom of the biggest bug yet; the BTS makes it very easy for
> overworked maintainers to forget what they're doing here, and
> maintainers are their own guardians.  (And on the whole, they do a
> great job, considering human nature...)
>
> To elaborate, the maintainer of 'debhelper' sees that the wishlist
> remedy seems to contradict his vision of packaging simplicity and
> elegance; fair enough, but then he forgets that the origin of this bug was
> a symptom, not a proposed remedy -- that is, closing the wishlist bug
> neither solves the problem of useful date information being lost in
> '/usr/share/doc' nor addresses the symptom in 'freeguide'.  Assuming
> that a wishlist was indeed a bad idea, then to make the best use of the
> BTS, the bug should be reclassified to wherever it best fits; or put
> aside until it makes more sense.  For example, it might be reassigned
> back to 'freeguide' and tagged 'upstream' or 'wontfix'.

The bug probably shouldn't be closed. I would tag it wontfix, and post
it on debian-devel for discussion. That dpkg-source doesn't preserve
time stamps is a straight-forward bug.

> > Preferably, the installed document should have the same time stamp as
> > the document's source file.
>
> Preferably, but I'm thinking of cases where the automated conversion
> adds or subtracts enough data to make its revision noteworthy.  Suppose
> a man2info converter deletes boilerplate paragraphs about "see the info
> page" since those are redundant in the info page itself.  Would that be
> different enough to deserve a new date?

Any conversion performed on a regular, automated basis doesn't warrant
updating the time stamp. However, if a developer runs help2man once by
hand to create a man page, I would update the time stamp.

> > I'm afraid fixing the time stamps of the Debian documentation is
> > actually *harder* than fixing the time stamps of the upstream
> > documentation. The Debian documentation is distributed in a patch
...
> Perhaps I've misunderstood what you're saying about Debian's patch
> system.  Did you mean that all patches, old or new, are "born yesterday"
> on unpacking?

Exactly. Time stamp information is meta-data, and a lot of mediums
don't preserve meta-data. For example, when a document is attached to
an email, typically the time stamps, permissions, et cetera are all
lost. Likewise for the Debian diff. All the Debian packaging,
including documentation, is packaged in the diff, and by default,
debuild does not preserve the time stamp meta-data in the diff. I
don't know why this is though, because diff does, by default, preserve
the time stamp meta-data.

Cheers,
Shaun

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#362699; Package debhelper. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: "Shaun Jackman" <sjackman@gmail.com>
Cc: 362699@bugs.debian.org
Subject: Re: Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
Date: Wed, 26 Apr 2006 03:00:28 -0400
On Sat, 22 Apr 2006 14:10:23 -0600
"Shaun Jackman" <sjackman@gmail.com> wrote:

> The bug probably shouldn't be closed. I would tag it wontfix, and post
> it on debian-devel for discussion. 

I'm with you for reopening and reclassifying, but I don't mix well with
'-devel', so far anyway.  Irreconcilable humor differences, maybe.

> That dpkg-source doesn't preserve
> time stamps is a straight-forward bug.

Has it been reported already?  

> Any conversion performed on a regular, automated basis doesn't warrant
> updating the time stamp. However, if a developer runs help2man once by
> hand to create a man page, I would update the time stamp.

That's reasonable.

> > Perhaps I've misunderstood what you're saying about Debian's patch
> > system.  Did you mean that all patches, old or new, are "born
> > yesterday" on unpacking?
> 
> Exactly. Time stamp information is meta-data, and a lot of mediums
> don't preserve meta-data. For example, when a document is attached to
> an email, typically the time stamps, permissions, et cetera are all
> lost. 

That sounds like another argument in favor of .zip or .tgz attachements,
when necessary.

> Likewise for the Debian diff. All the Debian packaging,
> including documentation, is packaged in the diff, and by default,
> debuild does not preserve the time stamp meta-data in the diff. I
> don't know why this is though, because diff does, by default, preserve
> the time stamp meta-data.

A question...  my typo fixes all use '.diff' files.  I used to use the
default 'diff' format which looked like this:

	% echo hello world > /tmp/A
	% echo Jello World > /tmp/B
	% diff /tmp/[AB]
	1c1
	< hello world
	---
	> Jello World

...then as per the useful critique of C. Wilson, I started using the '-u'
switch:

	% diff -u /tmp/[AB]
	--- /tmp/A      2006-04-26 02:43:41.000000000 -0400
	+++ /tmp/B      2006-04-26 02:44:00.000000000 -0400
	@@ -1 +1 @@
	-hello world
	+Jello World

Now it looks like the latter 'diff -u' keeps a time stamp, while the
former (default) 'diff' does not.  But you're saying that the default
of 'diff' does preserve time stamps.  Seems like a mix-up.

Either way though, I'd agree that it would be useful for our purposes to
have time stamps in patches, unless there are compelling though seldom
heard reasons not to.  



Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#362699; Package debhelper. Full text and rfc822 format available.

Acknowledgement sent to "Shaun Jackman" <sjackman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. Full text and rfc822 format available.

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

From: "Shaun Jackman" <sjackman@gmail.com>
To: agcosta@gis.net
Cc: 362699@bugs.debian.org
Subject: Re: Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
Date: Wed, 26 Apr 2006 10:39:51 -0600
On 4/26/06, A. Costa <agcosta@gis.net> wrote:
> On Sat, 22 Apr 2006 14:10:23 -0600
> "Shaun Jackman" <sjackman@gmail.com> wrote:
>
> > The bug probably shouldn't be closed. I would tag it wontfix, and post
> > it on debian-devel for discussion.
>
> I'm with you for reopening and reclassifying, but I don't mix well with
> '-devel', so far anyway.  Irreconcilable humor differences, maybe.

Hold off on the debhelper bug for now, perhaps. The dpkg-source
utility from the dpkg-dev package seems like a better place to start.

> > That dpkg-source doesn't preserve
> > time stamps is a straight-forward bug.
>
> Has it been reported already?

Not yet.

> > Likewise for the Debian diff. All the Debian packaging,
> > including documentation, is packaged in the diff, and by default,
> > debuild does not preserve the time stamp meta-data in the diff. I
> > don't know why this is though, because diff does, by default, preserve
> > the time stamp meta-data.
>
> A question...  my typo fixes all use '.diff' files.  I used to use the
> default 'diff' format which looked like this:
...
> ...then as per the useful critique of C. Wilson, I started using the '-u'
> switch:
...
> Now it looks like the latter 'diff -u' keeps a time stamp, while the
> former (default) 'diff' does not.  But you're saying that the default
> of 'diff' does preserve time stamps.  Seems like a mix-up.

Debian uses (and most of the open-source world) uses unified (-u)
diffs. I meant diff -u includes the time stamp information by default.

> Either way though, I'd agree that it would be useful for our purposes to
> have time stamps in patches, unless there are compelling though seldom
> heard reasons not to.

I would be interested to hear any argument against including the time
stamp information in the .diff.gz.

Cheers,
Shaun

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#362699; Package debhelper. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: "Shaun Jackman" <sjackman@gmail.com>
Cc: 362699@bugs.debian.org
Subject: Re: Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
Date: Tue, 9 May 2006 03:05:59 -0400
On Wed, 26 Apr 2006 10:39:51 -0600
"Shaun Jackman" <sjackman@gmail.com> wrote:

> Hold off on the debhelper bug for now, perhaps. The dpkg-source
> utility from the dpkg-dev package seems like a better place to start...

> > > That dpkg-source doesn't preserve
> > > time stamps is a straight-forward bug.
> >
> > Has it been reported already?
> 
> Not yet.

If you're too busy to report it I'd do it, but probably not half
as well, since I haven't yet used 'dpkg-source' and don't quite know
what to look for.  The symptoms seem plain enough though.

Looking at the bug list for 'dpkg-dev', I notice several 'dpkg-source'
bugs that mention timestamps, for instance:

	[DPKG-SOURCE] touch all patched files to avoid race conditions
	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=105750

	[DPKG-SOURCE] applying patch causes timestamps to skew and upset make
	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208276

...a quote from the latter bug:

	9/1/03 Dirk Eddelbuettel replies to Daniel Schepler:
	> I've heard this is going to be fixed in dpkg-source v2, by saving time
	> stamps in the diff.gz.

	Yes, agreed. This patching/timestamp issue is old.

Why there's no official bug for it (or if so, where) is beyond me.

> > ...Either way though, I'd agree that it would be useful for our
> > purposes to have time stamps in patches, unless there are
> > compelling though seldom heard reasons not to.
> 
> I would be interested to hear any argument against including the time
> stamp information in the .diff.gz.

<sounds of crickets chirping>



Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#362699; Package debhelper. Full text and rfc822 format available.

Acknowledgement sent to "Shaun Jackman" <sjackman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. Full text and rfc822 format available.

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

From: "Shaun Jackman" <sjackman@gmail.com>
To: "Control@BTS" <control@bugs.debian.org>
Cc: 362699@bugs.debian.org, "A. Costa" <agcosta@gis.net>
Subject: dpkg-source: Timestamps on documentation advance artificially
Date: Tue, 9 May 2006 10:22:50 -0600
clone 362699 -1
reassign -1 dpkg-dev
retitle -1 dpkg-source: Timestamps on documentation advance artificially
severity -1 normal
thanks

When dpkg-source applies the patch, the time stamp on each of the
patched files advances artificially. This makes it look as though the
documentation in /usr/share/doc/ has been modified recently at the
time the patch was applied, rather than its actual modification date.

See also...

	dpkg-dev
	[DPKG-SOURCE] touch all patched files to avoid race conditions
	http://bugs.debian.org/105750

	dpkg-dev
	[DPKG-SOURCE] applying patch causes timestamps to skew and upset make
	http://bugs.debian.org/208276

	debhelper
	Feature request: dh_fixtimestamps
	http://bugs.debian.org/362699

Quoting from #208276...

	9/1/03 Dirk Eddelbuettel replies to Daniel Schepler:
	> I've heard this is going to be fixed in dpkg-source v2, by saving
	> time stamps in the diff.gz.

	Yes, agreed. This patching/timestamp issue is old.

Cheers,
Shaun

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#362699; Package debhelper. Full text and rfc822 format available.

Acknowledgement sent to "Shaun Jackman" <sjackman@gmail.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. Full text and rfc822 format available.

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

From: "Shaun Jackman" <sjackman@gmail.com>
To: agcosta@gis.net
Cc: 362699@bugs.debian.org
Subject: Re: Bug#362699: files in '/usr/share/doc/freeguide' all have same date.
Date: Tue, 9 May 2006 10:29:35 -0600
On 5/9/06, A. Costa <agcosta@gis.net> wrote:
> If you're too busy to report it I'd do it, but probably not half
> as well, since I haven't yet used 'dpkg-source' and don't quite know
> what to look for.  The symptoms seem plain enough though.

OK, done. You should see a report on dpkg-dev soon. Thanks for bugging me. =P

>         9/1/03 Dirk Eddelbuettel replies to Daniel Schepler:
>         > I've heard this is going to be fixed in dpkg-source v2, by saving time
>         > stamps in the diff.gz.
>
>         Yes, agreed. This patching/timestamp issue is old.

This issue is quite clear-cut and really ought to be fixed. It's a
semi-major change, but I would certainly suggest issuign a new release
of dpkg-dev that adds only this one feature. Let people acclimatise to
it, and I'm sure the world wouldn't end. I don't think it's necessary
to wait for the mythical dpkg-dev v2.

> > > ...Either way though, I'd agree that it would be useful for our
> > > purposes to have time stamps in patches, unless there are
> > > compelling though seldom heard reasons not to.
> >
> > I would be interested to hear any argument against including the time
> > stamp information in the .diff.gz.
>
> <sounds of crickets chirping>

I want to go camping in the country now. <smirk>

Cheers,
Shaun

Bug 362699 cloned as bug 366555. Request was from "Shaun Jackman" <sjackman@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `debhelper' to `dpkg-dev'. Request was from "Shaun Jackman" <sjackman@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from "Shaun Jackman" <sjackman@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `normal'. Request was from "Shaun Jackman" <sjackman@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reopened, originator not changed. Request was from "Shaun Jackman" <sjackman@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Information stored:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #86 received at 366555-quiet@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: debian-dpkg@lists.debian.org
Subject: sourcev3 branch - quilt based source package
Date: Sat, 15 Mar 2008 15:24:33 +0100
Hello,

I pushed the last (functional) changes that I wanted to have in the
sourcev3 branch: a module handling a format named "3.0 (quilt)" which
is wig&pen based. I made the choice to directly use quilt if available
so that after extraction, one can continue to use quilt without finding a
way to recreate the ".pc" directory. Also the source generation is smart
enough to ignore this directory.

I would like some people to try running the code in that branch and report
problems/suggestions. I built the package for your convenience:
http://people.debian.org/~hertzog/packages/dpkg_1.14.17~srcv3_i386.changes

Using a new source format can be done either by adding a "Format: 3.0
(quilt/git/native)" field to debian/control (in the source stanza) or
adding a parameter to dpkg-source like:
dpkg-source "--format=3.0 (quilt)" -b package-X.Y/

We're approaching a state where it could be merged. What's left is:
- update entirely the dpkg-source manual page
- add non-regression tests on (some of) the modules created
- copy upstream tarballs in the extraction directory for
  all formats (and take it the relevant part out of the Format: 1.0 code).

My personal wish is that the new format "3.0 (quilt)" becomes the default
build format in lenny+1 (as soon as ftp-master accept it).

We also have a bunch of wishlist bugs against dpkg-source and I wonder
which are important enough to warrant changes and/or addition of new
features in the "3.0 (quilt)" format. Your comments are welcome... please
put in CC the relevant bugs.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366555
Right now, all patched files are modified to have the same timestamp and
the generated patches do not contain timestamps. This bug request the
inclusion of timestamp in patches files and that the timestamp be
respected at unpack time. Given everything I've read in the BTS, I'm not
sure it's a good idea.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=4588
Support addition of binary files. Now that the debian directory
is stored in a separate tarball, it's possible to add binary files
in the debian directory but it's not possible to add them directly in some
upstream directory, they have to be moved in place at build time if
needed. Is that enough to consider this bug solved?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=12564
Allow removal of files with patches. I think I'm going to implement this
one. It simply requires adding -E to the patch call and quilt already
use -E by default. However I won't change the fact that a removed file
is ignored during generation of a patch (at least by default, maybe I'll
add an option to change this behaviour).

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435126
Ignore by default all VCS specific directories in native tarballs.

There are
Cheers,
-- 
Raphaël Hertzog

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




Message sent on to "A. Costa" <agcosta@gis.net>:
Bug#366555. Full text and rfc822 format available.

Information stored:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #94 received at 366555-quiet@bugs.debian.org (full text, mbox):

From: "A. Costa" <agcosta@gis.net>
To: Raphael Hertzog <hertzog@debian.org>, 366555-quiet@bugs.debian.org
Subject: Re: Bug#366555: sourcev3 branch - quilt based source package
Date: Sun, 16 Mar 2008 01:41:01 -0400
On Sat, 15 Mar 2008 15:24:33 +0100
Raphael Hertzog <hertzog@debian.org> wrote:

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366555
> Right now, all patched files are modified to have the same timestamp
> and the generated patches do not contain timestamps. This bug requests
> the inclusion of timestamp in patches files and that the timestamp be
> respected at unpack time. Given everything I've read in the BTS, I'm
> not sure it's a good idea.

Could you elaborate, time permitting?  No rush, especially since your
blanket message suggests there's a lot going on elsewhere.

Note: users would be more interested in the result than the method.
Namely that the files in '/usr/share/doc/freeguide', (and some other
dirs, no doubt), all have the same undistinctive date, which is akin
to having no dates.  Therefore if your (pending?) method-based critique
is accurate that the patch/timestamp method above was unfeasible, I'd
say "let's think of a better method".




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: "A. Costa" <agcosta@gis.net>
Cc: 366555@bugs.debian.org
Subject: Re: Bug#366555: sourcev3 branch - quilt based source package
Date: Sun, 16 Mar 2008 11:11:22 +0100
On Sun, 16 Mar 2008, A. Costa wrote:
> On Sat, 15 Mar 2008 15:24:33 +0100
> Raphael Hertzog <hertzog@debian.org> wrote:
> 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366555
> > Right now, all patched files are modified to have the same timestamp
> > and the generated patches do not contain timestamps. This bug requests
> > the inclusion of timestamp in patches files and that the timestamp be
> > respected at unpack time. Given everything I've read in the BTS, I'm
> > not sure it's a good idea.
> 
> Could you elaborate, time permitting?  No rush, especially since your
> blanket message suggests there's a lot going on elsewhere.
> 
> Note: users would be more interested in the result than the method.
> Namely that the files in '/usr/share/doc/freeguide', (and some other
> dirs, no doubt), all have the same undistinctive date, which is akin
> to having no dates.  Therefore if your (pending?) method-based critique
> is accurate that the patch/timestamp method above was unfeasible, I'd
> say "let's think of a better method".

The long bug log clearly says that there's no point to try to conserve
timestamps for generated documentation. And I agree with that.

However with the new source format we have several changes:
- files in the debian directory are stored in a .tar.gz and thus we will
  conserve their timestamp
- but files patched by one or more of the patches in debian/patches/ will
  always have a timestamp that advances artificially at each unpack. This
  is required because if we don't ajust their timestamp to a single value,
  the timestamp difference means that we can have tricky side-effects
  like regeneration of some files due to timestamp skew (e.g. when you patch
  *.ac or *.in files from autoconf/automake)

Cheers,
-- 
Raphaël Hertzog

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 366555@bugs.debian.org
Subject: Re: Bug#366555: dpkg-source: Timestamps on documentation advance artificially
Date: Tue, 18 Mar 2008 00:45:25 -0400
On Sun, 16 Mar 2008 11:11:22 +0100
Raphael Hertzog <hertzog@debian.org> wrote:

> The long bug log clearly says that there's no point to try to conserve
> timestamps for generated documentation. And I agree with that.

Time permitting, would you kindly tell me where it says that?  I reread
the whole BTS log for #366555 yesterday, but might have missed or
even misread something.

> However with the new source format we have several changes:
> - files in the debian directory are stored in a .tar.gz and thus we
> will conserve their timestamp

Sounds good.

> - but files patched by one or more of the patches in debian/patches/
> will always have a timestamp that advances artificially at each
> unpack. This is required because if we don't ajust their timestamp to
> a single value, the timestamp difference means that we can have
> tricky side-effects like regeneration of some files due to timestamp
> skew (e.g. when you patch *.ac or *.in files from autoconf/automake)

IANADD, could you or somebody give a less abstract example?  Suppose
'/usr/share/doc/freeguide/FAQ.html' was dated a week earlier than
'/usr/share/doc/freeguide/TODO'; what bad thing would happen?

(If it matters, I'm mainly curious about 'doc' dates, not so
much binaries.)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: "A. Costa" <agcosta@gis.net>
Cc: 366555@bugs.debian.org
Subject: Re: Bug#366555: dpkg-source: Timestamps on documentation advance artificially
Date: Tue, 18 Mar 2008 08:11:35 +0100
On Tue, 18 Mar 2008, A. Costa wrote:
> > The long bug log clearly says that there's no point to try to conserve
> > timestamps for generated documentation. And I agree with that.
> 
> Time permitting, would you kindly tell me where it says that?  I reread
> the whole BTS log for #366555 yesterday, but might have missed or
> even misread something.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366555#31

I totally agree with Joey's comment. Adding supplementary infrastructure
to conserve timestamp on generated files is just a waste of time.
and over-engineering for very little value.

> > - but files patched by one or more of the patches in debian/patches/
> > will always have a timestamp that advances artificially at each
> > unpack. This is required because if we don't ajust their timestamp to
> > a single value, the timestamp difference means that we can have
> > tricky side-effects like regeneration of some files due to timestamp
> > skew (e.g. when you patch *.ac or *.in files from autoconf/automake)
> 
> IANADD, could you or somebody give a less abstract example?  Suppose
> '/usr/share/doc/freeguide/FAQ.html' was dated a week earlier than
> '/usr/share/doc/freeguide/TODO'; what bad thing would happen?

Nothing of course. But it's not the same when we speak of "configure" and
"configure.ac" and dpkg-source must not a different behaviour depending
on the filename that it patches, it's just too error-prone.

If you have a Makefile rule:
configure: configure.ac
	#regenerate configure

Then the fact that configure.ac is newer than configure will imply
execution of the rule when it's not wanted.

Cheers,
-- 
Raphaël Hertzog

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 366555@bugs.debian.org
Subject: Re: Bug#366555: dpkg-source: Timestamps on documentation advance artificially
Date: Thu, 20 Mar 2008 00:42:42 -0400
On Tue, 18 Mar 2008 08:11:35 +0100
Raphael Hertzog <hertzog@debian.org> wrote:

> On Tue, 18 Mar 2008, A. Costa wrote:
> > > The long bug log clearly says that there's no point to try to
> > > conserve timestamps for generated documentation. And I agree with
> > > that.
> > 
> > Time permitting, would you kindly tell me where it says that?  I
> > reread the whole BTS log for #366555 yesterday, but might have
> > missed or even misread something.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366555#31
> 
> I totally agree with Joey's comment. Adding supplementary
> infrastructure to conserve timestamp on generated files is just a
> waste of time. and over-engineering for very little value.

Thanks for the clarification.  Unfortunately, it therefore follows I'd
be favoring time wasting over-engineering --- provided of course, there
were only two possible ways of dealing with the bug,
(1. the wrong way, or 2. no fix at all).

But as was suggested to the emphatic JH back in 4/2006, there might be
more than one way to do it:

	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366555#36

(Your replies come in fast, but we've been spending a lot of email
time backtracking.  Perhaps lately you're too busy, rushing about with
the DPL thing, for my discursive style of email?  And good luck with
that election, here's hoping your ideas on "transparency and
communication" will bear fruit!)

Re: "very little value", that's harsh.  No objection if you meant
"relatively little value", which allows for different priorities
and preferences.

> > > - but files patched by one or more of the patches in
> > > debian/patches/ will always have a timestamp that advances
> > > artificially at each unpack. This is required because if we don't
> > > ajust their timestamp to a single value, the timestamp difference
> > > means that we can have tricky side-effects like regeneration of
> > > some files due to timestamp skew (e.g. when you patch *.ac or
> > > *.in files from autoconf/automake)
> > 
> > IANADD, could you or somebody give a less abstract example?  Suppose
> > '/usr/share/doc/freeguide/FAQ.html' was dated a week earlier than
> > '/usr/share/doc/freeguide/TODO'; what bad thing would happen?
> 
> Nothing of course...

Would a partial fix that only affected '/usr/share/doc/*' be safe from
tricky side-effects?

> ...But it's not the same when we speak of "configure"
> and "configure.ac" and dpkg-source must not a different behaviour

"...must not a..."; sorry, is there a missing verb?

> depending on the filename that it patches, it's just too error-prone.
> 
> If you have a Makefile rule:
> configure: configure.ac
> 	#regenerate configure
> 
> Then the fact that configure.ac is newer than configure will imply
> execution of the rule when it's not wanted.

Alas IANADD, and don't know much about 'autoconf', so the meaning of
the above is Greek to me.  Maybe you're saying the problem owes more to
the 'autoconf' package than to 'dpkg-source'.  Is this one of those
political bugs, that belongs in part to several packages, but is
practically insoluble because the maintainers fight?

Summing up:  back to 4/2006.  More than one way.  RH '08.  Level of
complexity controversial.  Some methods deprecated.  Where is the bug.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: "A. Costa" <agcosta@gis.net>
Cc: 366555@bugs.debian.org
Subject: Re: Bug#366555: dpkg-source: Timestamps on documentation advance artificially
Date: Thu, 20 Mar 2008 08:22:44 +0100
On Thu, 20 Mar 2008, A. Costa wrote:
> Thanks for the clarification.  Unfortunately, it therefore follows I'd
> be favoring time wasting over-engineering --- provided of course, there
> were only two possible ways of dealing with the bug,
> (1. the wrong way, or 2. no fix at all).
> 
> But as was suggested to the emphatic JH back in 4/2006, there might be
> more than one way to do it:
> 
> 	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366555#36

To be clear: this bug #366555 is assigned to dpkg-dev and dpkg-dev
doesn't control the timestamp of generated documentation. If you want
the generated documentation to have a timestamp that matches the source,
you should just write a tool that makes it easy to do so and hope that
some maintainers will use it to fix timestamp of the generated
documentation (but I doubt it, honestly and the maintainer of debhelper is
very much a reference concerning what is a reasonable packaging helper
tool).

dpkg-dev comes into play only at one place: the timestamp of files patched
by the diff.gz (or by debian/patches/* with a newer source package
format).

Up to now all files from the debian sub-directory are installed by the
diff.gz and thus get a timestamp reset by dpkg-source. In the future, when
we switch over to the new source format the files in the debian
directory will be installed by a debian.tar.gz file and thus we will
preserve timestamps. However upstream patched files will continue to have
their timestamp reset at unpack time.

> (Your replies come in fast, but we've been spending a lot of email
> time backtracking.

Not sure what you mean, I've read the whole bug log, I do have my opinion
and it probably doesn't match your expectation...

> > > IANADD, could you or somebody give a less abstract example?  Suppose
> > > '/usr/share/doc/freeguide/FAQ.html' was dated a week earlier than
> > > '/usr/share/doc/freeguide/TODO'; what bad thing would happen?
> > 
> > Nothing of course...
> 
> Would a partial fix that only affected '/usr/share/doc/*' be safe from
> tricky side-effects?

If the files are simply copied over, their timestamp is already
preserved. And it's unlikely that we patch upstream documentation.

So no, I'm not in favor at all to add any complexity to the
timestamp-resetting rule.

> > ...But it's not the same when we speak of "configure"
> > and "configure.ac" and dpkg-source must not a different behaviour
> 
> "...must not a..."; sorry, is there a missing verb?

"have"

> > depending on the filename that it patches, it's just too error-prone.


> Alas IANADD, and don't know much about 'autoconf', so the meaning of
> the above is Greek to me.  Maybe you're saying the problem owes more to
> the 'autoconf' package than to 'dpkg-source'.  

No.

> Is this one of those political bugs, that belongs in part to several
> packages, but is practically insoluble because the maintainers fight?

No. It's the normal and expected behaviour of the autoconf tools.

Cheers,
-- 
Raphaël Hertzog

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




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: control@bugs.debian.org
Cc: 12564@bugs.debian.org, 203792@bugs.debian.org, 220758@bugs.debian.org, 246918@bugs.debian.org, 323909@bugs.debian.org, 363018@bugs.debian.org, 366555@bugs.debian.org, 435126@bugs.debian.org, 4588@bugs.debian.org, 4628@bugs.debian.org, 463048@bugs.debian.org
Subject: setting package to dselect dpkg-dev dpkg, tagging 203792, tagging 463048, tagging 4588, tagging 12564 ...
Date: Thu, 27 Mar 2008 21:26:24 +0100
# Automatically generated email from bts, devscripts version 2.10.20
#
# dpkg (1.14.17) UNRELEASED; urgency=low
#
#  * Merge of the sourcev3 branch. dpkg-source has been heavily refactored to
#    make it easier to support multiple source package formats. Several new
#    source package formats have been added:
#    - the format "2.0" is the original wig&pen
#    - the format "3.0 (quilt)" is based on 2.0. It uses a tarball for the
#      debian directory and can thus include binary files. Binaries
#      outside of the debian directory can be also included if they
#      are listed in debian/source/include-binaries (and option
#      --include-binaries will generate this file automatically).
#      Closes: #4588, #4628
#    - thus it will also preserve timestamps on Debian-provided
#      documentation like README.Debian. Closes: #366555
#    - it handles an explicit series of patches and the patch can thus be
#      named without constraints. Patches can contain arbitrary
#      headers/comments between file chunks. Closes: #363018
#    - it ignores changes on a number of temporary and VCS-specific files
#      by default. Closes: #203792, #323909
#    - the patches in debian/patches can remove files. Closes: #12564
#    - the patches are applied at unpack time. Closes: #463048
#    - the formats "3.0 (quilt/native)" don't include VCS directories by
#      default. Closes: #435126
#    - the format "3.0 (custom)" can be used to create a source package
#      containing arbitrary files. It's useful for helper tools that can
#      generate the files by themselves in a more efficient way
#      (like all the *-buildpackage tools). Closes: #246918
#    - the formats "3.0 (git/bzr)" are experimental formats based
#      on corresponding VCS repositories.
#  * dpkg-source has a new --no-check option. It disables GPG check and
#    checksums checks. Closes: #220758
#

package dselect dpkg-dev dpkg
tags 203792 + pending
tags 463048 + pending
tags 4588 + pending
tags 12564 + pending
tags 4628 + pending
tags 435126 + pending
tags 366555 + pending
tags 246918 + pending
tags 323909 + pending
tags 220758 + pending
tags 363018 + pending





Tags added: pending Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Thu, 27 Mar 2008 20:36:26 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 366555@bugs.debian.org
Subject: Re: Bug#366555: dpkg-source: Timestamps on documentation advance artificially
Date: Fri, 28 Mar 2008 03:29:33 -0400
"Pending" already.  Maybe this reply is better late than never, though
it's relevant to the earlier 'freeguide' bug log, particularly
regarding homogenized upstream dates.  Sometimes "one" bug is really
several.

On Thu, 20 Mar 2008 08:22:44 +0100
Raphael Hertzog <hertzog@debian.org> wrote:

> To be clear: this bug #366555 is assigned to dpkg-dev and dpkg-dev
> doesn't control the timestamp of generated documentation. If you want
> the generated documentation to have a timestamp that matches the
> source, you should just write a tool that makes it easy to do so and
> hope that some maintainers will use it to fix timestamp of the
> generated documentation (but I doubt it, honestly and the maintainer
> of debhelper is very much a reference concerning what is a reasonable
> packaging helper tool).

I like your idea, it'd be a workable kludge pending some eventual
systemic fix or '.deb' revision.  It might work at install time, a user
tool, rather like 'apt-listchanges' or 'localepurge'.  (See below for
details.)

But if 'dpkg-dev' isn't relevent, (IIRC Shaun Jackman reassigned it from
'freeguide' to 'dpkg-dev'), then where to assign this other (correcting
upstream dates) bug? 

> ...Up to now all files from the debian sub-directory are installed by the
> diff.gz and thus get a timestamp reset by dpkg-source. In the future,
> when we switch over to the new source format the files in the debian
> directory will be installed by a debian.tar.gz file and thus we will
> preserve timestamps. However upstream patched files will continue to
> have their timestamp reset at unpack time.

So if I understand things correctly, the 'upstream' part of a package
is inviolate, never changing.  At present there's no preservation of
patch timestamps, (always the latest patch/unpack time), and no
provision for correcting upstream metadata -- the current format
and tool chain are not designed for (you and JH argue) any such
proposed metadata functions.  For my purposes the whole source
'.deb' is virtually taboo.

> > Would a partial fix that only affected '/usr/share/doc/*' be safe
> > from tricky side-effects?
> 
> If the files are simply copied over, their timestamp is already
> preserved. And it's unlikely that we patch upstream documentation.
> 
> So no, I'm not in favor at all to add any complexity to the
> timestamp-resetting rule.

The user changing doc dates after or during the install would be OK?
Assume the source '.deb' is untouched.  Would install-time date changes
be any worse for a system than say, 'localepurge'?

Some notes on date advancement ("date creep"?) in Debian...

Here's some ad hoc coding to see how often repeat dates occur in
'/usr/share/doc', i.e. many doc files per package with the same date.
On my system's 2920 packages, five or more doc date dups occur in
about 1200 packages.  

# Top 10:

# usage 'pick 7 6' prints fields $7 $6 (1 to 9 only)
% pick() { z="$*" ; while read x ; do set -- $x ; for f in $z ; do eval echo -n \$$f"\ "  ; done ; echo ; done ; }

% for t in `cd /usr/share/doc/ ; find -maxdepth 1 -type d | sed -e 's#^\./##' -e '/\./d'` ;   do find /usr/share/doc/$t -type f -printf "%C@ \n" | sort -g | uniq -c | sort -rg | xargs echo $t | pick 2 1 3 | xargs printf "%4i %40s %s\n" ; done 2> /dev/null | sort -g > /tmp/dupdate.txt 

# 1) # of repeat dates
# 2) package name
# 3) the repeated date itself, in seconds since 1970
% tail /tmp/dupdate.txt
 199                     libcommons-lang-java 1200704724.0000000000
 262                            gnome-dev-doc 1188363464.0000000000
 271                                      kde 1205914766.0000000000
 289                             debian-guide 1073455729.0000000000
 302                                  openssl 1203115202.0000000000
 391                                    HOWTO 1197753227.0000000000
 431                                       lg 1113243150.0000000000
 553                                 lilypond 1205128585.0000000000
 641                                      RFC 1203416145.0000000000
 648                              mplayer-doc 1205119451.0000000000

I guess some of these might be affected by the pending #366555?  For
those that aren't...

Idea about a 'Debian day 1' date for upstream packages like the above.
Earlier I suggested saving the dates the first time it's packaged.
Hess objected to polluting the source '.deb' with an added data
structure and handling code.  On 2nd thought: no additional data
structure is needed.  An older or installed package version already
contains the desired metadata.

Supposing version numbers are whole numbers:

	1) Day 1, version 1, relative to Debian or the users system, 
	   installed package has upstream dates.  No change from how 
	   it's done now.

	2) Version 2, relative to Debian.  Before unpacking, go through 
	  'doc' dir, compare checksums to "version 1", if they match, 
	   use the old dates.

	3) Version 'n' compare to version 'n-1'.

In theory it's easy to apply the same method to existing packages, either
starting from the earliest and working forward, or from the latest and
working back.  (Given access to older '.deb' files, or their metadata.)

So, a util that runs on a package upgrade, before it's unpacked**.
Save prior version's doc date & checksums to temp file.  After
unpacking, compare, then backdate unchanged doc files as needed.  

(**is there a "Debian Way" to run on upgrade before unpacking?  I know
how to code the rest, assuming I've not forgotten some other necessary
difficulty.)

HTH...




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: agcosta@gis.net, 366555@bugs.debian.org
Subject: Re: Bug#366555: dpkg-source: Timestamps on documentation advance artificially
Date: Fri, 28 Mar 2008 09:24:34 +0100
Hi,

On Fri, 28 Mar 2008, A. Costa wrote:
> > To be clear: this bug #366555 is assigned to dpkg-dev and dpkg-dev
> > doesn't control the timestamp of generated documentation. If you want
> > the generated documentation to have a timestamp that matches the
> > source, you should just write a tool that makes it easy to do so and
> > hope that some maintainers will use it to fix timestamp of the
> > generated documentation (but I doubt it, honestly and the maintainer
> > of debhelper is very much a reference concerning what is a reasonable
> > packaging helper tool).
> 
> I like your idea, it'd be a workable kludge pending some eventual
> systemic fix or '.deb' revision.  It might work at install time, a user
> tool, rather like 'apt-listchanges' or 'localepurge'.  (See below for
> details.)

I rather meant a build-time tool like:
sync-timestamp <reference> <destination>

Where <reference> is the original file (say in XML format) and the
<destination> is either a file or a directory with multiple files.

> But if 'dpkg-dev' isn't relevent, (IIRC Shaun Jackman reassigned it from
> 'freeguide' to 'dpkg-dev'), then where to assign this other (correcting
> upstream dates) bug? 

Nowhere. If the idea is to write a new tool, there's no pre-existing
package where to reassign it.

> > ...Up to now all files from the debian sub-directory are installed by the
> > diff.gz and thus get a timestamp reset by dpkg-source. In the future,
> > when we switch over to the new source format the files in the debian
> > directory will be installed by a debian.tar.gz file and thus we will
> > preserve timestamps. However upstream patched files will continue to
> > have their timestamp reset at unpack time.
> 
> So if I understand things correctly, the 'upstream' part of a package
> is inviolate, never changing.  At present there's no preservation of
> patch timestamps, (always the latest patch/unpack time), and no
> provision for correcting upstream metadata -- the current format
> and tool chain are not designed for (you and JH argue) any such
> proposed metadata functions.

Yes.

> The user changing doc dates after or during the install would be OK?
> Assume the source '.deb' is untouched.  Would install-time date changes
> be any worse for a system than say, 'localepurge'?

Well, I have no problem with the user changing timestamps of installed
files if that's something desirable to the user. But I really don't see
how you would expect this to work.

> Idea about a 'Debian day 1' date for upstream packages like the above.
> Earlier I suggested saving the dates the first time it's packaged.
> Hess objected to polluting the source '.deb' with an added data
> structure and handling code.  On 2nd thought: no additional data
> structure is needed.  An older or installed package version already
> contains the desired metadata.
> 
> Supposing version numbers are whole numbers:
> 
> 	1) Day 1, version 1, relative to Debian or the users system, 
> 	   installed package has upstream dates.  No change from how 
> 	   it's done now.
> 
> 	2) Version 2, relative to Debian.  Before unpacking, go through 
> 	  'doc' dir, compare checksums to "version 1", if they match, 
> 	   use the old dates.
> 
> 	3) Version 'n' compare to version 'n-1'.

Ouch. What a lot of work for simple timestamps. And it has problems: a
compressed documentation file will have a differing checksum even if the
content does match as the gzip header includes some timestamp as well.
So yo should compare uncompressed content.

Many auto-generated documentation will also include some sort of timestamp
in the generated page as well.

> So, a util that runs on a package upgrade, before it's unpacked**.
> Save prior version's doc date & checksums to temp file.  After
> unpacking, compare, then backdate unchanged doc files as needed.  
> 
> (**is there a "Debian Way" to run on upgrade before unpacking?  I know
> how to code the rest, assuming I've not forgotten some other necessary
> difficulty.)

Well, right now there's no such "hook" defined in dpkg. Thus this feature
can probably only be developed as a dpkg patch.

But I can tell you in advance, that any such wishlist bug against dpkg
will be tagged wontfix as it's way too complicated for too little gain.

Cheers,
-- 
Raphaël Hertzog

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




Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to "A. Costa" <agcosta@gis.net>:
Bug acknowledged by developer. Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: 366555-close@bugs.debian.org
Subject: Bug#366555: fixed in dpkg 1.14.17
Date: Sun, 30 Mar 2008 10:17:05 +0000
Source: dpkg
Source-Version: 1.14.17

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

dpkg-dev_1.14.17_all.deb
  to pool/main/d/dpkg/dpkg-dev_1.14.17_all.deb
dpkg_1.14.17.dsc
  to pool/main/d/dpkg/dpkg_1.14.17.dsc
dpkg_1.14.17.tar.gz
  to pool/main/d/dpkg/dpkg_1.14.17.tar.gz
dpkg_1.14.17_i386.deb
  to pool/main/d/dpkg/dpkg_1.14.17_i386.deb
dselect_1.14.17_i386.deb
  to pool/main/d/dpkg/dselect_1.14.17_i386.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 366555@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg 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, 30 Mar 2008 12:48:22 +0300
Source: dpkg
Binary: dpkg dpkg-dev dselect
Architecture: source i386 all
Version: 1.14.17
Distribution: experimental
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 dpkg       - package maintenance system for Debian
 dpkg-dev   - package building tools for Debian
 dselect    - user tool to manage Debian packages
Closes: 4588 4628 4655 12564 17243 68981 114774 142042 151540 203792 215374 217622 220758 246918 248693 255882 308285 311843 323909 355654 363018 366555 379028 435126 439979 443338 445552 448946 453267 462225 462403 462413 463048 463398 465282 465420 465651 466135 466321 466957 467470 468916 469520 469838 471342 472332
Changes: 
 dpkg (1.14.17) experimental; urgency=low
 .
   [ Guillem Jover ]
   * Replace strdup plus error checking usage with a new m_strdup function.
     Closes: #379028
   * Add new keybinding in dselect to restore all selections back to
     whatever's currently installed. Closes: #151540
     Thanks to Colin Watson.
   * Use system timersub and fix timeval normalization in multiplication in
     start-stop-daemon. Thanks to Andreas Påhlsson. Closes: #462225
   * Cosmetic fixes to start-stop-daemon output and man page. Document that
     --chuid will change the group even if it has not been specified. Add
     EXIT STATUS and EXAMPLE sections to man page. Thanks to Justin Pryzby.
   * Add Raphael Hertzog to Uploaders, and remove Brendan O'Dea and
     Christian Perrier with their permission.
   * Use functions from libcompat when those are not provided by the system.
     - Add strnlen to libcompat.
     - Link programs against libcompat which provides obstack. Closes: #142042
   * Change dpkg-gencontrol to not output the Homapage field on udeb.
   * Reintroduce 'no-debsig' back in dpkg.cfg to avoid failing to install any
     package when debsig-verify is installed. Closes: #311843
   * Fix some small memory leaks. Closes: #469520
     Thanks to Sean Finney.
   * Correct broken dselect logic for self-conflicting packages.
     Thanks to Ian Jackson.
   * Implement 'Breaks' properly in dselect. Closes: #448946
     Thanks to Ian Jackson.
   * Fix erroneous description of Breaks in dselect output.
     Thanks to Ian Jackson.
   * Allow compilation with --disable-nls on systems without libintl.h where
     a non glibc claims to be glibc. Closes: #465420
   * Fix crash when a .deb file becomes unreadable while dpkg is starting.
     Thanks to Ian Jackson. Closes: #255882
   * Few file descriptor cleanup and error handling fixes.
     Thanks to Ian Jackson. Closes: #443338
   * Move test suite invokation to a new check target in debian/rules.
   * Add support for nocheck DEB_BUILD_OPTIONS in debian/rules, so that the
     dpkg test suite can be skept if desired.
   * Improve log and status-fd output by printing more status change updates
     and actions. Thanks to Ian Jackson.
   * Implement triggers support. Thanks to Ian Jackson.
     Closes: #17243, #68981, #215374, #217622, #248693, #308285
 .
   [ Raphael Hertzog ]
   * Add a warning displayed by dpkg-genchanges if the current version is
     smaller than the previous one. Closes: #4655
   * Add -d and -c options in dpkg-checkbuilddeps to override
     build-depends/conflicts. Closes: #114774
   * Include list of libraries in dpkg-gensymbols' warning about new/lost
     libraries.
   * Add -R option to dpkg-buildpackage so that one can replace the usual
     "debian/rules" by something else. Closes: #355654
   * Always list all binary packages in the Description: field of .changes
     files. It's nice for reviewers and mentors.debian.net was using this field
     on source only uploads to display short description of what the package is
     about.
   * Handle the case when the library has a different SONAME than the one used
     to find it. Closes: #462413
   * Fix Dpkg::Version and Dpkg::Fields::Object to import _g() from
     Dpkg::Gettext. Thanks to Adam Heath and Olivier Berger for spotting
     this. Closes: #465651
   * Change PATH during make check to look into build directories containing
     dpkg and the related scripts. Thanks to Mike Frysinger. Closes: #466957
   * Some lintian cleanup:
     - add overrides for some useless I: tags
     - drop unused overrides
     - updated several manual pages to fix hyphen-used-as-minus-sign
     - fixed manpage-has-errors-from-man in several manual pages
     - removed empty debian/dpkg.prerm
   * Removed old upgrade code from dpkg's preinst and postinst which only
     concerns upgrading from dpkg version older than the one in oldstable
     already. And thus we get rid of old the last usage of read in those
     scripts (fixes lintian's warning read-in-maintainer-script).
   * Removed sorting of dependencies in dpkg-gencontrol and dpkg-source. But
     kept it for all other fields (Enhances, Conflicts, Replaces, Breaks,
     Build-Conflicts and Build-Conflicts-Indep).
   * Instead changed dpkg-shlibdeps to sort the dependencies generated in
     ${shlibs:*} variables.
   * Changed the logic of simplification of dependencies: if any dependency
     must be discarded due to another dependency appearing further
     in the field, the superseding dependency will take the place of the
     discarded one. Added a test case for this.
   * dpkg-shlibdeps properly accounts usage of symbols provided by private
     libraries without SONAME. Closes: #469838
   * Add a new warning to dpkg-shlibdeps when a library NEEDED is in fact
     not used by any of the binaries analyzed. Closes: #472332
   * Add a new --warnings=<value> option to select the set of warnings to
     activate. By default, do not activate the warning about useless
     libraries at the binary level (instead the new warning above is activated
     by default: it's less strict and more useful).
   * dpkg-source has been heavily refactored to make it easier to support
     multiple source package formats. Several new source package formats have
     been added:
     - the format "2.0" is the original wig&pen
     - the format "3.0 (quilt)" is based on 2.0. It uses a tarball for the
       debian directory and can thus include binary files. Binaries
       outside of the debian directory can be also included if they
       are listed in debian/source/include-binaries (and option
       --include-binaries will generate this file automatically).
       Closes: #4588, #4628
     - thus it will also preserve timestamps on Debian-provided
       documentation like README.Debian. Closes: #366555
     - it handles an explicit series of patches and the patch can thus be
       named without constraints. Patches can contain arbitrary
       headers/comments between file chunks. Closes: #363018
     - it ignores changes on a number of temporary and VCS-specific files
       by default. Closes: #203792, #323909
     - the patches in debian/patches can remove files. Closes: #12564
     - the patches are applied at unpack time. Closes: #463048
     - the formats "3.0 (quilt/native)" don't include VCS directories by
       default. Closes: #435126
     - the format "3.0 (custom)" can be used to create a source package
       containing arbitrary files. It's useful for helper tools that can
       generate the files by themselves in a more efficient way
       (like all the *-buildpackage tools). Closes: #246918
     - the formats "3.0 (git/bzr)" are experimental formats based
       on corresponding VCS repositories. Thanks to Joey Hess and Colin Watson
       respectively.
   * dpkg-source has a new --no-check option. It disables GPG check and
     checksums checks. Closes: #220758
   * dpkg-shlibdeps is now able to look into directories containing libraries
     used by cross-built binaries provided that the right environment variable
     are set. Closes: #453267
   * Change default value of LDFLAGS (set by dpkg-buildpackage) to ''
     instead of '-Wl,-Bsymbolic-functions'. It's safer at this point of the
     release cycle.
   * dpkg-buildpackage will set PKG_CONFIG_LIBDIR (but not override an existing
     value) in case of cross-compilation so that pkgconfig finds .pc files
     in the directory specific to the target architecture. Closes: #439979
 .
   [ Frank Lichtenheld ]
   * Add a warning in dpkg-buildpackage if the build-dependencies are not
     satisfied during -S. Closes: #445552
   * Add a missing space in the German scripts translation. Closes: #463398
   * Add improved deb-shlibs.5 manual page by Zack Weinberg. Closes: #466135
   * dpkg-buildpackage exports some build related environment variables
     now. Based on a patch by Matthias Klose. Closes: #465282
     (See dpkg-buildpackage(1) and https://wiki.ubuntu.com/DistCompilerFlags
      for details)
   * Add support for use of SHA1 and SHA256 checksums in .dsc and
     .changes files. Information will be available in Checksums-Sha{1,256}
     fields. .changes format version increased to 1.8.
   * Link dselect against libncursesw. Closes: #466321
   * Forward port a patch from the old changelog parser to the new
     one that got lost during the transition. '+' and '.' can now
     be used in distribution names yet again. Reported by dann frazier.
     Closes: #467470
 .
   [ Updated dpkg translations ]
   * Korean (Changwoo Ryu).
   * Polish (Robert Luberda).
   * Romanian (Eddy Petrişor).
   * Slovak (Ivan Masár). Closes: #471342
   * Swedish (Peter Karlsson).
   * Thai (Theppitak Karoonboonyanan). Closes: #468916
 .
   [ Updated manpages translations ]
   * German (Helge Kreutzmann).
   * Polish (Robert Luberda).
   * Swedish (Peter Karlsson).
 .
   [ Updated dselect translations ]
   * Basque. (Piarres beobide). Closes: #462403
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
   * Polish (Robert Luberda).
   * Swedish (Peter Karlsson).
 .
   [ Updated dselect translations ]
   * Polish (Robert Luberda).
   * Romanian (Eddy Petrişor).
Files: 
 56444961ee40787d3ea5021dcc06a876 1205 admin required dpkg_1.14.17.dsc
 0ca6340578ada3e552d65da20a156f63 6379035 admin required dpkg_1.14.17.tar.gz
 358289c629a4b576fc2b442c7651a415 2122620 admin required dpkg_1.14.17_i386.deb
 84ab760fccbd19f8471d0699adbcd5a0 736746 admin optional dselect_1.14.17_i386.deb
 faca7bfb16abe077738e7607379d64ec 626054 utils optional dpkg-dev_1.14.17_all.deb
Checksums-Sha1: 
 cac35895c30cbd70ab57139306353ee0168aa29e 968 dpkg_1.14.17.dsc
 15faa3d798821d27b05fc09a3250fb26bacfb4a4 6379035 dpkg_1.14.17.tar.gz
 fc2c83f6f73b59dd173d944ad2dbf456725b6728 2122620 dpkg_1.14.17_i386.deb
 22214ad294485c59baa3c268d89f44e4e7e5b76f 736746 dselect_1.14.17_i386.deb
 913250129eef33396fcbed06aa051d5d19d3460c 626054 dpkg-dev_1.14.17_all.deb
Checksums-Sha256: 
 59d7e12cf3ab6096a27c87b3181a9c950574398dd38c83afbad5493035b581f4 968 dpkg_1.14.17.dsc
 9c45ae389e305a76070340415169383ae1126c1e7e77376c16feaf35cc40b6d2 6379035 dpkg_1.14.17.tar.gz
 4e8f8a1d24aaa7584fc94aaa7f40d87b4a8bf66bfdc31cc2a4a6a0b66c656c2d 2122620 dpkg_1.14.17_i386.deb
 4b788d10b1779ea032dea864aebfc7171607c7a5de6a71a39f7b190b679e81a7 736746 dselect_1.14.17_i386.deb
 a598e6468317c6401593c5830fc7c7380f0acdce8dc61c45b07157834c92eb18 626054 dpkg-dev_1.14.17_all.deb

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

iD8DBQFH72VTuW9ciZ2SjJsRAtvcAKC3lKxZP+TcJkXuNk2YrhWMr54UJgCgp/Es
81b/wWSjXuYpn8Vku+tiby8=
=y/qC
-----END PGP SIGNATURE-----





Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#366555; Package dpkg-dev. Full text and rfc822 format available.

Acknowledgement sent to agcosta@gis.net:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: "A. Costa" <agcosta@gis.net>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 366555@bugs.debian.org
Subject: Caveat! Re: Bug#366555: dpkg-source: Timestamps on documentation advance artificially
Date: Fri, 11 Apr 2008 23:57:49 -0400
Argh, human error, please ignore that laste one if you like -- that was
from the draft folder, or rather I was using the 'queue' folder like it
was a draft folder again, and hit the wrong Sylpheed 'Send' button.

Not that there was anything inflamatory there, but it's been a busy
week, so I was still thinking about that stuff, and wanted a shorter
and better message.  Sorry...




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 25 May 2008 07:35:10 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: Sat Apr 19 00:23:06 2014; Machine Name: beach.debian.org

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