=== ampelbein is now known as Ampelbein
=== abentley1 is now known as abentley
=== abentley1 is now known as abentley
=== abentley1 is now known as abentley
=== Ampelbein is now known as ampelbein
=== Andre_Gondim is now known as Andre_Gondim-afk
[08:45] <Brucevdk> Question, anonymous users cannot upload a .po file even if a project is set to Open?
[08:46] <Brucevdk> We have a translator that does not wish to use the LP service for translating, but wouldn't mind uploading the .po file (so others don't think a translation is unavailable)
[08:48] <wgrant> Brucevdk: Correct. An LP account is very easy to create, so what is the problem with that?
[08:49] <Brucevdk> wgrant: well actually I didn't mean completely anonymous (but not a member of the project), he is logged in with his LP account and getting "Permission denied"
[08:50] <Brucevdk> Oh wait a second, turns out you have to click a language first and then upload
[08:51] <Brucevdk> Nevermind, still "Permission denied"
[08:52] <Brucevdk> Sorry, not "Permission denied" it works fine. Forgive me, I just woke up :-)
[08:53] <wgrant> So it works?
[08:53] <Brucevdk> wgrant: correct
[08:53] <wgrant> I've little experience with that part of LP.
[08:53] <Brucevdk> so do I :-)
=== Ampelbein is now known as ampelbein
[11:25] <pro-rsoft> is there a way to mark all bugs that are marked "Committed" to "Released"?
[11:32] <LarstiQ> pro-rsoft: I don't know about the webinterface, but via the api, yeah
[11:33] <pro-rsoft> hmm, how
[11:33] <pro-rsoft> I dont want to manually flag tons of bugs
[11:35] <LarstiQ> pro-rsoft: something like tools/check-newsbugs.py from bzr
[11:36] <pro-rsoft> ok
[11:48] <pro-rsoft> hmm how do I iterate over the bugs in one project and not in all projects
[11:50] <LarstiQ> pro-rsoft: bugs/<project> ?
[11:51] <pro-rsoft> in the api, I mean
[11:51] <pro-rsoft> (im using python)
[11:55] <LarstiQ> pro-rsoft: I don't really know the api myself, and check-newsbugs.py works from the other direction
[11:55] <intellectronica> pro-rsoft: [bugtask.status for bugtask in project.searchTasks()]
[11:55] <pro-rsoft> intellectronica, thanks
[11:55] <pro-rsoft> LarstiQ, I cant access it
[11:55] <pro-rsoft> its giving me a "let us known in #launchpad"
[11:56] <intellectronica> [bugtask.status for bugtask in project.searchTasks(status='Fix Commited')] even :)
[11:56] <pro-rsoft> sweet
[11:56] <intellectronica> pro-rsoft: have you seen https://launchpad.net/+apidoc/ ?
[11:56] <pro-rsoft> intellectronica, I have.
[11:57] <pro-rsoft> but didnt find that one
[11:57] <intellectronica> cool
[11:59] <pro-rsoft> hmm
[11:59] <pro-rsoft> I did task.status = "Fix Released"
[12:00] <pro-rsoft> but it doesnt show up yet on the website
[12:01] <pro-rsoft> hmm when I check task.status again it didndt change
[12:02] <pro-rsoft> when I use transitionToStatus('Fix Released') I get TypeError: __call__() takes exactly 1 argument (2 given)
[12:04] <thekorn> it's either task.transitionToStatus(status="Fix Released")
[12:05] <pro-rsoft> yeah, just noticed that
[12:05] <pro-rsoft> but it doesnt change yet
[12:05] <pro-rsoft> on the website.
[12:05] <thekorn> or task.status = "Fix Released"; task.lp_save()
[12:05] <pro-rsoft> ah.
[12:05]  * pro-rsoft tries that
[12:06] <pro-rsoft> nope
[12:06] <pro-rsoft> no change
[12:06] <pro-rsoft> on the website they still show up as "Fix Committed"
[12:07] <LarstiQ> pro-rsoft: you're not sneakily changing some other projects bugs? ;)
[12:07] <pro-rsoft> uh
[12:08] <pro-rsoft> tasks=lp.projects["panda3d"].searchTasks(status='Fix Committed')
[12:08] <pro-rsoft> for task in tasks:
[12:08] <pro-rsoft>    if "1.6.0" in str(task.milestone):
[12:08] <pro-rsoft>      task.status="Fix Released"; task.lp_save()
[12:09] <pro-rsoft> when I call that again, I get no results (there are no tasks "Fix Committed") anymore
[12:09] <pro-rsoft> but look here https://bugs.launchpad.net/panda3d/+bugs?search=Search
[12:14] <maxb> pro-rsoft: Perhaps you inadvertently ran the API script against Launchpad staging?
[12:14] <pro-rsoft> hm?
[12:14] <pro-rsoft> lemme see
[12:15] <pro-rsoft> yes, I did. darn.
[12:15] <pro-rsoft> thanks
[12:25] <pro-rsoft> excellent, it works now. thanks alot
[12:30] <pro-rsoft> when trying to delete something, I get 500 Internal Server Error
[12:31] <pro-rsoft> I just use release.delete()
[12:33] <intellectronica> pro-rsoft: please report a bug so that someone can take a look at it tomorrow
[12:33] <pro-rsoft> hm
[12:33] <pro-rsoft> its not that important
[12:34] <pro-rsoft> wow, I *do* get a lot of emails when changing a lot of bug statuses
[12:34] <pro-rsoft> is there a way to do it without sending an email?
=== abentley1 is now known as abentley
=== pro-rsoft is now known as pro-rsoft|away
=== pro-rsoft|away is now known as pro-rsoft
=== _neversfelde is now known as neversfelde
=== abentley1 is now known as abentley
[14:40] <_MMA_> Why do I have these "lp:~vcs-imports" branches on a couple of projects of mine? Are they automated or what?
[14:41] <LarstiQ> _MMA_: they are auotmated
=== abentley1 is now known as abentley
[14:42] <_MMA_> LarstiQ: Do you know for what purpose?
[14:42] <LarstiQ> _MMA_: they are import into bzr from a foreign vcs when so requested in the project settings
[14:42] <LarstiQ> imported even
[14:43] <_MMA_> LarstiQ: And if there is no "foreign vcs" as the projects live entirely on LP/BZR?
[14:45] <LarstiQ> _MMA_: could you name one or more of these projects that's happening for?
[14:45] <_MMA_> LarstiQ: https://code.launchpad.net/breathe-icon-set
[14:46] <_MMA_> This project is managed entirely on LP/BZR. I just don't see the need for the import branches.
[14:47] <LarstiQ> _MMA_: has this always been the case?
[14:47] <_MMA_> That the project has always been on LP/BZR? Yes. From the start.
[14:49] <LarstiQ> _MMA_: right, it looks like a configuration error
[14:49] <LarstiQ> This branch is an import of the Subversion branch from https://code.launchpad.net/~breathe-dev/breathe-icon-set/debian-packaging.
[14:49] <LarstiQ> for example
[14:50]  * LarstiQ tries to find where the imports are configured
[14:51] <_MMA_> To me, that says at one time it used Subversion. Which is not the case. I'm just trying to see why there are here and if they are just gonna sit here, without use, how to get rid of them.
=== ursula is now known as Ursinha
[14:52] <LarstiQ> _MMA_: to me that says someone filled in the bzr location in a config section "where to import from" and chose svn as vcs type.
[14:52] <LarstiQ> unfortunately, I have no access to those settings on ~breathe-dev, and I'm not finding something like that on a project I do yet
[14:53]  * LarstiQ tries help.launchpad.net
[14:54]  * LarstiQ is looking at https://help.launchpad.net/Code/Imports
[14:54] <LarstiQ> aha, the process has changed since I last did anything with it
[14:55]  * _MMA_ doesn't remember filling anything in with Subversion.
[14:55] <_MMA_> (and I made no request)
[14:56] <LarstiQ> _MMA_: it needen't have been you
[14:56] <LarstiQ> _MMA_: does https://edge.launchpad.net/breathe-icon-set/trunk/+edit do anything for you? I have no access
[14:57] <_MMA_> Yes. Since it's my project. :)
[14:57] <LarstiQ> _MMA_: also, I see Ted Gould has done some things for breathe-dev?
[14:57] <LarstiQ> _MMA_: he is also listed in the bzr-svn credits fwiw
[14:57] <LarstiQ> _MMA_: so, maybe talk to him :)
[14:58] <_MMA_> Ted helped me with some scripting. But yeah. He would be a good source.
[14:59] <LarstiQ> _MMA_: anyway, those two vcs-imports branches are bogus, if you can delete them that's what I would do.
[14:59] <LarstiQ> _MMA_: if not, I think filing a question against the imports team to ask for removal.
[15:00] <_MMA_> Doesn't look like I can. Yeah. Ill poke some of those guys tomorrow. Thanx for your time.
[15:00] <LarstiQ> np, I needed a break from studying :)
[15:01] <_MMA_> ;)
[15:45] <BUGabundo> hay
[15:45] <BUGabundo> question: what's the easiest way (aka nongeek) to add PPA keys ?
[15:46] <kiko> BUGabundo, guess using the instructions on help.l.n
[15:46] <BUGabundo> sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com
[15:46] <BUGabundo> I use this
[15:47] <BUGabundo> but I can't keep telling new user on my class to do that
[15:47] <BUGabundo> don't want to get them scared with terminal
[15:48] <BUGabundo> should Software Sources have a field to enter key as well as PPA line?
[16:04] <BUGabundo> hey Dupes with AJAX! nice work
[16:38] <LarstiQ> BUGabundo: provide a script for them that does that?
[16:39] <BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/software-properties/+bug/38781
[16:39] <ubottu> Ubuntu bug 38781 in software-properties "software-properties should offer field to insert PPA signed key" [Wishlist,Triaged]
=== abentley1 is now known as abentley
[17:53] <gnomefreak> anyone give me an idea on what OOPS-1177EC92 is?
[17:54] <intellectronica> gnomefreak: how did you get this ... using the api?
[17:55] <intellectronica> oh no, it's the web ui
[17:55] <gnomefreak> yep
[17:55] <gnomefreak> its pissing me off badle too :(
[17:55] <intellectronica> basically, you were trying to edit a bug task that doesn't exist
[17:55] <intellectronica> what were you trying to do?
[17:55] <gnomefreak> change firefox to firefox-3.0 and comment
[17:56] <gnomefreak> and status to incomplete
[17:56] <intellectronica> you mean, change the package of an ubuntu task?
[17:57] <gnomefreak> change package from firefox to firefox-3.0 since firefox ==2.0 and is no longer supported. Without changing the package i still get the oops
[17:57] <intellectronica> so, you already changed the package, and after it changed, it redirected you to the wrong page?
[17:57] <gnomefreak> it never changed. when i hit change to apply it gives me the oops
[17:58] <gnomefreak> see bug 139829
[17:58] <ubottu> Launchpad bug 139829 in firefox-3.0 "maximize/minimize with titlebar" [Undecided,Incomplete] https://launchpad.net/bugs/139829
[17:58] <intellectronica> gnomefreak: it did change
[17:58] <gnomefreak> wth
[17:59] <gnomefreak> it never told me it did it just oopsed
[17:59] <gnomefreak> intellectronica: thanks
[18:00] <intellectronica> gnomefreak: i can reproduce this on staging. care to file a bug?
[18:01] <gnomefreak> ok against launchpad?
[18:01] <intellectronica> gnomefreak: against malone
[18:01] <intellectronica> thanks!
[18:07] <gnomefreak> intellectronica: its filed if more info is needed let me know
[18:09] <intellectronica> gnomefreak: thanks a lot. no, i know how to reproduce it so should be easy to tackle
[18:09] <gnomefreak> intellectronica: ok thanks
[19:14] <ia> hello. i have very strange issue with ppa. At my desktop machine package compiles and builds successfully, but on ppa i've got error on build - here related part of build log - http://paste.ubuntu.com/135550/ - and i guess, that problem in 167 line : configure: error: C compiler cannot create executables. however, i would be very appreciate for any clues about how to fix this.
=== ejat is now known as e-jat
[19:47] <maxb> ia: That is pretty strange.  Have you tried building the package in a clean minimal chroot (e.g. pbuilder / prevu / sbuild) ?
[19:49] <ia> maxb: of course. as have been said, package builds successfully at my desktop - i builds via debuild/pbuilder
[19:50] <geser> ia: add " || cat config.log" after your configure call in debian/rules so you get more info why it fails
[19:55] <maxb> geser: there'll need to be an && exit 1 after that, no? (Or the build will continue despite the error, potentially building broken packages?)
[19:55] <maxb> Well, I guess make is going to get upset, usually
[19:55] <geser> if configure fails, there won't be a Makefile so it will fail soon anyways
[19:56] <ia> geser: em, maybe i'm not understand something - in that case log file will be created at ppa server (where i can't direct access) and will be deleted after building (will not?), so what's the point? and how can i get access to this log file at server?
[19:57] <geser> ia: the idea is to get the content of config.log into the build log so you can actually see what's the problem is
[20:02] <ia> geser: oh, i see, thanks. and just for check - maybe, do you mean something like that " 2>&1 | tee config.log" ?
[20:03] <geser> ia: no, as configure uses that file itself
[20:04] <geser> you have the output of configure already in the build log, what's missing is the contents of config.log if configure fails
[20:05] <ia> geser: yep, i've just got it - just forget that || means logical "or" :-)
=== ampelbein is now known as Ampelbein
[22:00] <calc> anyone know how to use launchpadlib to determine which bug_tasks are upstream bug tasks versus ubuntu bug tasks?
[22:06] <intellectronica> calc: if the task's target is not an ubuntu package but a project, then it's an upstream task
[22:07] <calc> intellectronica: ah ok i thought that might be the case once i realized i saw a bunch of status that looked like launchpad status, only some of them looked like bugzilla status
[22:07]  * calc is running a check to find bugs he can't find via the website due to a bug
[22:08] <calc> it takes a while since launchpadlib is a LOT slower than using the website directly
[22:08] <intellectronica> calc: it is? you mean the search is slower?
[22:08] <calc> probably doesn't help that I have to iterate over 2000 bugs to get the info i need
[22:08] <calc> intellectronica: hide_upstream hides bugs that have upstream tasks that are invalid
[22:09] <intellectronica> yes, i'm well aware of that bug :-/
[22:09] <calc> hide_upstream in the web interface i mean
[22:09] <calc> so i'm having to iterate over all OOo bugs to find ones that have upstream tasks that are invalid
[22:09] <calc> then print those out so i can make sure i work on those bugs
[22:09] <intellectronica> well, hide_upstream in launchpad lib behaves exactly the same
[22:09] <calc> since there is no other way to find them afaict
[22:10] <intellectronica> right. well, at least you've got that :)
[22:10] <calc> intellectronica: i didn't see a hide_upstream in launchpadlib maybe i just didn't look in the right place yet
[22:11] <intellectronica> oh, maybe it's not exported yet
[22:11] <calc> ah
[22:11] <calc> intellectronica: any hope of getting hide_upstream to not hide invalid bugs anymore?
[22:11] <intellectronica> anyway, i'll try to see if we can schedule a fix for hide_upstream so that you don't have to iterate over all the bugs, but it's nice that at least for now you can solve this with lplib
[22:12] <calc> currently hide_upstream hides them also resolved_upstream doesn't show them, so afaict there is no way to see them short of writing python
[22:12] <calc> intellectronica: great :)
[22:12] <calc> i'm pretty sure this will work, its just taking a very long time since it is probably also iterating over all OOo closed bugs :\
[22:13] <calc> i know there is a least one bug currently in that status so i can verify my code works
[22:13] <calc> er whoa
[22:13] <calc> it returned nothing
[22:13] <intellectronica> calc: you can pass a list of statuses you want to filter to searchTasks
[22:14] <calc> ok
[22:14] <calc> intellectronica: i do that before runing getBugTasks() on the source package?
[22:15] <intellectronica> calc: my_package.searchTasks(status=['New', 'Invalid', 'Confirmed']) etc'...
[22:16] <calc> ok
[22:20] <calc> intellectronica: it appears that if you set a project status to invalid instead of linking it is treated as a bug_task not as a bug_watch
[22:20] <calc> eg https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/89005
[22:20] <ubottu> Ubuntu bug 89005 in openoffice.org-qatesttool "[debian] [1:3.0.1-8] oosmoketest fails to run" [Undecided,Invalid]
[22:20] <calc> i get no results from that for bug_watches
[22:20] <calc> however if i search for it with hide_upstream in the gui its hidden
[22:21] <calc> i get all three tasks back as bug_tasks
[22:21] <calc> intellectronica: so is that a different bug?
[22:21] <intellectronica> calc: interesting, so, it used to have a bugwatch but that disappeared when you changed the status?
[22:22] <calc> it had a new need to link bit
[22:22] <calc> i never linked it upstrema afaicr
[22:23] <calc> so when i realized it was going to be fixed in debian by just deleting it in this case i marked it invalid
[22:23] <calc> even with it marked invalid it does not show up with hide_upstream in web interface, and now in launchpadlib it just shows up as a regular task
[22:24] <calc> so i didn't know if the two bugs are related to each other
=== Speedator1 is now known as Speedator
[22:24] <intellectronica> yes, it looks like a regular task to me in the web ui
[22:24] <calc> if tasks that are not part of ubuntu are supposed to show up in launchpadlib as bug_watches then there is an issue there
[22:24] <intellectronica> calc: i'm not sure what the expected behaviour is, so if you think that this is a bug, please file one
[22:25] <intellectronica> calc: tasks never show as bug watches. tasks can be assigned a bug watch, which sets their status
[22:25] <calc> intellectronica: well i guess as far as the launchpadlib is concerned i was wondering how do i get it to show me what the web interface thinks of as far as upstream things
[22:25] <intellectronica> but they are still tasks
[22:25] <calc> intellectronica: and the web interface appears to think that the openoffice task on this bug is an upstream item
[22:26] <calc> intellectronica: or is that just the singluar bug the fact the web interface thinks it is upstream when it isn't at all
[22:26] <intellectronica> calc: i'm not sure i understand
[22:26] <calc> so if i do this search:
[22:26] <calc> https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bugs?orderby=-datecreated&field.status%3Alist=TRIAGED&field.status_upstream=hide_upstream
[22:27] <calc> it does not show bug 89005
[22:27] <ubottu> Launchpad bug 89005 in openoffice.org-qatesttool "[debian] [1:3.0.1-8] oosmoketest fails to run" [Undecided,Invalid] https://launchpad.net/bugs/89005
[22:27] <calc> yet 89005 is triaged and is not upstream
[22:27] <calc> according to my understanding of what you just said hide_upstream should only hide bugs that have bug watches on them?
[22:28] <intellectronica> but it does appear to have an upstream task
[22:28] <intellectronica> no, i don't think that's the case. i think it hides bugs with task on an upstream project
[22:30] <calc> ah i see so the functionality between what i am seeing in launchpadlib and the web ui are different, the lib deals with tasks and bugwatches, the gui deals (primarily) with what type of task is on the bug
[22:31] <intellectronica> calc: not really. lplib uses exactly the same search as the web ui
=== sale_ is now known as sale
[22:31] <intellectronica> calc: bug watches have nothing to do with hide_upstream. upstream simply predicates on a task's bug having another task which is on a product
[22:32] <intellectronica> bug watches are a mechanism for allowing an external bug tracker set the status of a task
[22:32] <intellectronica> upstream projects need not have a bug watch
[22:32] <calc> how do i determine in lib which things the web thinks are upstream tasks?
[22:32] <intellectronica> au contraire, the really cool ones are tracked in Launchpad ;)
[22:32] <calc> so that i can check anything it thinks it is an upstream task for status invalid and then display that
[22:34] <intellectronica> for each task, iterate over task.bug.bug_tasks, and if at least one of them is on a product (rather than on a package or on ubuntu itself) then it's the upstream task
[22:34] <calc> ok
[22:36] <calc> intellectronica: how do i determine if it is a product?
[22:36] <calc> owner?
[22:38] <wgrant> type()?
[22:38] <wgrant> Or resource_type_link.
[22:39] <intellectronica> calc: examine task.target.resource_type_link
[22:41] <intellectronica> task.target.resource_type.link.split('#')[1] == 'project' should do the trick
[22:41] <calc> ah cool :)
[22:43] <calc> i printed resource_type_link and it showed up as:
[22:43] <calc> https://api.edge.launchpad.net/beta/#bug_task
[22:43] <calc> oh oops
[22:43] <calc> i need to add target to my code
[22:44] <calc> now that worked :)
[22:48] <calc> intellectronica: thanks for all the help! :)
[23:04] <calc> cool only one bug affected, at least now i know :)
[23:24] <calc> actually i had a bug in my script i found some now
[23:29] <ronny> yo
[23:29] <ronny> gmb: sup?
[23:49] <calc> intellectronica: wrt the hide_upstream issue in the web interface, it appears it only effectively hides bugs that are project invalid that are not bug watched
[23:49] <calc> intellectronica: bug watched invalid bugs show up in the resolved_upstream list