[00:01] <lifeless> don't you already have an account?
[00:02] <Keybuk> we created a new one for me, to avoid the cost of all the old bug subscriptions
[00:02] <Keybuk> remember?
[00:02] <Keybuk> it was your idea
[11:12] <tramm> hello
[11:13] <tramm> does anybody happen to know what is the default line width used by Launchpad translations for gettext files?
[11:13] <tramm> it seems to be either 75 or 76
[11:32] <tramm> well, it's seems to be the default though
[11:32] <tramm> probably translators have different widths in their editors
[11:35] <maxb> exarkun: Hi, sorry for disappearing on you over the weekend, I wasn't feeling that great :-/  Anyway, divmod svn...
[11:36] <maxb> So, I wrote a plugin implementing a custom layout... lp:~maxb/+junk/divmod_svn_layout... but then I found it caused bzr-svn to eat all the memory on my machine and crash
[11:36] <maxb> I also realized there should be a way to do it without a custom plugin, using bzr-svn's wildcard layout
[11:37] <maxb> So I added the lines "branches = branches/*/Axiom;trunk/Axiom" and "tags = tags/releases/*" to the relevant section of ~/.bazaar/subversion.conf
[11:37] <maxb> And then I found a bug in the wildcard layout, so I fixed it: lp:~maxb/bzr-svn/wildcard-layout-no-project-path
[11:38] <maxb> With such a configuration, I managed to run 'bzr svn-import file://..../Divmod Axiom.bzr' and similar for other projects
[11:38] <maxb> However, something about this history of Nevow causes bzr-svn to crash
[11:38] <maxb> I think we'll need to enlist jelmer on that
[11:39] <maxb> Also, when doing these imports, you end up with tags for *all* the projects in *all* the branched
[11:39] <maxb> *branches
[11:40] <maxb> I'd highly recommend tidying up the tags before pushing any branches to Launchpad, as once you've shared a tag, it tends to keep creeping back in, when you merge from someone who branched before the tags were deleted
[13:32] <hyperair> hi. is there something wrong with launchpad's patch detection?
[13:33] <hyperair> it complains that a patch which was generated by debdiff is not a patch.
[13:33] <hyperair> patch -p1 patches it cleanly, too.
[13:33] <gmb> FAIL
[13:34] <gmb> hyperair: Let me try to answer your question in a minute when I've fixed my inability to use IRC properly
[13:34] <hyperair> heh lol
[13:36] <gmb> Right
[13:37] <gmb> hyperair: ISTR that we've had problems detecting debdiffs properly in the past. Let me take a look for you...
[13:39] <hyperair> gmb: hmm but why is that, though? it looks like any other diff
[13:39] <gmb> hyperair: That's what I'm trying to find out. I can't remember if it's something to do with the Zope's built in file type detection.
[13:40] <hyperair> hmm
[13:40] <gmb> adeuring, allenap : Can either of you remember if / why we might still have problems detecting debdiffs properly?
[13:40] <gmb> (See hyperair's question for context)
[13:41] <allenap> gmb: It rings a bell, but I can't remember any specifics.
[13:41] <adeuring> gmb, hyperair we rely just on the filename's extension to figure out if a file could be a patch
[13:42] <gmb> Aah.
[13:42] <hyperair> ah
[13:42] <hyperair> that makes sense
[13:42] <hyperair> and kinda sucks
[13:42] <adeuring> hyperair:  yeah... we don't trust a mime type, and file(1) was really broken for diff output that last time I tried it
[13:43] <adeuring> but that's siome time ago...
[13:43] <hyperair> i se.
[13:44] <adeuring> hyperair: but I would really appreciate any suggestion how to do a better detection if a file is patch :)
[13:44] <allenap> Ah yes, I had a branch to use libmagic (what file(1) uses iirc) to auto-detect file types, but the magic database, while fine on Hardy, seemed to regress seriously after that.
[13:45] <hyperair> % file -i debdiff-sru                                                                                       [ 9:44PM]
[13:45] <hyperair> debdiff-sru: text/x-diff; charset=us-ascii
[13:45] <hyperair> adeuring: ^
[13:45] <hyperair> looks fine to me.
[13:45] <allenap> hyperair: It may be that the problem has been fixed.
[13:46] <hyperair> allenap: so launchpad should totally use file for patch detection
[13:46] <adeuring> hyperair, allenap yes, might be. but we should also try file output-from-bzr-diff . That was really broken...
[13:46] <hyperair> heh
[13:46] <hyperair> how about having both checks?
[13:47] <hyperair> if filename.endswith(".patch") or file_says_its_a_diff(filename)
[13:47] <adeuring> hyperair: yes, that would make sense: _if_ "file bugattachment" says that it is diff data, use it, else fall back to using the filename xtension
[13:48] <hyperair> right.
[13:48] <allenap> adeuring, hyperair: bug 34758 was where I tried to introduce libmagic, but bug 285031 is blocking it.
[13:49] <allenap> So, not a problem with diff, but a problem nonetheless.
[14:05] <gmb> danilos: Could you or one of the other still-translations-until-the-end-of-this-week developers take a look at https://answers.launchpad.net/launchpad/+question/140873 please?
[14:05] <gmb> losa ping
[14:05] <danilos> gmb, I'll try to get to it later today, I am already in Dallas
[14:06] <mthaddon> gmb: hi
[14:06] <gmb> danilos: Oh, right, I forgot. Feel free to pass it on to someone with more time and less Tex-Mex.
[14:06] <danilos> gmb, cheers
[14:06] <gmb> mthaddon: Is it possible for us to hide / delete comments on a Question?
[14:07] <gmb> Seems we have some minor spam.
[14:07] <mthaddon> gmb: I don't think we have a means of doing that yet
[14:07] <gmb> Bother.
[14:07] <gmb> mthaddon: I thought not, but worth checking. Thanks anyway.
[14:25]  * gmb -> out for a run; back in a bit
[15:12] <exarkun> maxb: Thanks for the further effort
[15:12] <exarkun> maxb: I tried an svn-import of Nevow with your bzr-svn fix but I still ran out of memory
[15:13] <maxb> You ran out of memory importing just Nevow?!
[15:13] <exarkun> yea
[15:14] <exarkun> on a 32bit machine, so it only had 3gb to play with I guess
[15:14] <maxb> huh. my import crashed long before that
[15:14] <maxb> with a non-memory error
[15:14] <exarkun> huh
[15:14] <exarkun> I left tags out of my subversion.conf
[15:56] <diwic> Hi, I'm having a problem with not getting emails from one of the private projects
[15:58] <diwic> hmm...maybe I'll ask on the Canonical channel instead
[16:24] <ahasenack> hi guys, I have a private PPA to where I just pushed a build. It failed, but the build logs are not available to me (it says "no such resource")
[16:24] <ahasenack> some others in my team can see the build logs, some can't
[16:24] <ahasenack> what's missing?
[16:30] <ahasenack> filed a bug about it: #701534
[16:30] <ahasenack> also, I got an oops when requesting a recipe build from https://code.launchpad.net/~sidnei/+recipe/lazr-js-package-test: (Error ID: OOPS-1837A1250)
[16:31] <ahasenack> note I'm not in the launchpad-beta-users group
[16:50] <bigjools-afk> ahasenack: is that build log problem repeatable?
[16:57] <bigjools>  /msg NickServ help
[16:57] <bigjools> sigh
[17:11] <ahasenack> bigjools: I didn't try, but I'm getting "no such resource" in other build links, like a package
[17:12] <ahasenack> bigjools: right now, https://launchpad.net/~landscape/+archive/lds-trunk/+files/python-lazr-js_1.5-0~bzr176~lucid1_all.deb is giving me that, and it's the result of a recent build in that ppa
[17:12] <bigjools> it works for me
[17:12] <bigjools> are you logged in?
[17:13] <ahasenack> yes
[17:13] <ahasenack> sidnei also can't see it
[17:13] <ahasenack> but bigkevmcd can
[17:13] <bigjools> ok
[17:14] <bigjools> lifeless: ahasenack and others can't see restricted librarian links on a private PPA, but others can.  They get "no such resource" - any ideas wtf is up?
[17:15] <lifeless> browser url mangling perhaps
[17:16] <ahasenack> lifeless: bigjools: fwiw, https://launchpad.net/~landscape/+archive/lds-trunk/+files/python-lazr-js_1.5-0~bzr176~lucid1.tar.gz becomes https://i62062625.restricted.launchpadlibrarian.net/62062625/python-lazr-js_1.5-0~bzr176~lucid1.tar.gz?token=6c0d5f505e2a57bde77c86e8dc9154e4
[17:17] <ahasenack> hopefully that token isn't very secret
[17:17] <bigjools> ahasenack: yes it redirects via a one-time token
[17:18] <bigjools> you need to use the original link every time as it checks your security
[17:18] <bigjools> ahasenack: what browser are you using, and the others where it doesn't work?
[17:18] <bigjools> lifeless: I have recollections of a browser mangling a URL...
[17:18] <ahasenack> bigjools: chrome
[17:18] <ahasenack> let me try ff
[17:19] <bigjools> yeah, chrome is busticated IIRC
[17:19] <bigjools> yup, re-created here in chrome
[17:19] <sidnei> ah, that explains it
[17:19] <ahasenack> chromium, to be more exact
[17:19] <sidnei> im using chrome too
[17:19] <ahasenack> 8.0.552.224 (68599) Ubuntu 10.04
[17:19] <bigjools> it's fine in FF
[17:20] <bigjools> I can't remember what Chromium mangles
[17:20] <bigjools> I think it hates the tildes
[17:20] <ahasenack> bigjools: yes, works here too with FF
[17:22]  * ahasenack updates the bug
[17:28] <lifeless> ahasenack: that token lets folk access the build for 24 hours
[17:29] <lifeless> we need to update lp url generation to emit canonical form urls
[17:29] <lifeless> ahasenack: whats the bug #?
[17:29] <ahasenack> lifeless: that exact url doesn't work, though, not even in ff, it was already broken by chrome
[17:29] <ahasenack> anyway, good I used a public package
[17:29] <lifeless> ahasenack: well, the damage is reversible ;)
[17:30] <ahasenack> lifeless: the token isn't valid for other packages in that ppa, is it?
[17:30] <lifeless> no, that one package
[17:30] <lifeless> ahasenack: whats the bug #?
[17:31] <ahasenack> lifeless: https://bugs.launchpad.net/bugs/701534
[17:40] <ahasenack> question about a recipe, the package was built, but the tarball has the top directory renamed:
[17:40] <ahasenack> andreas@nsn2:~/z$ tar tvzf python-lazr-js_1.5-0~bzr176~lucid1.tar.gz |head -n 2
[17:40] <ahasenack> drwx------ 0/0               0 2011-01-11 14:43 recipe-1.5/
[17:40] <ahasenack> drwx------ 0/0               0 2011-01-11 14:43 recipe-1.5/build/
[17:40] <ahasenack>  is that expected, a bug or a problem in our recipe?
[17:42] <ahasenack> these are the recipe contents:
[17:42] <ahasenack> # bzr-builder format 0.3 deb-version {debupstream}-0~bzr{revno}
[17:42] <ahasenack> lp:~ahasenack/lazr-js/lazr-js-packaging
[17:51] <maxb> ahasenack: I believe that's probably expected, and should not cause problems. Is it?
[17:51] <ahasenack> maxb: it was very unexpected to me
[17:52] <ahasenack> maxb: but ok, I'll yell again if it causes problems
[17:52] <maxb> ahasenack: the main reason it shouldn't be an issue is that dpkg-source should override the top dir name when unpacking
[18:02] <ahasenack> so the changelog of packages built with recipes will always have a "auto build" on top of your original changelog?
[18:03]  * ahasenack looks for the docs
[19:00] <ahasenack> just filed a bug about recipes: #701601
[19:00] <ahasenack> about a dapper build
[21:43] <evaluate> hello
[21:43] <evaluate> I uploaded a package around 15-20 minutes ago but I didn't get any mails yet and I can't see it on the site either. Is there a reason for this?
[21:57] <geser> does LP know that the gpg key you used for signing the upload is yours?
[22:08] <evaluate> geser, good point. I actually updated my key and forgot to update it on launchpad...
[22:08] <evaluate> geser, thanks!