[02:15] <mwhudson> how often does the publisher run for ppas?
[02:17] <lifeless> mwhudson: 60s IIRC
[02:33] <wgrant> mwhudson: Every 5 minutes.
[02:33] <mwhudson> thanks
[02:33] <mwhudson> reality appears to match wgrant a bit more closely
[06:13] <yofel> hey, since a few days ago I'm getting
[06:13] <yofel> W: Failed to fetch https://private-ppa.launchpad.net/kubuntu-ninjas/ppa/ubuntu/dists/oneiric/main/source/Sources  The requested URL returned error: 416
[06:13] <yofel> from apt. Launchpad or apt bug?
[06:41] <lifeless> yofel: thats range not satisfiable; weird
[10:28] <geser> gets the Contents file for the main archive for oneiric not updated anymore? last modified on 04-May-2011
[10:32] <jml> is there a guide somewhere for setting up a pre-merge testing thing with Launchpad? (ideally with Jenkins)
[11:28] <xguo> anyone know this error ?
[11:28] <xguo> bzr: ERROR: Server sent an unexpected error: ('error', 'Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "lp-73500496:///~xiaohu-guo/fluidity/hybrid-assemble/".')
[11:29] <henninge> xguo: what are you trying to do?
[11:32] <xguo> I am trying to commit my changes to my branch
[11:33] <xguo> I am using bzr ci -m ""  myfile
[11:34] <henninge> xguo: are you trying to commit directly to the branch on launchpad?
[11:34] <geser> bigjools or wgrant: does the Contents file for the main archive for oneiric get not updated anymore? last modified on 04-May-2011
[11:35] <spiv> xguo: it's basically as the error says:
[11:35] <xguo> I have my check out my launchpad branch to my workstation, and I am commit from my workstation
[11:36] <spiv> xguo: lp:~xiaohu-guo/fluidity/hybrid-assemble has the append_revisions_only option set, but the push or commit you are trying to do would cause some existing mainline revisions to change.
[11:36] <xguo> oh, then what I can do with this ?
[11:37] <spiv> xguo: e.g. if you compare the "bzr log" of your local branch and the remote one, they disagree about the revision number for some revisions, and that option says you want to prevent that.
[11:37]  * henninge is happy spiv took over and goes to lunch
[11:37] <spiv> henninge: actually I'm about to go to bed!
[11:37] <henninge-lunch> oh
[11:37] <spiv> xguo: is it a branch or a checkout?
[11:38] <spiv> xguo: if it's a branch, simplest is probably to make a fresh branch of lp:~xiaohu-guo/fluidity/hybrid-assemble, then merge your new changes into that and commit and push that back to lp
[11:38] <spiv> henninge: (although probably #bzr can help out)
[11:39] <henninge> spiv: sure thanks
[11:39] <xguo> oh, thanks, will try that
[11:39] <henninge> xguo: are you familiar with bzr or is that your first time using it?
[11:39] <xguo> first time use it
[11:39] <spiv> Possibly there's a simpler way, and if there isn't there probably should be.
[11:41] <henninge> xguo: maybe you should go through a little documentation first so you understand the differences that a distributed vcs has over a system like subversion.
[11:42] <henninge> http://doc.bazaar.canonical.com/bzr.2.3/en/
[11:43] <xguo> thanks henninge , the only change i have done is to following suggestions on http://amcg.ese.ic.ac.uk/index.php?title=Local:Using_branches_in_fluidity_development
[11:43] <xguo> which is trying to "keep revision numbers of a branch stable"
[11:44] <xguo> I might screw something up
[11:46] <henninge> xguo: I am not familiar with that hack.
[11:46] <spiv> Someone should update that wiki page to suggest 'bzr config append_revisions_only=True -d URL'
[11:46] <spiv> Rather than mucking about with editing branch.conf via SFTP
[11:47] <spiv> xguo: right, and that's why you got that error
[11:47] <spiv> xguo: because you turned that option on, then tried to do something that would have not kept the revnos stable
[11:48] <xguo> :), so I have followed the wrong instructions ?
[11:48] <henninge> xguo: what are you trying to achieve?
[11:48] <spiv> I'm a little curious about how you got into that situation (where you were pushing/committing something that was not a strict append)
[11:49] <xguo> I am trying to backup  my changes to my launchpad branches
[11:50] <xguo> so basically, we have a main trunk , I check out a fresh one, and also check out my branch to my workstation as well,
[11:50] <jml> is there a guide somewhere for setting up a pre-merge testing thing with Launchpad? (ideally with Jenkins)
[11:51] <xguo> every time I bzr up the main trunk in my workstation, and then bzr pull to update the branch in my workstation before I am doing any changes in my local branch
[11:51] <spiv> Well, you got an error, so you did something 'wrong' in that it didn't work for you.  I can't say if it's enabling append_revisions_only that was wrong for you, or if whatever it was you did that tripped the append_revisions_only check that was wrong for you though, without knowing more.
[11:53] <spiv> I'm a bit surprised you got that error with checkouts.  I would have expected that trying to commit to an out of date checkout would simply tell you to run 'bzr update', and then that should avoid this problem.
[11:53] <spiv> Anyway, I'm off to bed.
[11:53] <spiv> G'night (and good luck!)
[11:53] <henninge> spiv: thanks, good night
[11:54] <xguo> spiv: thanks, good night
[11:56] <henninge> xguo: I think you don't need the instructions for "keep revieion number stable" but I am not enough of a bazaar expert to help.
[11:56] <henninge> xguo: to work with bazaar branches you will normally use the branch, commit, merge, pull and push commands.
[11:57] <henninge> I have to go now, sorry.
[11:57] <xguo> thanks henninge
[12:14] <bigjools> geser: it's broken, it seems :/
[12:37] <SteveExodus> im thinking of doing my ubuntu building in obs now since it does debian and all the other main distros
[12:37] <maxb> obs?
[12:37] <SteveExodus> open build service
[12:39] <SteveExodus> i have obs configured to grab orig and dsc from lp at the moment
[12:55] <henninge> adeuring: Hi! I think it's your turn now ;-)
[12:55] <adeuring> henninge: it is our turn this week?
[12:56] <henninge> adeuring: well, the Thunderdome week would have been our week
[12:56] <adeuring> henninge: we did CHR rotation last week...
[12:56] <henninge> adeuring: so this would be our next unless you did it last week
[12:56] <henninge> ah, I see
[12:56] <henninge> adeuring: nm then
[13:10] <Laney> hey, what bugs can I watch to find out how close LP is to getting the sync button / API method? :-)
[15:09] <persia> So, Over the past 10 minutes, I've pushed 8629kB at supposedly 8 or 9 kB/s for a new stacked branch in LP for a 3019 byte patch (according to bzr diff -r 1488 | grep wc -c).  Am I experiencing an issue with LP or bzr?  Is there anything useful that can be done to troubleshoot whilst I'm waiting?
[15:15] <bigjools> persia: sounds like it's not stacked
[15:16] <bigjools> or maybe stacked on the wrong place
[15:16] <persia> Does it not automatically try to stack on :parent?
[15:23]  * persia gives up and goes to do something else, leaving the next experiment with bzr+LP for some time when there's nothing else to do
[15:37] <maxb> persia: What is the branch you are pushing?
[15:38] <persia> maxb, lp:~persia/debian-installer/publish-omap-spl
[15:39] <persia> And apologies for my fit of pique.  I'm less bothered now.
[15:39] <maxb> So, that ought to auto-stack on lp:debian-installer
[15:39] <persia> (although I'm rapidly approaching a semantic transfer rate of 1 byte / sec)
[15:39] <persia> Why?  That's not what it's branched from.
[15:40] <bdmurray> benji: I just updated the tags on bug that was incomplete and elligible for expiration 34 days from now and now date last updated has been updated and its now elligible for expiration in 59 days.  This doesn't seem like the best thing but it might just be me.
[15:40] <persia> I did `bzr branch lp:~ubuntu-core-dev/debian-installer/ubuntu; ${editing}; bzr push lp:~persia/debian-installer/publish-omap-spl`
[15:41] <maxb> The default stacking logic is based on project/package development focus, not where you branched it from
[15:41] <benji> bdmurray: I don't understand.  Do you think the expiry date should not have changed or do you think it should have been pushed further than 59 days into the future?
[15:41] <maxb> (Whether that's a good thing or not is another question)
[15:42] <persia> maxb, Ah, so every time I touch a branch for an Ubuntu effort, I have to restack N years of history to trunk?
[15:42] <bdmurray> benji: I don't think the expiry date should have changed (well rather the date last updated since expiry date is calculated using that)
[15:42] <persia> Is that something for which I can file a bug?
[15:43] <bigjools> persia: what branch is set as the development focus?
[15:43] <bigjools> that's what it stacks on
[15:44] <maxb> However, I don't see any evidence of stacking in the branch currently being pushed, so I'd guess you might have run into the bug where if an empty branch exists at the destination from a previous push attempt that failed, stacking does not happen
[15:44] <maxb> The dev focus is the debian git import
[15:44] <persia> Except I only typed bzr-push once, and I'm exceedingly unlikely to have ever used that name before, as I didn't notice it mattered until about an hour ago.
[15:44] <maxb> Hmm
[15:44] <benji> bdmurray: we could create a set of "second class" edits that don't change the base modification date, but it doesn't seem like enough of a win for the complexity
[15:44] <persia> maxb, Thanks: I was still looking :)
[15:45] <persia> I'd argue that for the upstream project in LP, that's the correct development focus.
[15:45] <maxb> persia: Is there any mention of "Creating new stacked branch ..." in your terminal?
[15:45] <persia> maxb, No: it says "Using default stacking branch..."
[15:45] <bdmurray> benji: okay that seems reasonable to me
[15:45] <maxb> oh, ok, that's what I meant
[15:45] <bigjools> it's not the first push then
[15:45] <persia> Really, I only ran bzr push once.
[15:46] <persia> And really, nobody else should be playing in ~persia
[15:47] <maxb> Crikey, d-i is pretty big
[15:47] <bigjools> I think you can delete the branch in LP and re-push
[15:48] <persia> I'm not done pushing yet.  Should I interrupt it?  How long should I wait for each of between interrupt and LP delete, between LP delete and re-push?
[15:48]  * maxb does a quick test of how much bzr transfers in this scenario
[15:48] <persia> quick?
[15:49] <maxb> I'm fairly sure the slowest network segment between me and the LP datacentre is 100 Mbit :-)
[15:49] <maxb> London++
[15:49] <maxb> Transferred: 27761kB (486.1kB/s r:210kB w:27550kB)
[15:49] <bigjools> don't take this personally, but I hate you :)
[15:50] <persia> The benefit there is latency, rather than bandwidth.   For long enough transfers, I can burst to ~50Mbit/sec to the DC from here.
[15:50] <nigelb> Yeah, me too.
[15:50] <maxb> Hah, OK - so : bzr push --stacked-on=bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu lp:~maxb/debian-installer/test2
[15:50] <maxb> Transferred: 68kB (17.8kB/s r:21kB w:47kB)
[15:50] <persia> That's kinda the behaviour I wanted.
[15:50] <nigelb> maxb: Now I hate you a little less :)
[15:52] <maxb> I would suggest manually providing a suitable --stacked-on option for now (which unfortunately doesn't accept lp: URLs - I have been looking at fixing that), and filing a bug pointing out that bzr could definitely benefit from using the parent branch as a stacking hint, where launchpad is concerned
[15:54] <persia> maxb, I'll definitely file the bug.  I'm loathe to stop the current push without some understanding of the timing involved in a new push.  Taking a couple hours to push a patch is one thing.  Taking several more hours while finding other issues is unlikely to be something I have the patience to complete.
[15:54] <bigjools> persia: push a different branch name then?
[15:54] <persia> So just interrupt, and then bzr push to a new name?
[15:55] <persia> What sort of URL do I want for --stacked-on ?
[15:55] <maxb> persia: I'd estimate your current push topping out at ~27MB, and a new push using around ~1MB
[15:55] <maxb> For the stacked on option, copy mine from above
[15:55] <persia> I'm at 25 MB now.
[15:56] <persia> If it finishes before I file the bug (waiting for LP to load ...), then I'll leave it.  Otherwise, I'll force stacking.
[16:04] <persia> maxb, bug #808871: please edit if you know something that would make that report more useful.
[16:04] <ubot5`> Launchpad bug 808871 in Bazaar "bzr could definitely benefit from using the parent branch as a stacking hint, where launchpad is concerned" [Undecided,New] https://launchpad.net/bugs/808871
[16:04] <persia> (and thanks for distracting me: my push is done!)
[17:27] <de22> benji, hello, i got some question regarding lauchpad, is there anyone ?
[17:28] <benji> de22: you can ask here or at https://answers.launchpad.net/launchpad/
[17:30] <de22> alright, i'll try there
[17:37] <czajkowski> sinzui: ping
[17:38] <sinzui> czajkowski, hi
[17:39] <czajkowski> sinzui: can you help or advise on a bug that may cause me to pull more of my hair out today please
[17:39] <czajkowski> https://bugs.launchpad.net/launchpad/+bug/700724
[17:39] <ubot5`> Ubuntu bug 700724 in Launchpad itself "Subscription policy inherited from parent team member" [Critical,Fix released]
[17:39] <czajkowski> god damn stupid london bus services
[17:39] <sinzui> Oh that is tricky
[17:40] <czajkowski> sinzui: you are killing me!!!!
[17:40] <czajkowski> sinzui: try and make my life easy today please :D
[17:41] <czajkowski> gmb: annoying bugs that effect locoteams which means my inbox gets full
[17:42] <gmb> czajkowski: Can you point me at  a bug number? I can't promise anything but I can at least suck at my teeth like a plumber and go "Hmm."
[17:42] <sinzui> czajkowski, I think the goal is to set the core teams to delegated; they do not care if the child team is open or closed.
[17:42] <czajkowski> gmb: the one up there above where sinzui goes it's tricky
[17:42] <gmb> Ah.
[17:43] <czajkowski> sinzui: but it;s still effecting teams, I thought this was fixed?
[17:43] <gmb> czajkowski: If sinzui thinks it's tricky, my chances are limited.
[17:43] <czajkowski> gmb: yer only lucky I wasn;t in Dublin mister!
[17:43] <gmb> :)
[17:43] <sinzui> my head just popped thinking about it
[17:43]  * sinzui tries to get the order right in his head
[17:44] <sinzui> czajkowski, is there a specific team or group of teams you want to make open?
[17:45] <czajkowski> sinzui: leogg team seems to be one of the issues
[17:45] <czajkowski> the guy who commented on the bug
[17:45] <sinzui> okay
[17:48] <sinzui> czajkowski, I cannot see a specific team of path that is part of the problem
[17:48] <czajkowski> can you say that to leogg
[17:48] <czajkowski> please
[17:48] <sinzui> czajkowski, I will reply to the bug
[17:48] <czajkowski> cheers
[18:04] <jml> is there a guide somewhere for setting up a pre-merge testing thing with Launchpad? (ideally with Jenkins)