[01:46] <jml> how can I filter merge proposal emails in GMail?
[01:52] <micahg> jml: I filter on Subject
[01:53] <jml> micahg, how does that work?
[01:53] <micahg> Don't they all have [Merge] in them?
[01:53] <micahg> although this might be better: [Merge][Merge]
[01:53] <micahg> oops
[01:53] <micahg> X-Launchpad-Notification-Type: code-review
[01:54] <micahg> that header might be better
[01:54] <jml> micahg, yes, they do. But I'd like proposals for different projects to be tagged differently
[01:54] <micahg> ah
[01:54] <micahg> can't you add multiple filters in gmail?
[01:54] <jml> micahg, do you know how to filter for arbitrary headers in gmail?
[01:54] <micahg> there's a project filter
[01:58] <micahg> jml: i don't know that it's possible
[01:59] <micahg> you could load gmail in thunderbird and do it there...
[02:00] <jml> micahg, hmm.
[02:00] <micahg> jml: maybe put a request into gmail for the feature?
[02:01] <jml> micahg, it turns out that filtering on arbitrary headers is one of the top 10 requested features :)
[02:01] <micahg> ok
[02:08] <mwhudson> i really don't understand why they haven't done that yet
[02:11] <wgrant> It seems like it'd be a pretty critical feature.
[02:11] <wgrant> I couldn't live without it.
[02:18] <mwhudson> mind you, as a launchpad developer i'm not really in any position to ask why an obviously useful feature hasn't been implemented yet...
[02:19] <micahg> jml: maybe by [Merge] and another thing in the subject
[02:19] <micahg> the project is in the subject as well
[02:20] <micahg> or if you have a server you control, you can pipe it through procmail and then have gmail pull it
[02:20] <micahg> and change the address to +project
[07:47] <noodles775> Nice... I love the new milestone page :)
[08:01] <ricli85> i uploaded a pot file through the web interface about a week ago but it still hasn't been approved, how long do i need to wait?
[08:04] <spm> ricli85: that should start fixing from earlier today actually. we were having some interesting issues around translations that necessitated a temporary hold.
[08:06] <ricli85> spm, ok, i'll wait some more then and see if it gets approved soon, thanks
[08:07] <spm> there's a bit of a backlog, aiui, so don't hold your breath; but things are happening again.
[08:40] <al> ok, so bazaar.launchpad.net only works while i'm in this channel i guess?
[08:41] <idnar> haha
[08:42] <spm> al: heh. nice timing; I just bounced it. should be good.
[08:42] <al> spm: k ;)
[08:58] <doctormo_> is the launchpadlib python code ready for general use? and is it possible to use it to do project searches and project details?
[09:01] <doctormo_> https://help.launchpad.net/API/launchpadlib <- In here it says that a cache dir needs to be specified. Is this still the case?
[09:01] <wgrant> doctormo_: If you want a cache, yes. But it's not mandatory.
[09:01] <wgrant> But it's a very good idea.
[09:02] <doctormo_> wgrant: Was there problems using XDG cache dir?
[09:02] <wgrant> doctormo_: Yes. The cache isn't thread-safe.
[09:03] <doctormo_> wgrant: Ew, that can't be good for the look of the thing. Any reason or is it arch problems?
[09:04] <wgrant> doctormo_: No idea.
[09:04] <doctormo_> wgrant: thanks for your help though, filled in a few data points
[09:05] <Daviey> doctormo_: unless i'm mistaken, you also need to be an edge user
[09:05] <wgrant> Daviey: No.
[09:05] <Daviey> oh?
[09:05] <wgrant> Daviey: It's both not restricted to beta testers on edge, and also now available on production.
[09:06] <Daviey> hmm.. wonder why i thought it was edge only
[09:06] <wgrant> Daviey: It was until two months ago.
[09:06] <Daviey> ah!
[09:06] <wgrant> However, it wasn't restricted to beta testers.
[09:09] <maxb> Has anyone filed a bug about making public info readable without oauth credentials?
[09:10] <wgrant> maxb: Yes.
[09:10] <wgrant> maxb: I did a couple of months ago.
[09:11] <wgrant> maxb: For now you can hack launchpadlib to use the webapp vhost, if you really want it.
[09:11] <maxb> egads, that works!?
[09:11] <maxb> Wow
[09:13] <wgrant> Not easily.
[09:13] <wgrant> It needs a couple of changes in wadllib too.
[09:23] <doctormo_> hmm
[09:24] <doctormo_> That bug effects me too, although I suppose it's not too much of a problem since my users are expected to have an account anyway.
[09:30] <doctormo_> wgrant: I don't suppose you've used a file resource object via launchpadlib? finding it hard to sort out how to use it.
[09:31] <wgrant> doctormo_: I haven't, but I thought they worked just like normal files.
[09:33] <doctormo_> wgrant: like normal file io objects?
[09:34] <wgrant> doctormo_: Yes.
[09:34] <doctormo_> ValueError: No JSON object could be decoded <- wow that errors gets annoying quickly
[09:36] <doctormo_> Ah, not file io, but a file object which needs .open()
[09:45] <soren> I think I asked this before, but has anyone succesfully interacted with the API from Javascript?
[09:46]  * soren is contemplating some nifty mashing up he could do with the launchpad data available as JSON
[09:47] <wgrant> soren: LP does lots of interaction like that.
[09:47] <wgrant> But there will be issues getting browser to let you do it from other sites.
[09:48] <cody-somerville> I use the launchpadlib to import launchpad data into my database and then use my own restful API and javascript
[09:51] <cody-somerville> grr
[09:52]  * cody-somerville loves how people rebuild the same packages over and over.
[09:53] <cody-somerville> that is, instead of looking to see if someone else has already published it in a PPA they upload to their own PPA
[09:54] <cody-somerville> and thanks to tools like bzr-builder, a lot of it is just crontabs firing
[09:55] <soren> wgrant: I'll be doing it from chrome, probably.
[09:55] <cody-somerville> I wonder how much buildd time is actually wasted by people carelessly using up a limited resource
[09:55] <soren> wgrant: Not Google Chrome. Firefox chrome.
[09:55] <wgrant> soren: Ah.
[09:55] <wgrant> soren: That would probably be fine, then.
[09:56] <soren> wgrant: Do you know where I can see some example code or something? Is there a library of sorts to do this?
[09:56] <wgrant> soren: LP has some JS client lib for it. Let me see...
[09:56] <thekorn> hi, has the link to directly jump to the sourcecode been removed accedentially from pages like https://code.edge.launchpad.net/~zeitgeist/zeitgeist/event-item-separation ?
[09:57] <thekorn> or is it part of the new blingbling design
[09:57] <wgrant> thekorn: It's currently lost in the middle of a page redesign.
[09:57] <wgrant> thekorn: It will be revived once the branch page is redesigned in a few days.
[09:58] <thekorn> ok, so there is hope it will come back soon
[09:58] <thekorn> thanks wgrant
[09:58] <wgrant> It will return.
[10:32] <IntuitiveNipple> For bugs, how is an upstream bug tracker link supposed to be added when there is no 'distro' option for the upstream package? In this case, I want to add a bug link to bugzilla.mozilla.org against xulrunner-1.9.1 (or firefox-3.5) in an existing bug #359407
[10:40] <wgrant> IntuitiveNipple: Create a task for the upstream bug (using "Also affects project"), and enter the project name and URL there.
[10:40] <wgrant> ... damn.
[11:51] <Lunar_Lamp> "Sorry, there was a problem connecting to the Launchpad server. " <== is this an issue that's being fixed etc.
[11:52] <dpm> jtv: we've got a problem with some UNR Karmic translation imports. Let's take the netbook-launcher as the main package. I had blocked the karmic netbook-launcher templates to allow translators to complete the translation work upstream. This blocked the PO files from the uploaded Ubuntu package as expected.
[11:52] <dpm> I now have approved the templates imported in the next package upload (5 days ago), but that upload didn't seem to provide any translations, as I cannot see any from that day in the imports queue (there are only the ones previously blocked back in August). https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+imports?field.filter_status=all&field.filter_extension=po
[11:52] <dpm> lool tells me that his logs show the PO files being stripped and imported, but as I say, I cannot see them in the imports queue. Any ideas?
[11:52] <Lunar_Lamp> Or am I doing something wrong?
[11:52] <jtv> Lunar_Lamp: were you looking at code?  Because that has problems sometimes.
[11:53] <wgrant> jtv: It seems to be actually dead now.
[11:54] <Lunar_Lamp> jtv: I was just tyring to go to:http://bazaar.launchpad.net/~mysql/mysql-server/mysql-5.1/revision/3106
[11:54] <jtv> dpm: not really parsing at the moment, but one data point that may help: if a blocked (or needs-review) pofile sits in the queue, and an update comes in, the queue entry's content text is updated without any other visible change.
[11:55] <jtv> Lunar_Lamp: so that's the code department...  rockstar, you here?
[11:55] <jtv> or abentley?
[11:55] <Lunar_Lamp> It seems to be working now jtv - and my issues are back to trying to fix other people's code.
[11:56] <Lunar_Lamp> (well, apply their patches anyway)
[11:56] <jtv> Lunar_Lamp: ok, glad it's not blocking you now...  is this patching business anything you need further help with?  I don't know who's on help rotation today, but I can find out.
[11:58] <Lunar_Lamp> jtv: I think my issues were because I had "checked out" the latest version of the repository, and then was trying to apply a patch that was already applied. Thus it wasn't applying cleanly.
[11:58] <Lunar_Lamp> (My experience with bazaar is about 30mins old, so forgive me if I'm not using the correct terms)
[11:59] <jtv> Lunar_Lamp: I haven't forgotten the feeling.  :)  Yes, when patches break, usually it's a sign that a human really does need to look at it.  In my experience bzr does very well at it, but that doesn't make it any easier when it does happen.
[12:00] <dpm> jtv: sorry, I didn't quite get that what is it not parsing at the moment? And what's the import queue's entry text?
[12:01] <dpm> entry content text, I mean
[12:02] <jtv> dpm: I'm not parsing what you're saying because of a few distractions.  :)  The import queue entry's content text.  In other words, the text of the actual file that's been uploaded.  When a file is uploaded, and there's already a queue entry for it from a previous upload, the entry is updated so it contains the latest version of the file—but you don't see that in the queue.
[12:03] <jtv> For instance, the upload date still reflects the _original_ upload that created the entry, not the latest upload that updated the same entry.
[12:03] <sivang> mrevell: hey matthew
[12:03] <jtv> (And yes, we have a bug open on that)
[12:03] <mrevell> Hi sivang
[12:03] <sivang> mrevell: got my email about orginizing a launchpad meeting in Budapest ?
[12:03] <sivang> mrevell: I will be attending the plone conference
[12:03] <jtv> dpm: also, the uploads aren't supposed to trigger approval; it's the auto-approver that should do that.
[12:04] <mrevell> sivang: Hi, yeah, it's on my list :)
[12:04] <sivang> mrevell: cool, I think we could create some itneresting sprints there to combine plone and launchpad as zope apps for one-stop-shop solution of managing both software production and content management
[12:04] <sivang> mrevell: but for that we need to have plone on zope3 for start
[12:04] <jtv> dpm: the auto-approver script at the moment is having a problem with a duplicated domain; I have a code fix in review now but we should probably also figure out which upload is causing this and deal with it manually.
[12:04] <dpm> jtv: yeah, but manually approving the template should trigger an auto-approval of the PO files, even if they were blocked, shouldn't it?
[12:05] <sivang> anyway, have to run to lunch
[12:05] <sivang> people are waiting
[12:06] <dpm> jtv: right, so do you think I should simply manually unblock the PO files in the queue, even if their date des not correspond to the date of the upload?
[12:07] <jtv> dpm: yes on both
[12:08] <jtv> dpm: I don't think the approver can safely unblock the translations by itself because it can't see whether they were blocked because their template used to be blocked, or whether they were blocked individually.
[12:12] <dpm> jtv: (the templates were approved some days ago) I'll do that (unblock the PO files from August), but as I said, what concerns me a bit is the date of those PO files. There have been 3 translation uploads, and there are PO files for the two first ones in the queue, but not for the last one. What I mean is that previous PO uploads _do_ seem to remain in the queue as new ones are added, but not for the last one. Anyway, I'll give that a go. Thanks!
[12:12] <dpm> lool: ^
[12:12] <jtv> dpm: when an import succeeds, its entry is gc'ed off the queue in... 3 days iirc.
[12:13] <jtv> dpm: and if the files' paths have changed, they won't be considered the same uploads.
[12:14] <dpm> yeah, but the import clearly didn't succeed, as there were no translations imported
[12:14] <dpm> and there were no path changes afaik
[12:15] <dpm> anyway, I'll try that and I'll report back
[12:30] <doctormo> What is the advice on uploading videos into bug reports on launchpad?
[12:30] <SamB> doctormo: keep them small ?
[12:30] <SamB> these would be screen-videos ?
[12:30] <doctormo> SamB: Yes, 7MB too large?
[12:31] <doctormo> https://bugs.launchpad.net/inkscape/+bug/429926 for instance
[12:31] <SamB> I would try to use a lossless codec optimized for pixel graphics
[12:31] <SamB> that doesn't sound all that large ...
[12:31] <stub> size of bug attachments is pretty insignificant compared to everything else in that storage.
[12:32] <stub> ISO images might raise eyebrows
[12:32] <SamB> stub: well, I was thinking more about the download time than anything
[12:32] <wgrant> stub: What's biggest these days? BinaryPackageFiles?
[12:32] <stub> yer
[12:33] <SamB> the codec bit was because I hate *PEG artifacts on screenshots ;-P
[12:34] <doctormo> SamB: It's an Ogv file, not a PEG
[12:34] <SamB> what codec ?
[12:34] <wgrant> Theora, presumably.
[12:34] <SamB> I don't presume such things
[12:35] <wgrant> These days it's a fairly valid assumption that .ogv is Theora, I think.
[12:35] <SamB> not really
[12:35] <SamB> it might be a good first guess
[12:35] <SamB> or, wait
[12:35] <SamB> maybe I'm thinking of ogm
[12:35] <doctormo> Desktop/bug429926.ogv: Ogg data, Skeleton v3.0
[12:36] <doctormo> I guess it's not good at telling me
[12:36] <SamB> yeah
[12:36] <SamB> file wouldn't be
[12:36] <SamB> it can't skip variable-sized chunks to find anything indicitive of the actual codec ;-)
[12:37] <SamB> heck, I'm kind of surprised that it can detect self-extracting zips ;-)
[12:37] <wgrant> libmagic is generally pretty good.
[12:38] <SamB> how does that differ from file(1)
[12:38] <SamB> ?
[12:38] <wgrant> file uses libmagic.
[12:38] <SamB> oh, you think they hard-coded it in the C code ?
[12:39] <wgrant> Huh?
[12:39] <doctormo> [Ogg] stream 1: video (Theora v3.2.1), -vid 0
[12:39] <doctormo> [Ogg] stream 2: audio (Vorbis), -aid 0
[12:39] <doctormo> Mplayer to the resque
[12:39] <SamB> most of the detection, you realize, is done based on rules in "magic" files
[12:39] <wgrant> SamB: I know.
[12:39] <SamB> but not all
[12:43]  * SamB struggles to understand how a self-extracting zip can begin with PK\003\004
[12:44] <wgrant> Hey, this is PE we're talking about.
[12:44] <SamB> wgrant: was pretty sure PE had a magic number!
[12:44] <SamB> well, not just one ;-)
[12:44] <wgrant> SamB: But you wouldn't put that at the start.
[12:44] <wgrant> That would be too obvious.
[12:44] <SamB> well, no.
[12:45] <SamB> but don't you neede the MZ header at the beginning?
[12:45] <idnar> PE doesn't care
[12:45] <idnar> you only need that if you want to print an error message when someone tries to run it in DOS
[12:45] <SamB> well, I thought winzip self-extractors worked also on DOS
[12:45] <SamB> idnar: or work on DOS ;-P
[12:47] <SamB> the other possibility is that this is actually just what happens if you remove the SFX stub from the beginning of a winzip SFX ...
[12:48] <SamB> oh, I guess the real file magic for self-extractors is mostly based on looking at offsets used by known stubs?
[12:51] <SamB> ewwwwww!
[12:51] <SamB> there is a DOS extender that uses valid PE executables ... which do not work in Windows!
[12:52] <lool> dpm, jtv: So I understand things are sorted out; do you need a no change netbook-launcher reupload?
[12:52] <SamB> and here I thought that the only dos extender that used PE for it's main executables was an implementation of a win32 subset ...
[12:52] <lool> dpm: No change of getting a langpack update today I guess?
[12:52] <lool> *chance
[12:53] <SamB> huh, I didn't know EFI used PE for executables ...
[12:55] <SamB> ... apparantly since before the Xbox existed
[13:00] <dpm> lool: I believe an upload is not necessary. Translations are now in Rosetta, and they will be included in the next language pack export. ArneGoetje is in charge of the generation of langpacks, he'll be able to tell you more on the actual date of generation and if it's possible to generate one today to pick those translations up. Note that I still haven't got on to approve the rest of the translations for other packages (desktop-switcher, go-home-applet, w
[13:00] <dpm> indow-picker-applet), but I'll do this later on today
[13:00] <lool> dpm: Ok; would you mind pinging me when the other UNR translations are in?
[13:00] <lool> dpm: What about the .mos in the translations tarball?  We dont care about these enough for a new upload?
[13:02] <leonardr> has anyone else experienced bug 353805 with the latest release of launchpadlib? (1.5.1)
[13:03] <dpm> lool: sure, I'll ping you when I'm done. I don't think we care about the mo files for this upload, as if I understand it correctly we only use them to figure out the translation domain, and in this case I entered it manually for all templates already.
[13:04] <lool> dpm: Ok
[14:24] <mrevell> beuno: ping
[14:24] <rhpot1991> hey guys, is there any way of setting up 2 email addresses for a mailing list in launchpad?
[14:24] <beuno> mrevell, pongz
[14:24] <beuno> barry, ^
[14:29] <barry> rhpot1991: no.  what's the use case?
[14:29] <rhpot1991> barry: I have a bot that I want to receive bugmail without creating a seperate LP account for him
[14:31] <barry> rhpot1991: ah, interesting.  no unfortunately there's no way to handle that currently without doing just that.  we have a bug open on "lurking" on mailing lists.  let me try to find that and you can add your use case to it
[14:32] <barry> rhpot1991: bug 194126 this might actually see some attention after lp3.0 is released
[15:02] <kfogel> jtv, danilo-afk: user asking a question at the bottom of http://blog.launchpad.net/translations/new-guides-to-translating-your-project
[15:05] <jtv> kfogel: I don't think he understood that another reader had answered his question.
[15:06] <kfogel> jtv: didn't that other reader only answer one of his questions?
[15:07] <jtv> kfogel: depends on what you call things I guess...  His one actual question was answered.  I'm answering the suggestions now.
[15:13] <danilo-afk> kfogel: I'll respond
[15:13] <danilo-afk> kfogel: oh, I see jtv is doing it already, never mind then
[15:14] <kfogel> jtv: well, he did say "questions and comments" iirc
[15:14] <jtv> kfogel: yes, mostly answered by actually reading the document. :-)
[15:17] <rhpot1991> thanks barry
[15:18] <barry> np!
[15:22] <james_w> are the new page titles fixed, or still in flux?
[15:22] <james_w> I'm seeing a couple that I find weird
[15:24] <james_w> e.g. https://code.edge.launchpad.net/~arky/ubuntu/karmic/envyng-core/fix-411915/+merge/11231
[15:25] <james_w> "envyng-core" package : 9.10 : Ubuntu
[15:25] <james_w> which is correct, but not really specific enough
[15:25] <beuno> james_w, https://wiki.canonical.com/Launchpad/UI/Navigation
[15:26] <beuno> the title (and breadcrumb) should be like in example #3 for MPs
[15:26] <bigjools> james_w: they're in flux a bit, but if you find any it's worth contacting the appropriate team
[15:26] <beuno> not sure if it's something salgado should do, or the code team
[15:27] <james_w> that would probably be better
[15:27] <james_w> it seems anything under Code for packages uses the same title
[15:27] <james_w> doesn't help me find what I want in the address bar
[15:27] <beuno> james_w, anything different from that page, is a bug  ;)
[15:28] <beuno> (sorry about it being in the private wiki, haven't had time to move it over)
[15:28] <james_w> the other was https://bugs.edge.launchpad.net/bzr/+filebug
[15:28] <james_w> +filebug : Bugs in bzr : Bazaar
[15:28] <james_w> "+filebug" should be transliterated in my opinion
[15:29] <james_w> "File a bug" or something
[15:29] <beuno> yeah, the +whatever needs to be fixed in many places
[15:29] <james_w> ok :-)
[15:29] <beuno> not sure if it's a per-page thing, or a site-wide change
[15:29] <james_w> want these filed as bugs?
[15:29]  * beuno looks at salgado and sinzui for an answer
[15:30] <salgado> beuno, I'm working on that
[15:30] <kfogel> jtv: oh -- sorry :-).
[15:30] <salgado> it's a site-wide thing -- when the bug is fixed we'll use the page's title instead of its name
[15:30] <beuno> perfect
[15:30] <beuno> so no bug needed I guess
[15:30] <james_w> great, thanks
[15:31] <james_w> I'll file one for the Code pages?
[15:31] <james_w> or is that the same change?
[15:48] <kirkland> i have some translations questions....  who should i point those at?
[15:49] <salgado> james_w, the +merge/nnn page is a separate issue
[15:49] <salgado> kirkland, danilos is your best bet
[15:49] <kirkland> salgado: thanks
[15:49] <dpm> some things I might be able to answer myself, but danilos, jtv, henninge or Ursinha will be able to give you authoritative answers. They're your best bet
[15:50] <kirkland> danilos: howdy, i'm still trying to learn to get translations working with my projects
[15:50] <dpm> kirkland: ^
[15:50] <kirkland> dpm: coold
[15:50] <kirkland> dpm: okay, the project is launchpad.net/byobu
[15:50] <kirkland> dpm: it's importing to launchpad
[15:50] <kirkland> dpm: and now i just went to https://translations.edge.launchpad.net/byobu
[15:50] <kirkland> dpm: requested a download, and got a tarball of .mo files
[15:51] <kirkland> dpm: so i can insert those into my package
[15:51] <dpm> kirkland: (unfortunately I've got a call in a couple of minutes, so I won't be very responsive :( . The LP translations team will be able to help you)
[15:51] <kirkland> dpm: that's fine and dandy, i think
[15:52] <dpm> but I believe you should simply download the PO files and put them in the source package, not the MO files
[15:52] <danilos> kirkland: hi
[15:53] <kirkland> danilos: howdy
[15:53] <kirkland> danilos: okay, so my project is gettext-ified i think
[15:53] <danilos> kirkland: heya...
[15:53] <kirkland> danilos: i think i really just need to know 2 things ...
[15:53] <kirkland> danilos: what is the "output" that my project needs to put out, and how does launchpad pick that up
[15:53] <danilos> kirkland: right?
[15:54] <kirkland> danilos: i think i know how to get the "input", i see i can just press a button and download a tarball of .mo files, which i can periodically pick up
[15:54] <danilos> kirkland: so, you should have a subdirectory with a .pot file (for now, you'll have to regenerate that yourself with either intltool-update -p, or xgettext usually), where you'd put the translated PO files as well
[15:55] <danilos> kirkland: let me take a look at your project branch and I might give a few more suggestions
[15:55] <kirkland> danilos: okay, yeah, i have made potfiles
[15:55] <danilos> kirkland: right, so, have you considered actually using our bzr export feature as well?
[15:56] <kirkland> danilos: i would love to!
[15:56] <danilos> kirkland: tarball download usually results in ugly filenames
[15:56] <kirkland> danilos: show me how
[15:56] <gaspa> Hi, seems bazaar.lanchpad.net has some kind of problem...  I'm the only experiencing that?
[15:56] <gaspa> (it just says 'internal server error' )
[15:56] <danilos> kirkland: so, I see you already set it up as  lp:~kirkland/byobu/translations on https://translations.edge.launchpad.net/byobu/trunk/+translations-settings
[15:57] <danilos> kirkland: exports happen daily (sometime during the night UTC), so that's when you'll see that branch populated with translations
[15:58] <danilos> kirkland: however, your main branch (which you are importing translations from) seems to be using the broken filenames for PO files which Launchpad produces but can't easily recognize later (yeah, very ugly bug)
[15:58] <kirkland> danilos: okay, so i should just merge from there?
[15:58] <danilos> kirkland: yeah, that should be it
[15:58] <kirkland> danilos: i think i would like to purge those .po files
[15:58] <danilos> kirkland: however, you should first rename files like byobu-de.po to de.po
[15:58] <kirkland> danilos: okay, let me do that
[16:00] <danilos> kirkland: so, you can see how your updated translation files show up in https://translations.edge.launchpad.net/byobu/trunk/+imports, but they are in 'needs review' (and will stay like that because LP auto-approver can't split the template name and language code from the filename); bzr export doesn't produce the crappy names so it's better :)
[16:01] <kirkland> danilos: okay, renamed!
[16:01] <danilos> kirkland: in general, you should be able to use exactly the same branch for translation exports, but in a few weeks export will be improved so it doesn't export po files even when they haven't changed
[16:02] <kirkland> danilos: now what?
[16:02] <kirkland> danilos: now i should merge from somewhere?
[16:02] <kirkland> danilos: to pull the updates?
[16:02] <danilos> kirkland: right, so, now the translations will be imported after auto-approver approves them (that may sometimes take a few hours), and exports will appear daily in the branch you are using for exports... then, at your leisure, just merge the export branch into trunk (i.e. before a release or something)
[16:03] <kirkland> danilos: where is this branch?
[16:03] <danilos> kirkland: if you are not accepting translations from any external source, you can also just let LP directly write to your trunk branch
[16:03] <danilos> kirkland: heh, I believe you set it up on https://translations.edge.launchpad.net/byobu/trunk/+translations-settings
[16:03] <kirkland> danilos: lp:~kirkland/byobu/translations ?
[16:03] <danilos> kirkland: the link tells me it's lp:~kirkland/byobu/translations
[16:03] <danilos> kirkland: yes
[16:04] <kirkland> danilos: cool
[16:04] <danilos> kirkland: (if you decide to go with direct write to the trunk branch, note that before we further improve it it will result in one commit every day, so might pollute your history; that fix should be in by next Wednesday)
[16:05] <kirkland> danilos: cool, i'll just pull at release time
[16:05] <danilos> kirkland: yep, that's fine as well
[16:06] <danilos> kirkland: also, if you are not committing translation updates directly to the trunk branch, you can also use only "Import template files"
[16:06] <kirkland> danilos: okay, now when i build my package, i should install the .po files where?
[16:06] <danilos> kirkland: (i.e. no need to import translations that you exported from LP back)
[16:07] <danilos> kirkland: oh, PO files need to be "compiled" into MO files... GNU gettext and intltool autoconf macros provide that functionality, if you are using any of them
[16:07] <kirkland> danilos: ./usr/share/locale/ja/LC_MESSAGES/byobu.mo
[16:07] <kirkland> danilos: that looks right?
[16:07] <danilos> kirkland: to get MO files, you need to use "msgfmt -o blah.mo blah.po"
[16:07] <kirkland> danilos: gotcha, okay, i have that
[16:07] <kirkland> danilos: it's just been broken up until now
[16:07] <danilos> kirkland: yes, though note that path depends on bindtextdomain call
[16:07] <kirkland> danilos: right!
[16:10] <kirkland> danilos: okay, so i'm ready to roll a release
[16:10] <kirkland> danilos: but i should probably wait for LP to pick up the changes I just made, renaming those files?
[16:11] <danilos> kirkland: the export branch looked fine already, though you might hit some conflicts... to resolve them, feel free to overwrite files in your trunk with those from LP export (it merges translations in a smart way for you)
[16:12] <danilos> kirkland: if you have updates in a branch, then yes, you should wait for LP to import them and export them afterwards
[16:12] <kirkland> danilos: my text hasn't changed in a long time
[16:12] <kirkland> danilos: okay, so i'll overwrite, and just take LP's on top of mine
[16:13] <danilos> kirkland: right, then there's probably no need to wait... a rename is just for the future
[16:13] <danilos> kirkland: i.e. get translations straight from the bzr export
[17:00] <cody-somerville> What would case python-launchpadlib to return a string instead of a datetime object?
[17:00] <cody-somerville> *cause
[17:02] <intellectronica> cody-somerville: what object.field are you asking for?
[17:02] <cody-somerville> date_targeted
[17:03] <cody-somerville> I think its an underlying lib it depends on
[17:03] <cody-somerville> as I backported karmic's launchpadlib to hardy
[17:18] <pwolanin> Can anyone point me to instructions for taking an existing source package in launchpad, then making my own version (updated source code), and then getting it into a PPA so it will build?
[17:22] <bigjools> pwolanin: there's nothing that explicit, but there's a PPA guide at https://help.launchpad.net/Packaging/PPA
[17:26] <pwolanin> bigjools:  yeah, that's a little confusing.  So if I have code in launchpad, do I have to upload it again to make a package?
[17:27] <bigjools> pwolanin: you have a tarball of the source?  or a source package?
[17:28] <pwolanin> bigjools: basically I want to take this official package, but then update the source and some of the config https://code.launchpad.net/~ubuntu-branches/ubuntu/hardy/nginx/hardy-backports
[17:29] <bigjools> pwolanin: okay, you shou;d be able to bzr branch it, then change stuff, then run "bzr builddeb"
[17:30] <bigjools> then upload it to your PPA
[17:31] <pwolanin> bigjools:  ok, so even if I make my own brnach of this code, there is always a separate uplaod step to the PPA?
[17:31] <bigjools> pwolanin: yes, that's unavoidable
[17:32] <pwolanin> bigjools:  ok, that's fine - just trying to grasp the process
[17:32] <bigjools> later this year we'll be working to put a button somewhere that will upload a branch to your PPA
[17:33] <pwolanin> bigjools: my bzr doesn't know about builddeb - is that an extra I need ot install?
[17:33] <bigjools> yeah it's a plugin, not sure where you get it.  james_w?
[17:33] <james_w> apt-get install bzr-builddeb
[17:33] <bigjools> there ya go :)
[17:34] <pwolanin> ok, let me give that a shot - bigjools the magic button would be nice of course :)
[17:35] <bigjools> it will happen :)
[17:40] <doko> is there a launchpad developers ML?
[17:44] <pwolanin> bigjools:  how does the PPA know which version of Ubuntu you want to build for?
[17:45] <bigjools> doko: yes
[17:45] <bigjools> launchpad-dev@lists.launchpad.net
[17:46] <bigjools> pwolanin: it's in the Distribution: field of the control file
[17:46] <bigjools> or you can override that in the upload path
[17:46]  * Spads has coffee and a faboo blueberry muffin
[17:46] <pwolanin> bigjools: ok, so e.g. if I start w/ a Hardy package there will be nothing to change
[17:46] <Spads> -EWRONGWIN
[17:53] <pwolanin> bigjools:  odd - the there control file has no Distribution line
[17:56] <james_w> pwolanin: it's actually the first line of debian/changelog
[18:00] <pwolanin> james_w: and that controls how the PPA builds it?
[18:00] <james_w> pwolanin: indirectly
[18:00] <james_w> "debuild -S" takes what is written there and puts it as the "Distribution:" line in the _source.changes that it creates
[18:01] <james_w> when you dput that to LP it will use that to decide what to build for
[18:01] <james_w> unless you override that in the dput path
[18:04] <pwolanin> hmm, so 8.04 installs an outdated bzr?
[18:04] <pwolanin> bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
[18:06] <beuno> pwolanin, 8.04 is... a year and a half old
[18:07] <pwolanin> beuno:  LTS?
[18:07] <beuno> pwolanin, yes
[18:07] <beuno> so it wasn't outdated then
[18:07] <beuno> it's outdated today
[18:07] <pwolanin> beuno:  it seems to still be the version Canonical would suggest for running a server
[18:08] <beuno> pwolanin, well, yes, as it's the most stable to date
[18:08] <beuno> but it also means it has older versions
[18:08] <beuno> so you may need to installer newer non-default versions
[18:08] <pwolanin> beuno: yes, sure - I don't see anything in hardy-backports though
[18:09] <beuno> pwolanin, I don't know about backports, but you can get the latest bzr from it's PPA
[18:09] <pwolanin> beuno: ya, just looking there
[18:44] <cr3> I've experienced a chroot problem when building packages for karmic, is that a known problem?
[18:46] <cjwatson> I'm trying to sort out an urgent problem with Ubuntu, but https://edge.launchpad.net/builders/crested/+edit and https://edge.launchpad.net/builders/molybdenum/+edit are timing out for me
[18:46] <cjwatson> can anyone help?
[18:51] <cjwatson> ... never mind, apparently different buildds are happier
[19:22] <pwolanin> am I doing somethign sill - lp wants create branches for me like  ~pwolanin/+junk
[19:24] <pwolanin> Do I need to create a project first - even if it's just a placeholder?  I'm a bit lost comparing this to github where I can clone an existing repo easily in order to start my own development
[19:29] <salgado> intellectronica, can you help pwolanin?
[19:36] <salgado> pwolanin, do you want to branch from an existing codebase or is this a completely new one?
[19:36] <maxb> pwolanin: It is mandatory that every branch be associated with a project, or "+junk" (or a distribution source package)
[19:36] <pwolanin> salgado:  from an existing codebase
[19:36] <salgado> pwolanin, is it hosted/mirrored in Launchpad already?
[19:37] <pwolanin> salgado: https://code.launchpad.net/~ubuntu-branches/ubuntu/hardy/nginx/hardy-backports
[19:37] <pwolanin> salgado:  basically I jsut want to use this as a basis for building a newer version of nginx
[19:37] <salgado> right
[19:37] <pwolanin> perhaps with some customized configuration
[19:39] <salgado> pwolanin, in Launchpad there's no need to create the branch through the web UI.  you make the branch using bzr commands, push it to Launchpad when you want and everything gets created automatically
[19:39] <salgado> $ bzr branch lp:ubuntu/hardy-backports/nginx
[19:39] <salgado> # hack, commit, push
[19:40] <pwolanin> salgado:  if I push where does that code go?
[19:40] <pwolanin> I can push to ~pwolanin/ubuntu/hardy-backports/nginx
[19:40] <pwolanin> ?
[19:40] <salgado> by default you have to specify where to push it to
[19:41] <salgado> yes, that'd be the correct location for this branch
[19:41] <pwolanin> ok, I was assuming that wasn't allowed based on it not being possible in the UI
[19:43] <pwolanin> apparently not
[19:43] <pwolanin> bzr: ERROR: Invalid url supplied to transport: "lp:~pwolanin/ubuntu/hardy-backports/nginx": No such distribution series hardy-backports.
[19:48] <salgado> pwolanin, I think you have to push it to lp:~pwolanin/ubuntu/hardy/nginx in this case
[19:48] <pwolanin> salgado: I tried that too
[19:49] <salgado> pwolanin, what error did you get with that?
[19:49] <pwolanin> bzr: ERROR: Invalid url supplied to transport: "lp:~pwolanin/ubuntu/hardy/nginx": ~pwolanin/ubuntu/hardy/nginx is too short to be a branch name. Try '~<owner>/+junk/<branch>', '~<owner>/<product>/<branch> or '~<owner>/<distribution>/<series>/<sourcepackage>/<branch>'.
[19:49] <salgado> oh, right
[19:49] <salgado> you need a branch name
[19:50] <salgado> lp:~pwolanin/ubuntu/hardy/nginx/<branch-name>
[19:50] <flacoste> beuno: still around?
[19:50] <pwolanin> salgado: ah, ok - let's see
[19:51] <pwolanin> salgado: ok, that did something, thoguh some warning about stacking
[19:52] <flacoste> beuno: if you could update the conversion script in your account to the latest revision on lp:~flacoste/+junk/3.0-template-tracker
[19:52] <flacoste> Ursinha: ping
[19:52] <Ursinha> flacoste, pong
[19:52] <flacoste> hey Ursinha!
[19:52] <Ursinha> :)
[19:52] <Ursinha> hi flacoste
[19:53] <flacoste> Ursinha, where do you keep the branch holding the QA test plan script?
[19:53] <Ursinha> flacoste, it's in the lp-qa-tools project
[19:53] <Ursinha> a moment
[20:01] <Ursinha> flacoste, here: https://code.edge.launchpad.net/~ursinha/lp-qa-tools/trunk-test-plan-tool
[20:01] <flacoste> Ursinha: that's "trunk"?Y
[20:02] <Ursinha> flacoste, yes
[20:02] <flacoste> Ursinha: can you set it as the trunk development focus?
[20:02] <flacoste> err, associated branch?
[20:02] <Ursinha> flacoste, a convention me and matsubara created when the lp-qa-tools was created
[20:03] <Ursinha> flacoste, I'm not sure I understand what you mean
[20:03] <Ursinha> flacoste, we have more than one "trunk" in there because the project has several scripts
[20:04] <matsubara> flacoste, short answer is no we can't. long answer, rather than have a single branch with all our utilities we have a bunch of small branches for each one and use the project to aggregate all of them
[20:04] <flacoste> matsubara, Ursinha, a, i see
[20:04] <flacoste> kind of goes against the grain of Launchpad here
[20:04] <flacoste> probably makes sense to have all the scripts in one branch
[20:05] <flacoste> that way you can share more code between them
[20:06] <Ursinha> flacoste, that makes sense, but the scripts are like mini projects that were created separately and then put together under lp-qa-tools project
[20:06] <flacoste> Ursinha: i don't see your branch listed on https://code.edge.launchpad.net/lp-qa-tools
[20:06] <flacoste> right
[20:06] <flacoste> never too late to fix that
[20:07] <fta> why are bug comments now folded? are we supposed to use pastebin links now to paste stuff??
[20:08] <fta> my last comment is barely readable: https://bugs.edge.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/399938/comments/9
[20:12] <Ursinha> flacoste, and now
[20:12] <Ursinha> ?
[20:12] <flacoste> yep, i see it
[20:13] <flacoste> are all the scripts in use on that page now?
[20:13] <flacoste> probably a bad question to ask
[20:13] <flacoste> since you probably see everything :-)
[20:13] <flacoste> i see 11 branches
[20:18] <flacoste> Ursinha: what's the script that generate the test plans stats for graphing?
[20:19] <Ursinha> flacoste, nope, not all scripts
[20:19] <Ursinha> let me do some magic here
[20:27] <Ursinha> flacoste, https://code.edge.launchpad.net/~launchpad/lp-qa-tools/test-stats
[21:02] <pwolanin> actually got a deb built, but something seems to be missing frmo the ppa docs
[21:02] <pwolanin> No signature on /home/pwolanin/build-area/nginx_0.7.62-acquia1~hardy1_source.changes.
[21:03] <pwolanin> gpg: no valid OpenPGP data found.
[21:04] <pwolanin> ah, no key info is shown on the PPA page - am I missing something?
[21:13] <salgado> cprov, can you help pwolanin?
[21:37] <pwolanin> anayone knwo about getting the PGP for a ppa?  do I just need to wait longer?
[21:44] <pwolanin> are these instructions out of date?  https://help.launchpad.net/Packaging/PPA#Your%20PPA%27s%20key
[21:47] <tormod> are ppa uploads blocked because of the karmic build issues?
[21:58] <pwolanin> I don't see any sort of notification  https://help.launchpad.net/
[21:59] <pwolanin> http://blog.launchpad.net/notifications
[22:35] <cjwatson> tormod: I believe so
[22:37] <doctormo> Uploading to ppa (via ftp to ppa.launchpad.net): Connection failed, aborting. Check your network [Errno 111] Connection refused
[22:37] <doctormo> Is everything ok in launchpad land?
[22:39] <tormod> doctormo: ^^
[22:50] <cprov> doctormo: ppa.l.m ftpd is dead.
[22:50] <doctormo> ok
[22:51] <cprov> doctormo: fixed
[22:51] <doctormo> wonderful, thanks cprov
[22:52] <cprov> doctormo: although, as someone mentioned, chroots are still in maintenance thus no builders
[22:53] <doctormo> cprov: Not a problem, it'll go in queue right?
[22:53] <cprov> pwolanin: sorry, what's exactly your problem ? (I've lost history)
[22:53] <cprov> doctormo: yup
[22:54] <pwolanin> cprov:  trying to get started with a ppa
[22:54] <pwolanin> cprov:  docs suggest that a GPG key needs to be installed locally from the ppa apge
[22:54] <cprov> pwolanin: right, and it will only be generated after the first successful upload
[22:55] <pwolanin> cprov: oh, I get an error abotu a missing key when I try to upload
[22:55] <cprov> pwolanin: it's not related
[22:55] <cprov> pwolanin: LP will generate a key to sign the PPA repository contents
[22:55] <pwolanin> cprov:  ok, it's not on the luanchpad page list of error messages - any ideas then?
[22:55] <cprov> pwolanin: you need to sign upload with your personal key
[22:56] <cprov> pwolanin: that's not an LP error, it's debuild AFAICS
[22:56] <cprov> pwolanin: what's your LP ID ?
[22:57] <pwolanin> cprov:  pwolanin
[22:57] <pwolanin> cprov: the erorr says:
[22:57] <pwolanin> Please remember that the signature file (.sig or .asc)
[22:57] <pwolanin> should be the first file given on the command line.
[22:57] <pwolanin> so somewhere the insturctions are missing a step
[22:58] <cprov> pwolanin: which command line did you run ?
[22:59] <pwolanin> cprov:  dput acquia nginx_0.7.62-acquia1~hardy1_source.changes
[22:59] <pwolanin> cprov:  where I edited the conf file per instructions to reference the ppa as "acquia"
[22:59] <cprov> pwolanin: okay, is your .changes file signed ?
[23:00] <pwolanin> cprov: no, I did not see that in the instructions
[23:00] <pwolanin> cprov:  folling this page https://help.launchpad.net/Packaging/PPA/Uploading
[23:00] <cprov> pwolanin: it's part of the default 'source building' instructions
[23:01] <cprov> pwolanin: the first link in that page is https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage
[23:02] <cprov> pwolanin: run `gpg --list-secret-keys pwolanin` and check if there is a secret gpg key available
[23:02] <pwolanin> cprov:  ok, I saw a note there about possible error messages, but maybe it's here somehwere https://wiki.ubuntu.com/PackagingGuide/Basic#Building%20the%20Source%20Package
[23:03] <cprov> pwolanin: right
[23:03] <pwolanin> cprov: I have a key and I registered it earlier today w/ launchpad
[23:03] <wgrant> debuild should have given you a warning that it couldn't find the key.
[23:03] <pwolanin> wgrant:  hmm someone here suggested using bzr builddeb
[23:03] <wgrant> The UID on the key needs to precisely match (including any comment) your name and email address in debian/changelog.
[23:03] <pwolanin> so I did it that way
[23:03] <wgrant> pwolanin: That uses debuild internally, so that doesn't matter.
[23:04] <pwolanin> wgrant:  ah, that could be it - I put the team e-mail address not my personal one
[23:04] <wgrant> pwolanin: If there is a good reason that the key doesn't match the changelog, give bzr-builddeb '-kDEADBEEF', where DEADBEEF is your key ID.
[23:04] <cprov> ah, bzr-builddeb joy ...
[23:05] <pwolanin> wgrant: ok, let me try that.  Seems like I needed -S flag too?
[23:05] <wgrant> pwolanin: Yes, you always need -S for Launchpad uploads.
[23:06] <cprov> we should write an help page specifically for users using bzr-builddeb and PPAs ...
[23:06] <cprov> while we implement BuildingSPBranches :)
[23:07] <wgrant> cprov: This issue wasn't specific to bzr-bd, though.
[23:08] <james_w> actually, if pwolanin is on an old release it was
[23:08] <cprov> wgrant: agreed, but a specific help would have helped.
[23:08] <pwolanin> bzr: ERROR: no such option: -k
[23:08] <james_w> oh, no
[23:08] <james_w> bzr-builddeb used to default to not signing
[23:08] <pwolanin> james_w: I got wahtever hardy installs - though I updated bzr itself via ppa
[23:09] <pwolanin> james_w: can I just sign the file manually?
[23:09] <wgrant> Ah. Ancient.
[23:13] <wgrant> pwolanin: debsign -kabcd1234 blah_source.changes
[23:13] <pwolanin> so if I just --clearsign the files is that going to work?
[23:14] <pwolanin> ok
[23:17] <pwolanin> ok, well did that - new error:  Checksum doesn't match for /home/pwolanin/build-area/nginx_0.7.62-acquia1~hardy1.dsc
[23:30] <pwolanin> ah success!