. [10:20] that's useful :) [10:21] aquarius: right. If you are confused by the API doc, it often helps to take a look at the webservice tests. In this case, I looked in lib/lp/registry/stories/webservice/xx-project-registry.txt of the LP source code. [10:21] adeuring, can't imagine why I didn't think to look there ;-) [10:21] (line 658) [10:21] that's handy, though; now I'll know where to look next time :) [10:22] aquarius: well, for perfcet documentation, that shouldn't be necessary ;) But we are humans and haven't yet figured out how to write perfect dics ;) [10:22] ...perfect docs... [10:27] * aquarius creates a project on staging from launchpadlib. Nice. [10:28] aquarius: Was that standalone, or with bzr lp new-project? [10:28] persia, lp new-project already exists?? [10:28] Not to my knowledge. I thought you were adding it. [10:29] oh right, OK, I see what you mean. No, not from a bzr plugin yet; direct with launchpadlib. I'm experimenting to see how to do it before I start writing code [10:42] Is there a page on Launchpad that shows, overall, what bugs affect the most users. (A tally sheet of 'affectsmetoo'). [10:56] Also is there a way to list the user a bug affects? [10:58] komputes: there is an API method bug.users_affected_collection_link [10:58] (for you latter question) [10:58] komputes: regarding your first question: I don't hink that we have such a page [10:58] adeuring: not sure how I can use that> in combinating with launchpad scripts (like what bdmurray does?) [10:59] Could one use the collection_link to get a countable list of users to get the affected count? [10:59] adeuring: how hard would it be to hack one together quickly (or would it kill the db)? [11:00] komputes: Note that making staging thrash would probably have less effect on most users. The data is a bit outdated, but it would be close to what you seek. [11:00] komputes: (1) load an launchpadlib bug object; (2) iterate over bug.users_affected [11:01] persia: tehre is also the API property bug.users_affected_count [11:01] nifty :) [11:01] SO it's just query all open bugs, and then sort by that property. Handy nice list. [11:01] adeuring: need some help with 1 & 2, sorry, I use launchpad a lot, but think is a little outside my comfort zone. Can any user do this or special permissions are needed? [11:02] persia: yes [11:02] komputes: Try installing launchpadlib and reading the docs. It mostly needs a bit of python. [11:02] persia: okidok [11:03] python-launchpadlib [11:03] komputes: Also https://help.launchpad.net/API/launchpadlib [11:03] * komputes is checking it out [11:03] komputes: as persia says: should be easy to do. See https://help.launchpad.net/API/ and https://help.launchpad.net/API/Uses to find examples. [11:04] iterating over all open bugs doesn't sound like a small amount of data [11:04] * komputes grrrs to himself, no man page ;) [11:05] komputes: There are lots of methods to find bugs; if you already know which bug or bugs you are interested in, simply call lp.load(https://api.edge.launchpad.net/beta/bugs/) to get the bug object. [11:07] And you can get the string "https://api.edge.launchpad.net/beta" as launchpadlib.launchpad.EGDE_SERVICE_ROOT (similar for staging) [11:13] can i download a tar package of a project which does not provide any download files? [11:14] (...from lauchpad, it was implicit) [11:14] launchpad* [11:16] marchino: you mean, can you download the current branch tip as a tarball? [11:17] mwhudson: yep [11:17] then no, that's not implemented yet [11:17] There's always "bzr export project.tar.gz lp:project" [11:18] you can do bzr export lp:foo foo.tar.gz, but most of the work is on your side in that case [11:18] Probably not amazingly efficient. [11:18] (But shouldn't be completely terrible either) [11:19] i haven't clone the project [11:19] i think i must do it === matsubara-afk is now known as matsubara [13:38] g.m. === mrevell is now known as mrevell-lunch === sale_ is now known as sale [14:48] Why does Launchpad like to change a couple of my Experimental branches to Development? === matsubara is now known as matsubara-lunch [14:54] Does anybody have any idea when launchpad ppa download counters are going to show up? [15:03] komputes: disregarding the formatting of the page - http://qa.ubuntu.com/reports/launchpad-database/bugs-with-most-users-affected.html [15:05] bdmurray: exactly what I was looking for, thanks [15:06] bdmurray: by the way I wanted to chat with you about a few things (private?) [15:10] bdmurray: that is, ping me when you have some free time === salgado is now known as salgado-lunch === mrevell-lunch is now known as mrevell === yofel_ is now known as yofel [16:12] anyone here that can remove/suspend a users LP account. Please see bug 505092 [16:12] Launchpad bug 505092 in firefox-3.0 "no visuals" [Undecided,Incomplete] https://launchpad.net/bugs/505092 === salgado-lunch is now known as salgado [16:19] gnomefreak: thanks for the notice! [16:19] adeuring: np [16:19] anyone from translation/licenses here? [16:22] RenatoSilva: for license question, ping bac; for trnaslations, henninge or danilos [16:23] hi RenatoSilva -- what sort of licensing issues are you referring to? [16:24] bac: imagine a project like MoinMoin which has its own system of translation, but wants to use LP now [16:25] bac: so they have to import current translations into LP, and the start new translations at Launchpad [16:25] RenatoSilva: if you are asking specifically about licensing of translations then you need to talk to henninge or danilos. [16:25] henninge: ^ [16:25] danilos: ^ [16:26] but afaik when you import translations in LP, they become available for all LP users under BSD license... [16:26] RenatoSilva: AFAIUI, All new translations done in LP will be BSD-licensed, the imported strings will remain whatever they are. [16:27] RenatoSilva: no, imported strings keep their license. [16:27] henninge: that's unclear in the wiki docs anyway, but how LP manages that, it has a flag for each msgstr standing whether it's from LP or external? [16:28] RenatoSilva: yes. [16:28] is it recent? because it seems the docs weren't clarified about that [16:29] henninge: you know MoinMoin right? So this all means that Thomas can start using LP for translations without worrying about copyright violation? [16:31] henninge: I have presented LP to Thomas and sugegsted him to use LP at least for translations, but he didn't because of license, he would have to ask each contributor to convert the msgstrs to BSD, now this is not needed, great [16:33] RenatoSilva: Yes, of course ... ;-) [16:33] henninge: btw, if you could look into this issue, I'd thank you: https://bugs.launchpad.net/rosetta/+bug/478902 [16:33] Launchpad bug 478902 in rosetta "Improve or clarify translation licensing procedure" [Undecided,New] [16:33] RenatoSilva: But what kind of violations are you expecting? === jon is now known as Guest28378 [16:34] henninge_: you mean what Thomas was afraid of? [16:34] RenatoSilva: Simple strings like "File", "Submit", etc. are too common to be protected. [16:34] RenatoSilva: yes [16:35] RenatoSilva: More complex strings are usually too specific to the project that their translations could not be used elswhere unless used with a fork of the software. [16:35] and that fork would be under the license of the software anyway. [16:35] GPL, I assume. [16:36] henninge_: at that moment a few months ago, we understood that all imported stuff wo9uld be available to LP users under BSD, which means a license change because Moin translations are GPL. And license change can be done only by copyright owners which are a LOT of people, and even unknown === beuno is now known as beuno-lunch [16:37] RenatoSilva: exactly, that is why we didn't even start on that for LP translations ... ;-) [16:37] RenatoSilva: BSD is most permissive. [16:37] public domain...:P [16:37] RenatoSilva: Basically, the feat would be that GPL'ed translations end up in non-free software. [16:38] s/feat/fear/ [16:38] henninge_: the problem was not use BSD, it was change the license with permission of ALL authors [16:38] Yes, bug a change from BSD to GPL for example is possible without any permission from any author, that's why it is the easier base. [16:38] s/bug/but/ [16:38] pardon my typing. [16:39] henninge_: this is the current fear, for NEW translations done in LP, but for the imported, we thought in the past that we needed to contact every translation contributor to ask "may we import all current stuff into LP and change the license to BSD?" [16:39] RenatoSilva: no need to do that, no. [16:39] henninge_: we misunderstood it in the past, or was it really that way some time ago? [16:40] RenatoSilva: not really [16:40] so we misunderstood, ok [16:40] RenatoSilva: We used to have two contradicting statements, one in the wiki, one in LP, I think. [16:41] RenatoSilva: Then at one point we clarified that to be BSD and had every LP translator agree with that or remove his/her translations. [16:41] I think the wiki is at least unclear, *still* [16:41] about a year ago [16:41] possibly ... ;) [16:41] * henninge_ looks at bog [16:41] bug [16:42] bug 478902 summarizes one thing I think is unclear [16:42] Launchpad bug 478902 in rosetta "Improve or clarify translation licensing procedure" [Undecided,New] https://launchpad.net/bugs/478902 [16:43] in a nutshell, making translations BSD require to add the BSD text in original and derived works === matsubara-lunch is now known as matsubara [16:44] but when you download a po, you don't get the BSD notice with the list of copyright owners, and I don't think developers pay attention on this and add mannually the BSD text in their softwares [16:45] I think a possible solution is to change the licensing from "I give this to you as BSD" to "I give this to you as any BSD-compatible license you wish" [16:46] this would eliminate the need of adding the BSD text in projects using these translations [16:47] is the gpl compatible with the bsd... [16:55] bsd -> gpl yes, gpl -> bsd no === henninge_ is now known as henninge [17:14] henninge: http://pastie.org/775085 [17:17] [15:17] ThomasWaldmann: sorry, it does NOT need to be rather "this po file is BSD", it MAY be "the same as project", however I think the BSD *text* should be exported together, either attached or inside the po body [17:20] RenatoSilva: thanks for the suggestions. [17:20] RenatoSilva: I will have to discuss this with the other's on the team to see what we can do here. === thunderstruck is now known as gnomefreak [17:24] RenatoSilva, fwiw, exported PO file is not BSD licensed, and it can't be, because it's a derivative work [17:24] henninge: ok thanks. Improvements in the docs and procedures are welcome, as Thomas is still a bit worried [17:25] RenatoSilva, what is BSD licensed are translations provided through LP; in general, current copyright law doesn't really cope with the way translations of free software happen, and that's the biggest problem [17:26] RenatoSilva, when these BSD-licensed individual translations end up in a PO file, copyright law would usually make them whatever-parent-project-is-licensed-under since almost all licenses are "stricter" than BSD [17:28] RenatoSilva, the point we should probably try to clarify is that licensing applies strictly to the translation texts when they are used (i.e. integrated elsewhere) [17:29] RenatoSilva, like being integrated into certain project PO files, when the entire "collection of works" is distributed under the strictest license of all the works [17:30] exported PO file is not BSD licensed, and it can't be, because it's a derivative work??? [17:31] works derived from BSD works canNOT be BSD still? [17:31] RenatoSilva, so, if you need to add BSD licensing information that would be completely correct, you could say something like: "for translations of messages 'blah', 'foo' and 'bar', you can also use those translations under BSD license" [17:31] RenatoSilva, PO file is not licensed under BSD because it's a derivative work of a POT file coming from a project (GPL in your case, I guess), some GPL translations (that you imported into Launchpad) and some BSD translations [17:32] what is BSD licensed are translations provided through LP ---> but exported po files may be made of these translations, fully or partially [17:32] RenatoSilva, such derivative work as a whole is basically GPL licensed; if you really want to be completely specific, you would have to say that some of the translations are available under looser terms of BSD, and you could list them [17:33] * RenatoSilva reading above, sorry... [17:34] RenatoSilva, basically, your full PO file can't be under BSD because it's a combination of works under GPL and BSD; for some parts of it, you can apply BSD to them; but for the whole file, you can only distribute it under GPL [17:34] that's why we chose BSD in the first place, because it can be embedded in any combined work (i.e. BSD is compatible with all free software licenses) [17:35] alternative is to do as TranslationProject did and ask for public domain translations, but we'd rather if people keep their copyright [17:37] danilos: I understand danilos [17:37] danilos: however the BSD text stands that it must be included in derived works, which doesn't happen when you get an exported .po file === adeuring changed the topic of #launchpad to: http://launchpad.net | Read https://help.launchpad.net for help | Help contact: - | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: see channel #launchpad-dev [17:38] danilos: the BSD text should go along with the .po when exporting from LP, and/or developers should be warned about the need of including the BSD text with copyright owners in their software [17:39] RenatoSilva, right, it's a tricky issue, since with GPL, you're probably fulfilling all the conditions anyway [17:40] danilos: I'm not sure, but don't we need the *exact* BSD text? [17:40] let me read it again [17:40] RenatoSilva, well, the thing is that Launchpad is a development tool; insisting on BSD license being included is like insisting that a source code browser which displays a single source file must also display the license on the same web page [17:41] RenatoSilva, you can eg. use bzr or svn or cvs (I know you can use cvs like this, don't think others can) to check-out a single file from the repository without getting the license file; and getting a single PO file is like this [17:41] RenatoSilva: btw, does any of the moinmoin guys actually agree on pushing the translations to lp? [17:44] I'm not sure if the GPL text itself (except for copyright list of course) is a "copy" or "implementation" of the BSD text, is it? [17:44] RenatoSilva, on reading it, it would still have to be included yes... so perhaps that was a bad choice on our part of the license [17:45] RenatoSilva, so, your source code distribution would probably have to include a copy of BSD if you want to be fully certain of being legal, but IANAL :) [17:46] ronny: please go to #moin if you can, but yes they seem friendly about using LP, jsut worried with licensing [17:47] IANAL? is there any irc dict command? :) [17:47] danilos: sorry but did you read that bug I pasted here? it's about this [17:48] danilos: my suggestion is: when some user translates something in LP, he's not giving his work to all the other LP users *under BSD*, but under *any BSD-compatible license* [17:49] danilos: it's like "changing the license early" (because developers using these translations will do that anyway) [17:49] danilos: the advantage is that there's no need to add the BSD text anymore [17:50] RenatoSilva, oh, haven't gotten to it yet, that sounds as a good idea, it's just a shame we haven't done it earlier because today... [17:50] RenatoSilva, today it would mean having everybody re-license their work *again* [17:51] RenatoSilva, also, I think nobody feels comfortable in lawyer offices with such blank statements (i.e. if we don't list what those licenses are, they're probably going to say that it's not legally binding) [17:52] how about each user having in its preferences what licenses he gives his translations under? [17:52] RenatoSilva, that would be impossible to track, and we'd have to implement per-message license checking which is exactly what we wanted to avoid [17:52] ok [17:54] RenatoSilva, i.e. we show translations from different projects as suggestions for identical strings, and if we introduce different licenses, we'd have to do license checks for each of the messages which would make code unreasonably complex [17:54] there isn't any legal meaning for "BSD-compatible"? For example, a legally acceptable list of compatible licenses, or even a clear way to determine in court whether a license X is compatible or not? [17:55] RenatoSilva, I don't think there is, "GPL-compatible" is a term defined by FSF and which talks only about licenses they wouldn't sue people over if they combined it with GPL work; others might still sue people if they have different interpretations of license compatibility [17:57] about everybody re-license their work, I can't get it. If you can change the license of current translations done in LP (can you?), then why users would need any re-licensed? [17:57] RenatoSilva, we can't change license of anything in LP, that's the whole thing [17:57] *re-licensing [17:57] danilos: so how you did in the past to change to BSD? [17:58] RenatoSilva, I've joined #moin, let's discuss it there [17:58] danilos: or are translations done in LP BSD since beginning?? [17:58] RenatoSilva, we've asked people to consent to the change with a form which stopped them from doing any work before they either agreed or disagreed with it [17:58] danilos: ok [17:58] RenatoSilva, later we removed all translations for those who disagreed === beuno-lunch is now known as beuno === mrevell is now known as mrevell-dinner [19:30] Is there a way to trigger a 500 on launchpad so I can see the oops page? [19:31] Alternatively what is the template that has the oops page? [19:33] jblount, append ++oops++ to the url (see https://dev.launchpad.net/Debugging) [19:33] * jblount high-fives mars [19:34] np [19:34] jblount, that won't give you the oops template page though [19:35] mars: Actually, I'm looking for the template, so I can look at the phrasing for inspiration for Ubuntu One [19:35] ah [19:35] jblount, the template for the oops page is oops.pt (lib/canonical/launchpad/templates/oops.pt) [19:36] well, a round-about way to do it is to view an OOPs, pick a unique string, grep-find :) [19:36] jblount, our oops template is pretty broken atm [19:37] matsubara: Thanks (also mars & beuno) [19:37] beuno, jblount: i just filed https://bugs.edge.launchpad.net/launchpad-foundations/+bug/506581 for the brokeness while QA'ing one of salgado's changes [19:37] Launchpad bug 506581 in launchpad-foundations "oops template page is out of center" [Undecided,New] [19:37] mars, great, thanks [19:38] matsubara, ^ [19:40] you're welcome :-) === salgado is now known as salgado-afk === matsubara is now known as matsubara-afk [20:48] hi, I have a Launchpad/Bzr branching question. [20:49] One of my friends published a branch with code, that is intended to be a part of a bigger project. [20:49] Now when I've written the bigger project and I'd like to include my friends code into it, what is the best way to do it? [20:50] Simply copying my friends code in a folder and then committing it does not sound good. [20:51] Should I do some kind of merger with two Bazaar branches, even though their content is completely different? [20:52] otto_sange, this ir more of a question for #bzr [20:52] (not an easy one) [20:53] Would the correct way be to first branch my friends code so that I have a local copy, then with bzr mv move all files into one folder caller "plugin", push it back into Launchpad as a new branch and finally merge my two own branches? [20:53] And what about access rights? How can my friend continue to commit to his code inside my bigger project? [20:58] your friend will maintain a plugin for your project? [20:59] RenatoSilva: yes, although it is not a plugin, rather a sub part [21:00] afaik at least LP has no support for commit permissions in parts of a branch [21:01] otto_sange: it seems you may want a build process [21:01] otto_sange: that process would bzr branch all required branches to set up a ready-to-use instance of your application [21:02] otto_sange: you could write a build.sh or so, and include that file itself in version control :) [21:03] RenatoSilva: ok, then the process to install the app is 1. branch my project 2. run build.sh which branches more projects as sub folders ..? [21:04] your friend could also branch the whole project, and work only in his subsystem, and *you* merge that work once in a while [21:04] RenatoSilva: ok [21:05] and he merges your changes which would not give any conflict as long as *you* don't touch *his* subsystem in the *main* branch [21:06] RenatoSilva: what about the series and milestones things in Launchpad. Are they of any use in this case? [21:07] for build.sh, maybe I would separate the result in another dir, targeted only for using, while current dir is targeted only for code commits. So I would not branch to a subdir. [21:08] RenatoSilva: apparently I could just register my friends branch as an independent series, so that it is visible in the code overview of my project, but that's it? [21:08] I would do somehting like zip required files to a /dist subdir, where that zip is already a download package ready for distribution, not just for testing while developing [21:09] that zip would be created with the files in the current main branch, plus the ones from you friend's branch, which would be bzr branched at the time of build to a /tmp or so [21:10] ok [21:10] otto_sange: I don't think series is suitable in your case [21:11] otto_sange: series is when you want to keep more than one big version [21:12] otto_sange: for example, bzr2 is an update of bzr1 with new features, but people still can use bzr1, which still receives security fixes etc [21:13] otto_sange: I have a project which is single-seried, that is, even when I add new features or change behavior of the software widely, that new version is pushed to end-users [21:14] they don't have the choice of using the old version, because I stop maintaing it immediatelly [21:15] if the users want important fixes, they need to move to the new version even if they don't like [21:17] ok, I was thinking about that too, but now when you confirmed it I feel much more confident in using bzr/Launchpad. Thanks for your help! [21:35] is there launchpad support personnel? [21:36] amondo: Not at the moment, see /topic. [21:36] okay thanks [21:39] amondo: But if you have a problem we can try and help you. [21:40] jpds: thanks... i am getting ubuntu bug reports to my launchpad project. my project has nothing to do with ubuntu. so i am trying to edit these user's bug reports and change the project that it affects to ubuntu or something. but searching for ubuntu in project list gives "too many projects" and then "undefined". no wonder the users are too pissed off to report the bugs to the right package. and its frustrating for me too because i h [21:40] ave to deal with all these bugs. [21:41] how do i put these bugs in the ubuntu bug queue? [21:42] amondo: Your project is packaged in Ubuntu, and you're getting bugs which should be going to the Ubuntu package against your project? [21:42] no, there is no connection to ubuntu at all. started project called lucid back in 2007 or so and now i am getting ubuntu lucid bug reports [21:43] i even named my project "Lucid Editor NOT UBUNTU" [21:43] Oh, whoops! [21:44] yeah, but you know, when users search for "ubuntu" in the package to report. they got nothing. [21:44] when they search for lucid, they at least get a hit. [21:48] amondo: Searching for "ubuntu" on bugs.launchpad.net brings up the Ubuntu project, but I can see your problem with lucid... [21:49] amondo: On bug #506445 - if you click "Also affects distro", you can mark it as an Ubuntu bug. [21:49] jpds: yes, it does.. i mean in a particular bug report, when you choose the "package name". it won't let you leave it blank. [21:49] Launchpad bug 506445 in lucid "Lenovo Thinkpad T61, x61: FN + F5 does not enable or disable the internal wwan" [Undecided,New] https://launchpad.net/bugs/506445 [21:49] oh i see... let me try [21:49] amondo: No, you can leave it blank, I just did that... [21:50] amondo: Then you'll have to mark your projects task as invalid, I'm afraid... [21:50] okay, so it still shows up in my bug list [21:51] jpds: marked it invalid now [21:51] Once Invalid, it shouldn't. [21:51] jpds: so that's all? should i repeat for other similar bugs? [21:51] Hmm, yeah... [21:51] jpds: thanks, will get on that shortly [21:52] amondo: And maybe have a template comment you can copy and paste into a comment explaining why you've done that. === micahg1 is now known as micahg === MTecknology is now known as MTeck-ricer === Ursinha is now known as Ursinha-afk [22:59] hi, I need some LP support [22:59] how do I change the list of packages that's listed on https://bugs.edge.launchpad.net/~edubuntu-bugs/+packagebugs ? [23:03] is the list derived from the actual bugs? [23:06] highvoltage: no support person here atm, see topic [23:08] amondo: I'm not sure how it's derived [23:08] amondo: I guess I'll have to hang around for a while then :) [23:10] highvoltage: yeah, hang around... but i suspect the page lists aggregated data based on individual bugs. so if you ubsubscribe from individual bugs, you won't have an entry in the projects page. for example, if you unsubscribe from Bug #177287, then you won't have an entry for "tuxpaint-stamps in ubuntu" [23:11] it won't be zero, it just will not appear on the page at all [23:11] you can always test it out in staging.launchpad.net [23:12] highvoltage: you need to subscribe the team to the packages in question [23:12] highvoltage: that should probably be discussed with your team [23:12] micahg: i think he's trying to unsubscribe them, to remove entries from the package list [23:13] amondo: same thing [23:13] yeah [23:13] amondo: it's packages that ~edubuntu-bugs are subscribed to. e.g. look at https://edge.launchpad.net/ubuntu/+source/denemo, under the "Bug subscriptions" heading in the sidebar. [23:15] spiv: yeah i see now [23:16] spiv: maybe "ubuntu development team" control the subscriptions [23:16] amondo: the team itself can control whether or not they are subscribed [23:24] I'm members of those teams but I don't see anywhere where I can unsubscribe ~edubuntu-bugs from those packages/bugs [23:24] highvoltage: I believe only team admins can subscribe/unsubscribe the team [23:26] ah, yeah, that's correct...it even says it on the page! [23:27] highvoltage: so it would have to be someone on the edubuntu council to do it [23:29] micahg: which I am on as well :) [23:30] indeed [23:30] highvoltage: on this page you should see a checkbox for Edubuntu Bugsquad: https://bugs.edge.launchpad.net/ubuntu/+source/atomix/+subscribe [23:35] micahg: ah, d'oh, I see now. I have to click on the "Subscribe" link in order to unsubscribe, that wasn't too obvious to me, thanks for your patience [23:35] highvoltage: np [23:35] (especially since there's a plus sign next to 'subscribe') [23:35] * micahg thought there was a bug to change that... [23:37] bug 273192 [23:37] Launchpad bug 273192 in malone "unsubscribe link on package page" [Medium,Triaged] https://launchpad.net/bugs/273192 [23:37] highvoltage: ^^ [23:37] cool