[13:55] <pmjdebruijn> I'm having an issue with a PPA build
[13:55] <pmjdebruijn> https://launchpadlibrarian.net/160015601/upload_5356618_log.txt
[13:56] <pmjdebruijn> https://launchpadlibrarian.net/160015571/buildlog_ubuntu-precise-i386.https-everywhere_3.4.3-1pmjdebruijn1~precise_UPLOADING.txt.gz
[13:56] <pmjdebruijn> the source tarball has proper dates
[14:03] <geser> pmjdebruijn: did you also check the dates within the .xpi file itself?
[14:03] <geser> the mentioned file comes from unzipping the .xpi file
[14:04] <pmjdebruijn> btw, the fun thing is, this is a backport from debian.org :)
[14:05] <pmjdebruijn> geser: isn't the .xpi generated by the packaging?
[14:05] <pmjdebruijn> there is no .xpi file in the source tarball
[14:05] <geser> I don't think the Debian archive has the same check for the dates
[14:05] <pmjdebruijn> apparently
[14:07] <pmjdebruijn> I built 3.4.1 a while ago without any issues
[14:10] <pmjdebruijn> oh wait
[14:10] <pmjdebruijn> makexpi.sh
[14:10] <pmjdebruijn> stops using zip
[14:10] <pmjdebruijn> but those python magic
[14:10] <pmjdebruijn> but some...
[14:12] <geser> so it looks like the .xpi is generated and then "installed" (unpacked again) into the staging directory. at this step the mentioned file gets the wrong timestamp (for whatever reason)
[14:13] <pmjdebruijn> oh ****
[14:13] <pmjdebruijn> this is intentional
[14:13] <pmjdebruijn>  DEFAULT_DATE = (1980,1,1,0,0,0)
[14:13] <pmjdebruijn> https://gitweb.torproject.org/https-everywhere.git/blob/HEAD:/utils/zipfile_deterministic.py
[14:14] <pmjdebruijn> to have byte-for-byte identical files
[14:15] <geser> then touch the mentioned file after "install-xpi" gets called to fix the timestamp for the deb
[14:15] <pmjdebruijn> well it's easier to revert to zip again
[14:15] <pmjdebruijn> like in 3.4.1 version
[14:16] <pmjdebruijn> since I'd otherwise have to recurse the whole tree
[14:26] <pmjdebruijn> geser: thanks for the hints btw, just pushed new builds
[14:26] <pmjdebruijn> if it all works out, I'll give the Debian maintainer a bump about this (since I guess they won't like weirdly timestamped files on the filesystem as well)
[14:38] <geser> pmjdebruijn: there is a lintian check for files older than 20 years (package-contains-ancient-file) but it only checks the year <= 1975
[14:42] <pmjdebruijn> ah
[14:43] <pmjdebruijn> I just mailed the debian maintainer with a patch though
[14:43] <pmjdebruijn> it's a trivial patch, comment one line, uncomment another
[17:04] <shadeslayer_> https://code.launchpad.net/~blue-shell/blue-shell/vokoscreen < seems to be failing to connect to the importer?
[17:07] <cjwatson> shadeslayer_: looking
[17:07] <shadeslayer_> thx
[17:11] <cjwatson> shadeslayer_: I've made a sysadmin request to fix the config in question
[17:11] <shadeslayer_> cjwatson: thanks alot
[17:12] <shadeslayer_> cjwatson: any clue how long that will take? This is somewhat time sensitive
[17:13] <cjwatson> should be minutes rather than hours, but I can't say exactly
[17:13] <shadeslayer_> awesome
[17:14]  * shadeslayer_ will wait for a couple of hours
[21:29] <me4oslav> anyone here that knows how to deal with import error from GIT to BZR?
[21:32] <dobey> what error?
[21:39] <me4oslav> dobey: https://code.launchpad.net/~numix/numix-icon-theme-circle/numix-icon-theme-circle and https://code.launchpad.net/~numix/numix-icon-theme/numix-icon-theme
[21:39] <me4oslav> the latest two import errors on both pages
[21:41] <dobey> looks like that requires IS poking
[21:42] <me4oslav> meaning?
[21:43] <dobey> meaning it looks like a problem contacting another canonical server
[21:44] <me4oslav> so, I should just wait 'til it is fixed from canonical?
[21:47] <dobey> me4oslav: i've pinged admins about it
[21:49] <me4oslav> dobey: awesome. Notify me when they nail it with a big hammer :)
[23:35] <slackner> wgrant: i assume that this is not what an bzr import should look like? http://launchpadlibrarian.net/160067358/pipelight-wine-compholio-wine-compholio-daily.log