[00:40] <tc-rucho> hello
[00:40] <tc-rucho> who should I talk to for a super-project name in launchpad?
[00:45] <thumper> tc-rucho: an admin, ask a question on the launchpad project
[01:52] <tc-rucho> what's the per-project available disk storage at launchpad?
[01:53] <persia> tc-rucho, While I don't have the answer to the ultimate question, I do know that you'll want to phrase it more specifically.  At least branches, bugs, translations, answers, and possibly more don't count towards any quota.
[01:55] <tc-rucho> persia: but still, space is not unlimited. Google gives 1GiB for mercurial repository. I was curious about launchpad's
[01:55] <spm> tc-rucho: additional to persia. I suspect you mean PPA's? the default limit is 1Gb. but that can be updated where necessary. We have no limit on bzr branches atm.
[01:55] <SamB> tc-rucho: you mean there's a limit ?
[01:55] <tc-rucho> spm: I see, well, that's good
[01:56] <tc-rucho> SamB: it is logic to think there is one, but since I didn't find it...
[01:57] <persia> spm, I know about the PPA limit.  Is there also a limit to release downloads?
[01:58] <spm> persia: not sure what you mean? as in the diff between PPA's and release downloads?
[01:58] <spm> oh. hang on. brain kicked in.
[01:58] <spm> not that I'm aware of no. The only limit I know of is with the PPA's.
[02:00] <persia> spm: heh.  Right.  Thanks.
[02:33] <nhandler> Did Launchpad recently speed up how often it processes PPA uploads? I've noticed a significant increase in speed between the moment I upload the package and the moment I get the email.
[02:34] <kklimonda> If I want to keep bzr branch of package I'm maintaining in LP I have to register project for this package?
[02:35] <persia> kklimonda, There's a special +junk project you can use while you're initially playing about, but if you want to share branches and take full advantage, yes.
[02:36] <kklimonda> persia: i see, I was wondering what this junk is for :)
[02:37] <persia> I'm not sure that's what it's for, in any sense, but you can use it that way.
[02:37] <thumper> kklimonda: there are package branches
[02:38] <thumper> kklimonda: so you don't need to register a project
[02:38] <thumper> kklimonda: which package?
[02:38] <kklimonda> thumper: crawl
[02:38] <thumper> kklimonda: you should be able to push to something like lp:~your-id/ubuntu/karmic/crawl/some-branch-name
[02:39] <thumper> +junk is for stuff that isn't really a project
[02:39] <persia> thumper, Does that work cleanly already?
[02:39] <thumper> persia: does what work?
[02:39] <thumper> persia: package branches?
[02:39] <thumper> yes
[02:39] <persia> package branches at code.launchpad.net
[02:39] <persia> Ah, cool.
[02:40] <thumper> persia: you have codebrowse, code reviews, email, push pull the works
[02:40] <jml> "the works" might be a little too extreme :)
[02:40] <thumper> some listing pages are still being worked on
[02:40] <thumper> :)
[02:40] <thumper> for some definition of "the works"
[02:40] <jml> https://bugs.edge.launchpad.net/launchpad-code/+bugs?field.tag=package-branches provides a pretty good working definition :)
[02:41]  * thumper goes back to emptying his inbox
[02:41] <kklimonda> thumper: lool.. come on, now I have to clean up my monitor..  ;)
[02:41] <persia> The two things that interested me are 1) being able to discover branches for packages with the UI, and 2) imports from uploads.
[02:41]  * persia looks at the bug list to see if those are part of the current "works"
[02:42] <jml> persia: imports from uploads are being tracked separately. james_w will be pushing up imports starting this week.
[02:43] <persia> And the discoverability seems to be covered by a bunch of bugs to be resolved soon.
[02:50] <jml> yeah.
[05:15] <MTecknology> What's going on w/ lp.net
[05:15] <MTecknology> pages aren't loading
[05:15] <MTecknology> correctly
[05:15] <MTecknology> no images or styles are being applied
[05:16] <mwhudson> probably the edge rollout
[05:16] <mwhudson> try shift-reload
[05:17] <MTecknology> oh
[05:17] <MTecknology> that cranked out finally :D
[05:18]  * MTecknology is excited
[05:18] <spm> MTecknology: happens this time of day atm. fwiw.
[05:18] <spm> about 17mins ago was kickoff for the auto edge update
[05:19] <MTecknology> oh, it's not a really big update?
[05:21] <spm> Tue Jun 2 05:00:07 BST 2009 About to update edge from 8487 to 8495 <== big enough given it's only Tues morning :-)
[05:21]  * MTecknology is too tired :P
[06:07] <ovnicraft> hi folks, how i can add a user to my project?
[06:07] <ovnicraft> i need a team for that?
[06:08] <persia> ovnicraft, Projects don't have direct association with people.
[06:08] <persia> A team may have a branch or a PPA.
[06:08] <ovnicraft> i created a project and i want add my friend
[06:08] <persia> Some projects do it this way.  Some just have lots of people submit branches.
[06:09] <ovnicraft> persia, done thx
[06:10] <lifeless> something is really disconnected that people thing of /projects/ as having defined people
[06:12] <persia> lifeless, Well, outside of code, projects typically do consist of people.  By "Project" we tend to mean something that might map to a barn-raising, but there are many things out there that have persistence (e.g. A project to improve the city centre)
[06:15] <lifeless> persia: This is true. But we're trying to gather the emergent aspect in lp - folk that improve the city centre should be listed, rather than folk that say 'I will improve...'
[06:16] <persia> I know this, and you know this, but this is different than other models.  I regularly encounter people who wish to become Ubuntu Members or Ubuntu Developers because they believe this is a required step to be permitted to contribute.
[06:16] <lifeless> yes
[06:16] <lifeless> but this is a core part of open source culture
[06:17] <persia> Yes.
[06:17] <lifeless> one *I* think is a key part of the success of the 'model'.... so how do we teach other people about this
[06:17] <persia> But I don't think it's fair to expect that meme to be intuitive as it scales to millions of people.  We need better documentation.
[06:18] <lifeless> I'm not sure that its intuitive at all
[06:18] <persia> Perhaps parables.
[06:18] <lifeless> be interesting to dig into its origins some time
[06:19] <persia> A set of fairly short stories that demonstrate rather than explaining, and are interesting enough in their own right to spread.
[06:19] <lifeless> that would be an interesting experiment
[06:20] <persia> To me, the origins come from volunteerism and close-knit communities.  The barn-raising is a handy example.  Everyone needs a barn, but they are hard to build by oneself.  Having a hundred people spend a weekend gets it done.
[06:20] <persia> Of course, that doesn't work well if there are cities, etc.
[06:22] <persia> Because the hundred people can't expect to get their own barn next time.  Of course, with software, replication cost is very low, which makes it easier to give everyone a barn, but unless people have experience with this sort of exchange, it may be new to them.
[06:22] <lifeless> people sending bug fixes in by tape to folk they have never met doesn't fit that model that closely
[06:23] <persia> I suppose.  I'd be in a better position to argue my case if I'd attended more than 3 barn-raisings, but I will say that I often didn't know the folk I met at them when I arrived.
[06:23] <persia> But I would know the hosts, which makes a difference.
[06:23] <lifeless> I think the economics of it are very similar
[06:24] <lifeless> mmm, or arguably similar
[06:25] <persia> It's a bit of a stretch.  The whole rationale for a barn-raising is that barns are expensive.  With open source, we make software cheap, which is different.
[06:25] <lifeless> software is horrendously expensive to produce
[06:25] <lifeless> cheap to replicate
[06:26] <lifeless> even small projects get price tags similar to barns quite quickly, if you trust sloccount
[06:27] <persia> Good point.  It's probably the production aspect that is interesting.  The low replication cost would map to the community trust that ensures each family gets a barn (well, excepting the librarian, the storekeeper, the printer, the blacksmith, etc.)
[06:28] <jmarsden> Is the "emergent" model really the primary one in FOSS software development?  The commonly-made distinction between those with commit priviledges to the project source tree, and those who send in patches (or their own branches which someone with privs can merge), is very much part of the open source culture, is present on LP ... and doesn't really fit this model, does it?
[06:29] <persia> jmarsden, Well, with DVCS, the definition of "project source tree" becomes slightly less important.
[06:30] <jmarsden> Only sort of... how does LP capture the fact that someone emailed 57 patches to the project team, but none were accepted?   Even if they created 57 private bzr branches...
[06:31] <jmarsden> When the original questioner above asked about "adding his friend", I suspect he intended to grant his friend some kind of "commit bit" ... right?
[06:31] <lifeless> jmarsden: the gatekeeper aspect is odd :)
[06:31] <persia> Well, private branches tend to be discouraged.  In the case of public branches, I believe it tracks that the branches exist, rather than that they were merged into some other branch.
[06:31] <lifeless> jmarsden: we don't know what the question asker was asking
[06:32] <lifeless> originally you *had* to send code to the author as there was a) no networking and b) no mesh networking
[06:32] <jmarsden> Argh, he's left already... oh well.
[06:33] <lifeless> later CVS/SVN provided an incentive to send patches straight in because there was still no robust mesh networking facilities
[06:33] <lifeless> but since dvcs meshing has become more feasible, and with the uptake of broadly available dvcs its becoming more a social choice rather than a technical imperative
[06:34] <jmarsden> lifeless: Yes, but consider the BSD world where there is a core team with commit privs.  Consider the SF model where you join a project and then are granted a subset of privs within that project... even projects that have used DVCS for some time still have gatekeepers and a "main" branch... consider the Linux kernel as an example...
[06:34] <persia> jmarsden, Right.  LP ignores all that, and encourages mesh working.
[06:34] <lifeless> jmarsden: and nearly universally one *earns* commit rights and gatekeeper privileges by *doing*
[06:34] <persia> So, if I trust you, I might merge your changes to the kernel, rather than waiting on some arbitrary gatekeeper.
[06:35] <lifeless> jmarsden: e.g. the linux kernel, folk become a gatekeeper by maintaining a tree with patches for the area/topic they consider specially important
[06:35] <jmarsden> Hmmm.  Lp still lets team members with admin privs decide who can commit to each branch, and designate one branch as "the" development branch, ...
[06:36] <jmarsden> I'm not sure things are nearly as egalitarian as your model seems to imply.
[06:36] <persia> jmarsden, No.  LP only lets people or teams commit to branches owned by those people or teams directly.  It's only if one has a special "committers" team that this is directly tied to a specific branch.
[06:37] <persia> The designation of the "official" branch is mostly convenience for bzr branch lp:foo, but I know that I, at least, usually pull or merge from branches other than trunk that more closely align with what I'm doing.
[06:41] <jmarsden> That's fine and useful for the personal use of a knowledgeable developer.  But at some point in the process, only one branch with be uploaded into Debian or Ubuntu... and rightly so, there'd be user confusion if Ubuntu includes 8 different versions of Evolution, 12 of Thunderbird, and 15 of OpenOffice or whatever... if you want your code in the released distribution, you need to get it into whatever branch that will be.
[06:41] <jmarsden>  As far as I know, anyway.
[06:42] <lifeless> jmarsden: welcome to PPA's
[06:43] <persia> Hrm.  I suppose that at some point, one could abolish the concept of "trunk", and have that be emergent based on the branch most likely to be merged into other branches.
[06:44] <persia> And one could abolish the idea of a true distribution, and instead construct one from a set of PPAs that one trusts.
[06:44] <jmarsden> Hmmm.  I am being told by folks mentoring me on my way to MOTU-ness that I need to get my stuff out of my PPA and into Debian experimental or unstable... :)
[06:45] <lifeless> jmarsden: you do, because by doing that you make it more easily accessible to people
[06:45] <persia> jmarsden, Well, that's about a team.  In order to be MOTU, you need to be perceived as a peer by MOTU.  This is best done by doing what MOTU do.
[06:45] <lifeless> but doing so is an example of your getting out and doing; which is precisely the emergent thing we're talking about :)
[06:46] <jmarsden> I'm not averse to getting out there, at all... but that makes the PPA-as-distro-equivalent seem... not yet a reality! I think that yes, in theory one could construct a less-gated approach, but I think the reality in the open source world remains one of "gatekept" codebases.
[06:47] <lifeless> I sense some conflation
[06:48] <persia> Even if we say that there are master codebases that are gatekept, most of those will permit anyone who actively contributes to participate in the gatekeeping.
[06:48] <lifeless> gatekeeping is fine; its a quality metric, and for a given branch of a project there will naturally be some gatekeeping policy the branch owner[s] enforce
[06:48] <persia> The few exceptions tend to be forked, for better or worse (e.g. glibc vs. eglibc)
[06:48] <lifeless> the distinction is project [many contributors, those that step up are visible] and branch [typically small number of direct committers]
[06:48] <persia> (or, more famously, emacs vs. xemacs)
[06:50] <spm> trust. do "we" trust "you" to hold dear our values as per this code/project/etc.
[06:54] <jmarsden> Sure.  And that means there will always be a "we" and a "you", and a way for an individual to become one of the "we" (to become a gatekeeper, perhaps).  But that's not really all that 'emergent', that's a clear distinction between two different classes of contributor, isn't it?  The "do you have a commit bit or not" distinction is in some sense quite hard and quite binary.  Which is fine... but I'm not sure it fits the "
[06:54] <jmarsden> just sort of join in and become a part of things by doing" model terribly well.
[06:54] <persia> spm, The trick is finding a way to determine which is the trusted codebase without asking people.  I don't think we can do that.  It also impinges on concepts of identity (I own this project vs. I contribute to this project)
[06:55] <persia> jmarsden, While I agree the "do you have the commit bit" is binary, I'm not sure that it's important if there's no specific "best" branch.
[06:56] <jmarsden> Agreed... but if one considers acceptance into a distribution as a common goal for software projects, then there *is* such a "best" branch... the one that will be uploaded into the distribution.
[06:56] <spm> +1
[06:56] <lifeless> which, for debian/ubuntu/redhat is rarely the upstream :)
[06:57] <persia> Well, I think it's rare that any branch is directly uploaded.  Usually it's an amalgamate branch constructed of merges that match the best set of code in the mind of the person uploading.
[06:57] <lifeless> persia: native
[06:58] <spm> hmmm. upstream + patches. pretty close to upstream. personally I monitor the distros and integrate their patches back. begs the question why they don't send them on but....
[06:59] <lifeless> spm: case closed :P
[06:59] <persia> spm, Well, that depends on the complexity of the gate.  In your case, you seem to have more of a welcome ramp, which makes the argument moot.  Where there is a stronger gate, we work around that.
[06:59] <persia> And in those cases, it may be not very close to upstream at all (e.g. OO.o)
[06:59] <spm> aye
[07:01] <spm> perhaps it's the same problem in both directions. eg insane upstreams that make distros work harder; and upstreams that believe distro XYZ is insane. two sides of the same coin.
[07:02] <spm> personally I prefer the more... "insane" distros - they stress the code in weirder ways. freebsd isims vs mandrivia ism's. by comparison redhat/suse/ubuntu are trivial.
[07:02] <persia> Indeed.  Or just sane people failing to effectively communicate.
[07:02] <spm> ha!
[07:07] <jmarsden> Speaking of getting stuff into Debian... what is the usual delay time between getting the "accepted" email back, and the package showing up on the debian mirrors?  I had something accepted into Debian unstable earlier today...
[07:09] <persia> jmarsden, 15 minutes to 6 hours + mirror sync delay (2 minutes to 1 week, depending)
[07:09] <persia> Plus, you often have to wait for builds, etc.
[07:11] <jmarsden> Thanks... ah, I just rechecked and it is there now :)
[07:13] <jmarsden> Will it now auto-sync into Karmic, or do I need to create a sync request bug?
[07:14] <jmarsden> (I should be asking this in #ubuntu-motu I suppose)
[07:14] <persia> jmarsden, You want to be asking these questions on #ubuntu-motu (and I'll happily answer them there) :)
[07:14] <persia> Yes :)
[11:59] <_simono_> hi, how long does it take until LP has scanned a new branch?
[12:01] <soren> It's usually a matter of minutes of me.
[12:02] <soren> Err...
[12:02] <soren> *for* me.
[12:03] <_simono_> soren: ok, i deleted the branch and reuploaded it, maybe that works
[12:04] <hyperair> hello. who can i talk to about my @ubuntu.com address alias issues? (it doesn't work)
[12:04] <lifeless> _simono_: that will cause it to start over
[12:05] <lifeless> _simono_: if its a big project scanning can take a few minutes; in future though please ask a question on answers.launchpad.net/launchpad-code, or ask the help contact listed in this channels' topic
[12:06] <_simono_> lifeless: ok, I thought this channel is for questions
[12:06] <lifeless> it is
[12:06] <lifeless> but if there is noone here at a given time there is a web interface too
[12:07] <lifeless> what I was specificially suggesting though was to avoid giving the system *more* work to do when its a little slow ;)
[12:11] <kiko> _simono_, what branch is that, btw? -- and don't mind lifeless, he's a bit grumpy this late ;)
[12:12] <lifeless> sorry if I was grumpy ;). Its the sinus headache thats doing it
[12:14] <_simono_> lifeless: No you weren't :)
[12:14] <kiko> we had an issue with the SS yesterday
[12:14] <kiko> wanted to make sure it wasn't so any longer
[12:14] <_simono_> kiko: https://code.edge.launchpad.net/~simono/byobu/fix-typo it's just a tiny commit
[12:15] <kiko> let me check
[12:36] <wgrant> Will CHR be starting again soon? There's been none for like 2.5 weeks.
[12:37] <oldman_> is anyone free to do a ~vcs-imports import review for me?
[12:40] <kiko> oldman_, sure
[12:40] <kiko> wgrant, there have been CHRs for most of the last 1.5 weeks
[12:40] <kiko> wgrant, yesterday, for instance, it was abentley
[12:41] <abentley> kiko: I was OCR, not CHR, yesterday.
[12:43] <kiko> you said CHR, but that's fine, somebody else was :)
[12:44] <wgrant> kiko: Last topic change involving a CHR person was 2009/05/15, AFAICS... or does it not go in the topic now?
[12:44] <kiko> sometimes people forget it
[12:44] <kiko> but at any rates, around allhands it definitely goes a bit crazy
[12:44] <wgrant> Of course.
[12:45] <kiko> wgrant, why didn't wee see you at UDS this time?
[12:45] <wgrant> kiko: I'm terribly burnt out and unable to usefully contribute to Ubuntu at the moment.
[12:45] <kiko> wgrant, work or what?
[12:46] <wgrant> Burnout + studying at uni + working at uni.
[12:47] <noodles775> wgrant: you're still contributing lots by watching and commenting on bugs :)
[12:47] <wgrant> noodles775: On Launchpad, perhaps.
[12:48] <noodles775> wgrant: Yep. BTW, have you seen jono's burnout talk in the past? if not, definitely get the slides/video from UDS when available...
[12:48] <noodles775> lots of useful stuff for dealing with burnout etc.
[12:49] <wgrant> noodles775: Thanks. I shall grab that when I find it...
[12:54] <kirkland> howdy good launchpaders ...  can someone approve the mailing list for ~byobu-users ?
[12:59] <_simono_> kiko: could you find out something about the scanner?
[13:00] <kiko> _simono_, it looks like it's busted -- I will need to get somebody to look at it
[13:08] <aleksander_m> hi all. when's launchpad going free software?
[13:08] <aleksander_m> I read some time ago that launchpad source would be published sometime this year, right?
[13:09] <bigjools> kirkland: done
[13:10] <kirkland> bigjools: rock on :-)  thanks!
[13:10]  * kirkland likes having faces to put to some of these launchpad nicks :-)
[13:10] <bigjools> kirkland: yes :)
[13:12] <kiko> aleksander_m, by july.
[13:12] <kiko> aleksander_m, there's an open sourcing faq on help.launchpad.net
[13:12] <kiko> (or is it on dev?)
[13:12] <aleksander_m> oh, nice, thanks
[13:12] <wgrant> dev.launchpad.net/OpenSourcing
[13:14] <bnikolic> Hello, was wondering about the import https://code.launchpad.net/~vcs-imports/gpe/trunk, seems to be pending review for quite a while now
[15:37] <kiko__> so
[15:37] <kiko__> the branch scanner did a nasty this morning
[15:37] <kiko__> jml and herb worked on getting it unstuck and it should be all back to normal now
[15:37] <kiko__> sorry to people that were impacted by this!
[15:51] <pan1nx> is the launchpad's PPA "Architecture aware". I mean, if I build a package for ARM, will it only build it in a ARM builder machine?
[15:52] <bigjools> pan1nx: we don't support ARM in PPAs (yet), or was that a more general question?
[15:59] <zoobab01> is Launchpad open source now?
[15:59] <zoobab01> where can I download the code?
[16:01] <persia> pan1nx, Aside from the current lack of PPA ARM builders, it's probably best practice to try to build things for Architecture: any or Architecture: all, rather than for specific architectures (unless it is known a priori that it's not possible to build on a specific architecture).
[16:02] <bigjools> pan1nx: LP will honour whatever Architecture: you specify when building in a PPA
[16:03] <bigjools> zoobab01: it's not open until late next month
[16:10] <kirkland> how long does it take a git import to happen in launchpad?
[16:10] <kirkland> https://code.edge.launchpad.net/~vcs-imports/qemu/qemu-kvm
[16:10] <kirkland> "pending review"
[16:12] <Ursinha> kirkland: I'm reviewing the imports today, as the person in charge
[16:12] <Ursinha> we have a backlog because of AllHands/UDS
[16:12] <kirkland> Ursinha: cool, thanks, man
[16:13] <Ursinha> lol, np :)
[16:21] <kirkland> Ursinha: whoops, sorry, dudette :-)
[16:23] <Ursinha> :P
[16:38] <bialix> hi, I have a feature request. Is it possible to have some checkbox or other settings to hide Fix Released bugs from Branch page. E.g. https://code.launchpad.net/~qbzr-dev/qbzr/trunk <-- there is too much bugs listed. Will be nice to hide some of them somehow?
[17:18] <doko> please could somebody answer question #72855?
[17:57]  * Ursinha looks at question 72855
[18:03] <kklimonda> http://launchpadlibrarian.net/27417827/kUum6p8vWSw2VbfV1vo7CfKfXVx.txt - I guess that's because .changes contain .orig.tar.gz which is already uploaded.. but shouldn't it die more gracefully? ;)
[18:04] <kklimonda> oh, wait - that's because I have reuploaded package..
[18:04] <kklimonda> (just saw version..) sigh - still this error is really weird :)
[18:29] <cprov> kklimonda: it should definitely die more gracefully, can you reproduce the issue ?
[18:29] <cprov> kklimonda: and possibly file a bug on soyuz so we can get it fixed soon
[18:29]  * cprov is embarrassed by that
[18:30] <kklimonda> cprov: I think it happens every time I upload new version of package when previous one is building.
[18:30] <kklimonda> I remember seeing it once before
[18:31] <cprov> kklimonda: uhm, isn't it a failed-to-upload build error ?
[18:31] <kklimonda> no
[18:32] <kklimonda> cprov: wait, i'll give you a build log
[18:33] <cprov> kklimonda: I think you misunderstood me then, it's has to be a failed-to-upload build error if you are going to show me a successfully buildlog.
[18:33] <kklimonda> :)
[18:33] <kklimonda> yeah, i probably did :)
[18:34] <cprov> kklimonda: by the time the binaries were built the source was not available in the archive because it was superseded by a new version
[18:34] <cprov> right ?
[18:35] <cprov> publishing too fast ...
[18:41] <mdke> is there a way to cleanly move a branch from one project to another in the UI, or is it necessary to push the branch to the new project and delete the branch on the original project?
[18:55] <intellectronica> mdke: you need to push it again, afaik. you can avoid making mistakes by setting a repository and setting the rules for public branches in your locations.conf, b.t.w. i never find myself thinking about where to push a branch. i just do `bzr push` and it goes to the correct place
[18:56] <mdke> intellectronica: thanks - it's not so much a mistake as a change of policy, in this particular case. I'll repush
[20:23] <mdke> what does it mean when pushing to Launchpad and you get the message "Using default stacking branch"?
[20:24] <beuno_> mdke, that it's not pushing all the history, instead, it's stacking on top of another branch
[20:24] <beuno_> so it transfers less data
[20:26] <mdke> beuno_: ok, kind of lik a shared repository?
[20:27] <beuno_> mdke, yeap, similar result
[20:27] <mdke> ok, cool - thanks
[20:27] <beuno> np
[21:23] <dajhorn> Should all PPAs be signed by Launchpad now?  I uploaded some PPA packages last week, but the Release.gpg file was not created.
[21:25] <beuno> dajhorn, they should, yes
[21:25] <beuno> maybe cprov knows
[21:25] <beuno> what's your PPA?
[21:26] <dajhorn> beuno: http://ppa.launchpad.net/dajhorn/ppa/ubuntu/dists/jaunty/
[21:27] <dajhorn> beuno: No Release.gpg for  1024R/1EE8660B is being published.
[21:27] <bigjools> there was a brief problem with the signing last week, file a Question on Soyuz and someone will fix it
[21:27] <dajhorn> bigjools: Will do.
[21:28] <bialix> can you direct me where is best place to send/file a feature request about hiding Fix Released bugs from Branch page?
[21:28] <bigjools> thanks, and sorry for the hassle
[21:33] <thumper> bialix: file a bug on launchpad-code
[21:35] <bialix> ah, jelmer already file such bug 291093
[21:36] <bialix> thx anyway
[21:44] <cprov> dajhorn: upload or copy something new to you ppa and it will trigger the signatures.
[21:45] <dajhorn> cprov: Just did a few minutes ago, and the Release.gpg has appeared.
[21:46] <dajhorn> (Thanks.)
[21:48] <cprov> dajhorn: np
[22:01] <tc-rucho> hi. Anyone here has used Google Code's mercurial hosting? what's your oppinion of it vs. launchpad's service?
[22:02] <tc-rucho> I'm... new to both... and would like to hear some opinion from some experienced user in any or preferably both
[23:41] <cody-somerville> wgrant, ping
[23:49] <Ampelbein> hi there. i want to assign a package to a bzr-branch of mine but can't find the appropriate edit-button to do so. i need a little help here. the branch i'm talking about is https://code.edge.launchpad.net/~amoog/+junk/gnome-doc-utils-devel
[23:50] <Ampelbein> to make it clearer, i want the +junk replaced to gnome-doc-utils.
[23:51] <thumper> Ampelbein: the simplest way is to push it to the project
[23:51] <thumper> we used to be able to reassign it to another project
[23:51] <thumper> but we are in a we bit of flux around package branches
[23:51] <thumper> so it is missing right now
[23:52] <Ampelbein> thumper: what do you mean by "push it to the project"? propose a merge?
[23:52] <thumper> Ampelbein: no, I mean `bzr push lp:~amoog/gnome-doc-utils/devel`
[23:52] <jml> Ampelbein: push it to Launchpad again, this time at ~amoog/ubuntu/karmic/gnome-doc-utils/devel or what have you.
[23:52] <thumper> from your local copy
[23:54] <Ampelbein> thumper, jml: oh, cool. i did not know you can do that, I always created the branch on the website and pushed there. thanks a lot!
[23:54] <jml> Ampelbein: np :)
[23:54] <thumper> Ampelbein: we have plans to have better help on that
[23:55] <Ampelbein> thumper: i followed https://wiki.ubuntu.com/DesktopTeam/Bzr - it mentions creating the branch before.
[23:56]  * thumper looks
[23:59] <thumper> Ampelbein: wiki updated