[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] <kiko> _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] <kiko> no
[01:21] <kiko> our bazaar codehost isn't really an SSH service
[01:21] <_steven_> ok, so sftp probably doesn't work that way either
[01:21] <kiko> _steven_, tell me what you are trying to do via the bzr client?
[01:22] <_steven_> bzr push
[01:22] <kiko> 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] <kiko> _steven_, first question is whether it's ever worked.
[01:23] <_steven_> no
[01:23] <kiko> okay. can you ping bazaar.launchpad.net?
[01:24] <_steven_> yes
[01:24] <kiko> and can you bzr branch lp:linuxdcpp?
[01:24] <thumper> _steven_: what version of bzr are you using? and on which platform?
[01:25] <_steven_> 1.3.1 on hardy
[01:25] <spiv> _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] <thumper> _steven_: `bzr lp-login` output?
[01:26] <_steven_> I've been able to bzr branch lp:linuxdcpp previously
[01:26] <spiv> _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] <thumper> _steven_: it doesn't give the best feedback in the world
[01:27] <thumper> _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] <spiv> _steven_: hmm, it's very shortly after that point that I get an (sftp) prompt where I can type "ls", etc.
[01:30] <spiv> _steven_: as in, debug2: channel 0: open confirm rwindow 131072 rmax 32768
[01:30] <spiv> debug2: Remote version: 3
[01:30] <spiv> sftp>
[01:31] <spiv> Anyway, that shows that you're authenticating to bazaar.launchpad.net ok.
[01:32] <_steven_> so any ideas?
[01:33] <spiv> Try adding -Dhpss to your bzr command, i.e. running "bzr -Dhpss push bzr+ssh://..."
[01:33] <spiv> 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] <spiv> That will show some details of the bzr+ssh conversation.  Feel free to pastebin the log.
[01:39] <spiv> _steven_: FWIW, everything seems to be working normally for me as far as I can tell
[01:40] <spiv> _steven_: are you doing a push atm?
[01:40] <_steven_> yes, looks like it's going to timeout again
[01:40] <spiv> _steven_: huh, that's weird.
[01:40] <spiv> _steven_: do you have anything unusual in your ~/.ssh/config ?
[01:41] <_steven_> don't have a config file
[01:41] <spiv> (I don't see any sign on the server that you've started a smart server session)
[01:41] <spiv> Hmm.  And plain sftp hung for you.
[01:42] <spiv> 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] <spiv> Yeah, and the key works.
[01:42] <spiv> Because you got "Authentication succeeded (publickey)" from sftp -vv
[01:43] <_steven_> I've tried pushing with sftp to with no luck
[01:43] <spiv> 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] <spiv> I've seen MTU problems cause SSH connections to hang mysteriously.
[01:44] <spiv> Right, so it's not successfully establishing an SSH session either, just like sftp.
[01:45] <spiv> Definitely sounding like a network issue.  Do you know how to use tcpdump or wireshark? :)
[01:45] <_steven_> kind of
[01:45] <spiv> 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] <spiv> "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] <spiv> I am just stabbing in dark, though.
[01:49] <spiv> 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] <kiko> _steven_, did it work? :)
[02:20] <kiko> hey emgent!
[02:21] <_steven_> kiko: yeah, I was using wireless so I hooked up ethernet from my router and it worked
[02:22] <emgent> hello kiko :)
[02:22] <spm> _steven_: funky firewall rules on the wireless interface vs wired perhaps?
[02:23] <kiko> _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] <kiko> emgent, how do you like https://edge.launchpad.net/ now? :)
[02:27] <kiko> not so much it sounds!
[02:40] <jamesh> looks pretty
[02:44] <kiko> jamesh :)
[02:44] <jamesh> although the "this site is running pre-release code" bar looks a bit out of place
[02:45] <jamesh> on https://launchpad.net, the tabs look more connected to the breadcrumbs
[02:45] <kiko> 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] <jamesh> kiko: attach it to the top of the screen instead of making it float?
[02:46] <kiko> jamesh, think it'd look okay?
[02:46] <jamesh> kiko: I don't think it'd look any worse than what we had before
[02:46] <jamesh> and I'm not sure where else to put such a message
[02:47] <kiko> jamesh, I want BETTER!!
[02:47] <jamesh> It doesn't necessarily need to be a dark grey bar with white text either
[02:47] <jamesh> we could use something more subtle ...
[02:47] <Hobbsee> 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] <Hobbsee> or features.
[02:48] <Hobbsee> wgrant: which recent events?
[02:49] <Hobbsee> 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] <persia> _steven_: Not really, although some teams will have team branches as the product branch trunk.
[03:10] <kiko> _steven_, well, one thing to point out is /~linuxdcpp is a team.
[03:10] <kiko> _steven_, (note the leading ~)
[03:11] <kiko> _steven_, I would assume when reading that URL that it's an official branch for that project. is that right?
[03:11] <kiko> i.e. maintained by the project core team
[03:12] <_steven_> kiko: it's not a real link, just an example
[03:13] <kiko> _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] <kiko> _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] <kiko> _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] <wgrant> Hobbsee: DNS vulnerabilities.
[03:15] <Hobbsee> wgrant: ah, yes.
[03:16] <_steven_> kiko: ok, got it now. makes sense
[03:16] <kiko> cool
[03:18] <wgrant> kiko: On a related note, is there a way ~ubuntu-dev can avoid being spammed by branch merge proposals?
[03:19] <Hobbsee> wgrant: is there a mail address set for it?
[03:19] <kiko> wgrant, I was going to bring that up with thumper -- but you can too
[03:19] <Hobbsee> i'm sure i poked and prodded enough to get addresses set for all three...
[03:19] <kiko> and should
[03:19] <wgrant> Hobbsee: No, but we don't want one AFAIK.
[03:19] <Hobbsee> wgrant: why not?
[03:19] <wgrant> Then the list will get spammed.
[03:19] <thumper> ??
[03:19] <Hobbsee> wgrant: only if you point it at the list.
[03:19] <thumper> wgrant: which branch?
[03:19] <thumper> wgrant: or proposal
[03:19] <wgrant> I think the concept of commiter == reviewer is a bit wrong.
[03:20] <wgrant> thumper: ~jazzva/firefox-extensions/firefox-sage.ubuntu
[03:20] <thumper> wgrant: I'm not sure where you get the idea that "committer == reviewer"
[03:20] <wgrant> thumper: Well, we're all spammed when somebody proposes a branch for reviewing.
[03:21] <wgrant> thumper: (we being people with commit rights)
[03:21] <thumper> 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] <thumper> wgrant: the default behaviour is (in my opinion) the right way
[03:22] <thumper> wgrant: most people want to know if someone is suggesting an update or fix
[03:22] <persia> 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] <persia> 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] <thumper> persia: I mean the vast majority of branch owners (which are individuals)
[03:23] <wgrant> Wasn't there a distinction between authors and owners before?
[03:23] <wgrant> And I see now that we are indeed subscribed - it's not implicit from owning it.
[03:23] <thumper> wgrant: that was somewhat crack
[03:24] <kiko> heh
[03:24] <wgrant> Not for our cases.
[03:24] <thumper> wgrant: it was a specific design decision not to have implicit email
[03:24] <persia> 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] <wgrant> thumper: Right, that makes sense, or there'd be no escape for us.
[03:25] <rockstar> persia, how is it restricting?
[03:25] <persia> rockstar: restricting the examined set of use cases
[03:26] <thumper> persia: but if you have a team branch, and the team is subscribed, then the team is notified
[03:26] <thumper> persia: I don't get your point
[03:26] <rockstar> +1 thumper
[03:26] <thumper> persia: which is wgrant's problem
[03:26] <persia> thumper: Except that the team that can commit may not be identical to the team that is the primary driver.
[03:26] <wgrant> Correct.
[03:26] <wgrant> ubuntu-dev and ubuntu-mozillateam in this case.
[03:26] <thumper> persia: right, but the team that can commit is normally interested in what is landing
[03:26] <wgrant> Normally.
[03:26] <wgrant> But again you forget that we are a distro.
[03:26] <wgrant> We are big.
[03:26] <wgrant> We are not normal.
[03:26] <persia> thumper: What is landing, yes, but not what is proposed.
[03:27] <persia> Well, I'd expect to see the same for e.g. GNOME.  Any sufficiently large project.
[03:27] <thumper> my response then is "why does the branch allow commits from people who aren't interested in it?"
[03:28] <wgrant> thumper: Because that's how distros like Ubuntu work.
[03:28] <wgrant> thumper: I might need to change a dependency, but not want to watch the branch closely.
[03:28] <persia> thumper: You are conflating "interest in the current state of the branch" with "interest in proposed changes to the branch".
[03:28] <mwhudson> i suspect this conversation is a bit over-specific
[03:29] <persia> 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] <wgrant> And Ubuntu isn't a minor user of LP...
[03:29] <mwhudson> persia: just in that we're talking in terms of what launchpad does now
[03:29] <thumper> if the distro branches are *special* then they should have special subscriptions
[03:29] <Hobbsee> wgrant: sure, but they're going for projects.  the size thing is irrelevant.
[03:29] <rockstar> persia, distros work just a bit differently than large, single projects.
[03:29] <thumper> so the larger team gets commit emails
[03:30] <persia> thumper: But it's not just distros.  Any large project will have the same issue
[03:30] <mwhudson> Hobbsee: for heavens sake
[03:30] <thumper> and the smaller team gets the proposals
[03:30] <wgrant> Hobbsee: I made that point earlier.
[03:30] <Hobbsee> wgrant: ah
[03:30] <persia> rockstar: Yes, but both have different sets of interest within the project.
[03:31] <persia> s/different/differing/
[03:31] <Hobbsee> persia: presumably the large project has a responsibility to operate around launchpad's limitations, then.
[03:31] <rockstar> Unfortunately, the default is not specific to the distro.
[03:31] <thumper> if someone proposes a merge, it is a bug to have no-one notified
[03:31] <persia> Hobbsee: That's not a useful argument from the point of view of defining how behaviour should be defined.
[03:31] <thumper> what we did seemed like a sensible default
[03:32] <thumper> however it is just a default
[03:32] <thumper> if it doesn't work for you
[03:32] <thumper> you can update it
[03:32] <persia> thumper: can it be changed on a per-branch basis, rather than a per-team basis?
[03:32] <thumper> persia: all are on a per-branch basis
[03:32] <thumper> with source package branches we may have a different default
[03:32] <wgrant> Are we going to have source package branches soon?
[03:32] <thumper> distro branches are different to upstream branches
[03:32] <rockstar> 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] <thumper> wgrant: define soon?
[03:33] <jml> wgrant: it's a very high priority for us
[03:33] <thumper> wgrant: we are planning to do these before the end of the year
[03:33] <wgrant> thumper: LP soon... two years seems to be about right.
[03:33] <persia> thumper: Just to make sure, it will be possible to have separate sets of people notified for commits to trunk vs. proposals?
[03:33] <wgrant> Aha, that's good.
[03:33] <jml> wgrant: Mark will skin us if it takes two years ;)
[03:33] <thumper> persia: yes it is right now
[03:33] <wgrant> persia: This seems to be a new feature - I hadn't noticed it before, but it's there now.
[03:33] <persia> thumper: Ah.  My misunderstanding then.  My apologies: I hadn't seen that.
[03:33] <thumper> wgrant: the feature has been there for quite some time
[03:34] <Hobbsee> 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] <Hobbsee> hopefully, that will be distro-agnostic, to be useful for any other distros that join.
[03:35] <rockstar> 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] <thumper> we really do want both "upstream projects" and "disto" use of the LP code features to work for them (easily)
[03:36] <thumper> s/disto/distro/
[03:36] <Hobbsee> rockstar: right.
[03:36] <Hobbsee> rockstar: full credit for not breaking the package accepting stuff, this ubuntu release, though.
[03:36] <Hobbsee> (thanks!)
[03:37] <rockstar> Hobbsee, I cannot take credit for that either.  :)
[03:37] <mwhudson> which branches does ~ubuntu-dev own currently?
[03:37] <Hobbsee> rockstar: which bit do you do?  QA?
[03:37] <rockstar> Code.
[03:37] <Hobbsee> ahhh
[03:38] <wgrant> 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] <mwhudson> (in particular, would they be source package branches if such things existed?)
[03:38] <mwhudson> wgrant: i guess i didn't phrase that right
[03:39] <wgrant> mwhudson: THey would be.
[03:39] <wgrant> Except maybe a couple.
[03:39] <mwhudson> wgrant: good to know
[03:40] <persia> 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] <jml> 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] <wgrant> jml: Correct.
[03:40] <wgrant> persia: We have some upstream branches because upstream isn't using LP.
[03:40] <jml> wgrant: that surprises me a little
[03:40] <persia> wgrant: Ah, right.
[03:41] <wgrant> jml: Why?
[03:41] <wgrant> jml: That's how Ubuntu works.
[03:41] <persia> 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] <jml> wgrant: I guess I would have, in my ignorance, expected that Ubuntu would follow the principle of least privilege.
[03:42] <persia> jml: It does.
[03:42] <wgrant> jml: We have too little manpower to restrict it any more.
[03:42] <skavez> how do you delete a project?
[03:43] <wgrant> We have two levels of privileges, though Soyuz does support more now.
[03:43] <Hobbsee> jml: obviously, ~ubuntu-dev could be a member of ~mozillateam
[03:43] <Hobbsee> whether that's a good, scalable solution, is a good question
[03:43] <jml> skavez: you have to contact a Launchpad admin. Best thing to do is ask a question on the launchpad project
[03:43] <persia> Hobbsee: Hrm?  Do you mean a member of ~ubuntu-dev, or the team?
[03:43] <skavez> jml: thanks
[03:43] <jml> Hobbsee: I'm missing something...
[03:43] <Hobbsee> persia: the team.
[03:43] <Hobbsee> wait, that wouldn't stop the mail problem.
[03:44] <jml> wgrant: I don't quite get how the two are related
[03:44] <jml> wgrant: manpower and more granular privileges, that is
[03:44] <persia> Hobbsee: It would actually exacerbate it.
[03:44] <wgrant> jml: We have a small number of people, many of whom have a small amount of time.
[03:44] <Hobbsee> 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] <wgrant> jml: Restricting privileges could well limit the number of people with available time to zero. Which is bad.
[03:44] <Hobbsee> if that helps
[03:45] <Hobbsee> persia: yeah, i just thought of that.
[03:45] <persia> 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] <Hobbsee> wgrant: why doesn't ~ubuntu-dev just branch any changes, and ~mozillateam merge them across into the main branch?
[03:46] <wgrant> Hobbsee: That would block on ~mozillateam, because one shouldn't upload before it's merged.
[03:46] <Hobbsee> hmm.
[03:46] <jml> 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] <jml> wgrant: I'm not suggesting this exactly, just trying to understand the situation more
[03:48] <wgrant> jml: And then somebody comes along, needs to do 600 rebuilds, and swears violently at having to join 300 teams.
[03:49] <jml> wgrant: you need to edit a branch to do a rebuild?
[03:49] <Hobbsee> wgrant: with some restricted ones, so they're blocked on getting accepted.
[03:49] <wgrant> People often need to touch packages only once.
[03:49] <wgrant> jml: Changelogs, yes.
[03:49] <persia> jml: It is precisely that model of which Ubuntu exists in protest.
[03:49] <Hobbsee> jml: if you want to keep the branch equal to what's in the archive...yes
[03:49] <jml> wgrant, Hobbsee: ok. that makes things clearer to me :)
[03:49] <wgrant> jml: If one doesn't do that, the branch owners get very annoyed when their next upload fails.
[03:49] <Hobbsee> and if they're not equal, then people stop using bzr and such very quickly.
[03:50] <Hobbsee> (as we found)
[03:50] <persia> 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] <wgrant> Mhm.
[03:50] <jml> persia: I thought Ubuntu existed in protest of Debian's inability to release ;)
[03:50] <wgrant> jml: That too.
[03:50] <persia> jml: Perhaps.  I'm not sure the two aren't unrelated.
[03:50] <wgrant> Though they do seem better now.
[03:50] <persia> 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] <persia> wgrant: Much more widespread use of 0-day NMU
[03:51] <jml> ok.
[03:51] <wgrant> persia: Indeed. I was a victim of one whilst waiting for sponsorship. I wasn't pleased.
[03:51] <wgrant> It's like going half-way to full group maintenance.
[03:51] <wgrant> Which is bad.
[03:52] <persia> 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] <jml> so, from the perspective of branches, I think a lot of this will be addressed by source package branches.
[03:52] <wgrant> persia: Indeed, that works well. Anyway, back to the topic at hand.
[03:53] <wgrant> jml: As long as somebody doesn't blindly implement them without asking anybody who has ever worked in a distro, sure.
[03:53] <jml> because the current plan is for them to have the same write permissions as the source packages to which they correspond
[03:53] <persia> jml: Depends on the implementation.
[03:53] <wgrant> That makes sense.
[03:53] <jml> wgrant: well, I flew to Prague specifically to talk to Colin and others about it :)
[03:54] <wgrant> jml: You also want to talk to universe people as well. We work somewhat differently again.
[03:55] <persia> An additional interest group might be the flavour developers, who often have additional different processes.
[03:55] <rockstar> wgrant, I think it would be difficult to cover every single possible workflow, but we will do our best.
[03:55] <jml> good points, both
[03:55] <mwhudson> er
[03:55] <mwhudson> what are we doing now, other than talking to distro people?
[03:55] <persia> rockstar: I think the important part is to be aware which workflows are being broken, rather than supporting them.
[03:56] <jml> also, we actually do change stuff based on feedback :)
[03:57] <rockstar> persia, is there a wiki page with specific launchpad workflows?
[03:57] <rockstar> That mould be an excellent start
[03:57] <persia> rockstar: There isn't one.  This was by decision.  Each workflow is documented in a page addressing the specific sort of work.
[03:58] <rockstar> persia, can I please have an example?
[03:58] <persia> rockstar: https://wiki.ubuntu.com/StableReleaseUpdates
[03:59] <jml> so, on a slight tangent
[03:59] <persia> 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] <jml> I'd be happy to fix a bug in Launchpad in exchange for an equivalent bug in Ubuntu :)
[04:00] <jml> there's this thing with my volume control...
[04:00] <persia> jml: Any bug?
[04:00] <jml> persia: not any bug :)
[04:01] <persia> That's not as interesting then :)
[04:02] <mwhudson> heh
[04:03] <jml> although almost everything in launchpad-bazaar is fair game.
[04:05] <Hobbsee> jml: i thought ubuntu people demanded payment in beer :P
[04:06]  * rockstar can be bribed in coke
[04:06] <jml> Hobbsee: I moved on to whisky months ago
[04:06] <rockstar> Er, the dark liquid kind...
[04:06] <Hobbsee> heh :)
[04:06] <Hobbsee> rockstar++
[04:24] <wgrant> Ooh dear.
[04:24] <wgrant> NZ's string dried out?
[04:24] <wgrant> Oh, same connection. I see.
[04:47] <hyperair> is there a way to request a rebuild of a package in ppa or has that feature been removed?
[04:57] <wgrant> hyperair: You've always had to upload a new version, unless you mean retrying a failed build.
[04:58] <hyperair> yes.
[04:58] <hyperair> i meant that
[04:58] <hyperair> retrying a failed build
[04:58] <hyperair> there used to be a button for that
[04:58] <wgrant> It's in the usual place.
[04:58] <hyperair> but i can't seem to find it anymore
[04:58] <hyperair> =\
[04:58] <hyperair> where?
[04:58] <wgrant> Somewhere on that page.
[04:58] <wgrant> Let me see...
[04:58] <hyperair> it used to be in the build log page
[04:58] <hyperair> oh nevermind
[04:58] <hyperair> i just realized i wasn't logged in
[04:58] <hyperair> jeez this is stupid
[04:59] <hyperair> of all things
[04:59] <wgrant> Heh.
[05:00] <hyperair> okay i fuond it =D
[05:00] <hyperair> hmm how long does it take for the .deb to be published after the build is successful?
[05:14] <wgrant> hyperair: Up to 20 minutes. They are currently published at XX:00, XX:20, XX:40.
[05:15] <hyperair> i see.
[05:19] <halg> hello
[05:20] <halg> while using launchpad, tried to list code files for revision.  Got message telling me to come here.
[05:20] <rockstar> halg, can you be a bit more specific?
[05:20] <halg> sorry.
[05:20] <halg> Hold on while I get the specifics.
[05:22] <halg> I was in mysql project.
[05:22] <mwhudson> ah
[05:22] <halg> Just kind of browsing, getting used to the code base and the lp system.
[05:22] <rockstar> halg, can you post a url?
[05:22] <halg> Sure.
[05:22] <halg> Here:  http://bazaar.launchpad.net/%7Emysql/mysql-server/mysql-5.1/annotate/2673?file_id=sp1f-buffer.cc-20041023073145-aao3dolyuw7jezlyrdgfk6nbxzxhy47c
[05:22] <halg> (yucch)
[05:23] <halg> Anyway, I tried to click on "browse files" (I think as I recall)
[05:23] <mwhudson> yeah, some of the mysql branches stress the code browsing rather a lot :/
[05:23] <halg> (Don't really remember what I was doing since I was just getting familiarized)
[05:23] <mwhudson> halg: the page loaded for me, maybe try again?
[05:23] <halg> OK, so I get this error page telling me to come here.
[05:23] <halg> Suer.
[05:23] <halg> hold on.
[05:24] <halg> Hmmm.  I thought I had selected something else.
[05:24] <halg> But anyway, it sounds like patience is the order of the day.
[05:24] <halg> Every day I mean.
[05:24] <halg> Mysql is a huge project.
[05:25] <mwhudson> yes, we noticed :)
[05:25] <halg> So the webserver is getting a bit bogged down?
[05:25] <mwhudson> yes
[05:25] <halg> So, under what conditions should I be concerned, if ever.
[05:25] <halg> ?
[05:25] <rockstar> halg, I don't think you need to be concerned.  That's our job.  :)
[05:26] <halg> Well, what I mean is re: mitigating damage to the repository or other services.
[05:26] <halg> I would hate to be in the middle of a transaction of some sort and cause corruption.
[05:26] <mwhudson> for bazaar.launchpad.net stuff, unfortunately, we know ABOUT the problems, but fixing them is going to take some work
[05:26] <mwhudson> halg: this sort of thing has no chance of corrupting data
[05:26] <halg> No way for ME, a user, to trash things?
[05:27] <mwhudson> no
[05:27] <halg> If the system gets bogged way down.
[05:27] <halg> Good!
[05:27] <halg> Relieved to hear that.
[05:27] <mwhudson> i mean, if you have the right to upload to the branch, you can mess things up that way
[05:27] <mwhudson> but not by browsing from the web
[05:28] <halg> Right.  But I meant in terms of just doing what I am supposed to, not an error in my content chagnes.
[05:28] <halg> changes.
[05:28] <mwhudson> right
[05:28] <halg> Thanks for your help.
[05:28] <mwhudson> no worries
[05:28] <halg> I'm sure I'll be back at some point ...
[05:28] <mwhudson> hope so :)
[05:28] <halg> ???
[05:28] <halg> You want me back?
[05:28] <halg> I'd think no news is good news!
[05:29] <halg> Later!
[05:30] <mwhudson> it's nice to hear from our users from time to time :)
[05:31] <halg> I'll see what I can break and get back to you.
[05:33] <wgrant> Why do branch merge proposal emails not respect team contact addresses?
[05:34] <jml> wgrant: what do you mean by "respect"?
[05:34] <wgrant> jml: They seem to spam all members regardless of the team contact address.
[05:35] <jml> wgrant: that's a bug.
[05:35] <wgrant> Oh. I see.
[05:35] <wgrant> Maybe it does.
[05:35] <wgrant> But this team has an email address, but it's somehow not set as the contact address.
[05:36] <jml> oh ok.
[05:36] <jml> wgrant: which team?
[05:36] <wgrant> ubuntu-dev
[05:37] <wgrant> What a confusing UI.
[05:39] <jml> wgrant: please file a bug if you find a bit of the UI confusing
[05:39] <jml> wgrant: especially if you can provide a suggestion for making it less so.
[05:39] <wgrant> 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] <jml> \sh: I'm not 100% sure it has been released yet.
[07:26]  * \sh needs to talk to gmb then ;) 
[10:22] <sabdfl> gmb, \sh: that lib should be available for anyone who wants to prototype and play
[10:22] <wgrant> Isn't it meant to be released to beta testers some time this week?
[10:23] <wgrant> (hi sabdfl)
[10:23] <sabdfl> hi
[10:23] <sabdfl> afaic it was supposed to be released a month ago, when the initial api pieces landed, though it's no doubt rough
[10:24] <wgrant> Rough is much better than private in this case, IMO.
[10:24] <Hobbsee> does it work, though?
[10:24] <wgrant> 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] <gmb> \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] <sabdfl> barry is the person who was responsible for the library, iirc
[11:36] <aa_> hi, is it possible to send copy of all announcements to an email address?
[11:38] <intellectronica> aa_: not in launchpad itself, but i'm sure there are rss to email gateways out there you could use
[11:39] <aa_> intellectronica: great, just saw I can get a feed of them
[11:42] <aa_> intellectronica: don''t suppose you know of any such services?
[11:47] <intellectronica> aa_: http://www.google.com/search?q=email+rss
[12:00] <aa_> ok thanks
[13:00] <mpt> Gooooooooooooooooood afternoon Launchpadders!
[13:02] <mpt> wgrant, unfortunately there isn't really a "that part of the code" that grep could be pointed at
[13:03] <wgrant> 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] <mpt> hm, only 70 occurrences
[13:04] <wgrant> Oh dear.
[13:04] <mpt> shouldn't be that difficult :-)
[15:08] <Annabel> hi all,
[15:08] <Annabel> 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] <Annabel> I have sought on the documentation wiki, but did not found the answer
[15:08] <Annabel> any help?
[15:08] <Annabel> or suggestions?
[15:32] <mrevell> Hey jelmer, would bzr-svn help Annabel ^^^^
[15:39] <jelmer> hi Matthew, Annabel
[15:40] <jelmer> Subversion client access to bzr branches isn't supported yet by bzr-svn, although there has been work on it
[15:40] <Annabel> Hi jelmer and mrevell
[15:40] <Annabel> ah OK
[15:40] <mrevell> thanks jelmerl
[15:41] <Annabel> I guess the same is true for client CVS access ...
[15:41] <jelmer> you should be able to keep a copy of the bzr branch in Subversion though (instead of direct access)
[15:43] <jelmer> Annabel, yeah, although it's harder to maintain a copy of the bzr branch in CVS
[15:43] <jelmer> for Subversion, keeping a copy should be as simple as "bzr push <svn-url>"
[15:43] <Annabel> it seems to be some kind of a workaround is not it? Can the SVNserver be hosted on the launchpad server or is it restricted to a personal server
[15:43] <Annabel> OK
[15:44] <jelmer> Launchpad doesn't provide Subversion hosting at the moment
[15:46] <Annabel> OK. Thanks a lot for your help, Jelner!
[15:46]  * Annabel needs to leave now
[15:46] <Annabel> CU
[16:40] <forrest> Hi all, I'm a freshman who never developed any linux programs before
[16:40] <forrest> Is there anyone who can lead me into the world of linux development?
[16:47] <kiko> forrest, hmmm, there's a lot of stuff out there on the web. what sort of app do you want to build?
[16:48] <forrest> I'm always thinking that start from the very beginning
[16:48] <forrest> but now I have already got some expirence on embeded system developing
[16:51] <forrest> Could you give me some advice of where to start?
[17:05] <mpt> mrevell, sorry for reporting a duplicate of bug 253274 -- I thought "nobody will have reported this already", so I didn't bother searching :-)
[17:06] <mrevell> heh, no worries mpt. You've seen that I've reported a few dupes in my time :)
[18:34] <sabdfl> everybody feeling the 2.0 love?
[18:37] <sidnei> hi kiko
[18:38] <ScottK> sabdfl: Unfortunately yes.
[18:41] <kiko> sidnei!
[18:41] <kiko> ScottK, couldn't hope to have anything more positive from you :)
[18:42] <sidnei> kiko: you've been hard to find lately :)
[18:42]  * cody-somerville is experiencing revision 6773 love.
[18:42] <ScottK> kiko: I don't like the new interface and I don't see any point in being shy about it.
[18:44] <cody-somerville> I'm starting to like the new interface.
[18:44] <sidnei> im wondering if there's any work planned on improving the experience on uploading releases to launchpad
[18:44] <kiko> sidnei, uploading release tarballs, you mean?
[18:44] <sidnei> kiko: tarballs and installers yes
[18:44] <sidnei> kiko: i frequently have to upload the plone windows installer which is 30mb and fails 3 out of 4 times
[18:45] <kiko> sidnei, because the upload fails?
[18:45] <sidnei> kiko: yes, the upload fails
[18:45] <kiko> that's disturbing
[18:46] <sidnei> kiko: i get a 'please try again' screen without any specifics. i suspect it's a timeout
[18:48] <sidnei> makes me kinda miss the ftp-based upload process from sourceforge. cumbersome but effective.
[18:49] <kiko> sidnei, I'll look into this. I wasn't aware this was such a problem -- and the fact that I'm not aware is really disturbing
[18:49]  * kiko winks ata cody-somerville
[18:53] <sidnei> kiko: i've opened a feature request some time ago, bug #174798, that would be ideal to me
[18:55] <sidnei> i see from bug #32772 that this is unlikely to get accepted though
[19:52] <sidnei> kiko: ?
[20:31] <kiko> siretart, yo
[20:31] <kiko> sidnei, sorry, was on the phone
[20:32] <sidnei> kiko: man, im almost giving up here. on the 5th try, each takes about 40 minutes :(
[20:33] <kiko> sidnei, this really bothers me, and Rinchen is going to look into this with the QA team -- I see the security implication of it but if all we're doing is putting stuff in the librarian.. people can upload anything to the librarian today.
[20:34] <kiko> sidnei, I think I'm going to put a feature request up for sftp:// uploads
[20:34] <sidnei> kiko: please, anything would be an improvement
[20:36] <kiko> sidnei, I wonder if I can upload it more easily from here. want me to try?
[20:37] <sidnei> kiko: wouldn't hurt i guess, but i've tried uploading from a box in houston and haven't had much luck
[20:37] <kiko> okay
[20:38] <kiko> sidnei, we're adding an item to tomorrow's meeting to talk this over
[20:39] <sidnei> kiko: i really appreciate that. thanks!
[20:39] <kiko> thanks for the feedback, I hate it when we don't know what's not working :-(
[21:02] <kiko> siretart, yo!
[21:14] <sidnei> kiko: if you still want to give it a try, i can give you a url to fetch the file from
[21:15] <kiko> sidnei, if you've tried from houston, I'm not sure it will be better from california :-(
[21:15] <kiko> sidnei, I was considering uploading from the DC itself
[21:15] <kiko> but I wonder if I can upload using w3m
[21:15] <mtaylor> kiko: who should I annoy about spec dependancies?
[21:16] <kiko> mtaylor, me, I guess :)
[21:16] <mtaylor> kiko: I tried to add a depend to a spec, and I got a wonderfully informative "Constraint not satisfied"
[21:17] <kiko> mtaylor, heh. is the spec on a different project?
[21:17] <mtaylor> kiko: nope.
[21:17] <mtaylor> kiko: I tried to add https://blueprints.edge.launchpad.net/drizzle/+spec/remove-include-dir as a depend of https://blueprints.edge.launchpad.net/drizzle/+spec/gettextize
[21:17] <kiko> hmm.
[21:18] <sidnei> kiko: if you cant upload with w3m that's a serious bug, ha! :)
[21:19] <ScottK> Currently you can't even browse Launchpad with it, so probably not.
[21:20] <LaserJock> ScottK: you can browse, you just can't login, correct?
[21:20] <mpt> because w3m follows the de-jure rules for cookies rather than the de-facto rules, iirc
[21:20] <ScottK> IIRC it was SSL certs.
[21:21] <ScottK> Maybe it was cookies.
[21:21] <sidnei> i bet one can handcraft a curl command line to upload
[21:21] <mpt> bug 59510 is the only one we have about w3m
[21:21] <kiko> it's a problem with cookie RFC violations? gar.
[21:22] <matsubara> sidnei: what's file URL?
[21:22] <sidnei> matsubara: https://houston.enfoldsystems.com/files/sidnei/Plone-3.1.4-buildout.exe
[21:22] <matsubara> sidnei: and where were you trying to upload it to?
[21:22] <sidnei> and add .asc to that too
[21:22] <sidnei> uploading into https://edge.launchpad.net/plone/3.1/3.1.4/+adddownloadfile
[21:25] <sidnei> does lp support http-basic auth too or only cookie?
[21:25] <kiko> sidnei, it used to support basic-auth, hmm
[21:27] <sidnei> yeah, seems to work
[21:40] <kiko> mtaylor, I'm a bit stumped.
[21:40] <mtaylor> kiko: ok
[21:40] <mtaylor> kiko: I guess maybe I just shouldn't associate those two... perhaps lp is starting to have emergent intelligence!
[21:41] <sidnei> OMG
[21:41] <kiko> mtaylor, I've been looking at the schema and code and..
[21:41] <sidnei> kiko: i was able to upload it with curl from a different host
[21:41] <sidnei> kiko: this one has slightly better uplink :)
[21:41] <kiko> heh
[21:41] <kiko> good
[21:42] <sidnei> kiko: did you open a bug about it?
[21:42] <kiko> sidnei, no, we're still talking about it
[21:42] <kiko> but it's on the radar
[21:42] <sidnei> kiko: ok
[21:43] <sidnei> kiko: fwiw, http://paste.lisp.org/display/64450
[21:53] <kiko> ScottK, https://bugs.edge.launchpad.net/launchpad/+bug/59510
[21:54] <kiko> sidnei, thanks! that is useful.
[21:54] <sidnei> kiko: np. gotta go, bye!
[22:07] <kiko> siretart, ping v3
[22:08] <siretart> kiko: hey there!
[22:08] <siretart> v3?
[22:08] <kiko> siretart!!
[22:08] <kiko> siretart, it's great to hear from you. do you have time tomorrow for a phone call?
[22:09] <siretart> what time do you think of?
[22:09] <kiko> siretart, your afternoon more or less
[22:09] <siretart> that should be doable, but let's please syncronize that on IRC
[22:09] <kiko> siretart, will do. I am hoping to get heno and colin in on that same call
[22:09] <siretart> allright!
[22:10] <kiko> cool
[22:10] <kiko> siretart, I'll mail you something now as a preamble
[22:10] <siretart> sounds cool! great!
[22:11] <kiko> mtaylor, oho, it's a bug :)
 kiko: you can't depend on an implemented spec, that's silly, but that's how it works
[22:11] <kiko> mtaylor, isn't that just daft!
[22:11] <LaserJock> siretart: hiya
[22:11] <mtaylor> kiko: that is, in fact, stupid
[22:11] <kiko> mtaylor, https://bugs.edge.launchpad.net/blueprint/+bug/140533
[22:11] <kiko> GAR
[22:11] <mtaylor> why not?
[22:11] <kiko> mtaylor, easy to work around though...
[22:11] <mtaylor> sure
[22:12] <kiko> well it says bug 140533 there for a reason :)
[22:19] <ScottK> kiko: Right.  That's the one.
[22:19] <kiko> ScottK, read my comments there
[22:19] <kiko> I think it's unlikely this is a bug in launchpad
[22:19] <kiko> those cookies are explicitly allowed in the netscape spec
[22:36] <ScottK> Of course RFC 2119 is a recent spec so it's unlikely you'd be in a position to support it.
[22:41] <kiko> mtaylor, I'm fixing the bug fwiw. should be on edge in 2 days
[22:42] <mtaylor> kiko: you rule!
[22:44] <kiko> mtaylor, some people say that too literally true!
[22:45] <mtaylor> :)
[23:04] <kiko> ScottK, the issue is more that that spec seems to be overly restrictive.
[23:06] <ScottK> Someone should take that up with the IETF.
[23:58] <kiko> ScottK, you didn't get my point I guess