| dOxxx | bialix: do you have any opinion about whether a Terminal window should be visible? | 00:00 |
|---|---|---|
| bialix | for explorer? | 00:00 |
| bialix | windows people always beg to hide it | 00:00 |
| dOxxx | yes, some of the comments mention that a Terminal window is required for entering ssh passwords | 00:00 |
| bialix | and we finally have bzrw.exe for this | 00:00 |
| dOxxx | Windows people have PuTTY and it's all-GUI solution for SSH | 00:00 |
| dOxxx | I believe on the Mac, paramiko will prompt in the console (Terminal window) for the ssh password if the key has not been added to the ssh-agent | 00:00 |
| bialix | paramiko can ask password, and I believe bzr will use the standard bzrlib.ui password propmpt for this | 00:00 |
| dOxxx | will bzrlib.ui password prompt display a graphical prompt in bzr-explorer? | 00:01 |
| bialix | therefore qbzr should start GUI dialog | 00:01 |
| bialix | someone should check, I guess | 00:01 |
| dOxxx | hmm ok, I'll experiment with this myself | 00:01 |
| bialix | if explorer+paramiko won't start the GUI dialog for password then it's definitely the bug in explorer | 00:02 |
| * bialix needs to check on windows too | 00:02 | |
| dOxxx | bialix: so I just tried it with bzr 2.2.1 and qbzr 0.19.1 -- I get a password prompt in the console window, no GUI prompt | 00:26 |
| dOxxx | on Mac | 00:26 |
| bialix | that's a bug in Explorer | 00:26 |
| bialix | can you file it? | 00:26 |
| dOxxx | this was with "bzr qbranch bzr+ssh://user@host/path/to/repo | 00:26 |
| dOxxx | ok | 00:26 |
| bialix | are you sure you're using paramiko as your ssh client? | 00:26 |
| dOxxx | how would I make sure? | 00:26 |
| bialix | set BZR_SSH=paramiko will helpto force | 00:26 |
| bialix | check the .bzr.log | 00:26 |
| dOxxx | aha | 00:26 |
| dOxxx | now it shows a GUI prompt | 00:26 |
| bialix | usually bzr mutters to .bzr.log which ssh client it's using | 00:26 |
| bialix | bingo | 00:26 |
| dOxxx | should I still file a bug? | 00:26 |
| dOxxx | i.e. that paramiko should be default for Mac? | 00:26 |
| bialix | can you open the same branch from Explorer? | 00:26 |
| dOxxx | testing | 00:26 |
| bialix | and check if it has the GUI prompt | 00:26 |
| bialix | I'm not sure about default | 00:26 |
| bialix | does ssh (openssh) on mac has ssh-agent> | 00:26 |
| bialix | ? | 00:26 |
| dOxxx | hmmm different bug... text fields in qbranch window are like 5 characters wide | 00:26 |
| dOxxx | was also visible when starting qbranch from cmdline though | 00:26 |
| dOxxx | I'll file that separately | 00:26 |
| bialix | hmm, for Explorer just use open action, not branch | 00:26 |
| dOxxx | ok | 00:26 |
| dOxxx | using Open Location in bzr explorer, I get the GUI password prompt | 00:26 |
| bialix | good | 00:26 |
| dOxxx | Mac does have ssh-agent, I use it myself. It's automatically started at login. | 00:26 |
| bialix | thank you | 00:26 |
| bialix | if there is ssh-agent then there is no sense to force paramiko as default | 00:26 |
| bialix | imo | 00:26 |
| dOxxx | so users invoking qbzr from bzr commandline, not from explorer, should be expected to know to set BZR_SSH=paramiko if they want GUI prompts? | 00:26 |
| bialix | hmm | 00:26 |
| dOxxx | on the other hand... | 00:26 |
| * bialix scratched the head | 00:26 | |
| dOxxx | if they're commandline, then they might be expecting console prompts, it's just a little icky having to switch between the windows | 00:26 |
| dOxxx | does paramiko use ssh-agent? | 00:26 |
| bialix | I know for sure only about pageant | 00:26 |
| dOxxx | let me check quickly | 00:26 |
| bialix | I think ssh-agent used by open-ssh clients directly, without paramiko | 00:26 |
| dOxxx | well, it looks like it is using keys in ssh-agent | 00:26 |
| dOxxx | I don't have the right key though so gimme a sec to get it | 00:26 |
| dOxxx | and I can test properly | 00:26 |
| dOxxx | bialix: yes, with BZR_SSH=paramiko set, it does use the ssh-agent | 00:26 |
| bialix | cool | 00:26 |
| === dOxxx is now known as dOxxx_dinner | ||
| === Ursinha-afk is now known as Ursinha | ||
| spiv | Good morning. | 01:03 |
| === dOxxx_dinner is now known as dOxxx | ||
| dOxxx | hi spiv | 01:11 |
| poolie | hi spiv, doxxx | 01:12 |
| maxb | Does 'bzr --no-plugins selftest bzrlib.tests.test_config.TestGlobalConfigItems.test_absent_user_id' fail for people other than me? (lp:bzr/2.3) | 01:15 |
| poolie | i'll try | 01:15 |
| poolie | hi mkanat ? | 01:15 |
| mkanat | Hey poolie. :-) | 01:15 |
| poolie | maxb, wfm | 01:15 |
| poolie | really the 2.3 branch? | 01:16 |
| poolie | i don't know what's in that | 01:16 |
| poolie | normally 2.3 just comes off trunk at this point | 01:16 |
| === dOxxx is now known as dOxxx_away | ||
| maxb | Well that's perplexing | 01:17 |
| poolie | maxb: how does it fail? | 01:18 |
| poolie | mkanat: how are things with loggerhead? | 01:18 |
| maxb | The test appears to be picking up my id from ~/.bazaar | 01:18 |
| mkanat | poolie: Well, I'm having quite a Monday over here. :-) But I'm hoping to get to the testing of the 1-thread solution this week. | 01:18 |
| mkanat | poolie: By the way, remember that discussion about releasing 1.18 on the mailing list? Do you want me to actually go ahead and spend the hours to do that? | 01:19 |
| maxb | huh. So if I run the exact same command as ./bzr, it passes. Compared to failing if I run it as "bzr" via PATH | 01:20 |
| poolie | maxb, ah, i see, vincent recently fixed some bugs like this | 01:20 |
| poolie | please file a new one if it's not already known | 01:21 |
| maxb | hah, actually, If I run bzr via the path with my cwd being anything other than /home/maxb, it passes | 01:21 |
| poolie | mkanat: is it really 'hours'? | 01:23 |
| mkanat | poolie: Well, I've never done a loggerhead release before, and I don't know what it entails. | 01:23 |
| poolie | mkanat: i'd say for not just make the branch | 01:23 |
| vila | maxb: test isolation bug, nice catch, the fix should be a one-liner s/TestCase/TestCaseInTempDir/ | 01:28 |
| poolie | hi there vila | 01:32 |
| vila | poolie: still up ? :D | 01:32 |
| poolie | :) | 01:33 |
| poolie | and you? | 01:36 |
| vila | oh, me, just passing around ;) I'll go back to bed. | 02:01 |
| spm | heya vila! | 02:03 |
| spiv | poolie: could I interest you in reviewing https://code.edge.launchpad.net/~spiv/bzr/hooks-refactoring/+merge/36101 ? | 02:27 |
| spiv | I think the line count must be scaring people off, but it's not too hairy, I promise :) | 02:28 |
| poolie | spiv, sure | 02:44 |
| poolie | it's not _that_ big | 02:44 |
| poolie | compared to john's lp-serve one | 02:44 |
| poolie | could i interest you in reading that, if you didn't alreaody? | 02:44 |
| spiv | Sure | 02:44 |
| poolie | hm i thought i read this already | 02:45 |
| poolie | but perhaps i just commented here on irc | 02:45 |
| poolie | and i didn't read it in detail | 02:45 |
| poolie | https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/35877 | 02:45 |
| spiv | Yes, I think I got some brief positive responses on IRC, but no-one prepared to click 'Save comment' apparently ;) | 02:47 |
| poolie | :) | 02:50 |
| poolie | ok done, tweak | 03:02 |
| poolie | hi spiv? | 03:32 |
| poolie | you're going to read john's branch? | 03:32 |
| spiv | Hi poolie, yep. | 03:33 |
| poolie | thanks | 03:33 |
| nprasath002 | hi how can i add an existing folder to revision without creating a trunk?? always do i need to create a trunk and add files to it?? | 04:16 |
| poolie | nprasath002: can you explain more? | 04:45 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| spm | *** FYI codehost is about to go down shortly for a Cherry Pick *** | 07:01 |
| spm | and all done | 07:03 |
| vila | spm: wow, *that* was short ;) | 07:04 |
| spm | vila: hey there! | 07:04 |
| spm | yeah, codehost is one of the simpler restarts | 07:04 |
| lifeless | there is an RT to make it no-downtime. | 07:15 |
| lifeless | *hint* | 07:15 |
| vila | hi all ! | 07:29 |
| vila | poolie: pingeling for a quick chat if you have time for it | 07:29 |
| poolie | hi there vila | 07:29 |
| spiv | Oof, jam's branch reviewed. | 07:40 |
| poolie | yay | 07:40 |
| poolie | well done | 07:40 |
| poolie | that was a blockbuster branch | 07:40 |
| poolie | even allowing the diff including a bit of extraneous stuff | 07:41 |
| spiv | The diff was unfairly large due to a some sort of branch targetting snafu, I think. | 07:41 |
| poolie | right | 07:41 |
| spiv | But yes, quite big even so :) | 07:41 |
| poolie | devel vs db-devel | 07:41 |
| poolie | "resubmit" is such a harsh color of red :) | 07:41 |
| poolie | kind of YOU FAIL IT | 07:41 |
| poolie | it should be a kindly burgundy or something | 07:41 |
| spiv | poolie: give firefox a custom style sheet to fix it ;) | 07:41 |
| spiv | Let's just ditch labels entirely, and review in colours. | 07:42 |
| spiv | Review: Taupe | 07:43 |
| maxb | Bzr really doesn't like being asked to version a tree with 430k files :-/ | 07:43 |
| spiv | maxb: using trunk? | 07:44 |
| maxb | 2.1.2 actually, I should update this box | 07:45 |
| spiv | maxb: trunk has some modest improvements over 2.2 for trees with lots of files. | 07:45 |
| spiv | Oh, definitely try trunk (or the latest 2.3 beta, anyway) then. | 07:45 |
| maxb | (It's a Debian stable box, at work, you see) | 07:46 |
| maxb | Could be worse. We still have bost boxen on oldstable | 07:46 |
| maxb | *most | 07:46 |
| poolie | vila, so, re releases | 07:49 |
| poolie | it seems to me there are factors in tension here: | 07:49 |
| poolie | doing several releases all at the same time is perhaps easier than switching in and out of that mode | 07:50 |
| poolie | at least i find it so | 07:50 |
| poolie | it is somewhat bursty work and you can parallelize a bit | 07:50 |
| vila | yeah, but there are long delays involving pqm | 07:50 |
| poolie | that's true | 07:50 |
| poolie | also, i was going to say | 07:50 |
| poolie | if we wait to announce any of them until all of them are done | 07:50 |
| poolie | that gives more lag | 07:50 |
| vila | exactly | 07:50 |
| poolie | (for others, this is http://paste.ubuntu.com/501962/) | 07:51 |
| poolie | spiv thanks so much for doing that, i'm sure john will appreciate it | 07:51 |
| poolie | now we just need someone from lp to actually sponsor it | 07:51 |
| poolie | once he does those changes | 07:51 |
| vila | even if I focus on releasing 2.2.1 first, 2.3b1 is in fact delayed too and also 2.1 and 2.0 and anyway people *misunderstood* when they'll see all the releases | 07:52 |
| spiv | Yeah. I think from LP's perspective I still count as launchpad reviewer, which is probably not really right anymore. | 07:52 |
| vila | if we decide to focus on 2.2 and 2.3 only for all users, keeping 2.1 and 2.0 for Ubuntu and whoever want to package them, I think the communication will be clearer | 07:52 |
| spiv | So by reviewing I may have actually reduced rather than raised the visibility of that merge proposal. | 07:52 |
| poolie | well, we can request a new review | 07:53 |
| spiv | Right. | 07:53 |
| poolie | john probably wants to resubmit against devel anyhow | 07:53 |
| poolie | vila in some ways it's only worth doing an old-branch release when there's a critical fix there | 07:53 |
| poolie | that would qualify for an SRU | 07:54 |
| vila | poolie: absolutely, that's already what we are doing with 2.0, even if we neglect it a bit too much in this case | 07:54 |
| poolie | in some ways i really doubt whether it's worth doing a 2.0.7 | 07:54 |
| vila | poolie: right | 07:54 |
| vila | but then we can't say we support 2.0 if we don't intend to ever fix it | 07:55 |
| poolie | if it's true most people running 2.0 are doing that because they're on karmic(?) then they'll need to plan to move soon | 07:55 |
| poolie | but otoh the whole world is not ubuntu, and there will be people on debian stable, or rhel | 07:55 |
| vila | indeed | 07:55 |
| vila | so we can say: we support stable releases for 2 years and will deliver a last release for pending critical bugs at the end of these two years. | 07:56 |
| vila | We can than release more for critical bugs if needed but only *during* these two years. | 07:56 |
| vila | After two years: please upgrade if you want more fixes. | 07:56 |
| vila | At the other end, for the most recent series, we keep doing time-based releases every month | 07:58 |
| poolie | i'm not sure we have to make a promise in advance about how many releases there will be | 07:58 |
| poolie | it's different to an OS distro where the fixes are being upstream and the question is whether Ubuntu will pass them on to you or not | 07:58 |
| vila | yup, we don't promise a *number* of releases, only that there will be *one* last *if* needed | 07:58 |
| poolie | istm that most of the people who are not running the current stable series | 07:59 |
| vila | I put some in the draft base dof wild guesses | 07:59 |
| poolie | are on an old one not specifically because they don't want a major upgrade | 07:59 |
| poolie | but because they want to track what their OS ships, and they'll only ship bug fixes | 07:59 |
| poolie | to start with the easiest bits: we could say, betas every month, stable series releases also every month | 08:00 |
| poolie | and then for the old series, we could just pick a larger window | 08:00 |
| poolie | 3, 4, or 6 months | 08:00 |
| poolie | probably 6 is unreasonably long for a fix to sit in the branch | 08:01 |
| vila | on the other hand we *alrady* backport less and less on 2.0, so less releases de-facto | 08:01 |
| poolie | right | 08:03 |
| vila | so, the idea is to define rules focused on RM availability and amount of work rather than hard numbers and have a proposed planning to ensure we don't delay some series for too long | 08:03 |
| vila | The RM can then just update the planning if a series doesn't need to be released. | 08:04 |
| poolie | hm | 08:04 |
| poolie | because your patch does seem to propose some hard numbers | 08:04 |
| poolie | i don't understand | 08:04 |
| vila | incomplete for now | 08:04 |
| vila | One major input the how long we support one stable series, 1 year could be the minimum, 2 years seems reasonable. The impact is direct on the number of series we maintain concurrently. | 08:05 |
| vila | s/input the/input is/ | 08:05 |
| vila | hence my feedback request :) | 08:05 |
| vila | Ideally there would never be two releases in the same week and at most 2 | 08:06 |
| vila | even to maintain 4 series concurrently | 08:06 |
| poolie | why do you say that? | 08:07 |
| poolie | to me it's better to have 4 in one week than 4 in successive weeks | 08:07 |
| vila | because then packagers have a lot more work which delay all releases | 08:08 |
| vila | and I want to reduce the delay between freeze and release | 08:08 |
| vila | because ultimately there is more entropy in such long delays | 08:09 |
| poolie | ok | 08:09 |
| poolie | so we could stagger from oldest through to newest | 08:09 |
| poolie | (maybe stagger is a bad word :) | 08:09 |
| poolie | cycle | 08:09 |
| vila | stagger ? | 08:09 |
| poolie | release 2.0.x, get that packaged and announced, then 2.1.y, then 2.2.z, then 2.3b | 08:10 |
| vila | dunno if it's bad but I don't understand it :) | 08:10 |
| vila | yes, I would favor that | 08:10 |
| vila | which also means fixes on 2.0 bubble quicker than today | 08:10 |
| vila | bubble up | 08:10 |
| vila | and using separate NEWS files helps for that ;) | 08:11 |
| poolie | ok, bubble up | 08:11 |
| poolie | i think that's fitne | 08:12 |
| poolie | i'd rather construe it as: do 2.0.x through to the finish, then start the next one immediately | 08:12 |
| poolie | i don't see much point in waiting, and it seems likely that it will just make things stall there | 08:12 |
| poolie | but i don't really mind either way | 08:12 |
| vila | there is some value in *not* doing that (2.0 before 2.1, etc): it avoids constraints on 2.3 | 08:13 |
| vila | we *can* release the backported/bubbled up fixes without releasing 2.0 anyway | 08:13 |
| vila | that's what I did yesterday for the run-test-while-build ones | 08:14 |
| vila | and that's where I get convinced that splitting NEWS allows more automation | 08:14 |
| vila | The current 'process' if far too error-prone (I made several mistakes even if doing it in the same day, as a background-not-super-concentrated way though) | 08:15 |
| poolie | ok, so, i think | 08:16 |
| poolie | avoiding coupling them together definitely makes sense | 08:16 |
| poolie | having some concept on the frequency of releases also does | 08:16 |
| vila | sorting releases has one nice result: grep ^2.: gives a nice overview and helps to find when did we fix that, | 08:16 |
| poolie | though perhaps it's better to just see that as a maximum and do them when we fix something really important | 08:17 |
| vila | so I wrote a little tools/fin-fixed.py to address that which means we don't care anymore and can split NEWS ;) | 08:17 |
| poolie | if the RM wants to do them all on one day or a few days apart i don't really mind | 08:17 |
| poolie | i feel i would probably try to do them all together | 08:17 |
| vila | +1 | 08:17 |
| vila | this adds some pressure on the packagers though | 08:19 |
| vila | ..until we better automate this part | 08:19 |
| poolie | right | 08:19 |
| poolie | let's just do that more | 08:19 |
| poolie | can we broadly agree on updates for old series approximately every quarter year, for two years? | 08:19 |
| poolie | subject to what comes up | 08:19 |
| vila | we do | 08:20 |
| vila | this fits with aligning our series with Ubuntu releases | 08:20 |
| vila | which we almost do right now except we didn't clearly state for how long we intend to support the series | 08:21 |
| vila | we *could* say: if someone want to maintain a series longer, please do, but... I think we'd better have several different RMs than just forking this part out | 08:22 |
| poolie | i'm inclined to go by what people say on the bugs | 08:23 |
| poolie | occasionally they'll indicate they're on 2.0.x and want a fix | 08:23 |
| vila | so regarding 'it's better to just see that as a maximum and do them when we fix something really important' translates literally to: create anew milestone when you release | 08:23 |
| poolie | at least then you know you're specifically helping someone | 08:23 |
| poolie | for example we very rarely hear now about 1.x bugs | 08:23 |
| vila | indeed | 08:23 |
| poolie | i think if 2-3 months have gone by and we have not done a stable series release, we should consider whether we want to do one | 08:24 |
| poolie | your spreadsheet is fine as a tool for thinking it over but it feels wrong to consider it firmly scheduled | 08:24 |
| vila | but it's open-ended, saying: two years then upgrade, put a sage-guard (sp?) | 08:24 |
| vila | that's the intent | 08:25 |
| vila | it doesn't make sense to plan two years (hence 4 series) ahead | 08:25 |
| vila | I don't know where to keep it though as it's likely a tool we'll want to update every 2, 3 or even 6 months | 08:26 |
| vila | hehe | 08:26 |
| vila | I *know* where to keep it: where it is right now in ~/src/bzr/releases | 08:27 |
| poolie | what's a sage-guard? | 08:27 |
| vila | ok, good enough for me the needed feedback unless you have more input ? | 08:27 |
| vila | safe-guard / | 08:27 |
| vila | safe-guard ? | 08:27 |
| poolie | oh ok | 08:28 |
| vila | I meant to type safe... of course :) | 08:28 |
| poolie | wfm | 08:31 |
| poolie | hm | 08:31 |
| poolie | i'm not sure i understood what was really important to you here | 08:31 |
| poolie | i guess it's that we shouldn't tie all the releases together? | 08:32 |
| vila | 2 years | 08:32 |
| vila | most important bit | 08:32 |
| vila | and the overall idea of making the releases lighter, I'll submit something along those lines in the coming days | 08:33 |
| vila | may be today even | 08:33 |
| vila | err, I mean something we can discuss of course | 08:34 |
| vila | Release provisional planning or Provisional release planning ? | 08:34 |
| vila | or Releases provisional planning | 08:35 |
| vila | poolie: http://paste.ubuntu.com/501984/ :D | 08:38 |
| poolie | heh, just by reading news? | 08:40 |
| poolie | neat | 08:40 |
| vila | http://paste.ubuntu.com/501986/ for duplicated entries and using a specified file | 08:42 |
| vila | yeah just reading NEWS, small step to 1) stop vgrepping NEWS, 2) towards automating tidying up NEWS files and bugs | 08:43 |
| === spike_ is now known as spikeWRK | ||
| vila | oh, regarding configs, quick quizz: | 08:51 |
| vila | if I define a variable both in branch.conf and locations.conf, which one is taken into account ? | 08:52 |
| vila | all readers are invited to answer, I just want to check what people think about it, so don't test, don't look at the code, just give the first answer that crosses your mind (and no cheating by reading other answers please ;) | 08:53 |
| poolie | <poolie> i think locations overrides it, but i think this is not the way it should work, and there is a bug about this | 08:53 |
| poolie | vila, a week after the freeze, let's just do the announcement as we planned | 08:54 |
| poolie | with whatever installers are ready then | 08:54 |
| vila | right, so I'll ... what's the name of the script to copy from propose bzr/proposed to bzr again ? | 08:55 |
| poolie | lp-promote-packages i think | 08:55 |
| vila | maxb: you confirm we can do that right ? | 08:55 |
| poolie | in hydrazine | 08:55 |
| maxb | hmm? | 08:55 |
| poolie | vila i think we should just fix that, we don't need another conf file | 08:56 |
| maxb | "lp-promote-ppa bzr/proposed bzr/ppa" | 08:56 |
| vila | poolie: I'm sure some people rely on it | 08:56 |
| vila | maxb: thanks ! | 08:56 |
| vila | maxb: and thanks for making it ready above all ! | 08:57 |
| vila | poolie: it can be used to override *remote* settings you don't have write access to | 08:57 |
| vila | poolie: and whether or not there are valid use cases already used today, I can't answer and don't want to break | 08:58 |
| maxb | locations.conf overrides branch.conf, and IT REALLY ANNOYS ME | 08:58 |
| lifeless | ditto | 08:59 |
| maxb | Because it means that once you set up an appendpath based policy, you can't override it on an individual basis AT ALL | 08:59 |
| ddaa | +1 | 08:59 |
| vila | poolie: but I clearly remember abentley reminding that it was an intent in the original proposal | 08:59 |
| poolie | +1 | 08:59 |
| ddaa | The problem however is that locations.conf definitely should override branch.conf in some cases | 08:59 |
| ddaa | like the default parent branch set by "bzr branch" | 09:00 |
| poolie | vila i think we may need a plan for setting the priority between them | 09:00 |
| ddaa | or the default push branch set by the initial "bzr push" w/o --remember | 09:00 |
| vila | I have a plan ;) | 09:00 |
| maxb | Well, perhaps we can add a new flag, which, in any given locations.conf section, changes it from "override" to "default" behaviour | 09:00 |
| poolie | perhaps like the policy thing, there needs to be a way to make a high-priority setting | 09:00 |
| vila | maxb: eeerk | 09:00 |
| vila | poolie: eerk | 09:00 |
| poolie | what was your plan? | 09:01 |
| vila | adding another .conf file will avoid my head exploding | 09:01 |
| poolie | doesn't the same issue exist between other config files? | 09:01 |
| vila | not now because there is only place (and a half) where we define a hierarchy between conf files | 09:02 |
| maxb | hmm. Separate config file means I don't have to specify an option in every locations.conf section | 09:02 |
| vila | make that 2.5: bzr-svn, locations/branch and pqm ? | 09:02 |
| vila | maxb: it means you specify it in one file or the other | 09:02 |
| maxb | on the other hand, I don't like splitting things into multiple files when it can be avoided | 09:03 |
| vila | it depends on the variable use | 09:03 |
| vila | it seems to me that the feedback is: we want this new file, not locations.conf (including me) | 09:03 |
| maxb | It feels more discoverable/explainable to say "to change the priority of this, make a setting", rather than "to change the priority of this, move the content to a file with a different name" | 09:04 |
| vila | I can't parse that | 09:04 |
| vila | set defaults in defaults.conf, set overrides in locations.conf | 09:05 |
| vila | or whatever file name we chose | 09:05 |
| maxb | Putting one specific bit of the semantic meaning of a block of configuration into its location, when the rest is in a key/value format, feels kludgy to me | 09:05 |
| vila | exactly | 09:06 |
| vila | I want policy to be for conf files, not for variables | 09:06 |
| vila | append_path being the notable exception | 09:06 |
| maxb | Oh, hmm | 09:06 |
| vila | but even that may be useless | 09:06 |
| maxb | I think you may have just convinced me | 09:06 |
| maxb | In a perfect world, we'd rename locations.conf to location-overrides.conf, but aargh compatibility and all that | 09:07 |
| maxb | location-defaults.conf could be good | 09:07 |
| poolie | ok | 09:08 |
| vila | and as a first step I want 'bzr config' to show me what is defined where so I can grasp what is selected in various cases | 09:08 |
| vila | *then* we can add repo.conf, wt.conf, project.conf (versioned, propagated), mymum.conf and kitchen_sink.conf but the later may be overkill | 09:10 |
| vila | Also, for security reasons (among others) we may also want to define, at the *variable* level where it could be defined (so we can forbid overriding some variables in locations.conf instead of the actual implementation that does it with STORE_* in specific accessors, some end result but declarative instead of procedural) | 09:33 |
| vila | s/some end/same end/ | 09:33 |
| vila | http://paste.ubuntu.com/502016/ woot ! Ok, enough fun. | 09:57 |
| vila | poolie: ping, regarding https://code.edge.launchpad.net/~vila/bzr/323111-orphan-config-option/+merge/35690 , I think the discussion and landing this are two different things, care to re-review (the pre-requisite may need a vote too) | 10:34 |
| poolie | in a brief skim it looks good | 10:34 |
| poolie | i should really go | 10:34 |
| poolie | i can read it more tomorrow? | 10:34 |
| vila | poolie: sure | 10:35 |
| vila | Didn't mkanat said it will report a bug about a test isolation problem about a grabbing its ~/.bazaar/bazaar.conf ? | 10:36 |
| poolie | i don't know what 'it' is, but i think there is a bug about that | 10:38 |
| poolie | oh, it=max | 10:38 |
| poolie | yes | 10:38 |
| maxb | .oO( /nick it ) | 10:43 |
| bialix | vila: how's your feebsd this morning? I'm not really awake so you can expect some speedup... | 10:47 |
| vila | bialix: lol | 10:47 |
| bialix | bonjour vila :-) | 10:48 |
| vila | maxb: he's not online but I typed its nick anyway | 10:48 |
| vila | maxb: oooh ! But it wsa *you* not mkanat ! Sry abouth the confusion it was 2:30 AM :) | 10:49 |
| vila | maxb: did you file it ? | 10:49 |
| maxb | I've made a note to investigate and bugreport properly | 10:50 |
| maxb | I think it was around 2:30 AM for me too | 10:51 |
| maxb | :-) | 10:51 |
| vila | maxb: I reproduce locally.. hehe :) | 10:51 |
| vila | maxb: is it close to 11:51 for you right now ? | 10:51 |
| maxb | ah, so maybe it was 1:30AM for me. Close enough :-) | 10:53 |
| vila | maxb: sure, so we are close time-zone wise, good to know | 10:53 |
| Q__x | Hi all | 11:26 |
| Q__x | just a question | 11:26 |
| Q__x | we are making this very cool game Wesnoth Tactics, we are just beginning... | 11:26 |
| Q__x | we have branch that is like 1GB or so | 11:27 |
| Q__x | but checkout takes under 400MB | 11:27 |
| Q__x | it took me over an hour to commit, adding a single 45KB file | 11:27 |
| Q__x | from checkout | 11:27 |
| Q__x | is it normal? | 11:27 |
| Q__x | is this how bzr should behave? | 11:28 |
| Q__x | is there a way for making it work faster? | 11:28 |
| ddaa | Q__x: maybe | 11:30 |
| ddaa | can you provide the url to a public branch, so people can try it for themselve | 11:31 |
| ddaa | in particular, so developers can figure out what's taking so long if they can reproduce the problem | 11:31 |
| Q__x | we use this place: http://bazaar.launchpad.net/~wtdevs/wtactics/trunk/changes | 11:33 |
| ddaa | oh lite checkout | 11:34 |
| ddaa | try using a normal checkout | 11:34 |
| ddaa | you really only want to use lite checkouts when the repository is local or on a very fast network | 11:34 |
| Q__x | for a price of increasing speed I'd use a branch instead. If I have to aim something this big it doesn't make a difference | 11:35 |
| Q__x | but thanks anyway | 11:35 |
| ddaa | in bzr, a "checkout" is actually a branch | 11:36 |
| ddaa | with some magic that makes it automatically push on every commit | 11:36 |
| ddaa | and make commit fail if push would fail because of a divergence | 11:36 |
| Q__x | uhm | 11:37 |
| ddaa | The "light checkout" is something different | 11:37 |
| ddaa | that needs to ask the remote repository for anything | 11:37 |
| ddaa | another way of thinking of it is "a plain checkout is a light checkout with a full copy of the history as a local cache" | 11:38 |
| ddaa | bottom line being, only use light checkouts if the repository is local or on a fast LAN. | 11:39 |
| Q__x | I guess I'm too much accustomized to how SVN works :/ | 11:39 |
| ddaa | because what you save in initial checkout time, you pay back in slower operations | 11:39 |
| ddaa | Q__x: actually, if you just do "bzr checkout" "bzr commit" | 11:40 |
| ddaa | it should work right | 11:40 |
| ddaa | that's tuned to be easy to svn users | 11:40 |
| ddaa | you're just making it complicate for yourself by using a lightweight checkout as a way to try and make it work like svn. | 11:40 |
| Q__x | sure, I;m OK with pphilosophy, just don't have a place for all this GBs of our history | 11:41 |
| ddaa | then you're out of luck | 11:41 |
| Q__x | and time for working with lite checkout often... | 11:41 |
| steshaw | ddaa, do you know why the light checkout is slower? | 11:41 |
| ddaa | steshaw: I don't KNOW why it's slower in this particular case. | 11:42 |
| ddaa | but generally, using a light checkout with a remote repository involves a lot more network traffic | 11:42 |
| steshaw | I wonder why is causes more network traffic on commit? | 11:43 |
| ddaa | with a normal checkout, the revision data is generated entirely from local data, and bzr only needs to upload the result. | 11:43 |
| ddaa | steshaw: because the repository is across the network | 11:43 |
| steshaw | ah, I figured it would have enough information locally to manage a commit | 11:43 |
| ddaa | nope, use a plain checkout for that | 11:44 |
| steshaw | ok, np | 11:44 |
| ddaa | there is a perennial wanted feature that would make you happy | 11:44 |
| steshaw | I'm been wondering whether bzr has a way to "prune" and "splice" repositories | 11:44 |
| ddaa | that's called "history horizons" | 11:44 |
| ddaa | but it has complex ramifications and has never been urgent enough to implement | 11:45 |
| steshaw | thanks ddaa, I am googling for it :) | 11:45 |
| ddaa | if you can't cope with a few GB of history data, just take a couple dozen bucks and buy a new hard drive. | 11:46 |
| ddaa | Bought 500GB 2.5" for 50€ | 11:46 |
| ddaa | couple of days ago | 11:46 |
| steshaw | I personally prefer a full copy of the repo. I was just curious why the shallow one was slower. | 11:46 |
| Kinnison | ddaa: To be fair, it's more bandwidth than storage which makes me anxious for horizons | 11:46 |
| Q__x | its incompatible with FLOSS ideology to demant new hardware for developing software, ddaa | 11:47 |
| ddaa | Q__x: okay, I'm probably violating some code of conduct by saying that. But That's a stupid statement you just made. | 11:48 |
| ddaa | You are working on a project with has hundreds of MB of data. | 11:48 |
| Q__x | nah, bzr is just bizarre :D | 11:48 |
| ddaa | It's not a matter of ideology, you just need a few GB of storage space to work on that. | 11:49 |
| Q__x | yes, hundreds MB of content, but in a year we'll have a half terabyte of data if it will be growing that fast :( | 11:50 |
| ddaa | if your repo is polluted by unwanted bulky cruft, you can trim it out with a combination of fast-export and fast-import. | 11:50 |
| ddaa | Q__x: nothing specific to bzr there | 11:50 |
| ddaa | maybe you do not want a DVCS if you cannot cope with that | 11:50 |
| ddaa | you'll have the same problem with git or mercurial | 11:50 |
| Q__x | ok, thanks for pointing fast import/export things | 11:51 |
| Q__x | it may solve lots of issues to delete the history after the project will be operating more vertically and less horizontally | 11:53 |
| ddaa | frankly, I'm not convinced svn would not make you more happy | 11:53 |
| Q__x | i think it would | 11:53 |
| ddaa | people would still have the option to use bzr-svn if they want | 11:54 |
| ddaa | also | 11:54 |
| ddaa | bzr-svn provides the option to serve the bzr branch using the svn protocol | 11:54 |
| ddaa | mhhh | 11:55 |
| ddaa | but that does not work for commit, yet | 11:55 |
| Q__x | did'nt knew that :) | 11:55 |
| ddaa | bzr-svn is like awesomeness topped with love | 11:55 |
| Q__x | frustration, not love in my case | 11:56 |
| maxb | bzr-svn is awesomeness | 12:03 |
| maxb | The frustration occasionally occurs when it's not ultimately awesome | 12:03 |
| Q__x | not, its constantly with me | 12:04 |
| maxb | Well, talk to people here, we can probably help :-) | 12:05 |
| maxb | I have to admit, it helps a lot that I understand a lot of the guts of bzr-svn now | 12:05 |
| Q__x | Just did it, maxb | 12:05 |
| maxb | Hmm? I thought the previous conversation was about lightweight checkouts, not bzr-svn? | 12:05 |
| Q__x | I don't want to get into guts, really... I need a documentation, guide, working GUI (which is not in latest stable XP version), not a helpful hand, wasting other's time and energy with any minor problem | 12:06 |
| Q__x | ok, thanks a bunch once again folks | 12:10 |
| vila | maxb: thanks anyway :D | 12:12 |
| ddaa | oh, I did not think to ask about windows | 12:26 |
| ddaa | lightweight checkouts + windows is probably quite pathologic | 12:27 |
| ddaa | because the dirstats don't work very well | 12:27 |
| ddaa | ... but people generally don't like it when they are told their filesystem sucks... | 12:27 |
| chmouel | hi is it here the newbies question about bazaar? | 12:31 |
| ddaa | all questions welcome, just ask, don't ask to ask | 12:31 |
| ddaa | you can also check https://answers.launchpad.net/bzr | 12:32 |
| === jorge_ is now known as jcastro_ | ||
| === jcastro_ is now known as jcastro | ||
| vila | jam: ping | 14:41 |
| james_w | yay, another inconsistent delta bug | 14:46 |
| jam | morning vila | 14:59 |
| vila | jam: hey ! | 14:59 |
| vila | jam: Did you heard about GaryvdM lately ? | 14:59 |
| jam | vila: about him? no | 15:00 |
| jam | from him? Only on the mailing lists | 15:00 |
| vila | yeah, but nothing since 2010-10-24 :-/ | 15:00 |
| vila | as discussed with poolie, I'll release 2.2.1 without the windows installer | 15:01 |
| jam | vila: he just wrote to bzr-explorer-dev about 6 hours ago | 15:01 |
| jam | he wanted to release the new bzr-explorer to put it into the windows installer | 15:01 |
| vila | >-/ I'm not sunscrined there :-/ | 15:01 |
| vila | that's subscribed under the sun probably... | 15:02 |
| jam | but yes, prior to that the last word from him was 9/19 | 15:02 |
| maxb | btw, is Andrew Starr-Bochicchio on IRC at all? | 15:03 |
| vila | jam: is this clear enough: http://paste.ubuntu.com/502131/ | 15:03 |
| maxb | I need to ask questions about the qbzr debian branch | 15:03 |
| vila | maxb: lp-promote-ppa works like a charm ! | 15:03 |
| maxb | :-) | 15:03 |
| maxb | I really ought to give it --dry-run and --sourcepackagenames options | 15:04 |
| * vila sends gratitude to maxb to help ;) | 15:04 | |
| jam | vila: I would probably swap the first two paragraphs, say what we are doing, then say what it is :) | 15:05 |
| jam | otherwise, seems fine to me. | 15:05 |
| jam | If we could get ahold of gary, then I'd like to know what's up, but I guess we have to see | 15:05 |
| * vila fixes (and fixes releasing.txt too :) | 15:06 | |
| vila | jam: me too | 15:06 |
| vila | jam: the first one gives feedback to the other ok ? | 15:06 |
| vila | jam: or tell Gary :) | 15:06 |
| jam | vila: certainly, I'll try emailing him directly. Did you want to release *today*? | 15:07 |
| jam | gary's email said he wanted to release bzr-explorer tonight to put it into the installer | 15:07 |
| jam | so it sounds like he wants to build it *today* | 15:07 |
| vila | vila: I did mail him yesterday. Well, we are already at 10 days after freeze and I updated the ppa already, the OSX installers are ready and people have already dl'ed them, FreeBSD includes it, etc.. | 15:08 |
| jam | vila: I certainly understand. You did say 5-days | 15:08 |
| jam | Its up to you as RM, I was always *really bad* at it. | 15:08 |
| vila | :-/ | 15:08 |
| vila | I'm a noob RM though and accept all feedback :-D | 15:09 |
| === vednis is now known as mars | ||
| james_w | maxb: yes, at least something | 15:14 |
| james_w | asomething IIRC | 15:14 |
| maxb | I don't think I've seen him around then. I guess I'll fall back to mail | 15:15 |
| vila | jam: 'announce availability' or 'announce the availability' ? | 15:16 |
| jam | vila: well, it is a release, not an rc, so we can just say "we have released" | 15:16 |
| jam | the availability stuff is for 'gone gold' and for 'announcing the availability of a release candidate' | 15:17 |
| vila | 8-/ This is so passing way above my head :-/ | 15:17 |
| vila | I mean, the tiny english differences... I think I understand the difference between a micro release and a rc ;) | 15:18 |
| vila | Grr, forgot the [ANN] in the subject | 15:23 |
| ddaa | I think the general idea is that RC are not "releases" (noun) (as in, not supported), so the verb "release" cannot be used for them | 15:26 |
| ddaa | so we use the periphrase "annonce availability" | 15:26 |
| vila | ddaa: right so 'announce availability of a new release' is correct, my question is 'announce *the* availability of a new release' was correct too :D | 15:35 |
| ddaa | grammatically speaking, I would think both are acceptable | 15:37 |
| ddaa | but my point is that it's a mouthful which is better avoided | 15:38 |
| vila | yeah, excuse my english I'm French (and also excuse my president...) | 15:39 |
| ddaa | Ahem Vincent, tu te ne te souviens plus de moi? Si je me souviens bien, on s'est vu chez Steve. | 15:41 |
| ddaa | And I am not any less french than you are. | 15:42 |
| GaryvdM | Hi all | 15:47 |
| vila | GaryvdM: !!!!!! | 15:49 |
| vila | hellllooo, I was beginning to worry that you lost internet connection or even worse :) | 15:49 |
| vila | hmm, may be I've been too enthusiastic... GaryvdM ? Still there ? | 15:52 |
| GaryvdM | Yes - doing BE release, for first time | 15:53 |
| GaryvdM | sorry, timing has just been bad - busy at work | 15:53 |
| vila | ouch | 15:53 |
| vila | Are you including a *new* be in 2.2.1 ? | 15:53 |
| GaryvdM | I hope it's not to different to qbzr. | 15:53 |
| GaryvdM | vila: did not understand *new* question. | 15:54 |
| vila | Is the BE version you're releasing based on the one included with 2.2.0 or based on trunk or newer ? | 15:55 |
| GaryvdM | vila: Based on trunk, but I could make a cherry picked version. | 15:56 |
| GaryvdM | vila: Looking at the log since the last release, it's only really bug fixes. | 15:57 |
| vila | GaryvdM: Do your best | 15:57 |
| GaryvdM | vila: My gut is to release from trunk, even though I know that deviates from our general procedures. | 15:58 |
| vila | GaryvdM: and keep me informed about the windows installers availability ;) I guess you don't know when that will be ? | 15:59 |
| GaryvdM | vila: I'm sure I can do it tonight. | 15:59 |
| vila | follow your guts ! (Not doing it can lead to weird stuf ;) | 15:59 |
| vila | great | 15:59 |
| * bialix waves at GaryvdM | 16:17 | |
| GaryvdM | Hi bialix | 16:17 |
| bialix | heya Gary! | 16:17 |
| bialix | if you need my help - say | 16:17 |
| GaryvdM | bialix: I had a look at the mp's you wanted to do before the release, but it seemed a bit involved, so I left it. | 16:19 |
| GaryvdM | sorry | 16:19 |
| bialix | GaryvdM: np, I'm starting 1.1.1 | 16:20 |
| GaryvdM | bialix: I've tag a release and uploaded the .tar.gz | 16:20 |
| bialix | do you want me to upload the installer for explorer? | 16:21 |
| GaryvdM | bialix: Yes please. my iscc broken for some reason. | 16:22 |
| === zyga is now known as zyga-dinner | ||
| bialix | ok, will do | 16:22 |
| GaryvdM | I can fix, but that would allow be to move on the the bzr installer. | 16:22 |
| GaryvdM | bialix: Thanks. | 16:22 |
| vila | Do we have https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa users/testers here ? | 16:26 |
| vila | dOxxx: ping | 16:32 |
| === zyga-dinner is now known as zyga | ||
| === bialix_ is now known as bialix | ||
| GaryvdM | jam: How did you normally gpg sign the installer that you built on ec2? | 16:54 |
| GaryvdM | jam: Copy and sign locally? | 16:55 |
| jam | GaryvdM: upload it to my own machine, sign it, and upload them from there | 16:55 |
| jam | yep | 16:55 |
| GaryvdM | jam: Ok | 16:55 |
| GaryvdM | It's a bit slow for me because of bad bandwidth... | 16:56 |
| jam | GaryvdM: if it is on that machine, I can grab it and do the upload if you would prefer | 16:57 |
| GaryvdM | jam: And you sign? | 16:58 |
| jam | GaryvdM: unless you want to give me your key :) | 16:58 |
| GaryvdM | jam: Don't worry, I've already started uploading.. | 16:58 |
| jam | GaryvdM: does that mean you are done with ec2? | 16:59 |
| GaryvdM | jam: nearly | 16:59 |
| GaryvdM | jam: Um - also want to do a 2.3 beta build. | 17:00 |
| GaryvdM | after this is done. | 17:00 |
| jam | k | 17:00 |
| jam | just let me know when you are done | 17:00 |
| vila | GaryvdM: yeah for 2.3b1 build !! With sugar on top :) | 17:05 |
| bialix | GaryvdM: explorer installer has been uploaded | 17:06 |
| mushookies | can someone help me I have a problem | 17:06 |
| bialix | shoot | 17:06 |
| mushookies | I am coding with someone who uses firebug for testing | 17:06 |
| mushookies | and commits the code | 17:07 |
| mushookies | I want to prevent them from commiting or strip fb() | 17:07 |
| bialix | GaryvdM: if needed I'll send announcement tomorrow | 17:07 |
| mushookies | from the code beging commit or prvent commit | 17:07 |
| mushookies | to a bzr repo | 17:07 |
| mushookies | the code is PHP | 17:07 |
| mushookies | and i want to prevnet commiting of fb() function | 17:07 |
| mushookies | in bzr | 17:07 |
| mushookies | were would i begin looking for a solution | 17:08 |
| rubbs | mushookies: check out this plugin, it may do what you want: http://doc.bazaar.canonical.com/plugins/en/text-checker-plugin.html | 17:08 |
| mushookies | I would even pay someone this is a thorne in my side | 17:08 |
| rubbs | doesn't look like it will check for specific text yet, but you may be able modify it to do what you need | 17:09 |
| mushookies | this is nice | 17:09 |
| mushookies | hmm | 17:09 |
| rubbs | alternatively you may be able to use testrunner and write a test that greps for that specific function and dissallow commiting if it doesn't pass. Just an idea | 17:11 |
| mushookies | wonder how much effort it would be to code what i need | 17:11 |
| mushookies | I guess ill check latter | 17:11 |
| mushookies | thanks rubbs | 17:11 |
| rubbs | np | 17:11 |
| bialix | vila: will you send announcements to bazaar-announce ML? | 17:19 |
| vila | bialix: I did for 2.2.1 | 17:19 |
| bialix | for some reason I haven't received it | 17:20 |
| vila | maxb: by the way, you know about the selftest '-s' option right ? (Just filed bug #650001 and realized you didn't mentioned '-s' when you first reported the problem) | 17:24 |
| ubot5` | Launchpad bug 650001 in Bazaar "bzrlib.tests.test_config.TestGlobalConfigItems.test_absent_user_id fails when run in $HOME (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/650001 | 17:24 |
| maxb | Ah, that would be faster, wouldn't it :-) | 17:25 |
| vila | maxb: especially in this case, try it | 17:25 |
| vila | maxb: also, you can use some shorcuts: -s bt == -s bzrlib.tests, bb == bzrlib.tests.blackbox, bp == bzrlib.plugin | 17:26 |
| vila | maxb: and you can use it multiple times -s bb -s bt.test_config | 17:27 |
| vila | <blinks> | 17:34 |
| vila | lp merge proposal display links for bugs if --fixes was used..... obviously I noticed that before... but didn't realize it aws *useless* to mention it in the cover letter... | 17:35 |
| === beuno is now known as beuno-lunch | ||
| === abentley is now known as abentley-lunch | ||
| jelmer | maxb: hi | 18:01 |
| maxb | hi | 18:01 |
| maxb | I imported 2.2.1 using 'bzr merge-upstream' for the PPA packaging. I was wondering if it was worth pushing the result of that import somewhere within pkg-bazaar namespace, and mentioning it on pkg-bazaar-maint, so that it would be available if 2.2.x gets uploaded to Debian anywhere | 18:02 |
| maxb | Also, I was surprised to discover that the pkg-bazaar qbzr/unstable branch is ahead of unstable, and wondered if there are any team guidelines that apply | 18:03 |
| maxb | s/ahead/ahead by an upstream version/ | 18:03 |
| jelmer | maxb: I think Andrew pushed to unstable before he knew we shouldn't upload to unstable. | 18:04 |
| jelmer | maxb: did you merge-upstream while also specifying the upstream branch? | 18:05 |
| maxb | yes | 18:05 |
| jelmer | maxb: I'm not sure if it would be useful to push that anywhere. experimental has 2.3b1 already, no new versions will be uploaded to unstable. | 18:06 |
| maxb | since 2.3.0 will be out before squeeze is, right | 18:06 |
| jelmer | maxb: 2.3 won't make it into squeeze | 18:07 |
| maxb | Right, 2.3.0 will be released before testing unfreezes, thus 2.2.x will never be uploaded to unstable ever | 18:07 |
| jelmer | maxb: right | 18:08 |
| maxb | In that case, I think I should "bzr rm .bzrignore" in the pkg-bazaar branches, since that caused me some consternation when trying to figure out how to drive bzr merge-upstream, until I figured out that the fact it's absent in the tarball means it should be absent in the merge-upstream-ed branch | 18:09 |
| jelmer | maxb: I disagree, I think that's a bug in bzr-builddeb. After the first merge where .bzrignore is ignored merge should not try to remove it again. | 18:16 |
| maxb | Well, the problem with that option is that the .bzrignore in the packaging branch becomes disconnected from the one in mainline, and does not receive future merges of updates | 18:17 |
| jelmer | maxb: An out of date .bzrignore is better than none at all imho. The upstream branch (which you're specifying) has the .bzrignore file though so bzr-builddeb /could/ merge it in. | 18:19 |
| maxb | I guess it could. It would be a very weird special case of merging, though | 18:20 |
| === beuno-lunch is now known as beuno | ||
| vila | maxb: I agree with Jelmer. There should a way to say: I don't want to hear from this file, at least in the foreseeable future. Please remind me in six months or when this or that change, but please, don't make it a conflict each time I merge. | 18:29 |
| vila | sudobzr don't conflict (and sudo make me a sandwich ;) | 18:29 |
| maxb | The issue is not the conflicts | 18:35 |
| maxb | The issue is that there are three 'threads' | 18:36 |
| maxb | The upstream thread has a .bzrignore | 18:36 |
| maxb | The tarball-mirroring bzr-builddeb-maintained intermediate thread does not | 18:36 |
| maxb | And the packaging branch does | 18:36 |
| maxb | And changes to the .bzrignore ideally need to be merged from the first to the third | 18:36 |
| GaryvdM | 2.2.1 windows installers done. | 18:41 |
| * GaryvdM busy updating wiki. | 18:41 | |
| Kobaz | I just broke bzr... http://pastebin.ca/1950530 | 19:18 |
| fullermd | Uh oh. You've got insurance, right? | 19:20 |
| Kobaz | heh | 19:20 |
| vila | GaryvdM: Yeeeehaaa ! | 19:20 |
| fullermd | Seems to me that error came out of a mismatched plugin. bzr-svn maybe? | 19:21 |
| Kobaz | i dont think so... the error came all of a suddon, when i did a pull | 19:21 |
| vila | Kobaz: while I realize you're not on windows, you may have noticed that bzr-2.2.1 is officially out | 19:21 |
| Kobaz | i upgraded bzr to 2.2 just to see if whatever bug happened was already fixed | 19:21 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | Release Manager: vila | bzr 2.2.1 is officially out | bzr-2.0.6, 2.1.3 and 2.3b1 need installers, aTdHvAaNnKcSe ! Some of them are already available, please test !| work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| Kobaz | fullermd: i did a bzr pull, a bunch of bzr reverts and bzr resolveds, and then bzr st broke | 19:22 |
| vila | Kobaz: can't stay here, but this sounds like a known bug. Did you try to report it ? | 19:22 |
| Kobaz | not yet | 19:22 |
| fullermd | See if you have any fragments of lock files around? | 19:23 |
| Kobaz | what are the filenames | 19:23 |
| fullermd | .bzr/branch/lock/, any files in there. | 19:23 |
| fullermd | Ditto .bzr/checkout/lock/ | 19:23 |
| fullermd | And .bzr/repository/lock/ | 19:23 |
| fullermd | The dirs should all exist, but be empty. | 19:24 |
| Kobaz | all empty | 19:24 |
| vila | bzr st should barf if any lock was involved methinks, your dirstate file may be corrupted see the FAQ on lp on how to rebuild it | 19:24 |
| Kobaz | http://pastebin.ca/1950535 | 19:26 |
| Kobaz | that's the leadup to the st error | 19:26 |
| vila | Kobaz: wow, really sorry I must go, but this sounds like a new bug, mention 'inconsistent delta' in the subject | 19:28 |
| Kobaz | k | 19:40 |
| === abentley-lunch is now known as abentley | ||
| GaryvdM | 2.3b1 installers done, and uploading. | 20:13 |
| GaryvdM | jam: I'm looking at doing bzr 2.1.3 and 2.0.6 installers. I think the best is going to be to branch lp:bzr-windows-installers from rev 93 | 20:14 |
| GaryvdM | jam: Ian made comments that the new scripts would not work with 2.0/2.1. I'm not sure why, but I guess I should trust him. | 20:16 |
| jam | GaryvdM: I'm sure we could make them work, but I don't think he was trying to get it to work | 20:22 |
| jam | so yes, I agree | 20:22 |
| jam | just use the old version | 20:22 |
| GaryvdM | jam: Ok | 20:22 |
| vila | GaryvdM: don't rush on 2.1.3 and 2.0.6, we haven't built them for OSX, debian may not use 2.0.6 either | 20:24 |
| vila | GaryvdM: the rationale is that since we 'package' for windows and osx, we don't have to maintain compatibility for 2.0 and 2.1 | 20:24 |
| GaryvdM | vila: Ok. | 20:25 |
| vila | GaryvdM: people can just update to 2.2 since we provide *all* the needed parts | 20:25 |
| GaryvdM | jam: I'm done with the ec2 host then. Please shut down. | 20:26 |
| vila | GaryvdM: I'd say (to dOxxx and to you now), let's wait for people with good reasons to not update to 2.2 before building them | 20:26 |
| GaryvdM | lol | 20:26 |
| vila | I will post to the ML on the subject soon, so we can discuss it, but I think 2.0.6 and 2.1.3 installers can wait during the discussion | 20:27 |
| GaryvdM | ok | 20:27 |
| vila | We already have full plates by releasing a first beta and there will be certainly be a bug pike | 20:28 |
| vila | 2.1.3 may never land in debian either AIUI | 20:28 |
| vila | FreeBSD maintains the latest stable only | 20:29 |
| vila | I'm unclear on gentoo (any user or packager of gentoo around ?) | 20:29 |
| vila | but anyway, I'm already talking about distributions based on source which can be released without installers | 20:30 |
| GaryvdM | Woot - the beta ppa has 2.3 b1 - nice maxb | 20:30 |
| vila | GaryvdM: yup, we are ready to release. I'll release it soon. | 20:36 |
| AdvancedGarde | Hello there. | 20:42 |
| rubbs | hello | 20:44 |
| AdvancedGarde | I'm trying to setup a reposity on my server through sftp. I'm getting ~ "/.bzr": [Errno13] Permission denied | 20:45 |
| AdvancedGarde | I'm trying to conect from my windows machine. | 20:47 |
| AdvancedGarde | If I try to initialise using the gui, it asks for the password, says authentication successful! then asks for the password again before giving a permission denied error. | 20:48 |
| AdvancedGarde | The server is running ubuntu | 20:48 |
| AdvancedGarde | What else might you need to know? | 20:48 |
| GaryvdM | AdvancedGarde: Can you ssh to the box and do a "ls -la" | 20:48 |
| GaryvdM | AdvancedGarde: check what the owner and group is, and what the permissions are. | 20:49 |
| GaryvdM | you may need to do a chown/chmod | 20:49 |
| vila | If the server is Ubuntu use bzr+ssh instead of sftp | 20:50 |
| AdvancedGarde | GaryvdM would you like me to paste the result to a pastebin? | 20:50 |
| GaryvdM | AdvancedGarde: Ok - just check for private data. | 20:51 |
| AdvancedGarde | You mean, don't paste anything private? | 20:51 |
| GaryvdM | Yes | 20:52 |
| AdvancedGarde | kk | 20:52 |
| AdvancedGarde | http://pastebin.com/5y4SaFef | 20:53 |
| GaryvdM | AdvancedGarde: Sorry - should have said - please do this in your branch. | 20:55 |
| GaryvdM | AdvancedGarde | 20:55 |
| GaryvdM | cd branch | 20:55 |
| GaryvdM | AdvancedGarde: What user are you doing the bzr init/push? | 20:56 |
| GaryvdM | as | 20:56 |
| AdvancedGarde | I've created a user on the server called bazaar | 20:56 |
| AdvancedGarde | There is no brance on the server at the moment? | 20:57 |
| GaryvdM | AdvancedGarde: Are you doing a init, or init-repo, or push? | 20:57 |
| AdvancedGarde | bzr init-repo sftp://bazaar@advancedgarde.co.uk | 20:59 |
| magge | good evening. i have a bzr repo where i think theres some files with incompatible filenames. bzr says the following on checkout "exceptions.UnicodeEncodeError: 'latin-1' codec can't encode character u'\uf0f8' in position 60: ordinal not in range(256)". how can i get around that? im on ubuntu, the files were checked in on win. | 20:59 |
| GaryvdM | AdvancedGarde: You probably want sftp://bazaar@advancedgarde.co.uk/home/bazaar/my-repo | 20:59 |
| GaryvdM | AdvancedGarde: with out that, it's going to try create the repo in the root of your file system. | 21:00 |
| AdvancedGarde | xd okay, let me give that a try | 21:00 |
| GaryvdM | question to others: do we support sftp://user@server/~/my-repo? | 21:01 |
| AdvancedGarde | sexy! that worked. Thanks a bundle. I'd assume it would be working in the home dir. | 21:01 |
| GaryvdM | Good night all. | 21:02 |
| === BasicPRO is now known as BasicOSX | ||
| === lifeless_ is now known as lifeless | ||
| === Ursinha is now known as Ursinha-afk | ||
| james_w | mgz: have you seen this before? http://paste.ubuntu.com/502332/ | 23:03 |
| mgz | ...the actual exception doesn't seem to be in that paste, but... upgrade your testtools from 0.9.4 | 23:04 |
| james_w | mgz: oh, sorry: AttributeError: 'NoneType' object has no attribute 'decode' | 23:05 |
| mgz | ...man, I really don't want testtools to stay 0.9.4 for squeeze or I'm gonna be sauing that a lot. | 23:05 |
| mgz | *saying | 23:05 |
| james_w | mgz: I don't think anything has changed in the environment, so what causes this? | 23:05 |
| james_w | lifeless should update it in sid, and then my environment would update | 23:06 |
| mgz | cause is one of my branches having a bug that I didn't find till after landing | 23:07 |
| lifeless | squeeze is frozen | 23:07 |
| mgz | it's been frozen for a while... | 23:08 |
| lifeless | yup | 23:08 |
| mgz | I remember for lenny that they let bugfixing minor changes land during freeze | 23:09 |
| mgz | but it may not be possible. | 23:10 |
| poolie | hi there john | 23:12 |
| swebo | hi | 23:15 |
| swebo | can i edit the bzr-history? i forgot to add a file at a ci lots of revisions ago. i would be great if i can add it afterwards to a defined revision in the past... is that possible? | 23:17 |
| dash | swebo: revisions are immutable, you'd have to essentially rebuild the history | 23:17 |
| swebo | can i delete a revision? | 23:18 |
| poolie | swebo: you can use bzr-rewrite to make a new better history | 23:35 |
| poolie | or more lazily, just uncommit everything back to there and make one big revision that's correct | 23:35 |
| poolie | depending on how much you care about keeping the detail | 23:35 |
| swebo | hmm or i copy the whole branch and copy the files of each revision to check them in again... that are not so many revisions | 23:36 |
| mgz | swebo: if you're thinking about that it's easier to do bzr uncommit --force and bzr shelve --all repeatedly, fix the revision you care about, then unshelve and commit, can even preserve the commit messages with a little copy and paste | 23:40 |
| poolie | mgz i wonder what would have happened if you'd run annotate to give a leaderboard for misspelling its/it's :) | 23:42 |
| lifeless | I would win. | 23:43 |
| poolie | i think so | 23:43 |
| mgz | I deliberately resisted that, because I'd be standing in a glass house when it comes to spelling :) | 23:43 |
| poolie | :) | 23:47 |
| poolie | bug 647588 is a bit poignant | 23:47 |
| ubot5` | Launchpad bug 647588 in Bazaar "launchpad plugin doesn't work with Python 2.7 (dup-of: 612096)" [Undecided,New] https://launchpad.net/bugs/647588 | 23:47 |
| ubot5` | Launchpad bug 612096 in Bazaar "XMLRPCTransport is incompatible with python 2.7 (affected: 8, heat: 53)" [High,Fix released] https://launchpad.net/bugs/612096 | 23:47 |
| poolie | all that careful analysis and then just closed as an already-fixed dupe :) | 23:48 |
| mgz | yeah, man I felt bad about that one | 23:48 |
| mgz | I wish the close-as-dupe page was like the other status edit pages and let you put a comment in at the same time, nearly always you want to say something | 23:49 |
| poolie | i agree | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!