upload rejected for files with a time stamp too far in the past

Bug #836935 reported by Matthias Klose
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Invalid
Undecided
Unassigned
php-compat (Ubuntu)
Fix Released
High
Unassigned
Oneiric
Fix Released
High
Unassigned

Bug Description

apparently Debian does accept this kind of package into the archive. where should this be fixed?

https://launchpad.net/ubuntu/+source/php-compat

INFO Processing upload php-compat_1.6.0a3-1_i386.changes
INFO Upload was rejected:
INFO php-compat_1.6.0a3-1_all.deb: has 115 file(s) with a time stamp too far in the past (e.g. usr/share/doc/php-compat/tests/function/acosh.phpt [Thu Jan 1 09:14:39 1970]).
INFO Committing the transaction and any mails associated with this upload.

Tags: ftbfs oneiric

Related branches

Matthias Klose (doko)
summary: - upload rejected
+ upload rejected for files with a time stamp too far in the past
Changed in php-compat (Ubuntu):
importance: Undecided → High
status: New → Confirmed
tags: added: ftbfs oneiric
Revision history for this message
Colin Watson (cjwatson) wrote :

Matthias, are you sure? I see a virtually identical check in dak.

Revision history for this message
Deryck Hodge (deryck) wrote :

FWIW, on the Launchpad side, we do indeed do the rejection on our side, but we'll accept packages dated as far back as 1984. This seems like we're trying to match Debian since Colin notes the same check.

Revision history for this message
Colin Watson (cjwatson) wrote :

cjwatson@ries:~/ftp/pool/main/p/php-compat$ dpkg -c php-compat_1.6.0a3-1_all.deb | grep usr/share/doc/php-compat/tests/function/acosh.phpt
-rw-r--r-- root/root 263 2011-06-30 23:16 ./usr/share/doc/php-compat/tests/function/acosh.phpt

I think what happened is as follows:

  1) The Debian maintainer uploaded this package from a build directory where those files had newer mtimes, and those mtimes were copied into the .deb.
  2) dpkg-source does not create diff entries when only a file's timestamp differs between the original source and the build directory.
  3) As a result, when unpacked on a buildd and built afresh, it builds a .deb with ancient mtimes that would be rejected by dak and are rejected by Launchpad.

This package will fail in Debian too once Debian moves to throwing away maintainer-uploaded binaries and building them anew (which was discussed at DebConf and is supposed to be happening reasonably soon). As such, I would recommend filing a Debian bug about this, and fixing the package directly in Ubuntu if it's urgent (e.g. by explicitly touching the affected installed files).

Revision history for this message
Deryck Hodge (deryck) wrote :

I'm closing the Launchpad task based on Colin's explanation here. Thanks, Colin!

Changed in launchpad:
status: New → Invalid
Revision history for this message
Thomas Goirand (thomas-goirand) wrote :

Hi,

I'm the maintainer of that package in Debian. Would it help you guys if I made another upload, fixing upstream tarball? Or is it fine as-is, and you can still accept it for the latest Ubuntu?

There's no new upstream version, no bugs on the package, so no real reason for me to re-upload appart from fixing this tiny file date issue inside upstream tar.gz. So if I can avoid re-uploading, that'd be great! Please let me know.

Thomas Goirand (zigo)

Revision history for this message
Matthias Klose (doko) wrote : Re: [Bug 836935] Re: upload rejected for files with a time stamp too far in the past

On 08/31/2011 06:29 PM, Thomas Goirand wrote:
> Hi,
>
> I'm the maintainer of that package in Debian. Would it help you guys if
> I made another upload, fixing upstream tarball? Or is it fine as-is, and
> you can still accept it for the latest Ubuntu?
>
> There's no new upstream version, no bugs on the package, so no real
> reason for me to re-upload appart from fixing this tiny file date issue
> inside upstream tar.gz. So if I can avoid re-uploading, that'd be great!
> Please let me know.

either this, or I'll have to do that myself for ubuntu.

Revision history for this message
Colin Watson (cjwatson) wrote :

Thomas, I think this is worth fixing in Debian too, because otherwise any attempt by anyone other than you to upload the package will fail; this should be counted as an RC bug (consider security support). You don't need a new upstream tarball, though, as you could just add this after dh_installdocs:

  find debian/$(package)/usr/share/doc/$(package)/tests | xargs touch

Revision history for this message
Thomas Goirand (thomas-goirand) wrote :

Hi,

First of all, the package is team maintained. So it isn't only me here. If you want, feel free to join the Debian PHP PEAR Maintainers <email address hidden>, we'd be very (extremely, delighted...) happy to have some more hands, because there's lots of packages to maintain.

Second, I just had a longer look at the issue. Just after installing the package, here's what I have:

# ls -lah /usr/share/doc/php-compat/tests/function/acosh.phpt
-rw-r--r-- 1 root root 263 Jun 30 23:16 /usr/share/doc/php-compat/tests/function/acosh.phpt

As you see, the date is correct. So I didn't understand first what issue we were having here. Then I finally understood: file dates in the Git repository are also correct, and only the orig.tar.gz has wrong dates, but since I'm packaging with Git, I don't see the issue. You'll have it only if you don't use git-buildpackage to build, but downloading the source package and building. I tried, and it proves me correct!!! So I wonder, when you pull a package from Debian, do you *ALWAYS* rebuild it before importing it in Ubuntu?

Anyway, instead of doing what you asked above (eg, using a find and a touch after dh_installdocs), I've switched to using the dh short style and pkg-php-tools, since this is a waaaaaaaaay better, cleaner, faster, and more maintainable. And magically, this solves the issue, even when *not* using git-buildpackage. I'm not sure what the scripts of pkg-php-tools are doing, but it is well possible that they have addressed the situation, since the issue of stupid dates in upstream PHP PEAR packages are recurring. FYI, I'm currently in the process of switching all of my PHP PEAR packages to this style of packaging, which I believe will smooth everything.

So, here's the changelog for my last upload:

php-compat (1.6.0a3-2) unstable; urgency=low

  * Now using DEP5 for the debian/copyright.
  * Now using pkg-php-tools and dh 8 short style (so depends on dh 8).
    This also sloves an issue when rebuilding the package without using
    git-buildpackage, because of upstream file dates set to 1/1/1970,
    which was affecting Ubuntu (LP: #836935).
  * Section is now php.

 -- Thomas Goirand <email address hidden> Tue, 20 Sep 2011 01:13:22 +0800

So, I would suggest you to synch this last upload to SID, since it will fix your troubles. I hope you didn't mind the long explanations, but I thought it was worth explaining! :)

Cheers,

Thomas Goirand (zigo)

P.S: Note that I couldn't use the ${phppear:Debian-Depends} since it was erroring on me...

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package php-compat - 1.6.0a3-2

---------------
php-compat (1.6.0a3-2) unstable; urgency=low

  * Now using DEP5 for the debian/copyright.
  * Now using pkg-php-tools and dh 8 short style (so depends on dh 8).
    This also sloves an issue when rebuilding the package without using
    git-buildpackage, because of upstream file dates set to 1/1/1970,
    which was affecting Ubuntu (LP: #836935).
  * Section is now php.
 -- Matthias Klose <email address hidden> Tue, 20 Sep 2011 15:15:36 +0000

Changed in php-compat (Ubuntu Oneiric):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.