[05:52] 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] 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] but only one of the builds failed that way... [05:58] Crypticfortune: The timestamps in that tarball are a bit odd [05:59] The one you uploaded, that is [05:59] All the files are dated about 7 hours in the future [05:59] I suspect your clock is wrong [06:03] wgrant: that seems unlikely because it'd definitely 3pm here.... [06:03] Crypticfortune: Perhaps your timezone is incorrect [06:03] What does 'date' say? [06:04] Wed Oct 24 15:04:02 JST 2012 [06:04] Intriguing. [06:04] How did you construct the tarball? [06:04] What do the file timestamps in the source directory look like locally? [06:05] 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] wgrant: "dpkg-buildpackage -S" [06:06] 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] It's not the same tarball [06:06] You're using a native package (possibly accidentally), so it's always a different tarball [06:08] true, well it should be identical except for the -{series}~1 bits in debian/changelog [06:08] Huh [06:08] The precise timestamps are in the future too [06:08] It should have been rejected, unless it's just over the threshold now [06:08] Anyway, your system is creating tarballs with incorrect timestamps, so you should probably track that down [06:09] The threshold is 8 hours [06:09] That's probably why the precise build worked [06:10] It just happened to build late enough [06:10] Crypticfortune: what does 'TZ=gmt date' output for you ? [06:10] ITYM date -u [06:10] StevenK: blah [06:10] Hm, indeed, perhaps there's another definition of JST [06:11] lifeless StevenK : Wed Oct 24 06:10:43 UTC 2012 [06:11] Evidently not [06:11] Close enough [06:11] Crypticfortune: thanks [06:11] 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] something weird's goin on... [06:11] steven@undermined:~% TZ=Japan date [06:11] Wed Oct 24 15:11:44 JST 2012 [06:12] Crypticfortune: Hah [06:12] Looks right to me [06:12] Crypticfortune: That could do it [06:12] what VCS ? [06:12] Crypticfortune: How'd you check it out? [06:13] wgrant: hg clone.... dunno how that's screwing up, but I know where to start looking now. thanks! [06:13] Perhaps it sets the mtime to the last commit, and the last commit has a bad clock, or something like that [06:13] that would be disturbing.... [06:13] lots of things about hg are disturbing :) [06:13] Last committer, that is [06:14] +++ b/.hgtagsWed Oct 24 12:50:24 2012 +0900 [06:14] Looks fine :/ [06:22] 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] Crypticfortune: Ouch [06:23] That would do it, though! === jtv1 is now known as jtv [11:34] looks like the copy packages is broken? [11:36] aboudreault: No, why? [11:36] It can take a couple of minutes for a copy to complete [11:36] But it's not broken [11:36] well, tried to copy a packages yesterday, it didn't work..... just retry, same error [11:36] What's the error? [11:37] 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] https://oops.canonical.com/?oopsid=OOPS-02eefd0ef2b9e47058302b1c275a5504 [11:37] Hm, that should have given you a more descriptive error message [11:37] cjwatson: ^^ [11:37] aboudreault: CannotCopy: geos 3.3.3-2~precise2 in precise (same version already has published binaries in the destination archive) [11:39] Yeah, it should have done - please file a bug [11:39] Rather surprised it didn't, since I thought I'd QAed that specific case [11:40] But it was a while back [11:40] wgrant, I see. thanks [11:40] Anyway, yeah, you can't copy that because it already exists - or used to exist - in the destination [11:41] But please do file a bug and I'll see about fixing up the e-mail [11:43] cjwatson, ok [11:47] cjwatson, , where should I fill that bug? [11:47] https://bugs.launchpad.net/launchpad/+filebug [11:48] just tried to copy another package, which is not in packages.ubuntu.com.... and got the same error [11:49] Copied from: ubuntugis-unstable. Copied by: Alan Boudreault Target series: Quantal [11:49] gdal 1.9.1-2~precise4 in precise (same version already has published binaries in the destination archive) [11:50] there is only 2 python packages in quantal in the ppa [11:50] aboudreault: The "has published binaries" check does not care about series [11:50] Which is the destinatination archive? [11:51] er, apparently I fail at typing. You get the idea, though [11:52] so the copy/rebuild still doesn't work in the same PPA? [11:54] anyway, will upload manually [11:55] It can't really just work, as we'd have to mangle the version in potentially evil ways [12:03] 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] aboudreault: version numbers are cheap, so just use a new one [12:04] yeah === dpm__ is now known as dpm === yofel_ is now known as yofel === dpm is now known as dpm-afk === Ursinha-afk is now known as Ursinha === glebihan_ is now known as glebihan [21:31] hello [21:31] it is possible upload a meta package in a ppa ? [21:33] kanor_: Sure. Metapackages are just packages whose purpose is only to depend on other packages; there's nothing particularly special about them. [21:36] i create my package with equivs-build [21:37] easy [21:37] but in the command [21:37] dput ppa:your-lp-id/ppa [21:38] i get how "source.change" [21:40] (and excuse me for the bad english ) [22:27] StevenK, wgrant https://bugs.launchpad.net/launchpad/+bug/351011 [22:27] Ubuntu bug 351011 in Launchpad itself "rosetta-pofile-stats.py needs optimizing" [Critical,Triaged] [23:20] sinzui: I found some more timeouts for you. Just FYI, they don't impact me but I can repeat them [23:20] sinzui: OOPS-eb5ac431223bfa1934d392bc09bdc9c9 [23:20] https://oops.canonical.com/?oopsid=OOPS-eb5ac431223bfa1934d392bc09bdc9c9 [23:20] sinzui: OOPS-449e45477aef722fb6c8e6a507bb99f3 [23:20] https://oops.canonical.com/?oopsid=OOPS-449e45477aef722fb6c8e6a507bb99f3 [23:20] sinzui: from https://launchpad.net/ubuntu/gutsy [23:35] timeouts confirmed: OOPS-2664a79beb13cc06adeec95b13596690 [23:35] https://oops.canonical.com/?oopsid=OOPS-2664a79beb13cc06adeec95b13596690