=== egon_ is now known as egon === lifeless_ is now known as lifeless [02:03] hi, I was having trouble with a recipe based package build, and from the build log it isn't clear that its my fault. [02:03] somedetailsplease :) [02:03] would anyone mind taking a look? https://launchpadlibrarian.net/94596215/buildlog.txt.gz [02:04] from what I can tell, the debian_bundle module might be out of date w.r.t. bzr-builder [02:04] the LP page for the recipe is https://code.launchpad.net/~jamesh/+recipe/echoprint-codegen-daily [02:06] the debian_bundle module in oneiric certainly looks like it could accept a file-like object, but the one on the build slave looks like it expects a string [02:21] jamesh: is this the one where the fix is "put 0.3 where it says 0.4 in your recipe now"? [02:22] mwhudson: I don't know what that one is, so it might be. [02:22] jamesh: where is your recipe? [02:22] (that bug might be fixed now too, i'm not sure) [02:22] mwhudson: https://code.launchpad.net/~jamesh/+recipe/echoprint-codegen-daily [02:24] jamesh: you could try changing the "bzr-builder format 0.4" to "bzr-builder format 0.3" and see what happens [02:24] jamesh: but please don't mistake me for someone who knows what's going on :) [02:26] mwhudson: okay. I've requested a single build with that change [02:27] mwhudson: but looking at the error in the build log, it almost definitely looks like version skew between the bzr-builder and python-debian packages [02:47] jamesh, mwhudson: That error is indeed normally fixed by s/0.4/0.3 [02:47] It's version skew indeed, but it only affects 0.4. [02:53] https://bugs.launchpad.net/ubuntu does not load, gives (Error ID: OOPS-be0aa0c0fc73cffbd8ff6af8037d4bea) [02:53] https://lp-oops.canonical.com/oops.py/?oopsid=be0aa0c0fc73cffbd8ff6af8037d4bea [02:55] nevermind, ity just loaded [02:55] it* [02:58] hey folks [02:59] can anyone help provide some guidance on how I write some launchpadlib to determine if someone has achieved the accomplishments outlined on https://wiki.ubuntu.com/Accomplishments/Trophies/Scripts [03:00] what you really want is to capture those events as they happen [03:00] we have some work to go to enable that [03:00] anyhow, you basically need to walk an appropriate collection fo rmost of them [03:00] jono: Could I PM you? [03:00] this may be slow (expensive) and time out, as it will be deep historical data [03:01] vibhav, sure [03:04] jono: Hm, "First New Source Package" probably wants to be an unachievement. [03:04] It's not something we probably want to encourage :) [03:07] wgrant, no? [03:07] there is a lot of angst around that topic [03:07] (In Ubuntu and MOTU specifically) [03:10] lifeless, you mean around people submitting crappy packages?]\ [03:10] and new packages of crappy upstreams [03:10] And new packages of good upstreams. [03:10] That then rot. [03:11] there is a history of one-shot things person foo has a package of bar, and then never updates it [03:11] Because the contribution is drive-by [03:11] we have, in theory, team maintenance, but these folk usually don't contribute to that at all [03:13] wgrant,mwhudson: thanks for the help. Looks like I've got a build going with the recipe format set to 0.3 (had to get rid of the 0.4-only variable substitutions in the version number though) [03:13] lifeless: the angst is not only in Ubuntu ;) [03:13] jamesh: np, it's a shame it's not fixed yet [03:14] lifeless: the gentoo package tree more or less grows without bound because we do a really poor job of removing dead software; there is in fact a whole team of people dedicated to it ;) [03:14] right, I see the point, but the goal of the accomplishments is less about saying someone will constantly be achieving good work, and more about highlighting new experiences such as successfully producing a source package for Ubuntu [03:14] * wgrant doesn't really know how Gentoo's maintainer policies work [03:14] but I agree there is plenty of potential for debate around whether this accomplishment should be included [03:14] jono: it depends, do you expect people to seek out the badges? [03:15] jono: if yes, then surely each badge should be something we're happy with hundreds or thousands of folk doing ? [03:15] wgrant: at least for Ubuntu, you have actual releases which seem to be a solid time to cull software that is unmaintained. [03:15] lifeless, I expect some people to try and game the system for the sake of gaming it, but then again, I suspect those folks will give up when it becomes too much work [03:15] there will be people who seek out the achievements for there own sake, no matter what your intentions are [03:15] antarus: Yeah. But we have complete team maintenance, so it's difficult to judge when a package is unmaintained. [03:16] antarus: Debian has an easier job normally, because they often have no team maintenance, so you can judge by maintainer whether stuff needs to be removed. [03:16] lifeless, the primary goal of this system to help people feel good about their contributions and to help people learn how to participate [03:16] wgrant: ahh as far as that we have 'herds [03:16] er 'herds' [03:17] Debian nowadays has focused teams for some types of packages [03:17] eg the Python modules team [03:17] wgrant: some herds work pretty well (the 'python' herd for example will actually take care of anything in dev-python) [03:17] wgrant: others will completely ignore packages in their herd [03:17] Heh [03:18] lifeless, is there any guidance you could provide on that wiki page for the other accomplishments? [03:18] I am just looking for a few code fragments to help me get started [03:20] wgrant: the big problem w/gentoo is that there is 0 barrier to entry. I have commit access and I can basically add whatever packages I want; even if there is no upstream, or I am the upstream, or its some tiny shell script that probably just shouldn't be available in the 'main repo' sort of style that Gentoo has. [03:21] * antarus is unsure what the entry criteria for MOTU are [03:22] antarus: New packages from a MOTU require a review from another MOTU, and there's a pretty sensible group of archive admins who review all new packages once they're uploaded. It's mostly for copyright and packaging quality purposes, less for usefulness purposes, but I suspect that barrier is enough to make people think. === SamB__ is now known as SamB [04:27] * micahg will suggest First Source Package in Debian to Jono as an accomplishment :) === stub1 is now known as stub [09:04] good morning === danhg_ is now known as danhg [12:31] Is it possible to close a bug or can a bug be updated indefinitely? [12:32] nothingspecial: fix committed? [12:33] czajkowski, thanks does that close it to further updates? [12:34] nothingspecial: well has there been a fix committed to it ? [12:35] or is it invalid and you dont need any more updates? [12:36] Hy there, https://lists.launchpad.net/ seems to be down. Can you bring it up again please? [12:36] gr0bi: can you try again page working fine here [12:37] czajkowski, I am not asking about a particular bug, this is just a general question as to whether or not a bug can be closed in either senario [12:37] czajkowski, yeah it's working again! [12:37] czajkowski, thx for fast responding [12:37] nothingspecial: it depends on the bug, if it's invalid or there has been a fix committed [12:37] gr0bi: np I did nothing bar look at the webpage :) [12:39] czajkowski, thanks, so if a fix has been committed that is the end of the bug [12:39] process [12:40] czajkowski, so the force may be with you ;) [12:52] nothingspecial, czajkowski: there's fix released after fix committed; however, what you are asking isn't doable. the bug is still there and can still be commented on or status changed. there is no "this bug is now unwritable in the db and closed for good." [12:54] dobey, thanks for the clarification [12:56] can i ask here about bzr dailydeb or if not, where should i? #bzr is quiet === epsy is now known as \u03b5 === yofel_ is now known as yofel === danhg_ is now known as danhg [16:58] hi [16:58] i forgot my password for my launchpad acct [16:58] can an admin look into it and sent it? [16:59] i tried the send by mail option and didnt get nothing fro launchpad [17:00] at the "eset your Launchpad Login Service password" page [17:00] after i input the email address, it doens't say anything if the mail went through or the email was right or anything [17:03] nvm will register [17:03] .wc === deryck is now known as deryck[lunch] [17:11] repost from ubuntu-desktop: [17:11] dammit launchpad! *shaking-angry-grandpa-fist* [17:11] how do I get rid of this stupid duplicate libreoffice (openSUSE) tracker on bug 562027 [17:12] Launchpad bug 562027 in libreoffice (Ubuntu Lucid) "[Upstream] Unable to shutdown / reboot / logout when quickstarter is active" [Undecided,Confirmed] https://launchpad.net/bugs/562027 [17:12] funny thing is: there is a minus button behind almost all the other remote trackers, but not behind baltix and opensuse .... [17:12] (note that the same remote is tracked twice ...) [17:13] Sweetshark: which bit do you want to remove ? [17:17] czajkowski: the tracking of openSUSE [17:19] Sweetshark: ah not sure I can let me check, came across this earier when something was assinged and fixed released couldnt remove the project [17:25] Sweetshark: no answer as of yet but as soon as I find out I'll leave a comment in here if I can if you're still here [17:26] czajkowski: Ill be gone in a minute. [17:26] anyway, thanks! [17:27] Sweetshark: well if if I find out it can be done I;ll get it done :) === deryck[lunch] is now known as deryck [18:35] hello [18:36] can someone tell how can I get the source code and make a patch for update-manager package in Ubuntu ? === matsubara is now known as matsubara-afk [21:58] Hi, I'm having some trouble using the LP API to search for bugs in a particular series. The API returns 0 bugs for a given series regardless of how many bugs are targeted to the series. Any suggestions? Sample code is here: http://pastebin.ubuntu.com/861136/ [22:00] smagoun: Try setting omit_targeted=False in searchTasks [22:01] * smagoun tries [22:01] Bug #320596 [22:01] Launchpad bug 320596 in Launchpad itself "Series.searchTasks() always returns an empty collection" [High,Fix released] https://launchpad.net/bugs/320596 [22:01] Hm [22:01] Meant to be fixed [22:01] Still try the workarou [22:02] wgrant: adding omit_targeted=False gives me the results I expected from my sample code - thank you [22:03] wgrant: I'll file a new bug against LP, referencing 320596 [22:04] smagoun: Which version of the API are you using? [22:05] smagoun: In devel it defaults to False [22:05] So if you use devel it should be OK. [22:05] wgrant: production [22:05] (I think?) [22:05] smagoun: There are three versions of the API on production. [22:05] beta, 1.0 and devel [22:05] We encourage scripts that aren't in released software to use devel. [22:06] wgrant: I don't do anything in my sample code to set the API. Does that default to 1.0? [22:06] You set the version by saying version='devel' in your login_with or login_anonymously call [22:06] The default changes depending on the version of launchpadlib, I believe. [22:07] wgrant: adding version='devel' to login_with does result in the expected behavior even if I don't include omit_targeted=False [22:07] smagoun: Great, so not a separate bug. [22:08] wgrant: ok...then you don't need me to file one, it sounds like [22:08] smagoun: Right [22:09] got it, thanks (a documentation update would be nice...it's not obvious from either the API docs or the bug you linked that this is fixed in newer versions of the API) [22:33] hi all [22:40] Hey poolie [23:09] hey folks [23:10] what is the liklihood of getting https://launchpad.net/bugs/610491 implemented? [23:10] Ubuntu bug 610491 in Launchpad itself "[API] Please expose getPublishedSources(package_creator,package_signer)" [Low,Triaged] [23:12] unless someone contributes a patch or formally escalates it, pretty low