[00:32] <poolie> hi, can anyone here help with launchpad comment spam?
[00:32] <poolie> spm: are you home?
[00:32] <poolie> in https://bugs.edge.launchpad.net/bzr/+bug/215674
[00:32] <thumper> poolie: he is, but was looking for fud
[00:32] <ubottu> Ubuntu bug 215674 in bzr-gtk "uncommit needs an option for saving commit messages" [High,Fix released]
[00:37] <poolie> ahah
[00:37] <poolie> fooled again by bug 277352 - it looks like that user has not placed any comments
[00:37] <ubottu> Launchpad bug 277352 in malone "should be easier to search for closed bugs" [Medium,Triaged] https://launchpad.net/bugs/277352
[01:09] <spm> poolie: hi, yes - will fix
[01:15]  * wgrant is glad to see geographically-distributed LOSAs.
[01:15] <mwhudson> yes, hooray for that
[01:15] <spm> poolie: removed, and user suspended.
=== mcasadevall is now known as NCommander
[01:16] <spm> technically I think it fair to say that last week we 3 *were* geographically distributed.
[01:16] <spm> relative to our homes... ;-)
[01:16] <wgrant> True.
[01:17] <NCommander> wgrant, launchpad issues?
[01:17] <wgrant> NCommander: A few times during the week.
[01:17] <NCommander> wgrant, hrm, seems all the icons disappeared off the main page, and on my team page
[01:18] <wgrant> NCommander: That's just a bug, which is filed.
[01:18] <NCommander> pretty serious bug
[01:18] <wgrant> Why?
[01:19] <wgrant> Custom branding vanishing could not in any way be regarded as serious.
[01:21] <Zanko> hi
[01:21] <Zanko> i have a litte question about translation:
[01:22] <Zanko> i have imported a .po file for the french version of my project, however launchpad says that 18 of 18 strings are untranslated in french
[01:23] <Zanko> also the .po file is still marked as "need review" in the import queue
[01:23] <Zanko> can someone help me ?
[01:23] <Zanko> how to make launchpad to use my po file ?
[01:25] <wgrant> Zanko: The strings are shown as untranslated because the file hasn't been imported yet - 'Needs Review' indicates that it needs manual review by one of the Launchpad Translations people.
[01:25] <wgrant> Once they approve it, the strings should show as translated.
[01:25] <Zanko> ok thanks
[01:27] <Zanko> this is a bit strange no ? I mean, I am the creator of the project, I have added the translation to the bzr repo, why review it ?
[01:28] <poolie> thanks spm
[01:29] <Zanko> if i'm not trusted to add translation to a project i created, why should i be trusted to add code to it ?
[01:30] <wgrant> Zanko: Possibly because translations affect the whole of Launchpad, as suggestions are shared between projects. But I don't know for sure.
[01:31] <Zanko> you're probably right, i had'nt think to this
[01:31] <mwhudson> Zanko: have you seen https://help.launchpad.net/Translations/ImportPolicy ?
[01:32] <Zanko> no thanks i will read it
[01:33] <Snova> The OpenSourcing page says that Code hosting will not be released publicly- how much does this encompass?
[01:41] <poolie> hm that's odd
[01:47] <poolie> Snova: it's to-be-announced
[01:47] <poolie> i think at least the web ui relating to code will be released
[01:48] <Snova> Ok. There are some neat features that would be nice to have in a local installation, I'm just wondering what scope of them will remain. (Assuming I can set it up :P)
[01:48] <poolie> what kind of thing?
[01:50] <Snova> Honestly, I can't name anything specific.
[01:52] <Snova> The code section, now that I look closely at it, has little on the surface that I would need in a private installation. I suppose I'm simply curious what will be missing.
[01:53] <thumper> Snova: what is your rationale for running a local copy?
[01:55] <Snova> thumper: Mostly just to mess with it. I don't do anything serious, and if it becomes too much effort, I probably won't.
[01:56] <Snova> I tend to start a lot of little personal projects and having a Launchpad around would be handy- but they're never large/involved enough to justify an actual project on LP.
[01:56] <poolie> hm
[01:56] <poolie> it's kind of an interesting observation
[01:56] <poolie> if running your own copy seems easier then the work to make a project on lp is probably too high
[01:57] <poolie> or if not work, the degree of emotional commitment or something
[01:57] <poolie> degree of publicity
[01:57] <wgrant> A few people have made this point in the past couple of weeks.
[01:57] <wgrant> Projects are pretty permanent, I guess.
[01:57] <Snova> It's not a lot of work. They just don't merit being made public, what you said about sums it up.
[01:57] <poolie> mm
[01:57] <poolie> there's a big jump between +junk and a real project
[01:57] <poolie> comes back to this idea of a nursery or something
[01:58] <Snova> Occasionally I'll produce something I wish to share with a few people, but a simple +junk branch serves me well enough. Any "bugs" people report I either write down or fix immediately.
[01:58] <wgrant> But running one's own Launchpad seems like utter overkill.
[01:59] <Snova> Yes... lately I've been happy to find how easy it is to create a Trac instance, and I can tear it down in a heartbeat. launchpad.net would require filing an answer... so I tend not to.
[02:00] <poolie> does it really, to make a new project?
[02:00] <poolie> that's definitely too slow
[02:00] <wgrant> No, it requires one to *remove* a project.
[02:00] <wgrant> Creation takes seconds.
[02:01] <thumper> hmm...
[02:01] <thumper> a project owner should be able to remove it if there is no third part contributions I guess
[02:01] <Snova> To remove it later. And most of my silly little projects are, eventually, going to disappear. I have one "official" project on LP that I grew bored with quite some time ago.
[02:01] <thumper> it is hard to decide when to allow something to be made "unpublic"
[02:01] <wgrant> What do other hosting sites do?
[02:01] <thumper> Snova: someone may take it up though...
[02:02] <Snova> Also, I tend to do most coding after I can't use the internet, and thusly LP...
[02:02] <thumper> Snova: if you are just wanting to share code, loggerhead does that pretty well
[02:03] <wgrant> Snova: DVCSes solve that problem.
[02:04] <poolie> someone should write this up...
[02:06] <Snova> So they do, but only the code part.
[02:06] <thumper> Snova: what exact problem are you trying to solve?
[02:07] <Snova> I don't have a problem. This started when I inquired as to what elements of LP Code weren't going to be published, and I found my answer almost immediately (that it isn't specified). :)
[02:07] <thumper> :)
[02:08] <wgrant> I would have expected the private bits to have be determined by just weeks before the code is released...
[02:08] <wgrant> s/be/been/
[02:10] <Snova> Perhaps the reason I want to create a local LP installation is to use it as something like a staging area... a place I can keep track of my little projects before they are large enough to consider publishing "officially". Once they get somewhere I don't mind using LP, but until then I find myself writing todo/bug lists.
[02:13] <cody-somerville> I see plenty of rationale for private instances of launchpad but not for local instances. By the time I get to the point where I need a bug tracker, I've probably made an initial release.
[02:13] <cody-somerville> And by rationale, I mean personal rationale
[02:13] <thumper> well...
[02:13] <Snova> How do you define "private" and "local"? The terms are synonymous to me, both meaning "on my laptop, for me".
[02:13] <thumper> anyone attempting to contribute should be able to run a local launchpad
[02:13] <spm> Snova: if you just need a personal bug tracker etc; why not use eg flyspray?
[02:13] <thumper> at the very least to test it :)
[02:14] <thumper> `make run` will work :)
[02:14] <wgrant> spm: Because most other bugtrackers suck.
[02:14] <thumper> (with enough initial setup)
[02:14] <Snova> spm: I've been making some use of those recently, actually, I just like Launchpad and don't mind trying to install it. :)
=== Hellow is now known as Hellow__
=== Hellow__ is now known as Hellow|Alt
=== Hellow|Alt is now known as Hellow
=== Snova_ is now known as Snova
=== \sh_ is now known as \sh
[09:38] <SiDi> Hello
[09:39] <SiDi> Is it please possible to change the exemple project in https://help.launchpad.net/Answers/AskingForHelp ?
[09:39] <SiDi> The Exaile devs are bored of having offtopic questions apparently :)
[09:40] <intellectronica> SiDi: sounds like a reasonable request to me. can you please file a bug on the launchpad documentation project? you're of course welcome to make the change yourself too
[09:44] <SiDi> I dont have the rights to edit it, gonna fill a bug
[09:45] <intellectronica> SiDi: really? you should be able to edit after logging into the wiki (using your LP credentials)
=== sonicmctails is now known as mcasadvall
[09:45] <SiDi> intellectronica: ok, found the edit button :d
[09:46] <SiDi> intellectronica: any idea of a suitable project ? :p
[09:47] <intellectronica> SiDi: how about https://edge.launchpad.net/null ?
[09:47] <SiDi> hm yeh
[09:47] <intellectronica> SiDi: also, it would be better to link to staging.launchpad.net, so that whatever actions users might do won't interfere with normal launchpad data
[09:48] <SiDi> intellectronica: but then they might take the uri and replace the project name and not notice they're in the staging platform
[09:48] <intellectronica> hmmm .... right
[09:49] <intellectronica> so let's use null for now
[09:49] <SiDi> changed : https://help.launchpad.net/Answers/AskingForHelp
[09:49] <intellectronica> SiDi: we can discuss with mrevell when he's next online and see if he has a better suggestion
[09:49] <SiDi> thanks intellectronica :)
[09:49] <SiDi> yeh. I guess we should avoid any non-lp non-ubuntu project anyway
[09:49] <SiDi> its not nice for the chosen project :p
[10:10] <wgrant> To increase the SNR across Launchpad, maybe link them to a project where asking a question suspends their account!
[10:14] <intellectronica> wgrant: SNR?
[10:15] <wgrant> intellectronica: Signal-to-noise ratio.
[10:15] <intellectronica> ah of course
[10:17] <SiDi> wgrant: it sounds a bit *drastic* for newbies
[10:18] <wgrant> SiDi: Ah yes, but they'd be newbies who clearly can't read.
[10:19] <wgrant> But yes, using null sounds like a reasonable solution.
=== BjornT changed the topic of #launchpad to: https://launchpad.net/ | Help contact: BjornT | Join https://launchpad.net/~launchpad-users | Channel logs: http://irclogs.ubuntu.com | Open Sourcing: https://dev.launchpad.net/OpenSourcing
[10:49] <\sh> dear launchpadlib devs, please look at bug #81689 and remove the symlink so I can do some work for LP on windows, too ;)
[10:49] <ubottu> Launchpad bug 81689 in bzr "Branches with symlinks can't be checked out on Windows" [Medium,Triaged] https://launchpad.net/bugs/81689
[10:51] <magcius> \sh, that looks like a bug in bzr, not LP
[10:51] <\sh> magcius: well...lifeless writes: This is the key: contact the launchpadlib developers and ask them to not
[10:51] <\sh> use symlinks.
[10:51] <SiDi> \sh: what is windows ?
[10:52] <\sh> magcius: but yes it's also a bug in bzr ;)
[10:53] <SiDi> It's a bug in NTFS imo :) Do you have the bzr plugin that simulates symlinks in windows ?
[10:54] <\sh> SiDi: tbh I don't care...but I would like to use lplib on windows (because I want to have leonov very OS independend) I just need this bug fixed, one way or the other
[10:55] <SiDi> \sh: do you have that plugin simulating symlinks in windows ?
[10:55] <\sh> SiDi: nope...regarding the plugin description it only works until bzr 0.9x
[10:55] <SiDi> Well, you should at least test it
[10:56] <SiDi> and if it doesnt work, report a bug against bazaar asking for the plugin to be ported
[10:56] <SiDi> You can't reasonably ask developers not to use symlinks just for windows.
[11:00] <\sh> SiDi: if the software is declared as OS independend which means it should run on un*x and non un*x OS, then I would think that we don't use any os dependent functionality, no?
[11:02] <SiDi> \sh: not FS indenpendant, though (this was a troll \o/). File against launchpadlib too then
[11:05] <\sh> SiDi: that was the plan :)
[11:05] <SiDi> \sh: :D
=== magcius_ is now known as magcius
[12:09] <Saviq> hi all, guys, is there a way to migrate translations between a project series?
[12:14] <noodles775> danilos: ^^^
=== menesis1 is now known as menesis
[12:15] <danilos> Saviq: yeah, just upload a new POT file with exactly the same name to a new series, and translations will be migrated automatically once it's imported
[12:15] <danilos> Saviq: new POT might need manual approval if you are not using bzr imports, but feel free to ping us about it
[12:16] <Saviq> yeah that won't work since we already have changed our template names
[12:16] <Saviq> I'll need to download and upload the POs by hand, will they be fuzzy-matched?
[12:17] <danilos> Saviq: what do you mean?
[12:17] <danilos> Saviq: in general, you should try to use the same names if they are same templates
[12:18] <Saviq> danilos: yeah they were wrong before
[12:18] <danilos> Saviq: if you do that, translators will be able to translate multiple series at the same time
[12:18] <danilos> Saviq: right, but we can easily fix them
[12:18] <danilos> Saviq: what's the project?
[12:18] <Saviq> lp:elisa
[12:18] <Saviq> 0.5 vs 1.0
[12:19] <danilos> Saviq: right, and into what series do you want to migrate translations? into trunk or from 0.5 into 1.0?
[12:19] <Saviq> from 0.5 into 1.0
[12:19] <Saviq> the template names in 1.0 are 'correct'
[12:19] <Saviq> the ones in 0.5 lack 'elisa-plugin-' in them
[12:20] <danilos> Saviq: right, do you want me to fix them? (fwiw, I was looking into this recently, since we are planning on doing database migration soon to share translations, and I've got some notes on Elisa and what we need to do about it :) If we can solve it right away, even better :)
[12:21] <Saviq> yeah that would be great
[12:24] <Saviq> and if there's anything else we could do to improve the experience, please tell as we're in the process of making Elisa / Moovida as translator-friendly as possible
[12:29] <danilos> Saviq: sure, I am looking at it right now
[12:29] <danilos> Saviq: so, all template names should be as in 1.0?
[12:29] <Saviq> yes
[12:30] <Saviq> the 'i18n' one isn't there in 0.5
[12:30] <danilos> Saviq: ok, cool
[12:30] <Saviq> it actually shouldn't be in 1.0 either as it's a test-case, but that's a small problem
[12:30] <danilos> Saviq: oh, I can remove it as well, if that's what you want :)
[12:30] <Saviq> it will get imported from bzr on next commit anyway, no?
[12:31] <Saviq> no way to 'blacklist' a templte
[12:32] <danilos> Saviq: ah, right, it will... we can mark them as "Blocked", but won't work with bzr imports
[12:32] <Saviq> never mind that
[12:32] <danilos> Saviq: do you want translation domain (i.e. path it's exported as) changed as well?
[12:32] <robin_> jml: hi. Is there any change in bug 382795?
[12:33] <ubottu> Launchpad bug 382795 in launchpad-code "mirror-branch using too much memory" [Critical,Fix committed] https://launchpad.net/bugs/382795
[12:33] <Saviq> no, leave them as they are, we'd have to backport some changes into 0.5 for that to work
[12:33] <danilos> Saviq: ok, sure
[12:37] <danilos> Saviq: ok, names should match between 0.5 and 1.0 now; however, actual sharing between them will happen properly only once we do the migration (this is a relatively recent feature, and I'd love to make sure it works fine for Elisa as well)
[12:38] <jml> robin_, remind me where we were at with that
[12:38] <danilos> Saviq: it will take us a few days to test it all out before we can actually do it; do you mind filing a request to share translations between 0.5 and 1.0 in elisa on answers.launchpad.net/rosetta so we can keep track of it?
[12:38] <Saviq> danilos: great, thanks - I will
[12:38] <robin_> jml: I try what you said, but it failed
[12:39] <danilos> Saviq: thank you as well :)
[12:39] <jml> robin_, ok. did you ask a Question on Launchpad?
[12:40] <robin_> jml: No. I am focus on my code these days. My branch is banned again several days ago.
[12:40] <jml> robin_, ok. so, that bug is now fixed in production
[12:40] <jml> robin_, your core problem though is that somehow bzr is behaving badly.
[12:41] <robin_> jml: it means?
[12:42]  * jml thinks
[12:42] <jml> robin_, I mean that you can push that branch to Launchpad, but something in your local config or some thing that you are doing is causing it to fail (I think)
[12:43] <jml> robin_, but I don't know what that is.
[12:43] <robin_> jml: May be I should upgrade bzr to 1.17-dev?
[12:43] <jml> robin_, that's certainly one thing to do.
[12:44] <robin_> jml: ok, I try it.
[12:44] <jml> robin_, but even more important than that is to go here -- https://answers.edge.launchpad.net/launchpad-code/+addquestion -- and describe exactly what you are doing, and what you see, and what you expect to see
[12:45] <robin_> jml: got it
[12:46] <jml> robin_, thanks.
[12:46]  * jml -> lunch
[12:57] <Saviq> danilos: while I have you around - I was asked about Austrian (de_AT) that isn't available in LP, is there a way to add additional languages? what would happen if we'd commit a de_AT.po file?
[12:59] <danilos> Saviq: if it's imported, it will show up; but in general, people should not have such translations (i.e. bigger projects such as GNOME disallow them)
[13:00] <danilos> Saviq: in the future, we might do more than just not show them before there's any translation, so I wouldn't count on any behaviour unless we are convinced it's the right thing to do
[13:00] <Saviq> ok, thanks
[13:02] <bullgard4> What is meant by "official tags" in https://bugs.launchpad.net/ubuntu/jaunty/+source/ekiga?
[13:08] <wgrant> bullgard4: Official tags are those that the project or distro's maintainers have declared as official. They are more prominent on bug pages and appear in the tag autocomplete list.
[13:10] <bullgard4> wgrant: Thank you.
[13:23] <resolve> hi folks. i have a couple of questions about the translations section
[13:23] <resolve> i see that launchpad can automatically import files from a bzr repo
[13:24] <resolve> as items are updated on launchpad, will launchpad automatically commit those changes to the repo? or does it require downloading the po files and applying them to the repo manually?
[13:28] <Saviq> danilos: one more thing, we have a file structure like so:
[13:28] <Saviq> i18n/<domain>.pot
[13:28] <Saviq> i18n/<locale>.po
[13:28] <Saviq> but downloaded files are
[13:28] <Saviq> i18n/<domain>.pot
[13:28] <Saviq> i18n/<domain>-<locale>.po
[13:29] <Saviq> will <locale>.po renamed to <domain>-<locale>.po be picked up automatically, too?
[13:32] <danilos> Saviq: it should, but in general, it's a bug in our export code (it should export paths just like you import them, which is a much better layout)
[13:33] <Saviq> ah ok we'll leave it as-is then
[13:36] <danilos> Saviq: it will currently require you to rename files when you export them from Launchpad, but we definitely want to fix this bug asap :)
[13:36] <Saviq> yup
[13:36] <Saviq> it's not a big issue
[13:37] <resolve> to answer my own question, it seems automatic export into branch is not implemented yet
[13:39] <resolve> my other question - i've been waiting a few days for the initial import to be improved. is there any way to clear the import queue so I can try again? the latest tarballs I uploaded a few days ago were in the launchpad-preferred dir/<locale>.po format, so they should have been automatically improved, but I suspect my previous attempts have stopped that from working
[13:39] <resolve> in the mean time one of my users uploaded an update to a single po file, and that went through quickly. do i have to resort to manually uploading each file in turn to expediate the process?
[13:51] <resolve> if there's a more appropriate place for these questions, please let me know. :-)
[13:52] <wgrant> resolve: This is the right place.
[13:52] <wgrant> Maybe danilos can help you.
[13:52] <danilos> resolve: approvals happen automatically only if you use bzr imports, or if we have already approved your previous templates manually (using same paths in tarballs)
[13:53] <danilos> resolve: in general, you should be using the same set-up as initially for it all to work correctly
[13:53] <resolve> danilos: i started with a bzr import but the directory structure was not the launchpad-preferred way, so it blocked awaiting approval
[13:54] <resolve> i marked all those files as deleted, changed the directory structure in bzr, and then clicked 'request one time import' again
[13:54] <danilos> resolve: and, no, automatic export to branches is not ready yet (we are in the process of QAing it, so it should be ready next month)
[13:54] <resolve> (actually i went through this process 2-3x before getting it just right)
[13:54] <danilos> resolve: and they are still not imported? what's the project you are trying to import?
[13:54] <resolve> anki
[13:55] <danilos> resolve: this can happen if you've got a number of different templates where it's hard for system to pick up which is which; I'll look at your project now
[13:55] <resolve> thanks - appreciated
[13:57] <danilos> resolve: are you talking about translation files?
[13:57] <danilos> resolve: I can see your POT file as being imported, but for around 24 languages you are using what is not well coped with in Launchpad
[13:57] <resolve> the templates appear to have been approved, but the translation files are blocked
[13:58] <resolve> hmm, it should be about 12 languages - there are two domains
[13:58] <danilos> resolve: i.e. instead of using "de_DE.po" you should use "de.po", and only add country code where it's actually relevant (i.e. "pt_BR.po")
[13:58] <danilos> resolve: right, 24 files
[13:59] <danilos> resolve: if you just rename them to "de.po", "es.po", "fi.po", "fr.po"... it will all be fine and  they'll be auto-approved as well
[13:59] <resolve> okay, i'll give that a go, thanks
[13:59] <danilos> resolve: np, sorry it's so confusing
[14:00] <resolve> i realise it's still in an active state of development :-)
[14:01] <danilos> resolve: software is always in active state of development or dead, but hey :)
[14:01] <danilos> resolve: everything can always be improved :)
[14:02] <resolve> i don't suppose you know off the top of your head where I can find out which codes require the country qualifier?
[14:02] <resolve> i guess I could just change all the ones that blocked in launchpad.. :-)
[14:04] <danilos> resolve: there are only a few, where languages/scripts actually differ; out of your list, none do
[14:04] <danilos> resolve: i.e. pt_BR does, zh_CN, zh_TW, zh_HK as well, can't think of any other ones myself
=== mrevell is now known as mrevell-lunch
=== mrevell-lunch is now known as mrevell
=== abentley1 is now known as abentley
=== bac` is now known as bac
[15:25] <resolve> danilos: okay, i've got the new files in the import queue, and i'm just waiting for the automatic approval script to reach them. i'll have a check in the morning. thanks a lot for the help!
[15:35] <danilos> resolve: it should all be fine by the looks of it (they should be auto-approved in the next few hours and then imported shortly afterwards)
[15:37] <resolve> i'm just trying to figure out the best workflow for future updates. my app is actually in a git repo, so i split the po and pot files out from that and put them in a separate bzr repo, simply for the sake of syncing with launchpad
[15:38] <resolve> i guess i'll need to write a script to pull the latest translations from launchpad periodically and reapply them to the bzr branch
[15:38] <resolve> and a script to update the template from the source and update bzr
[15:39] <resolve> one question: do I need to msgmerge each of the individual translations when I update the template? or can I rely on launchpad doing that after a new translation is uploaded?
[15:46] <radix> did bug-branch link whiteboards disappear, or am I confused?
[15:48] <jml> yes, they did.
[15:49] <jml> but ought they be regarded as mutually exclusive options?
[15:50] <SamB> jml: I think he was hoping he was just confused
[15:50] <SamB> and that they were really still somehow there, right under his nose
[15:51] <jml> SamB, yes, I detected that nuance.
[15:52] <oubiwann> hey guys, radix and I noticed that launchpad (edge) no longer seems to have the whiteboard for branches
[15:52] <radix> oubiwann: I already mentioned that :)
[15:52]  * oubiwann scrolls up...
[15:52] <radix> like, 6 lines ago :)
[15:53] <oubiwann> heh
[15:53] <radix> jml: ok. that's too bad. we used those.
[15:53] <oubiwann> yeah, like a *lot*
[15:53] <oubiwann> for annotating multiple parent branches
[15:53]  * SamB stocks up on sharpies so he can write on the branches anyway
[15:54]  * oubiwann cries
[15:56] <zirpu> maybe it was getting spammed.  i'd email the ubuntu lp ops/support and ask them directly.
[15:56] <jml> radix, what for?
[15:56] <oubiwann> jml: where do we sign the petition to bring back "Classic Whiteboard"
[15:56] <jml> oubiwann, beuno's face.
[15:56] <oubiwann> hehe
[15:56] <radix> jml: mostly what oubiwann just said. we would specify which parent branch a branch is based on.
[15:56] <radix> or to indicate other things that should be known to a reviewer or whatever.
[15:56]  * beuno goes find a mask
[15:57] <zirpu> isn't that in the meta data w/ the working copy?
[15:57] <radix> like, "you'll need to install the genchi package to review this"
[15:57] <oubiwann> jml: what was the reason for removing the whiteboard?
[15:57] <beuno> radix, we have branch descriptions, no?
[15:57] <jml> radix, to me, those seem to be properties of the branch or of the merge proposal
[15:57] <jml> not information about the link between the branch and the bug.
[15:57] <radix> beuno: I think those are gone, too? but even so, the bug-branch link was very convenient to edit and view, since it was right on the bug page.
[15:58] <radix> and we do everything with bugs.
[15:58] <jml> branch descriptions aren't gone.
[15:58] <radix> ok
[15:59] <radix> jml: anyway, that may be true, but the merge proposal system is still basically not as good as using bugs for us.
[15:59] <jml> wow.
[15:59] <radix> jml: it's getting really close, but I think one of the biggest blockers is that thing that came up on launchpad-users recently (IIRC), about tracking review-responses
[16:00] <radix> that is, knowing when someone has fixed all the issues in our last review.
[16:00] <radix> so that we can re-review
[16:00] <jml> how is bugs any better for that?
[16:00] <radix> jml: well, the author puts the review tag back on the bug.
[16:00] <jml> I see.
[16:00] <oubiwann> jml: and that was something else we used the whiteboard for ;-)
[16:01] <oubiwann> jml: e.g., "+1 count: 2"
[16:02]  * jml feels slightly demoralized
[16:04] <radix> развитие!
[16:04] <jml> I feel that using the bug/branch whiteboard in this way is something of a happy abuse
[16:05] <jml> rather than a feature.
[16:05] <radix> well, I'm not sure what that whiteboard was originally for.
[16:05] <radix> it was pretty useful as a stopgap for other unimplemented features.
[16:05] <jml> yeah...
[16:06] <jml> who was it that said most wiki pages are prototype web applications?
[16:06] <jml> I don't know what the whiteboard was originally for either.
=== oojah_ is now known as oojah
=== yofel_ is now known as yofel
[16:12] <jml> radix, I don't know what else to say.
[16:15] <radix> that's okay. I think we can deal with it by using bug comments, which is what we used to do.
[16:16] <jml> radix, do you feel that these are things that the code review system should do?
[16:17] <radix> jml: I'm not sure if it's possible for the code review system to automatically figure out what the parent of a branch is.
[16:17] <radix> although, hm, I guess that's what "target branch" is.
[16:17] <jml> radix, what precisely do you mean by 'parent'?
[16:18] <radix> probably the wrong word for it. I mean the branch that you should review the branch-for-review against.
[16:18] <radix> we often have a branch A, which isn't yet merged, and which the same or another developer will create a branch from to continue some work that depends on it.
[16:18] <jml> radix, because the code review system _is_ intended to handle the case of 'branch A will land on branch B but it was branched from branch C'
[16:19] <radix> oh, nice.
[16:19] <radix> does it already handle that?
[16:19] <jml> radix, it just fails to match that intent with execution.
[16:19] <radix> ok. :)
=== deryck is now known as deryck[lunch]
[16:19] <jml> radix, due also to UI simplification. :)
[16:19] <radix> jml: code review requests have a description, though, right? so we could use that barring any other feature.
[16:19] <jml> radix, yes, they do.
[16:20] <jml> radix, that's what we do (although it makes the generated diff suck)
[16:21] <radix> ah. right.
[16:21] <radix> jml: although I guess we can also just set the target of B to A.
[16:22] <jml> radix, I tried that once. it has one or two minor negative consequences.
[16:23] <jml> radix, branch B won't be marked as merged automatically until it is merged into A (which might never actually happen), and branch A will always appear as a suggested target branch on the web ui for whoever proposes that merge.
[16:23] <radix> ah, yeah.
[16:36] <resolve> danilos: i had a ee_EE file which was an estonian translation, but ee.po came up as 'ewe' rather than estonian. i've renamed the file in bzr (and I assume it will be automatically picked up in the next few hours). is there any way to delete the ewe translation?
[16:37] <danilos> resolve: we'll have to remove it manually, please file a request in answers.launchpad.net/rosetta and we'll get to it one of these days
[16:37] <resolve> thanks
[16:37] <danilos> resolve: please give a direct link to a translation so it's easier for us to do it
[16:37] <resolve> will do
[16:37] <danilos> resolve: thanks :)
[16:44] <resolve> danilos: and sorry, just to confirm - if I update the template then export the .po files, they will have been message merged to the latest template, right?
[16:45] <danilos> resolve: that's right, as soon as updated template has been imported
[16:45] <resolve> so when I get the email from launchpad, i know it's safe?
[16:48] <resolve> apologies for all the questions - I did read the docs first :-)
[16:50] <resolve> i'll create another question on launchpad so that others can see the answer too
[17:01] <resolve> ah, exporting sends an email with the location to download. that makes scripting an export a bit hard
=== deryck[lunch] is now known as deryck
[17:58] <kb9vqf_> Anyone here willing to rescore a PPA build?  This one https://launchpad.net/~ubuntu-389-directory-server/+archive/ppa/+build/1097734 and related were affected by bug 392104 , but it will be many hours before the build is retried with a score of 0!
[17:58] <ubottu> Launchpad bug 392104 in ca-certificates-java "[Karmic] Update to ca-certificates 20090624 prevents ca-certificates-java from installing" [High,Fix released] https://launchpad.net/bugs/392104
[18:31] <kb9vqf_> Anyone here willing to rescore a PPA build?  This one https://launchpad.net/~ubuntu-389-directory-server/+archive/ppa/+build/1097734 and related were affected by bug 392104 , but it will be many hours before the build is retried with a score of 0!
[18:31] <ubottu> Launchpad bug 392104 in ca-certificates-java "[Karmic] Update to ca-certificates 20090624 prevents ca-certificates-java from installing" [High,Fix released] https://launchpad.net/bugs/392104
=== Hellow_ is now known as Hellow
[18:54] <bigjools> kb9vqf_: done
[18:54] <kb9vqf_> Thanks! :-)
[18:55]  * bigjools is glad of tab completion on nicks
[18:56]  * kb9vqf_ wonders if the build farm is completely overloaded today
[18:56] <resolve> danilos: thanks for the reply on answers
[18:57] <danilos> resolve: np :)
[18:57] <danilos> anyway, I am out, see you all
=== hsitter is now known as apachelogger
[19:58] <shaw> hi! cody-somerville sent me over here to ask about PPA trouble.
[19:59] <shaw> I'm trying to build ARM, and I see some PPAs can do it and some can't.
[19:59] <nhandler> shaw: Unless you have a "special" PPA (which only a handful of people have), you can't build for ARM in your PPA
[20:00] <shaw> nhandler: ah. so mcasadevall/ppa and doko/toolchain (from https://launchpad.net/builders) are special?
[20:00] <nhandler> shaw: Yes
=== BjornT changed the topic of #launchpad to: https://launchpad.net/ | Help contact: - | Join https://launchpad.net/~launchpad-users | Channel logs: http://irclogs.ubuntu.com | Open Sourcing: https://dev.launchpad.net/OpenSourcing
[20:01] <shaw> nhandler: any idea who I can beg to be special too?  :P
[20:02] <nhandler> shaw: Michael was doing a lot of work on porting packages to ARM. Doko also has done some porting work (and some other stuff). Unless you are involved with porting to ARM, you are probably out of luck
[20:02] <shaw> nhandler: well, that's actually what I was trying to do (port a specific tool to ARM).  is there some place to find the ARM porters and talk with them?
[20:08] <shaw> nhandler: ah, found #ubuntu-arm, I'll go bug people there.  thanks!
[22:46] <waldo323>  is there a way to transfer a team membership from one launchpad account to another? (realized I have 2 launchpad accounts)
[22:51] <waldo323> nm, I found you can merge accounts