=== mpt_ is now known as mpt === zequence_ is now known as zequence === Gwaihir_ is now known as Gwaihir === xnox_ is now known as xnox === jamesh__ is now known as jamesh === BradCrittenden is now known as bac [13:55] I'm having an issue with a PPA build [13:55] https://launchpadlibrarian.net/160015601/upload_5356618_log.txt [13:56] https://launchpadlibrarian.net/160015571/buildlog_ubuntu-precise-i386.https-everywhere_3.4.3-1pmjdebruijn1~precise_UPLOADING.txt.gz [13:56] the source tarball has proper dates [14:03] pmjdebruijn: did you also check the dates within the .xpi file itself? [14:03] the mentioned file comes from unzipping the .xpi file [14:04] btw, the fun thing is, this is a backport from debian.org :) [14:05] geser: isn't the .xpi generated by the packaging? [14:05] there is no .xpi file in the source tarball [14:05] I don't think the Debian archive has the same check for the dates [14:05] apparently [14:07] I built 3.4.1 a while ago without any issues [14:10] oh wait [14:10] makexpi.sh [14:10] stops using zip [14:10] but those python magic [14:10] but some... [14:12] 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] oh **** [14:13] this is intentional [14:13] DEFAULT_DATE = (1980,1,1,0,0,0) [14:13] https://gitweb.torproject.org/https-everywhere.git/blob/HEAD:/utils/zipfile_deterministic.py [14:14] to have byte-for-byte identical files [14:15] then touch the mentioned file after "install-xpi" gets called to fix the timestamp for the deb [14:15] well it's easier to revert to zip again [14:15] like in 3.4.1 version [14:16] since I'd otherwise have to recurse the whole tree [14:26] geser: thanks for the hints btw, just pushed new builds [14:26] 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] 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] ah [14:43] I just mailed the debian maintainer with a patch though [14:43] it's a trivial patch, comment one line, uncomment another === Ursinha-afk is now known as Ursinha [17:04] https://code.launchpad.net/~blue-shell/blue-shell/vokoscreen < seems to be failing to connect to the importer? [17:07] shadeslayer_: looking [17:07] thx [17:11] shadeslayer_: I've made a sysadmin request to fix the config in question [17:11] cjwatson: thanks alot [17:12] cjwatson: any clue how long that will take? This is somewhat time sensitive [17:13] should be minutes rather than hours, but I can't say exactly [17:13] awesome [17:14] * shadeslayer_ will wait for a couple of hours === shadeslayer_ is now known as shadeslayer === jacekn_ is now known as jacekn === jkyle_ is now known as jkyle === jkyle is now known as Guest75169 [21:29] anyone here that knows how to deal with import error from GIT to BZR? [21:32] what error? [21:39] 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] the latest two import errors on both pages [21:41] looks like that requires IS poking [21:42] meaning? [21:43] meaning it looks like a problem contacting another canonical server [21:44] so, I should just wait 'til it is fixed from canonical? [21:47] me4oslav: i've pinged admins about it [21:49] dobey: awesome. Notify me when they nail it with a big hammer :) === Logan_ is now known as Guest47136 === Logan__ is now known as Logan_ [23:35] 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