[05:52] <Crypticfortune> Hi. Can anyone help me figure out what's going on with this package and its "Failed to upload" errors? https://launchpad.net/~cryptickrisp/+archive/samscope/+packages
[05:53] <Crypticfortune> the upload logs say it has files with dates too far in the future (I suspect because I'm in Japan, and local time wise, I'm maybe a day-ish in the future...)
[05:53] <Crypticfortune> but only one of the builds failed that way...
[05:58] <wgrant> Crypticfortune: The timestamps in that tarball are a bit odd
[05:59] <wgrant> The one you uploaded, that is
[05:59] <wgrant> All the files are dated about 7 hours in the future
[05:59] <wgrant> I suspect your clock is wrong
[06:03] <Crypticfortune> wgrant: that seems unlikely because it'd definitely 3pm here....
[06:03] <wgrant> Crypticfortune: Perhaps your timezone is incorrect
[06:03] <wgrant> What does 'date' say?
[06:04] <Crypticfortune> Wed Oct 24 15:04:02 JST 2012
[06:04] <wgrant> Intriguing.
[06:04] <wgrant> How did you construct the tarball?
[06:04] <wgrant> What do the file timestamps in the source directory look like locally?
[06:05] <wgrant> I know there's no general problem with timezones, since I've been building packages from +10/+11 for quite a number of years now :)
[06:05] <Crypticfortune> wgrant: "dpkg-buildpackage -S"
[06:06] <Crypticfortune> wgrant: yeah, all the previous packages worked fine, and you'll notice that for some reason the build on "preceise" worked (with the same tarball) =/
[06:06] <wgrant> It's not the same tarball
[06:06] <wgrant> You're using a native package (possibly accidentally), so it's always a different tarball
[06:08] <Crypticfortune> true, well it should be identical except for the -{series}~1 bits in debian/changelog
[06:08] <wgrant> Huh
[06:08] <wgrant> The precise timestamps are in the future too
[06:08] <wgrant> It should have been rejected, unless it's just over the threshold now
[06:08] <wgrant> Anyway, your system is creating tarballs with incorrect timestamps, so you should probably track that down
[06:09] <wgrant> The threshold is 8 hours
[06:09] <wgrant> That's probably why the precise build worked
[06:10] <wgrant> It just happened to build late enough
[06:10] <lifeless> Crypticfortune: what does 'TZ=gmt date' output for you ?
[06:10] <StevenK> ITYM date -u
[06:10] <lifeless> StevenK: blah
[06:10] <wgrant> Hm, indeed, perhaps there's another definition of JST
[06:11] <Crypticfortune> lifeless StevenK : Wed Oct 24 06:10:43 UTC 2012
[06:11] <wgrant> Evidently not
[06:11] <StevenK> Close enough
[06:11] <lifeless> Crypticfortune: thanks
[06:11] <Crypticfortune> wgrant: but whoah! before doing "dpkg-buildpackage" I check out a fresh copy of the source tree, and for some reason the files there are indeed in the future....
[06:11] <Crypticfortune> something weird's goin on...
[06:11] <StevenK> steven@undermined:~% TZ=Japan date
[06:11] <StevenK> Wed Oct 24 15:11:44 JST 2012
[06:12] <wgrant> Crypticfortune: Hah
[06:12] <StevenK> Looks right to me
[06:12] <wgrant> Crypticfortune: That could do it
[06:12] <lifeless> what VCS ?
[06:12] <wgrant> Crypticfortune: How'd you check it out?
[06:13] <Crypticfortune> wgrant: hg clone.... dunno how that's screwing up, but  I know where to start looking now. thanks!
[06:13] <wgrant> Perhaps it sets the mtime to the last commit, and the last commit has a bad clock, or something like that
[06:13] <Crypticfortune> that would be disturbing....
[06:13] <lifeless> lots of things about hg are disturbing :)
[06:13] <wgrant> Last committer, that is
[06:14] <wgrant> +++ b/.hgtagsWed Oct 24 12:50:24 2012 +0900
[06:14] <wgrant> Looks fine :/
[06:22] <Crypticfortune> Ahahaha, found the problem. So for packaging, I was cloning into an NFS directory, and that NFS server's NTP is dead for some reason, and the clock is (almost) 7 hours in the future...must have been broken for a looong time... =/
[06:23] <wgrant> Crypticfortune: Ouch
[06:23] <wgrant> That would do it, though!
[11:34] <aboudreault> looks like the copy packages is broken?
[11:36] <wgrant> aboudreault: No, why?
[11:36] <wgrant> It can take a couple of minutes for a copy to complete
[11:36] <wgrant> But it's not broken
[11:36] <aboudreault> well, tried to copy a packages yesterday, it didn't work..... just retry, same error
[11:36] <wgrant> What's the error?
[11:37] <aboudreault> Launchpad encountered an internal error during the following operation: copying a package.  It was logged with id OOPS-02eefd0ef2b9e47058302b1c275a5504.  Sorry for the inconvenience.
[11:37] <wgrant> Hm, that should have given you a more descriptive error message
[11:37] <wgrant> cjwatson: ^^
[11:37] <wgrant> aboudreault: CannotCopy: geos 3.3.3-2~precise2 in precise (same version already has published binaries in the destination archive)
[11:39] <cjwatson> Yeah, it should have done - please file a bug
[11:39] <cjwatson> Rather surprised it didn't, since I thought I'd QAed that specific case
[11:40] <cjwatson> But it was a while back
[11:40] <aboudreault> wgrant, I see. thanks
[11:40] <cjwatson> Anyway, yeah, you can't copy that because it already exists - or used to exist - in the destination
[11:41] <cjwatson> But please do file a bug and I'll see about fixing up the e-mail
[11:43] <aboudreault> cjwatson, ok
[11:47] <aboudreault> cjwatson, , where should I fill that bug?
[11:47] <cjwatson> https://bugs.launchpad.net/launchpad/+filebug
[11:48] <aboudreault> just tried to copy another package, which is not in packages.ubuntu.com.... and got the same error
[11:49] <aboudreault> Copied from: ubuntugis-unstable. Copied by: Alan Boudreault Target series: Quantal
[11:49] <aboudreault> gdal 1.9.1-2~precise4 in precise (same version already has published binaries in the destination archive)
[11:50] <aboudreault> there is only 2 python packages in quantal in the ppa
[11:50] <maxb> aboudreault: The "has published binaries" check does not care about series
[11:50] <maxb> Which is the destinatination archive?
[11:51] <maxb> er, apparently I fail at typing. You get the idea, though
[11:52] <aboudreault> so the copy/rebuild still doesn't work in the same PPA?
[11:54] <aboudreault> anyway, will upload manually
[11:55] <wgrant> It can't really just work, as we'd have to mangle the version in potentially evil ways
[12:03] <cjwatson> aboudreault: the on-disk representation of a PPA has a single pool/ for all series, so you can never reuse versions in a single PPA (regardless of precise/quantal/etc.) because the filenames would clash
[12:04] <cjwatson> aboudreault: version numbers are cheap, so just use a new one
[12:04] <aboudreault> yeah
[21:31] <kanor_> hello
[21:31] <kanor_> it is possible upload a meta package in a ppa ?
[21:33] <cjwatson> kanor_: Sure.  Metapackages are just packages whose purpose is only to depend on other packages; there's nothing particularly special about them.
[21:36] <kanor_> i create my package with equivs-build
[21:37] <kanor_> easy
[21:37] <kanor_> but in the command
[21:37] <kanor_> dput ppa:your-lp-id/ppa <source.changes>
[21:38] <kanor_> i get how "source.change"
[21:40] <kanor_> (and excuse me for the bad english )
[22:27] <sinzui> StevenK, wgrant https://bugs.launchpad.net/launchpad/+bug/351011
[23:20] <joey> sinzui: I found some more timeouts for you. Just FYI, they don't impact me but I can repeat them
[23:20] <joey> sinzui: OOPS-eb5ac431223bfa1934d392bc09bdc9c9
[23:20] <joey> sinzui:  OOPS-449e45477aef722fb6c8e6a507bb99f3
[23:20] <joey> sinzui: from https://launchpad.net/ubuntu/gutsy
[23:35] <TheLordOfTime> timeouts confirmed: OOPS-2664a79beb13cc06adeec95b13596690