[01:22] I seem to have left a hung bzr process on lp, is there a way to kill it? [01:22] Unable to obtain lock held by psusi@bazaar.launchpad.net at crowberry [process #13056], acquired 4 minutes, 9 seconds ago. [01:22] psusi: bzr help break-lock [01:23] StevenK, it says only to use that if you are sure the process has been stopped [01:23] psusi: It's remote, you can't be sure. Use it anyway [01:24] that's not good... maybe I should file a bug report against bzr then... break-lock should try to kill the process rather than just hope it has stopped [01:25] psusi: Then I'd suggest you ask in #bzr what break-lock will attempt [01:25] (Before filing a bug) [01:37] hrm... when using the edit@ bug mail interface, it seems that the body of the message is ignored rather than added as a comment to each of the multiple bugs. Is there a way to correct that, or is this a bug or just an intentional lack of feature? === Ursinha is now known as Ursinha-afk [03:20] I'm trying to find out how much one of my PPA's is getting used. I'm pulling download stats for all versions of a single package from my PPA, but there doesn't seem to be a way to pull just certain dates. I'm using getDailyDownloadTotals, which allows start and end dates, but is there another way to query only a certain date range? Specifically, if I could do something like getPublishedBinaries(binary_name="mythtv-common", start_date=yesterday, [03:20] end_date=today) would be nice) [03:33] tgm4883: Yeah, the current API doesn't work so well for daily PPAs. Or for much at all. It was very much an initial step that I implemented to check if the data was OK. [03:58] wgrant, ah ok, is there future plans to add something to account for that? [03:58] I mean, I can periodically just do a full download, which takes about 30 minutes, but I can't think LP likes that too much [04:02] tgm4883: No immediate plans, no. I did the initial download count implementation before I had a boss telling me what to do. [04:03] wgrant, ah ok, that makes sense, we'll probably just do a monthly pull then [04:04] wgrant, thanks for the info [04:14] Gar, can't view my code page due to timeouts :( [04:15] lifeless is fixing that. [04:17] can has review, then can has fix === jtv is now known as jtv-eat [06:35] maxb: it is a vcs import. it shouldn't be stacked on anything! [06:37] siretart: https://code.launchpad.net/~siretart/libav/packaging-trunk is stacked on the name. [06:37] the old name. [06:39] wgrant: but this doesn't make sense, it has no common history to the vcs import [06:40] siretart: LP assumes that your project branches are related, and stacks branches on the development focus. [06:40] bzr will stack even if there is no common history. [06:40] can I reconfigure lp:~siretart/libav/packaging-trunk to non-stacked? [06:41] Try bzr reconfigure --unstacked lp:~siretart/libav/packaging-trunk' [06:41] It may work. But it may need you to manually unstack it. [06:41] (which in this case consists of deleting one line of config) [06:41] bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~siretart/libav/master/". [06:41] (or using maxb's fixup script, followed by reconfigure --unstacked. [06:42] Either sftp in and remove stacked_on_location from .bzr/branch/branch.conf, or use maxb's script. [06:44] maxb: thanks, your script fixed lp:~siretart/libav/packaging-trunk! [06:44] great - we really need a UI in bzr for this - oh for more round tuits :-) [06:45] wgrant: thanks for the explanation to you as well, of course! === doko_ is now known as doko === warp11 is now known as warp10 [08:18] maxb: wgrant: seems that this still didn't do it completly: https://code.launchpad.net/~motumedia/+recipe/libav-daily [08:18] checking out the packaging branch manually works now, though [08:19] Hmm. It's a different error. [08:19] Ah. [08:19] yes, it says now: bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/%2Bbranch/libav/". [08:19] I see. [08:19] It's now stacked on /+branch/libav, which is invalid. [08:20] I did: ./bzr-set-stacked-url lp:~siretart/libav/packaging-trunk lp:libav [08:20] That will have broken fairly recently :/ [08:20] hmm [08:20] was this wrong? what should I have done? [08:21] What if you rerun it with lp:~motumedia/libav/master instead? [08:22] okay, I can still check it out, I'll request a new build to test [08:23] this might be fallout from the failed attempt to stop using xmlrpc to resolve names [08:23] i don' have the bug number here [08:23] poolie: That's my assumption. [08:24] But isn't that only in bzr.dev? [08:24] Hmm. [08:24] siretart, what bzr version are you running [08:24] I thought it only did it for bzr+ssh in 2.3 [08:24] But perhaps it is setting a bzr+ssh URL, and LP is translating it to HTTP. [08:30] poolie: the version in lucid, 2.1.1 [08:31] but yay, it did work this time! :-) [09:04] G'morning [09:08] something's wrong there: https://launchpad.net/~chromium-daily/+archive/beta/+buildjob/2415716 [09:11] hi [09:11] i have a question [09:13] i have problem to upload a 120M file on launchpad [09:13] is there a limit with size? [09:38] nobody can answer? === jtv1 is now known as jtv === jtv1 is now known as jtv [11:16] hello, I have been getting time out everytime I try to access my code page, I was wondering if there are any issues known about that and if I can do anything in my side to fix that [11:17] mandel: known issue, fix is expected to be deploy quite soon AIUI [11:17] the last oops id is Error ID: OOPS-1915G1081 [11:17] https://lp-oops.canonical.com/oops.py/?oopsid=1915G1081 [11:18] mandel: on your side if you try ~user/proj rather than ~user you might have better luck, maybe. [11:18] Let me just check where in the pipeline the fix is. [11:18] spiv: oh, cool, thx for the info [11:21] does launchpad have means to import bug data from roundup to malone? [11:24] umm... maybe [11:24] allenap or gmb would know better [11:28] I don't know of an exporter for roundup. [11:31] we are currently considering to migrate from roundup and look for options. currently, bugzilla and launchpad have been proposed [11:33] siretart: There isn't a specific bug importer for roundup -> Launchpad. However, https://help.launchpad.net/Bugs/ImportFormat can give you guidance about how to generate an XML file that we can import for you. [11:35] gmb: thanks [11:35] np === jtv1 is now known as jtv === yofel_ is now known as yofel === Ursinha-afk is now known as Ursinha === bfiller is now known as bfiller_afk [14:49] please kill https://launchpad.net/~chromium-daily/+archive/beta/+buildjob/2415716 === deryck is now known as deryck[lunch] === Anthony|Away is now known as MadnessRed [16:18] gmb, around? somebody from Linaro is wondering why the upstream task of https://bugs.launchpad.net/gcc-linaro/+bug/710652 hasn't been updated even though the remote bug was updated a couple days ago [16:18] Ubuntu bug 710652 in gcc "ARM neon vld1q_lane_u8 & co. don't accept lanes >= 8" [Medium,In progress] [16:19] * gmb looks [16:21] salgado: It failed because we're trying to update the remote bug to include a link to the LP bug and we don't have credentials to be able to do that. [16:21] (Though the error is buried somewhat and I only found it because of an OOPS) [16:21] OOPS-1888CCW531 [16:21] https://lp-oops.canonical.com/oops.py/?oopsid=1888CCW531 [16:21] oh, and because of that we don't suck data from the remote bug either? [16:23] salgado: Hmm, interesting point. Let me dig at the code a bit; it might be that this is a failure state from which we don't recover well, even though we should. [16:37] salgado: So, it's not updated because the remote bug was changed after the last time the watch was checked. Because there have been errors on the watch, checkwatches has rate-limited the number of checks we do, so it won't be updated until tomorrow morning (at which point the latest changes should be pulled down). [16:37] (FTR, the watch was last checked at 2011-03-28 03:02:08 but the remote bug was changed at 2011-03-28 10:32:12). [16:38] gmb, oh, cool. I suppose there's no way to see the time it was last updated from the web UI, right? [16:39] salgado: Not at the moment, no. But if you'd be so kind as to file a bug we can change that when we get chance. === deryck[lunch] is now known as deryck [16:40] salgado: I think it's probably worth filing a bug for getting us credentials on the gcc bugzilla, too, since otherwise all the gcc watches are going to be rate limited to 1 check per week, eventually. [16:40] salgado: In fact, I'll take care of the credentials bug. [16:40] gmb, ok, I think I have someone who can push that [16:41] the guy is a gcc upstream developer so maybe he can help with that? [16:42] salgado: Yes, that would be great. We don't need anything on their end other than the OK to go ahead with comment syncing and back-linking. [16:43] gmb, oh, ok, and the credentials is something you'd get yourself by registering there? [16:43] Right. [16:43] Normally we just register the feedback address. [16:43] salgado: https://bugs.launchpad.net/launchpad/+bug/745794, FTR. [16:43] Ubuntu bug 745794 in Launchpad itself "Launchpad needs credentials for the GCC Bugzilla" [High,Triaged] [16:52] gmb, is the comment syncing two-way? [16:53] salgado: Yes. [16:55] gmb, is it possible to have it one-way only? are other projects happy with two-way syncing? [16:57] salgado: At the moment we have no mechanism for turning it off in one direction or the other. Most projects seem okay with the bi-directionality of it, FWIW. [16:58] gmb, I ask because the guy I'm talking to doesn't seem very keen on that. he said the best way to get permission would be to email gcc@gcc.gnu.org [17:00] salgado: Okay. Could you add a comment on the bug to that effect? [17:00] sure [17:03] thanks for the help, gmb. just filed bug 745809, btw [17:03] Launchpad bug 745809 in Launchpad itself "Show when was the last time a bug watch was updated" [Undecided,New] https://launchpad.net/bugs/745809 [17:03] Cool, thanks. === salgado is now known as salgado-lunch === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [19:47] lifeless: I appreciate your dedication to getting a page (the archive administraton page) that not very many people use working well. Thanks. [19:48] ScottK: my pleasure [19:48] ScottK: we want LP to work well [19:48] over and above this being part of LP, pages that are slow have all sorts of cascading impacts [19:49] so we really need all pages to be snappy and sane [19:49] It's progress that I filed a bug when it only failed once. Historically it was broken enough I didn't even bother with a bug unless I couldn't get it to work after multiple tries. [19:50] ScottK: \o/ [19:50] ScottK: we've been getting quite a bit of feedback along those lines recently [19:51] 'I no longer hate using LP because of speed' [19:51] ScottK: we've a ways to go to be truely fast, but I think we'll get there [19:51] Performance has been one of my major complaints since I started using LP. [19:51] It's great to see it finally getting some attention. [19:51] (and progress) [19:52] yeah, I'm starting to like using it from here :) [19:52] performance is hard though, long way to go still === romaia-tef is now known as romaia [21:09] Hi all. [21:09] hello [21:09] I am trying to change the owner of a private branch in launchpad [21:09] but I am getting an oops [21:09] OOPS-1915G1944 [21:09] https://lp-oops.canonical.com/oops.py/?oopsid=1915G1944 [21:09] if it helps [21:10] Hmm. It's a time of the day when official Canonical folks are likely to be a little scarce [21:10] It would probably be best for you to file your issue in the launchpad answers tracker [21:10] https://answers.launchpad.net/launchpad/+addquestion [21:11] maxb, I work with kiko [21:11] he said a few names that could help me [21:11] I only remember rockstar [21:12] romaia, hi. [21:12] hi rockstar [21:12] maxb: I guess we need to hire a bunch of people who sail around in the middle of the pacific. [21:12] thumper might be around now. [21:13] romaia, what's the branch in question? [21:13] lp:stoqtef [21:14] georgeyk tried to change the owner to stoq-dev [21:14] benji: It's probably more efficient to just hire software developers who drink too much coffee :-) [21:15] maxb: I thought that was already a requirement. [21:15] maxb, that would be thumper. [21:15] :-) [21:15] * thumper is making a coffee now [21:16] * rockstar is psychic [21:16] * maxb jumps on the Launchpad *is* getting faster bandwagon [21:16] Although being <5ms pingtime away from the datacentre must help :-) [21:17] * thumper waits for the oops to sync [21:17] romaia, so I've changed the ownership of the branch. The oops you got should be taken care of by the Launchpad developers soon (they're getting fast at fixing oopses). [21:17] thanks rockstar [21:17] rockstar, thanks [21:18] stupid arrhythmia, keeping me from drinking as much coffee as I want === Ursinha is now known as Ursinha-bbl === matsubara is now known as matsubara-afk === cnd` is now known as cnd [23:18] Hello launchpad. [23:19] Approximately six times this week, I've had to explain to someone that "view the branch content" means "view the code". Is there any possibility that this wording could be changed? I realize that "branch content" is formally more accurate than "code", since branches might contain other stuff, but I have yet to meet a single person who actually knew what the link meant. [23:25] glyph: do you have any suggested wording? [23:25] glyph: some branches don't have code :) [23:26] a niggle I know [23:26] thumper: But the tab is named Code again. [23:26] yes, it is [23:27] thumper: "browse the code". [23:27] thumper: I don't care that it's not accurate, it's what every other website in the world calls it, so that's what people look for :) [23:28] Maybe in 10 years when bzr has a nice GUI that is integrated with plugins for Photoshop and Microsoft Word, and we don't have to look at crummy text diffs all day to use it, people will realistically have some stuff in bzr branches that aren't code :) [23:37] glyph, i agree 'view the code' would be better [23:37] also, the link is kind of hidden considering it's a pretty important function [23:38] poolie_: Yes. Really it shouldn't be a link. The front page of each project should have a root directory listing of the current development focus as most of the page. [23:45] For the pedants, just argue that non-source files are binary codes ;) [23:45] spiv: it should be a localization feature [23:46] spiv: "en_US.UTF-8" and "en_WHAT_A_JERK.UTF-8" [23:46] spiv: and then it could say "retrieve branch contents via network connection" [23:46] because hey, if you're blind, maybe you're not "viewing" the branch content! it's prejudicial to assume that's what the user is doign. [23:47] I was thinking en_MEME.UTF-8, with lots of “Hi gentlemen how are you!!” and “I made you a web page but I eated it” [23:48] that would be an even better locale [23:54] thumper and I talked about this every 6 months or so. I hope someone changes the name of the link at least. [23:54] if someone will file the bug, I'll fix it ASAP [23:57] thumper, I'm pretty sure there's a bug already. I think zooko filed it.