=== amagoon_ is now known as amagoon [01:14] Hi all. I maintain a package whose source, if maintained in bzr, would not be small enough to "bzr branch" in the packaging recipe tools. Is there a way to keep just the debian/ dir in a packaging branch and get the upstream orig.tar from some place inside a packaging rule? [01:15] (I ask , having read the source and being pretty sure there isn't so far. Maybe someone has an idea or inspiration to make a way.) [01:17] qengho: There's no way to do that using a recipe, I'm afraid. [01:28] wgrant: Right. *Should* there be? Why should branches need the orig tarball unpacked already and checked in somewhere? I don't think it makes sense. [01:31] wgrant: Launchpad PPA builders already have an archive of tarballs. It could try to get from there. That is elegant. [01:41] qengho: Recipes are designed specifically for the case of combining branches to construct a source package. [01:41] Primarily for the case of daily builds. [01:41] Where a release tarball doesn't necessarily exist. [01:43] qengho: you can always generate source package with $ bzr builddeb -S (which does support version controlling debian/ only) and dput into ppa [02:19] wgrant, xnox, yeah, I can make source packages and upload every night. I like the recipes and automatic building if changed based on Launchpad branches only. I didn't want to depend on an outside machine. [02:20] I know what it does and what I can do. I'm saying what else I think it should do. === jgeboski- is now known as jgeboski === tjaalton_ is now known as tjaalton [13:04] good morning! I'm using launchpad to translate my app, and I need to change one single string in all languages in the same way. Is there some magic format for a po.tgz upload that automatically recognizes languages? [16:12] I'm having problems copying a package from another archive to my own. First I copied a newer version, which sucked so I deleted it and are now trying to copy the previous version again but keep getting error notifications "a different source with the same version is published in the destination archive". While that package name is not listed anymore as far as I can see [16:22] I can now find it as "superseded", how can I change it to published again? [16:28] copy it from the same archive back into itself, making sure to include binaries [16:31] nice trick [16:31] let's see, pending [16:44] thanks it worked [16:47] you're welcome === Kyle_ is now known as Kyle [18:31] hi, what's the recommended way of proceeding when vcs-import failed by remote git repo has gpgsig in some of the commits? [18:31] looks to be a bug in bzr-git, fail log is like this one: https://launchpadlibrarian.net/148599666/fcitx-team-fcitx-autoimport-fcitx.log [23:16] wgrant: Oh, by the way - cross-site scripting support for the API. Any bug or progress or thoughts on that? [23:33] RAOF: We're unlikely to implement it in the foreseeable future without a compelling usecase, but we'd accept a patch that didn't introduce security vulnerabilities. [23:34] And I don't suppose ‘Chris would like to pull some metadata about the latest release of Do from do.cooperteam.net’ counts as a compelling usecase? :) [23:35] Regrettably not :P [23:47] RAOF: I think perhaps patches accepted? [23:48] lifeless: Yeah. For me that would require a significant time investment in domain knowledge. [23:49] lifeless: Current state of domain knowledge: “Oh, so XMLHttpRequest is the thing to poke at to do AJAX from javascript. Now, where would I put that…” [23:53] RAOF: well, thats client side; server side it's a policy thing exported by the api [23:54] lifeless: Yes. I guess the specific domain knowledge required is (a) "how to build launchpad", which I understand is not desperately hard these days, and (b) how to tell whether I've introduced a security vuln. [23:54] which code review will catch, cause paranoid reviewers are paranoid