[01:19] <_steven_> I am not able to successfully connect to bazaar.launchpad.net either through sftp or ssh when pushing a branch or just connecting directly [01:19] <_steven_> any ideas? [01:19] _steven_, really? tell me more. or hmm let me try first! [01:20] <_steven_> I should be able to ssh steven-sheehy@bazaar.launchpad.net, right? [01:20] no [01:21] our bazaar codehost isn't really an SSH service [01:21] <_steven_> ok, so sftp probably doesn't work that way either [01:21] _steven_, tell me what you are trying to do via the bzr client? [01:22] <_steven_> bzr push [01:22] the exact commandline :) [01:23] <_steven_> bzr push bzr+ssh://steven-sheehy@bazaar.launchpad.net/~steven-sheehy/linuxdcpp/trunk [01:23] <_steven_> that command times out for me [01:23] _steven_, first question is whether it's ever worked. [01:23] <_steven_> no [01:23] okay. can you ping bazaar.launchpad.net? [01:24] <_steven_> yes [01:24] and can you bzr branch lp:linuxdcpp? [01:24] _steven_: what version of bzr are you using? and on which platform? [01:25] <_steven_> 1.3.1 on hardy [01:25] _steven_: you can do "sftp bazaar.launchpad.net", it's just "ssh ..." that fails because you can't get a shell on that host. [01:25] _steven_: `bzr lp-login` output? [01:26] <_steven_> I've been able to bzr branch lp:linuxdcpp previously [01:26] _steven_: so "sftp -v bazaar.launchpad.net" may help you diagnose the problem [01:26] <_steven_> bzr lp-login is steven-sheehy [01:27] <_steven_> right now bzr branch lp:linuxdcpp is either really slow or not working [01:27] _steven_: it doesn't give the best feedback in the world [01:27] _steven_: it is probably working [01:29] <_steven_> sftp -vv steven-sheehy@bazaar.launchpad.net gets past "Authentication succeeded (publickey)." and hangs at "debug2: channel 0: open confirm rwindow 131072 rmax 32768" [01:30] _steven_: hmm, it's very shortly after that point that I get an (sftp) prompt where I can type "ls", etc. [01:30] _steven_: as in, debug2: channel 0: open confirm rwindow 131072 rmax 32768 [01:30] debug2: Remote version: 3 [01:30] sftp> [01:31] Anyway, that shows that you're authenticating to bazaar.launchpad.net ok. [01:32] <_steven_> so any ideas? [01:33] Try adding -Dhpss to your bzr command, i.e. running "bzr -Dhpss push bzr+ssh://..." [01:33] Then watch ~/.bzr.log [01:35] <_steven_> now I get connection timed out when I run bzr branch lp:linuxdcpp [01:35] <_steven_> ok, I'll try that [01:37] That will show some details of the bzr+ssh conversation. Feel free to pastebin the log. [01:39] _steven_: FWIW, everything seems to be working normally for me as far as I can tell [01:40] _steven_: are you doing a push atm? [01:40] <_steven_> yes, looks like it's going to timeout again [01:40] _steven_: huh, that's weird. [01:40] _steven_: do you have anything unusual in your ~/.ssh/config ? [01:41] <_steven_> don't have a config file [01:41] (I don't see any sign on the server that you've started a smart server session) [01:41] Hmm. And plain sftp hung for you. [01:42] That's sounding like a weird network problem, maybe? [01:42] <_steven_> is there anything I need to do to setup beforehand? [01:42] <_steven_> the key on my launchpad site matches the one in my id_rsa.pub [01:42] Yeah, and the key works. [01:42] Because you got "Authentication succeeded (publickey)" from sftp -vv [01:43] <_steven_> I've tried pushing with sftp to with no luck [01:43] At this point I'd be trying tcpdump (or wireshark), I think :( [01:43] <_steven_> last thing in .bzr.log is 0.179 ssh implementation is OpenSSH [01:43] I've seen MTU problems cause SSH connections to hang mysteriously. [01:44] Right, so it's not successfully establishing an SSH session either, just like sftp. [01:45] Definitely sounding like a network issue. Do you know how to use tcpdump or wireshark? :) [01:45] <_steven_> kind of [01:45] Also, if you have an SSH account somewhere else, see if you can sftp to that host (or even bzr push sftp://that-host/...) [01:47] "kind of" is probably good enough. :) I think we're just interested in something obviously strange like the connection hanging because your side sends a packet but never gets an ACK, for instance. [01:47] I am just stabbing in dark, though. [01:49] All I can really say for sure is that our systems seem to be working normally, and I can use bazaar.launchpad.net just fine from my laptop here in Sydney, so it seems likely to be something strange on your end. [02:19] <_steven_> thanks for all the help everyone :) [02:20] _steven_, did it work? :) [02:20] hey emgent! [02:21] <_steven_> kiko: yeah, I was using wireless so I hooked up ethernet from my router and it worked [02:22] hello kiko :) [02:22] _steven_: funky firewall rules on the wireless interface vs wired perhaps? [02:23] _steven_, cool. I was a bit concerned at first because we had just rolled out new code for 2.0 and I don't like problems popping up 5 minutes after we roll out! [02:23] emgent, how do you like https://edge.launchpad.net/ now? :) [02:27] not so much it sounds! [02:40] looks pretty [02:44] jamesh :) [02:44] although the "this site is running pre-release code" bar looks a bit out of place [02:45] on https://launchpad.net, the tabs look more connected to the breadcrumbs [02:45] jamesh, yeah, mpt chided me for doing that. But I hated the floating bar at the top.. hopefully there's another solution which we can produce. [02:46] kiko: attach it to the top of the screen instead of making it float? [02:46] jamesh, think it'd look okay? [02:46] kiko: I don't think it'd look any worse than what we had before [02:46] and I'm not sure where else to put such a message [02:47] jamesh, I want BETTER!! [02:47] It doesn't necessarily need to be a dark grey bar with white text either [02:47] we could use something more subtle ... [02:47] ScottK: ah, i was *wondering* why i was getting mail about a bzr branch i'd never heard of before. gotta love LP bugs. [02:47] or features. [02:48] wgrant: which recent events? [02:49] jamesh: funny, i liked that bar there. it actually made the top panel look more asthetically pleasing. [03:03] <_steven_> is it possible to push a branch to a project and not have to store it in your user area? [03:05] <_steven_> like have it stored at https://code.launchpad.net/~linuxdcpp/linuxdcpp/trunk vs https://code.launchpad.net/~steven-sheehy/linuxdcpp/trunk [03:06] _steven_: Not really, although some teams will have team branches as the product branch trunk. [03:10] _steven_, well, one thing to point out is /~linuxdcpp is a team. [03:10] _steven_, (note the leading ~) [03:11] _steven_, I would assume when reading that URL that it's an official branch for that project. is that right? [03:11] i.e. maintained by the project core team [03:12] <_steven_> kiko: it's not a real link, just an example [03:13] _steven_, sure. but did you understand my point? you can create a team called linuxdcpp and hand the branch over to the team. [03:13] <_steven_> yeah, just wondering why we can't store the branch in the project [03:14] _steven_, because branches are tied to people always -- it makes it clear who owns it (which is, in reality, who can commit to it) [03:14] _steven_, note that you can use lp:linuxdcpp to pull and push the official branch, so the long URL is only visible to people using specific branches [03:14] Hobbsee: DNS vulnerabilities. [03:15] wgrant: ah, yes. [03:16] <_steven_> kiko: ok, got it now. makes sense [03:16] cool [03:18] kiko: On a related note, is there a way ~ubuntu-dev can avoid being spammed by branch merge proposals? [03:19] wgrant: is there a mail address set for it? [03:19] wgrant, I was going to bring that up with thumper -- but you can too [03:19] i'm sure i poked and prodded enough to get addresses set for all three... [03:19] and should [03:19] Hobbsee: No, but we don't want one AFAIK. [03:19] wgrant: why not? [03:19] Then the list will get spammed. [03:19] ?? [03:19] wgrant: only if you point it at the list. [03:19] wgrant: which branch? [03:19] wgrant: or proposal [03:19] I think the concept of commiter == reviewer is a bit wrong. [03:20] thumper: ~jazzva/firefox-extensions/firefox-sage.ubuntu [03:20] wgrant: I'm not sure where you get the idea that "committer == reviewer" [03:20] thumper: Well, we're all spammed when somebody proposes a branch for reviewing. [03:21] thumper: (we being people with commit rights) [03:21] wgrant: if you don't want the emails, then edit the branch subscription for the ubuntu development team to not get code review emails [03:22] wgrant: the default behaviour is (in my opinion) the right way [03:22] wgrant: most people want to know if someone is suggesting an update or fix [03:22] thumper: By "most people" do you mean the set of committers, or the primary set of authors? [03:23] * rockstar is in most people [03:23] Consider the case where you have a small team that does most of the work (and wants to see all the proposed merges), and a larger team who can commit for integration purposes. [03:23] persia: I mean the vast majority of branch owners (which are individuals) [03:23] Wasn't there a distinction between authors and owners before? [03:23] And I see now that we are indeed subscribed - it's not implicit from owning it. [03:23] wgrant: that was somewhat crack [03:24] heh [03:24] Not for our cases. [03:24] wgrant: it was a specific design decision not to have implicit email [03:24] thumper: Why? As long as we aren't talking about individuals, they are often different. Restricting to individuals doesn't feel very collaborative. [03:25] thumper: Right, that makes sense, or there'd be no escape for us. [03:25] persia, how is it restricting? [03:25] rockstar: restricting the examined set of use cases [03:26] persia: but if you have a team branch, and the team is subscribed, then the team is notified [03:26] persia: I don't get your point [03:26] +1 thumper [03:26] persia: which is wgrant's problem [03:26] thumper: Except that the team that can commit may not be identical to the team that is the primary driver. [03:26] Correct. [03:26] ubuntu-dev and ubuntu-mozillateam in this case. [03:26] persia: right, but the team that can commit is normally interested in what is landing [03:26] Normally. [03:26] But again you forget that we are a distro. [03:26] We are big. [03:26] We are not normal. [03:26] thumper: What is landing, yes, but not what is proposed. [03:27] Well, I'd expect to see the same for e.g. GNOME. Any sufficiently large project. [03:27] my response then is "why does the branch allow commits from people who aren't interested in it?" [03:28] thumper: Because that's how distros like Ubuntu work. [03:28] thumper: I might need to change a dependency, but not want to watch the branch closely. [03:28] thumper: You are conflating "interest in the current state of the branch" with "interest in proposed changes to the branch". [03:28] i suspect this conversation is a bit over-specific [03:29] mwhudson: Why so? Any large project has the same issues. Distros are one example, but one could say the same for e.g. KDE. [03:29] And Ubuntu isn't a minor user of LP... [03:29] persia: just in that we're talking in terms of what launchpad does now [03:29] if the distro branches are *special* then they should have special subscriptions [03:29] wgrant: sure, but they're going for projects. the size thing is irrelevant. [03:29] persia, distros work just a bit differently than large, single projects. [03:29] so the larger team gets commit emails [03:30] thumper: But it's not just distros. Any large project will have the same issue [03:30] Hobbsee: for heavens sake [03:30] and the smaller team gets the proposals [03:30] Hobbsee: I made that point earlier. [03:30] wgrant: ah [03:30] rockstar: Yes, but both have different sets of interest within the project. [03:31] s/different/differing/ [03:31] persia: presumably the large project has a responsibility to operate around launchpad's limitations, then. [03:31] Unfortunately, the default is not specific to the distro. [03:31] if someone proposes a merge, it is a bug to have no-one notified [03:31] Hobbsee: That's not a useful argument from the point of view of defining how behaviour should be defined. [03:31] what we did seemed like a sensible default [03:32] however it is just a default [03:32] if it doesn't work for you [03:32] you can update it [03:32] thumper: can it be changed on a per-branch basis, rather than a per-team basis? [03:32] persia: all are on a per-branch basis [03:32] with source package branches we may have a different default [03:32] Are we going to have source package branches soon? [03:32] distro branches are different to upstream branches [03:32] Hobbsee, we are quite mindful of the issues with the distro, and are trying to find ways of making things easier for you. [03:33] wgrant: define soon? [03:33] wgrant: it's a very high priority for us [03:33] wgrant: we are planning to do these before the end of the year [03:33] thumper: LP soon... two years seems to be about right. [03:33] thumper: Just to make sure, it will be possible to have separate sets of people notified for commits to trunk vs. proposals? [03:33] Aha, that's good. [03:33] wgrant: Mark will skin us if it takes two years ;) [03:33] persia: yes it is right now [03:33] persia: This seems to be a new feature - I hadn't noticed it before, but it's there now. [03:33] thumper: Ah. My misunderstanding then. My apologies: I hadn't seen that. [03:33] wgrant: the feature has been there for quite some time [03:34] rockstar: ah. I hope for the distro-related soyuz stuff to get implemented, so more community members can deal with integral parts of the distro, then. [03:35] hopefully, that will be distro-agnostic, to be useful for any other distros that join. [03:35] Hobbsee, unfortunately, I cannot comment on that. I just wanted to make sure you understood that the distro specific stuff is a priority for us. [03:35] we really do want both "upstream projects" and "disto" use of the LP code features to work for them (easily) [03:36] s/disto/distro/ [03:36] rockstar: right. [03:36] rockstar: full credit for not breaking the package accepting stuff, this ubuntu release, though. [03:36] (thanks!) [03:37] Hobbsee, I cannot take credit for that either. :) [03:37] which branches does ~ubuntu-dev own currently? [03:37] rockstar: which bit do you do? QA? [03:37] Code. [03:37] ahhh [03:38] mwhudson: Good to know it's not only the users who can't discover the UI. https://code.edge.launchpad.net/~ubuntu-dev, perhaps? [03:38] (in particular, would they be source package branches if such things existed?) [03:38] wgrant: i guess i didn't phrase that right [03:39] mwhudson: THey would be. [03:39] Except maybe a couple. [03:39] wgrant: good to know [03:40] wgrant: Which wouldn't be source package branches? Many of the native packages have dedicated teams, and encouraging that practice seems appropriate in many cases. [03:40] so, just to be clear, they are owned by ~ubuntu-dev because everyone in ~ubuntu-dev should be allowed to commit to them? [03:40] jml: Correct. [03:40] persia: We have some upstream branches because upstream isn't using LP. [03:40] wgrant: that surprises me a little [03:40] wgrant: Ah, right. [03:41] jml: Why? [03:41] jml: That's how Ubuntu works. [03:41] jml: Everyone in ~ubuntu-dev can commit to every package in universe, much as everyone in ~ubuntu-core-dev can commit to every package in Main. [03:42] wgrant: I guess I would have, in my ignorance, expected that Ubuntu would follow the principle of least privilege. [03:42] jml: It does. [03:42] jml: We have too little manpower to restrict it any more. [03:42] how do you delete a project? [03:43] We have two levels of privileges, though Soyuz does support more now. [03:43] jml: obviously, ~ubuntu-dev could be a member of ~mozillateam [03:43] whether that's a good, scalable solution, is a good question [03:43] skavez: you have to contact a Launchpad admin. Best thing to do is ask a question on the launchpad project [03:43] Hobbsee: Hrm? Do you mean a member of ~ubuntu-dev, or the team? [03:43] jml: thanks [03:43] Hobbsee: I'm missing something... [03:43] persia: the team. [03:43] wait, that wouldn't stop the mail problem. [03:44] wgrant: I don't quite get how the two are related [03:44] wgrant: manpower and more granular privileges, that is [03:44] Hobbsee: It would actually exacerbate it. [03:44] jml: We have a small number of people, many of whom have a small amount of time. [03:44] jml: ~mozillateam: team actually cares about the branch stuff, and wants to know about every update. ~ubuntu-dev: team that needs to commit occasionally, but doesn't want to know more than they have to [03:44] jml: Restricting privileges could well limit the number of people with available time to zero. Which is bad. [03:44] if that helps [03:45] persia: yeah, i just thought of that. [03:45] Not just time, but vertical applications: if someone wants to e.g. update all the packages that depend on an obsolete library, that is work worth doing even if that person has not previously worked on those packages. [03:45] wgrant: why doesn't ~ubuntu-dev just branch any changes, and ~mozillateam merge them across into the main branch? [03:46] Hobbsee: That would block on ~mozillateam, because one shouldn't upload before it's merged. [03:46] hmm. [03:46] wgrant: so, what I was thinking of is having a team like ~python-motu-maintainers, that team could own the package branches for python packages in universe, and then people who want to contribute just ask to be members of that team [03:47] wgrant: I'm not suggesting this exactly, just trying to understand the situation more [03:48] jml: And then somebody comes along, needs to do 600 rebuilds, and swears violently at having to join 300 teams. [03:49] wgrant: you need to edit a branch to do a rebuild? [03:49] wgrant: with some restricted ones, so they're blocked on getting accepted. [03:49] People often need to touch packages only once. [03:49] jml: Changelogs, yes. [03:49] jml: It is precisely that model of which Ubuntu exists in protest. [03:49] jml: if you want to keep the branch equal to what's in the archive...yes [03:49] wgrant, Hobbsee: ok. that makes things clearer to me :) [03:49] jml: If one doesn't do that, the branch owners get very annoyed when their next upload fails. [03:49] and if they're not equal, then people stop using bzr and such very quickly. [03:50] (as we found) [03:50] jml: Essentially, Ubuntu discards the concept of "package maintainer" in the interest of integration. While individuals have foci, they are not blocked on others when the work requires changes to several packages. [03:50] Mhm. [03:50] persia: I thought Ubuntu existed in protest of Debian's inability to release ;) [03:50] jml: That too. [03:50] jml: Perhaps. I'm not sure the two aren't unrelated. [03:50] Though they do seem better now. [03:50] Consider the difficulties of release management when even the release manager isn't supposed to fix a known problem without some response from a package maintainer. [03:51] wgrant: Much more widespread use of 0-day NMU [03:51] ok. [03:51] persia: Indeed. I was a victim of one whilst waiting for sponsorship. I wasn't pleased. [03:51] It's like going half-way to full group maintenance. [03:51] Which is bad. [03:52] wgrant: Indeed, and complicated by the lack of a central mechanism to track candidates: this is why I think putting candidates on mentors or REVU is broken, and advocate debdiffs and checking for bugs when uploading. [03:52] so, from the perspective of branches, I think a lot of this will be addressed by source package branches. [03:52] persia: Indeed, that works well. Anyway, back to the topic at hand. [03:53] jml: As long as somebody doesn't blindly implement them without asking anybody who has ever worked in a distro, sure. [03:53] because the current plan is for them to have the same write permissions as the source packages to which they correspond [03:53] jml: Depends on the implementation. [03:53] That makes sense. [03:53] wgrant: well, I flew to Prague specifically to talk to Colin and others about it :) [03:54] jml: You also want to talk to universe people as well. We work somewhat differently again. [03:55] An additional interest group might be the flavour developers, who often have additional different processes. [03:55] wgrant, I think it would be difficult to cover every single possible workflow, but we will do our best. [03:55] good points, both [03:55] er [03:55] what are we doing now, other than talking to distro people? [03:55] rockstar: I think the important part is to be aware which workflows are being broken, rather than supporting them. [03:56] also, we actually do change stuff based on feedback :) [03:57] persia, is there a wiki page with specific launchpad workflows? [03:57] That mould be an excellent start [03:57] rockstar: There isn't one. This was by decision. Each workflow is documented in a page addressing the specific sort of work. [03:58] persia, can I please have an example? === kiko is now known as kiko-afk [03:58] rockstar: https://wiki.ubuntu.com/StableReleaseUpdates [03:59] so, on a slight tangent [03:59] That documents the interaction with bugs, upload targets, etc. for an update. Each type of thing done (aside from trivial bug closure) is likely to have a similar page. [04:00] I'd be happy to fix a bug in Launchpad in exchange for an equivalent bug in Ubuntu :) [04:00] there's this thing with my volume control... [04:00] jml: Any bug? [04:00] persia: not any bug :) [04:01] That's not as interesting then :) [04:02] heh [04:03] although almost everything in launchpad-bazaar is fair game. [04:05] jml: i thought ubuntu people demanded payment in beer :P [04:06] * rockstar can be bribed in coke [04:06] Hobbsee: I moved on to whisky months ago [04:06] Er, the dark liquid kind... [04:06] heh :) [04:06] rockstar++ [04:24] Ooh dear. [04:24] NZ's string dried out? [04:24] Oh, same connection. I see. [04:47] is there a way to request a rebuild of a package in ppa or has that feature been removed? [04:57] hyperair: You've always had to upload a new version, unless you mean retrying a failed build. [04:58] yes. [04:58] i meant that [04:58] retrying a failed build [04:58] there used to be a button for that [04:58] It's in the usual place. [04:58] but i can't seem to find it anymore [04:58] =\ [04:58] where? [04:58] Somewhere on that page. [04:58] Let me see... [04:58] it used to be in the build log page [04:58] oh nevermind [04:58] i just realized i wasn't logged in [04:58] jeez this is stupid [04:59] of all things [04:59] Heh. [05:00] okay i fuond it =D [05:00] hmm how long does it take for the .deb to be published after the build is successful? [05:14] hyperair: Up to 20 minutes. They are currently published at XX:00, XX:20, XX:40. [05:15] i see. [05:19] hello [05:20] while using launchpad, tried to list code files for revision. Got message telling me to come here. [05:20] halg, can you be a bit more specific? [05:20] sorry. [05:20] Hold on while I get the specifics. [05:22] I was in mysql project. [05:22] ah [05:22] Just kind of browsing, getting used to the code base and the lp system. [05:22] halg, can you post a url? [05:22] Sure. [05:22] Here: http://bazaar.launchpad.net/%7Emysql/mysql-server/mysql-5.1/annotate/2673?file_id=sp1f-buffer.cc-20041023073145-aao3dolyuw7jezlyrdgfk6nbxzxhy47c [05:22] (yucch) [05:23] Anyway, I tried to click on "browse files" (I think as I recall) [05:23] yeah, some of the mysql branches stress the code browsing rather a lot :/ [05:23] (Don't really remember what I was doing since I was just getting familiarized) [05:23] halg: the page loaded for me, maybe try again? [05:23] OK, so I get this error page telling me to come here. [05:23] Suer. [05:23] hold on. [05:24] Hmmm. I thought I had selected something else. [05:24] But anyway, it sounds like patience is the order of the day. [05:24] Every day I mean. [05:24] Mysql is a huge project. [05:25] yes, we noticed :) [05:25] So the webserver is getting a bit bogged down? [05:25] yes [05:25] So, under what conditions should I be concerned, if ever. [05:25] ? [05:25] halg, I don't think you need to be concerned. That's our job. :) [05:26] Well, what I mean is re: mitigating damage to the repository or other services. [05:26] I would hate to be in the middle of a transaction of some sort and cause corruption. [05:26] for bazaar.launchpad.net stuff, unfortunately, we know ABOUT the problems, but fixing them is going to take some work [05:26] halg: this sort of thing has no chance of corrupting data [05:26] No way for ME, a user, to trash things? [05:27] no [05:27] If the system gets bogged way down. [05:27] Good! [05:27] Relieved to hear that. [05:27] i mean, if you have the right to upload to the branch, you can mess things up that way [05:27] but not by browsing from the web [05:28] Right. But I meant in terms of just doing what I am supposed to, not an error in my content chagnes. [05:28] changes. [05:28] right [05:28] Thanks for your help. [05:28] no worries [05:28] I'm sure I'll be back at some point ... [05:28] hope so :) [05:28] ??? [05:28] You want me back? [05:28] I'd think no news is good news! [05:29] Later! [05:30] it's nice to hear from our users from time to time :) [05:31] I'll see what I can break and get back to you. [05:33] Why do branch merge proposal emails not respect team contact addresses? [05:34] wgrant: what do you mean by "respect"? [05:34] jml: They seem to spam all members regardless of the team contact address. [05:35] wgrant: that's a bug. [05:35] Oh. I see. [05:35] Maybe it does. [05:35] But this team has an email address, but it's somehow not set as the contact address. [05:36] oh ok. [05:36] wgrant: which team? [05:36] ubuntu-dev [05:37] What a confusing UI. [05:39] wgrant: please file a bug if you find a bit of the UI confusing [05:39] wgrant: especially if you can provide a suggestion for making it less so. [05:39] I plan to. [07:22] <\sh> does anyone know where the bzr repo is hiding for the new python lib for the new lp api? leonov needs to get hands on :) [07:26] \sh: I'm not 100% sure it has been released yet. [07:26] * \sh needs to talk to gmb then ;) === RAOF is now known as ROAF === ROAF is now known as RAOF [10:22] gmb, \sh: that lib should be available for anyone who wants to prototype and play [10:22] Isn't it meant to be released to beta testers some time this week? [10:23] (hi sabdfl) [10:23] hi [10:23] afaic it was supposed to be released a month ago, when the initial api pieces landed, though it's no doubt rough [10:24] Rough is much better than private in this case, IMO. [10:24] does it work, though? [10:24] Hobbsee: If we can make screenscraping work, we can make a broken proper API work. [10:28] <\sh> sabdfl: ah good to hear :) [10:30] <\sh> sabdfl / gmb: if someone can point me to a place where I can export/branch it, we'll start right away with an implementation in leonov :) [10:31] \sh: Off the top of my head, I don't know where that is (it's not something that I've personally been working on). I'll find out for you, though, and get back to you. [10:31] <\sh> gmb: thx a lot :) [10:33] <\sh> wgrant: well, I don't know how thekorn thinks about it, but I think it's good to have two ways working for a little time...but regarding my work on py-lp-bugs, I don't want to see everything screenscraped in general ;) [10:43] * \sh is brb...marathon meeting [10:51] barry is the person who was responsible for the library, iirc === thekorn is now known as thekorn_ [11:36] hi, is it possible to send copy of all announcements to an email address? [11:38] aa_: not in launchpad itself, but i'm sure there are rss to email gateways out there you could use [11:39] intellectronica: great, just saw I can get a feed of them [11:42] intellectronica: don''t suppose you know of any such services? [11:47] aa_: http://www.google.com/search?q=email+rss [12:00] ok thanks === abentley1 is now known as abentley [13:00] Gooooooooooooooooood afternoon Launchpadders! [13:02] wgrant, unfortunately there isn't really a "that part of the code" that grep could be pointed at [13:03] mpt: I haven't seen Open or Closed used anywhere except that page, so I presumed it would have been somewhere local to that page. [13:04] hm, only 70 occurrences [13:04] Oh dear. [13:04] shouldn't be that difficult :-) === mars is now known as Guest65430 === vednis is now known as mars [15:08] hi all, [15:08] I am in the process of releasing a major open source package for matlab and I wondered whether users could have SVN client access to the trunk branch of a project. [15:08] I have sought on the documentation wiki, but did not found the answer [15:08] any help? [15:08] or suggestions? === salgado_ is now known as salgado [15:32] Hey jelmer, would bzr-svn help Annabel ^^^^ [15:39] hi Matthew, Annabel [15:40] Subversion client access to bzr branches isn't supported yet by bzr-svn, although there has been work on it [15:40]