[00:35] <gregcoit> back to the beginning - is it common to have a trunk branch for devel and then "push" to another branch for stable?
[00:35] <gregcoit> or a branch called "trunk"
[00:35] <gregcoit> rather
[00:36] <gregcoit> what I'm tryiong to get to is: at least 2 branchs in a project - and each branch should have development and stable
[00:36] <gregcoit> so that one can remote bzr the stable to use or devel for development and testing
[00:37] <gregcoit> but I can't use "trunk" fpr development of both code projects
[00:37] <gregcoit> since their in the same "launchpad" project
[00:38] <gregcoit> er, s/their/they're/
=== nhandler_ is now known as nhandler
[00:43] <persia> gregcoit: Consider four branches: stable-release, stable-trunk, trunk, and experimental.
[00:43] <persia> gregcoit: You may be able to skip stable-release as a separate branch by using release tags in some way (I'm not actually sure, nor a bzr expert)
[00:44] <gregcoit> persia: 4 for each of the 2 code branches?
[00:44] <persia> No, four total, plus however many extras come from external contributors.
[00:44] <wgrant> Why do you want two branches each with development and stable branches?
[00:44] <wgrant> Normal practice is to have a trunk branch and nother one for each maintained release series.
[00:44] <gregcoit> our project has 2 parts drupal profile files and bcfg2 configuration files
[00:45] <wgrant> Ah.
[00:45] <gregcoit> yeah - it's making my head hurt
[00:45] <lifeless> persia: what is stable-trunk for ?
[00:45] <gregcoit> and the reason we want them in seperate branches is they live in different places on clients servers and we want them to be able to bzr update to get changes from us
[00:45] <persia> lifeless: To work around my lack of understanding of releases and tags :)
[00:45] <lifeless> persia: I still don't see the use case
[00:46] <lifeless> gregcoit: why not just have two lp projects?
[00:46] <lifeless> thing-drupal and thing-bcfg2
[00:46] <gregcoit> while development of drupal and bcfg2 is differnt, the releases are tied...
[00:46] <persia> lifeless: One may want to get the latest stable release as a bzr tree, rather than the current state of candidate patches for the next bugfix update release.
[00:47] <lifeless> persia: that would excuse stable-release. I asked about stable-trunk
[00:47] <lifeless> persia: (as for tags - 'bzr commit --tag foo' adds a tag at commit time; also 'bzr tag -r foo bar' adds a tag later)
[00:47] <persia> lifeless: stable-trunk is for the set of candidate patches for the next bugfix update release.
[00:48] <lifeless> persia: I don't understand that
[00:48] <lifeless> persia: I suspect you are thinking about this as a distro person not an upstream, but we're discussing upstream workflow
[00:48] <persia> lifeless: So, I release 1.1 and work starts on 1.2, but there are bugs in 1.1, so I'm preparing a 1.1.1, and want a branch for 1.1.1 stuff prior to 1.1.1 release.
[00:49] <lifeless> persia: there is no guarantee you won't need the 1.1.1 branch after you release 1.2
[00:49] <lifeless> persia: so calling it stable-trunk is both insufficient and confusing. Call it '1.1.1'
[00:49] <gregcoit> ok, can I make a project called thing, and then 2 more called thing-bcfg2 and thing-profiles and make them *part* of project thing?  And if so, can I list releases of thing-bcfg2 and thing-profiles in project thing?
[00:49] <lifeless> persia: or 1.1.dev
[00:50] <gregcoit> which is the main project?
[00:50] <lifeless> gregcoit: there are project groups; they need a help contact to create them
[00:50] <gregcoit> er, no ? on that last statement
[00:50] <lifeless> and yes, you can then make multiple projects part of the one group, and releases done in each sub ting show up on the group rss feed etc
[00:51] <lifeless> so you'd have a group 'thing', two projects 'thing-foo' and 'thing-bar'
[00:51] <gregcoit> oh, i make a group
[00:51] <gregcoit> I see
[00:51] <wgrant> Reading the earlier discussion (with differing release schedules), two projects in a project group seems like the way to go.
[00:51] <gregcoit> and teams can be part of the group?
[00:51] <lifeless> teams are orthogonal to all of this
[00:52] <gregcoit> gotcha
[00:52] <persia> lifeless: That's better nomenclature, yes.
[00:52] <lifeless> you can assign management teams to the group and they will flow down to the projects; or you can have completely separate teams. Whatever you want.
[00:53] <gregcoit> can groups be part of another group?
[00:53] <lifeless> persia: so, I would say - 'trunk', '$release-dev' as branches
[00:53] <wgrant> A project group cannot be part of another project group.
[00:53] <wgrant> A team can be a part of another team, though.
[00:53] <lifeless> with releases merged into trunk and their tags preserved
[00:54] <gregcoit> hmm, that's hard - we're a part of group drupal already
[00:55] <gregcoit> or rather group drupal-projects
[00:55] <lifeless> well, then you shouldn't have any issue.
[00:56] <lifeless> both your releases will show up in the drupal feed.
[00:56] <gregcoit> if I make 2 projects only, right?
[00:56] <lifeless> [meta] I would like project groups to be more like tags and less like containers.
[00:56] <persia> lifeless: Indeed, that's better.
[00:56] <lifeless> gregcoit: yes. Which seems to fit your dev process needs.
[00:56] <gregcoit> rather than try to make this work with just one project
[00:56] <wgrant> lifeless: Project groups need to die and be replaced with tags.
[00:57] <gregcoit> ok, i'll talk to the boss about 2 projects
[00:57] <gregcoit> thanks again guys for helping me think this through
[01:23] <Saviq> hi all, sorry for a stupid question... how do I link a bug on LP to an external bugzilla that is registered on LP?
=== jamalta-afk is now known as jamalta
[01:28] <lifeless> Saviq: 'affects product', paste the url in the field
[01:29] <Saviq> yeah, just found it
[01:29] <Saviq> thanks
=== nhandler_ is now known as nhandler
=== nhandler_ is now known as nhandler
[04:04] <keithy> I just did a commit to launchpad and it went into the wrong repository branch
[04:04] <poolie> ok
[04:04] <keithy> here is what launchpad says I should use to psuh
[04:04] <keithy> lp:~smalltalkers/cuis/class-comments
[04:05] <poolie> k
[04:05] <keithy> oh it did go to the right place... in that case
[04:05] <keithy> what does this mean
[04:05] <keithy> bzr push lp:~smalltalkers/cuis/class-comments --use-existing-dir
[04:05] <keithy> Using default stacking branch /~smalltalkers/cuis/docs at lp-64613584:///~smalltalkers/cuis
[04:05] <keithy> Created new stacked branch referring to /~smalltalkers/cuis/docs.
[04:06] <lifeless> keithy: it's a slightly nerdy message
[04:06] <lifeless> it means that a mini-repository has been created at lp:~smalltalkers/cuis/class-comments - so its a lot smaller and faster to push
[04:06] <lifeless> but if you wanted to back it up with (say) rsync, you'd need to also grab lp:/~smalltalkers/cuis as well
[04:07] <wgrant> Basically it means that the new branch is going to share the stacking branch's revisions, so you only have to upload the data that is specific to the new branch.
[04:07] <keithy> aarg
[04:07] <lifeless> keithy: it is a good thing
[04:07] <keithy> I only put docs there as aplaceholder to get rid of the banner asking for a trunk
[04:08] <lifeless> keithy: so you have the real deal ready now ?
[04:08] <keithy> since I dont have a single trunk
[04:08] <lifeless> keithy: if so, just bzr push --overwrite lp:cuis
[04:08] <wgrant> keithy: Why don't you have a single trunk?
[04:09] <keithy> when you nominate a repo for trunk, it doesnt show up in the list of branches any morre
[04:09] <wgrant> It does. It just shows up at the top with a shorter name (normally lp:<PROJECT>)
[04:09] <keithy> so I mad an inocuous dummy up just to get rid of the baneer
[04:10] <keithy> yes but if I named it in such a way as to declare its purpose
[04:10] <keithy> that name has gone
[04:10] <keithy> I am working in a smalltalk image
[04:10] <wgrant> Is there a single branch of cuis that is where the main development happens?
[04:10] <lifeless> keithy: a trunk is a social convention
[04:10] <wgrant> If not, why not?
[04:10] <keithy> and exporting slices of code into branches for others to import if they want to
[04:11] <lifeless> wgrant: he probably has 'micro projects'
[04:11] <keithy> wgrant no
[04:11] <keithy> lots of micro projects
[04:11] <lifeless> wgrant: to make up an lp term for it
[04:11] <keithy> and any branch is an optional build
[04:11] <wgrant> Why are they all in the one project, then?
[04:11] <lifeless> wgrant: orthogonal elements of a system, classes, traits, etc each of which is tiny and not a branch of the greater whole
[04:12] <keithy> well I doubt you want me to open 700 projects
[04:12] <lifeless> keithy: I don't think we'd care, actually.
[04:12] <keithy> and if I did, I couldnt see a listing of them all on one page
[04:12] <lifeless> if they were in a  project group you could, though it might blow sinzui's mind :)
[04:12] <keithy> 6 projects is enough to be going on with
[04:13] <lifeless> sure
[04:13] <lifeless> anyhow, for the record, 700 gardened projects would be noticed, but its not huge
[04:13] <keithy> cuis, and cuis-packages, pharo pharo-packages etc
[04:13] <lifeless> its certainly not that much data on disk, in and of itself - a few MB
[04:13] <keithy> I will leave importing squeaksource until tomorrow ;-)
[04:14] <keithy> lifeless: do you work at canonical?
[04:14] <lifeless> yes
[04:15] <keithy> ah ic
[04:23] <poolie> keithy: i think you should get the licence stuff sorted before you put a lot of time into this
[04:24] <poolie> clearly squeak is open source in spirit
[04:30] <swarna> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities/rocketfuel-setup is not opening
[04:32] <lifeless> swarna: #launchpad-dev please
=== mordred_ is now known as mtaylor
=== doctormo_ is now known as doctormo
[05:53] <keithy> poolie: I am using cuis rather than squeak, cut down less stuff MIT licence
[05:53] <keithy> the discussion about squeak is only because of the natural parallel, and I want to pull code out of it
=== mordred_ is now known as mtaylor
[06:56] <jussi01> morning all
[06:57] <wgrant> Evening jussi01.
[06:57] <jussi01> wgrant: just the man Im after...
[06:58] <wgrant> Are you here about the massive spam you probably got?
[06:58] <jussi01> wgrant: no, well, kinda
[06:58] <jussi01> Ive changed all the teams to self renew, is it possible to now send out an invite to renew?
[06:59] <wgrant> I suspect that another warning message will be sent out tomorrow saying that, but I'm not quite sure.
[07:00]  * wgrant tries.
[07:01] <wgrant> Yes, tomorrow everyone should get the same email as today, except it will tell them that they can renew it themselves.
[07:01] <wgrant> But most people will probably ignore it, since it's so similar.
[07:02] <wgrant> There is no other facility to send such a message, except for "Contact this team"
[07:02] <micahg> why are there builders idle when jobs are queued up?
[07:02] <jussi01> wgrant: thats fine. thanks for the help, as long as it send the correct one tomorrow.
[07:04] <wgrant> micahg: Is bug.
[07:04] <wgrant> micahg: I'll poke somebody about in an hour when they appear.
[07:04] <micahg> :), thanks
[07:04] <wgrant> It failed last night too for the first time in weeks, but this is a different type of failure.
[07:05] <micahg> wgrant: I'm going to sleep, just hoping builds are done in 6 or 7 hours :)
[07:05] <wgrant> micahg: They should be, as long as the queue doesn't get too much deeper.
[09:07] <rowinggolfer> morning folks.
[09:08] <rowinggolfer> Is it possible for the owner of a ppa to get any feedback on how many subscribers the ppa has?
[09:08] <rowinggolfer> or how many times a package has been dl'd?
[09:08] <bigjools> rowinggolfer: not yet but we have a plan
[09:08] <rowinggolfer> bigjools: excellent news.
[09:09] <wgrant> This has been a popular question this week.
[09:09] <rowinggolfer> I was asking the canonical bods about this at scale
[09:09] <rowinggolfer> they pointed me in this direction
[09:10] <rowinggolfer> I ask because I have packaged git pitivi in a ppa, and would love to convince the lead dev that this was a worthwhile venture.
[09:10] <bigjools> there were a few people interested in this so some of them might start coding it
[09:11] <rowinggolfer> great.
[09:13] <rowinggolfer> I presume the info will be added under the PPA activity header, where sole information currently is "5 updates this month"etc..
[09:14] <bigjools> not sure yet, that needs to be talked over and designed
[09:15] <wgrant> It'll more than likely first be exposed over the API. No UI has been thought much about yet.
[09:16] <noodles775> We did always plan for some info to be there in the PPA activity portlet, but yes, first via the API...
=== yofel_ is now known as yofel
[09:18] <noodles775> rowinggolfer: wgrant has some branches in progress for the backend work, I hope we'll get time to work on the UI once they're done.
[09:18] <rowinggolfer> noodles775: wgrant - much appreciated. good work.
[09:21] <persia> bigjools: Would you have time time to talk about native-source-sync ?
[09:22] <bigjools> persia: not much, is it quick?
[09:22] <persia> Possibly not.  wgrant and I were discussing the status over the past couple days with an eye towards trying to make it move forward.
[09:22] <persia> It was thought that you might know more about it than others.
[09:23] <bigjools> quite possibly :)
[09:23] <persia> Another time also works for the discussion.
[09:24] <bigjools> what TZ are you in these days?
[09:27] <persia> I'm shifty, but prefer large positive values.
[09:28] <persia> So early EU times is likely best.
[09:30] <bigjools> persia: ok, so I'll try for something tomorrow or Friday morning EU
[09:32] <persia> bigjools: OK.  I have a pending engagement at one of those times (not confirmed which yet), but if we're lucky we'll pick the same one :)
[09:32] <persia> Otherwise next week maybe?
[09:32] <bigjools> yeah no worries
[09:34] <persia> Excellent.  Thanks.
[09:34] <bigjools> heads up to you and wgrant though, it's not easy because we need to do a load of change log fixing first
[09:34] <wgrant> Yeah, we worked that much out.
[09:34] <bigjools> bug 139162 bug 55795 bug 247456
[09:34] <persia> Yeah, we figured out that much, and looked at the bugs for it.  Our conclusion was that Soyuz needed to grow the ability to extract the changelogs from the packages, because we don't have .changes files for syncs from Debian.
[09:34] <wgrant> Announcements are going to be seriously awkward, because there's no PackageUpload for the SPR, and so also no changes file...
[09:34] <ubottu> Launchpad bug 139162 in soyuz "Store the pristine debian/changelog for each SourcePackageRelease" [Low,Triaged] https://launchpad.net/bugs/139162
[09:34] <ubottu> Launchpad bug 55795 in soyuz "+changelog includes misleading information related to package versions and authors" [Medium,Triaged] https://launchpad.net/bugs/55795
[09:34] <ubottu> Launchpad bug 247456 in soyuz "changelog listing are incomplete and/or undiscoverable" [Undecided,New] https://launchpad.net/bugs/247456
[09:35] <bigjools> persia: right
[09:35] <persia> There was another bug about exposing private addresses that we saw as well that ought be hit in that list.
[09:36] <persia> bug #523093
[09:36] <ubottu> Launchpad bug 523093 in soyuz "private e-mail address gets stuffed into and published in changes file" [Low,Triaged] https://launchpad.net/bugs/523093
[09:36] <bigjools> yeah that's a new one
[09:37] <persia> OK.  Sounds like we're roughly on the right track then.  Catch you when you have real time :)
[09:38]  * bigjools wonders what that is .... :/
[09:39] <persia> heh
=== jtv is now known as jtv-afk
=== jtv-afk is now known as jtv
[12:26] <shadeslayer> hi anyone who would like to give a quick how to use PPA's with me on 27th feb 1700 UTC?
[12:29] <rowinggolfer> shadeslayer: what's your target audience - folks pushing packages, or end-users adding as a repo?
[12:29] <shadeslayer> rowinggolfer: people pushing their own packages
[12:30] <rowinggolfer> where are you going to do this - on here?
[12:31] <shadeslayer> rowinggolfer: in #ubuntu-classroom
[12:31] <rowinggolfer> shadeslayer: family permitting, I'll be there
[12:32] <shadeslayer> rowinggolfer: ok.. thanks ill just inform dholbach :)
[12:33] <rowinggolfer> not sure I'll be much use
[12:33] <rowinggolfer> :(
[12:33] <shadeslayer> rowinggolfer: well how long have been using PPA's?
[12:34] <rowinggolfer> about 6 months
[12:34] <rowinggolfer> but I have automated a lot of it, and promptly forgotten much
[12:35] <shadeslayer> rowinggolfer: hehe... well can you please brush up a bit... i just need someone who can help me if theres a error i cannot resolve :)
[12:35] <rowinggolfer> ok.
[12:36] <rowinggolfer> I'll be there unless my wife has plans.
[12:36] <shadeslayer> although ive been using ppa's for a month...
[12:36] <rowinggolfer> I am passionate about ppas
[12:36] <shadeslayer> ok
[12:36] <shadeslayer> :D
[12:36] <rowinggolfer> I wish more upstream projects would use them
[12:36] <rowinggolfer> a great way to get beta testers
[12:37] <shadeslayer> well unless anybody else is absolutely free,rowinggolfer youre confirmed :)
=== jtv is now known as jtv-eat
[13:08] <shadeslayer> rowinggolfer: do you have a launchpad id?
[13:09] <rowinggolfer> shadeslayer: https://launchpad.net/~rowinggolfer
[13:10] <rowinggolfer> is it there?
[13:10] <shadeslayer> yeah
[13:11] <shadeslayer> i was just dispatching a mail to a ML...
[13:21] <lfaraone> nhandler: unfortunately, PROJECTS was rejected upstream: http://bugs.freedesktop.org/show_bug.cgi?id=26576
[13:21] <ubottu> Freedesktop bug 26576 in General "Add a new field to xdg-user-dirs" [Normal,Resolved: wontfix]
=== ChanServ changed the topic of #launchpad to: http://launchpad.net | Read https://help.launchpad.net for help | Recent problems browsing branches should be fixed. | Help contact: mars | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: see channel #launchpad-dev
[13:59] <DaveDavenport> can I merge a proposed patch via launchpad?
[14:02] <beuno> DaveDavenport, no, you need to merge yourself
[14:03] <DaveDavenport> aah
[14:03] <DaveDavenport> to bad
[14:03] <DaveDavenport> how can I assign a commit to a specific user
[14:03] <DaveDavenport> (sorry bzr noob)
[14:11] <james_w> DaveDavenport: --author
[14:12] <DaveDavenport> thx
=== al-maisan_ is now known as al-maisan
[14:53] <PandaDogCat> Hi guys
=== PandaDogCat is now known as cbx33
[14:53] <cbx33> ahhh that's better
[14:54] <cbx33> so many familiar nicks
[14:55] <cbx33> So, guys, if someone wanted to run their own instance of launchpad, from the dev code, is the a tag/branch that is stable? - or have we not reached that kind of level yet for standard users?
[14:59] <mars> cbx33, I don't know if there is a tag or anything, but I can say that whatever revision is currently on edge has passed the entire test suite - all 23,000+ tests.
[15:00] <cbx33> woh ok!
[15:00]  * cbx33 has edge access
[15:00] <cbx33> so is what is on edge, what is in the repo?
=== danilo__ is now known as danilos
[15:01] <mars> cbx33, we do continuous deployment, so edge is trunk.  When we deploy to production, we just roll out whatever is on edge.
[15:02] <cbx33> ok
[15:02] <mars> cbx33, https://help.launchpad.net/LaunchpadReleases
[15:02] <cbx33> mars got time for a quick pm?
[15:02] <mars> cbx33, sure
[15:08] <cbx33> ping sinzui
[15:08] <sinzui> hi cbx33
[15:08] <cbx33> sinzui, got time for a quick pm?
[15:08] <sinzui> I am in a meeting at the moment. maybe in 30 minutes
[15:09] <cbx33> ok great
[15:10] <sinzui> cbx33: edge is the devel branch, changes arrive once a day
[15:10] <cbx33> ok
[15:11] <cbx33> sinzui, I have other questions, mars told me to ping ya!
[15:11] <cbx33> :)
[15:13] <cbx33> so I'll talk to ya in a bit
=== gnomefreak76 is now known as gnomefreak
[15:30] <mars> bad day for code imports.  Lots of people submitting password-protected repos, which we can't process :(
=== jtv-eat is now known as jtv
[15:40] <cbx33> when the docs say the source tree is 280Mb
[15:40] <cbx33> then they say it may take a couple of hours to get everything
[15:40] <cbx33> which is right?
[15:41] <cbx33> i know it's dependant on net connection - mines about 8Mb
[15:41] <cbx33> 8MB/s
[15:41] <cbx33> no
[15:41] <cbx33> 8Mb/s
[15:41] <cbx33> sorry
[15:41] <cbx33> brain went wonky
[15:43] <mars> cbx33, it will take 3? hours.  It helps if you have a Launchpad user set up already.  Auth access is faster than anon access.
[15:43] <mars> cbx33, are you using rocketfuel-setup?
[15:44] <cbx33> well i was going to yes
[15:44] <cbx33> I do have LP access
[15:44] <mars> good
[15:44] <cbx33> if i look at the source at lp.net i see the build number - is there a way to pull this revision number
[15:44] <mars> cbx33, by the way, you may want to jump onto #launchpad-dev.  That is where most of the people who have a successful local setup hang out.
[15:44] <cbx33> to ensure stability?
[15:45] <mars> cbx33, you can probably edit the RF script to pull what you want.  it is pretty straight forward.
[15:45] <mars> RF script == rocketfuel-setup
[15:46] <cbx33> ya
[15:46] <cbx33> I got that
=== salgado is now known as salgado-lunch
=== matsubara is now known as matsubara-lunch
[16:28] <davidstrauss_> MemoryError: https://code.launchpad.net/~economist-magic/economist-magic/sprint
[16:36] <qense> nigelb: I think I've found the bug in your code snippet.
[16:36] <qense> You were looking for a bug, weren't you?
[16:37] <davidstrauss_> mars: I'm getting a MemoryError on https://code.launchpad.net/~economist-magic/economist-magic/sprint
[16:37] <nigelb> qense: more or less.  It wasn't working
[16:38] <nigelb> qense: how do I correct it?
[16:39] <qense> nigelb: correct the function name ( valules should become values) and at line 15 change mask_value to mask_string
[16:41] <nigelb> qense: hm, I'm doing something fundamentally wrong.  It still isn't working
[16:41] <qense> nigelb: What error message are you getting?
[16:42] <nigelb> qense: its not an error, apport is not showing the gconf file
[16:43] <qense> maybe you're filtering everything
[16:43] <qense> nigelb: I'm not that familiar with regexes, I would suggest you to ask someone else about that.
[16:43] <nigelb> qense: ah, I had made a mistake, now I can see the report
[16:44] <nigelb> but only thing the filter isn't working
[16:48] <qense> I'm afraid I can't help you a lot with that
[16:50] <nigelb> qense: np :)
=== matsubara-lunch is now known as matsubara
[18:05] <mars> sinzui, any idea what is up with the MemoryError that davidstrauss is getting on his +sprint page ^?
[18:05] <SEJeff> Is there a way to download old builds from a ppa from the launchpad ppa? For example from somewhere like: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+packages?field.name_filter=thunderbird-3.0&field.status_filter=superseded&field.series_filter=karmic
[18:06] <SEJeff> It says "No files published for this package" and I'm not seeing how to download the debs short of clicking "view all builds" and wading through everything.
[18:06] <bigjools> SEJeff: yes open the triangle on the left but if it's too old the files are deleted
[18:07] <SEJeff> bigjools, How long are those old files kept?
[18:07] <bigjools> officially 7 days but there's another 7 day lag on top of that "just in case"
[18:08] <bigjools> that's 7 days after they're superseded or deleted
[18:08] <SEJeff> bigjools, Perfect
[18:08] <bigjools> cool
[18:12] <sinzui> davidstrauss: I am looking into the issue how did you get to that link because I can see that the URL is wrong
[18:13] <sinzui> oh...
[18:13] <davidstrauss> sinzui: private branch
[18:14] <sinzui> davidstrauss: I see I misunderstood I was thinking your team had registered a sprint, but this is a branch.
[18:15] <sinzui> thumper: abentley: davidstrauss is having an branch/code issue with https://code.edge.launchpad.net/~economist-magic/economist-magic/sprint
=== yofel_ is now known as yofel
[18:56] <abentley> davidstrauss, hi.
[19:00] <abentley> losa: could you please sync /x/launchpad.net-logs/scripts/loganberry-bzrsyncd/scan_branches.log ?
[19:01] <mars> abentley, they may be offline, sprinting
[19:02] <abentley> mars, or EODed, but I thought I'd try.
=== mpt_ is now known as mpt
[19:58] <davidstrauss> abentley: hi (just saw your earlier note)
[19:58] <davidstrauss> abentley: Hope all is well in Toronto. :-)
[19:59] <abentley> davidstrauss, things are good here.  mars pointed out your MemoryError.
[19:59] <abentley> davidstrauss, unfotunately, I don't think I can debug it until tomorrow, because I don't have access to the right logs.
[20:00] <davidstrauss> abentley: There's no rush. I'm just pushing things to LP in preparation for switching this client to Bazaar.
[20:01] <abentley> davidstrauss, cool.  I'll let you know what we find out.
[20:01] <davidstrauss> abentley: Thanks.
[20:20] <kklimonda> why is there such a big delay between changes to the bug and emails being send? :/
[20:22] <beuno> kklimonda, there's a 5 minute window to group changes into one email
[20:22] <beuno> instead of sending out, say, 10 for 10 changes in a row
[20:25] <mars> beuno, neat, I did not know that (but I did wonder how the grouping took place :)
[20:25] <beuno> mars, it may be 4 minutes
[20:25] <beuno> I forget  :)
[20:34] <rioch> is it possible for me to close bugs/blueprints in the comment to a commit?
[20:35] <beuno> rioch, not at the moment, no
[20:35] <rioch> beuno: sounds like it will be one day?
[20:36] <beuno> rioch, we'd like that feature
[20:36] <beuno> but it hasn't been scheduled yet
[20:37] <rioch> ell I can wait. I've been doing it manually and always wondered. I look forward to seeing it.
=== salgado is now known as salgado-afk
=== matsubara is now known as matsubara-afk
[21:47] <cnd> I'm hosting a project and I've decided the best way to manage things is to split the source code between branches, one being the source code and the other being the debian directory overlay
[21:47] <cnd> I've got the source code hosted in lp already
[21:47] <cnd> I tried to add a new branch for the debian dir overlay
[21:48] <lifeless> whats the package name you build
[21:48] <cnd> but I got an error about how the source code branch and the new debian branch have different rich-root support
[21:48] <cnd> lifeless: rinput
[21:48] <cnd> I'm wondering if I'm going about this the right way
[21:48] <lifeless> then you probably want to be pushing to lp:~cnd/ubuntu/lucid/rinput/packaging
[21:48] <lifeless> but I would suggest not using an overly
[21:48] <cnd> lifeless: what do you suggest?
[21:48] <lifeless> instead use a branch with the debian dir added
[21:49] <lifeless> and use bzr builddeb to import releases etc so you can build from the branch
[21:49] <cnd> lifeless: doesn't that just make things more difficult when you have to maintain two separate branches of the same source?
[21:49] <cnd> lifeless, I'm the upstream maintainer and I'm trying to be the debian packaging maintainer
[21:50] <cnd> I started with bzr bd, but transitioning from it to proper debian packaging is giving me headaches
[21:51] <lifeless> bzr bd is proper packaging
[21:51] <lifeless> and no, it doesn't make it harder
[21:51] <lifeless> see the ubuntu distributed development wiki pages in the ubuntu wiki
[21:51] <cnd> I'm probably not going about it right, because I've been maintaining it as a native package
[21:51] <lifeless> http://rbtcollins.wordpress.com/2009/12/19/debianising-with-bzr-builddeb/
[21:52] <lifeless> that blog post may help as well
[21:52] <cnd> maybe I need to be maintaining it differently using bzr bd
[21:52] <lifeless> its a little stale, there is now a dh_make command; I should test and blog that/
[21:54] <cnd> lifeless, does your blog post method import all the sources into a new bzr branch?
[21:54] <lifeless> no
[21:55] <cnd> lifeless: so what ends up in the new bzr branch exactly?
[21:55] <lifeless> it brings in the debian packaging on top of an existing branch; so you start by making the new branch off of your release
[21:55] <lifeless> cnd: everything
[21:55] <cnd> lifeless: ok, if it's everything then that includes the source code too right?
[21:56] <lifeless> cnd: yes, thats rather the point ;)
[21:56] <cnd> ok, so the reason this is better than a debian overlay is that there is no synchronization issues between the debian dir and the upstream I'm guessing?
[21:57] <lifeless> its better because you can just branch it to build it, you don't need the separate tarball (it can be reconstructed). Its all in one place, so there is no chance of losing the tarball. You can merge changes rather than patching.
[21:59] <cnd> lifeless: so with this approach is there just one branch, or two (upstream source and packaged source)?
[22:00] <cnd> the reason I'm asking these questions is that I want to pick the best option for me being that I'm upstream AND maintainer
[22:00] <cnd> not just wanting to be maintainer
[22:00] <cnd> that's why I don't want two branches with the same source code that I have to sync up between all the time
[22:04] <lifeless> two branches
[22:04] <lifeless> cnd: you could do it with one if you really wanted
[22:04] <lifeless> cnd: but the debian (and ubuntu) build system are rather heavily predicated on the idea of upstream doing 'releases'
[22:05] <lifeless> and unless *every commit* is a new release, with changelog, tarball, release notes etc, you'll find it a lot easier to have two separate things.
[22:06] <lifeless> note that you can totally automatically build a new package as a point update against a previous release, using a small amount of scripting
[22:06] <cnd> lifeless: agreed. I'll try out your bzr bd method from the blog just to play with it at least
[22:06] <cnd> thanks
[22:07] <lifeless> james_w in #ubuntu-motu is the author of bzr bd; he or I or others there can help
[22:13] <MTecknology> If lpia fails to build but amd64 and i386 do build, will it still publish and just lack the lpia?
=== micahg1 is now known as micahg
[22:22] <cnd> lifeless: I'm trying to run bzr bd -S, but it's complaining about not being able to find rinputd_1.0.3.orig.tar.gz in the parent directory, even though it's there
[22:22] <cnd> any ideas what could be going wrong?
[22:24] <cnd> lifeless: I had to put it in ../build-dir, I don't remember having to do that in the past...
[22:24] <cnd> oh well
[22:30] <lifeless> cnd: #ubuntu-motu is a better channel to discuss this
[22:30] <lifeless> MTecknology: yes
[22:30] <cnd> lifeless: ok
=== jelmer__ is now known as jelmer
=== jelmer is now known as Guest75587
[22:42] <MTecknology> lifeless: thanks
=== Guest75587 is now known as ctrlsoft
=== EdwinGrubbs is now known as Edwin-brb