| spiv | Morning. | 00:25 |
|---|---|---|
| poolie | hi there spiv | 00:40 |
| === gitaxxx is now known as git__ | ||
| === frakturfreak_ is now known as frakturfreak | ||
| jeremyw | jam: ping | 02:28 |
| poolie | maxb: hi, still here? | 03:07 |
| maxb | poolie: at 3am my time? unlikely :-) | 07:11 |
| poolie | hi maxb | 07:48 |
| poolie | i wasn't sure what tz you were in | 07:48 |
| poolie | maxb, oops, i also had you confused with mkanat | 08:14 |
| poolie | vila, so, regarding releases | 08:39 |
| poolie | perhaps we can try to get more clear on what we desire | 08:39 |
| poolie | high on my list is not wasting time on the release process itself | 08:40 |
| * vila nods | 08:40 | |
| poolie | which is not to say that all release-type work is a waste; clearly it is useful, but any costs that don't gain an incremental benefit are a waste | 08:40 |
| poolie | and that's got two parts: wasted actual labor, and also unnecessary delay | 08:41 |
| vila | agreed | 08:41 |
| poolie | on the other hand, we don't want to waste our users' time and attention by telling them about something that they can't actually install | 08:42 |
| poolie | which in practice means its very good for binaries for various platforms to be available when it comes out | 08:42 |
| vila | yup, that's why I want to change the process a bit so we can ensure we will successfully build the installers the day we announce the source freeze | 08:42 |
| poolie | that would be good | 08:43 |
| poolie | i guess really the ideal is to _automatically_ build them as a consequence of deciding to release | 08:43 |
| poolie | but that seems a bit elusive | 08:43 |
| vila | for naming reasons, we can't build them *before* freezing, but we can prepare for that and avoid last minute fixes | 08:43 |
| vila | we are almost there for OSX minus 10.5 machine availability | 08:44 |
| vila | well, I have one, but I plan to upgrade it to 10.6 soon | 08:44 |
| vila | we made some significant progress on the windows front too with more people setting up their own environment, but there are still some glitches | 08:45 |
| vila | thanks to maxb things are also clearer on the debian and Ubuntu fronts but still not fully automated (well as fully as possible, there will always be some manual steps | 08:46 |
| vila | ) | 08:46 |
| poolie | so what broke in 2.3b1? i haven't read all my mail from the weekend | 08:46 |
| vila | well, AIUI, for some users, a dll is missing and abort the installation | 08:47 |
| vila | both GaryvdM and mgz have been hammering on it but I think we still haven't a fix | 08:47 |
| vila | the number of affected users is also unclear | 08:48 |
| vila | I'm very tempted to *not* announce 2.3b1 (knowing that ~600 downloads have already occurred so people are testing it anyway) and focus on 2.3b2 | 08:49 |
| vila | OR | 08:49 |
| vila | announce it with with a warning about this dll bug | 08:49 |
| poolie | ah, this one | 08:50 |
| poolie | i think the second is strictly better than the first, isn't it? | 08:50 |
| vila | 2.3b2 is planned for 2010-10-08 aka next Friday, we can change that to 2010-10-14 instead | 08:50 |
| poolie | the only down side perhaps being that people may see too many announcements | 08:50 |
| vila | yup | 08:51 |
| poolie | we should make sure we have something clear explaining the different series | 08:51 |
| vila | it's also why I didn't announce 2.0.6 and 2.1.3 on the assumption that the targeted population may be too small | 08:51 |
| poolie | mm | 08:52 |
| vila | which in turn raise the question about *how* we should package them (or not) | 08:52 |
| poolie | i think we should try to do SRUs for them, | 08:52 |
| poolie | but only if that can be done at a reasonably low cost | 08:52 |
| vila | for OSX and windows where we (collectively) package more than just bzr-core, it makes sense to focus on 2.2 and 2.3 only | 08:52 |
| vila | there is bug #525571 for 2.1.3 | 08:54 |
| ubot5 | Launchpad bug 525571 in bzr (Ubuntu) "No locking when updating files in ~/.bazaar (affected: 7, heat: 75)" [Undecided,New] https://launchpad.net/bugs/525571 | 08:54 |
| vila | and bug #582656 for 2.0.6 | 08:54 |
| ubot5 | Launchpad bug 582656 in bzr (Ubuntu) "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 36)" [Undecided,New] https://launchpad.net/bugs/582656 | 08:54 |
| vila | I don't expect much until maverick is out | 08:55 |
| vila | oh, and for 2.2.1, based on a discussion with maxb, I'm preparing a report about test failures differences between 2.2.0, 2.2.1 and 2.2.2 (not yet released :) | 08:56 |
| vila | which I interrupted yesterday evening, but roughly 2.2.0 and 2.2.1 have the exact same failures but more tests are run for 2.2.1 | 08:58 |
| vila | I still need to check that we have no more failures with 2.2.2 which is a bit more involved as the env is different (running from the installed version as root is required and I encounter some failures I wasn't aware of) | 09:00 |
| vila | I thought we got them all.. | 09:00 |
| poolie | bug 582656 is worth fixing in old distros | 09:03 |
| ubot5 | Launchpad bug 582656 in bzr (Ubuntu) "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 36)" [Undecided,New] https://launchpad.net/bugs/582656 | 09:03 |
| poolie | 525571 is a bit less so, i think, because it probably only comes up with bzr-svn and that's not so hot in karmic | 09:04 |
| maxb | poolie: Is there anything in 2.0.6 that's important enough to make it worth bothering with SRUing into a release that's only got 7 months to run to EOL anyway? | 09:05 |
| vila | poolie: indeed, but it seems that SRUs are a more heavy process than ppas... so for Ubuntu we already have an answer which is: use our last stable, 2.2 | 09:05 |
| vila | which kind of converge with the OSX and windows philosophy | 09:05 |
| poolie | i think SRUs _ought_ to become quite lightweight | 09:06 |
| poolie | with the microrelease exception etc | 09:06 |
| poolie | and with maxb's help too | 09:06 |
| poolie | for 2.0.6 perhaps we should see if anyone actually cares to ask on the bug | 09:07 |
| vila | yup, I'm proposing to avoid them, just mentioning an alternative | 09:07 |
| vila | eeeerk | 09:07 |
| vila | yup, I'm *NOT* proposing to avoid them, just mentioning an alternative | 09:07 |
| poolie | to avoid what? | 09:09 |
| vila | SRUs | 09:09 |
| poolie | ok | 09:09 |
| vila | maxb: It would be nice if you could make a mail summary about the packaging branches status and what you think about the current process (including debian of course) | 09:11 |
| poolie | so perhaps for old series, which at the moment means only karmic | 09:11 |
| poolie | we should just wait for someone to ask for the sru | 09:11 |
| vila | to trigger 2.0.7 you mean ? Or already for 2.0.6 ? | 09:12 |
| poolie | but for newer ones, where we care more about pushing the update, i think SRUs are better than packaging them ourselves | 09:14 |
| poolie | and they should converge more | 09:14 |
| poolie | maxb asked if it was worth SRUing 2.0.6 and i'm not convinced that there is | 09:14 |
| vila | well, I'm convinced we can build with no test failures for 2.2 (and of course 2.3) and comply with the MRE rules, but for 2.0 and 2.1, SRUs are still needed, we can wait a couple of weeks for maverick activity to settle a bit and see what ~ubuntu-sru do | 09:19 |
| poolie | that works for me | 09:20 |
| poolie | with regard to the betas, i think we should stick with, and stick more closely to, the plan that we will give a limited window to build installers | 09:20 |
| poolie | and after that announce without them | 09:20 |
| poolie | but perhaps you should post about this to the list and we can see if people object | 09:21 |
| vila | yup, I will do that | 09:21 |
| vila | oh and we haven't bump the 2.3 API yet | 09:24 |
| poolie | we should do that | 09:26 |
| vila | poolie: oh, and about releasing from *trunk*, both you and jam mentioned it but it isn't described in releasing.txt (which I followed closely hence the 2.3 pqm branch) | 09:26 |
| vila | so I think I understand what it means | 09:26 |
| vila | which is creating the tarball from trunk and create the pqm branch only when... when what ? First RC ? True 2.3.0 ? | 09:27 |
| vila | in the mean time I will probably just ask a losa to pull --overwrite the pqm branch so no harm has been done | 09:28 |
| maxb | ooi, why do we have a release structure that requires losa intervention all the time? | 09:29 |
| vila | maxb: only when we create a new series | 09:29 |
| maxb | it's still oddly inefficient | 09:29 |
| poolie | it is | 09:31 |
| poolie | it would be good to fix that | 09:31 |
| poolie | it's oddly... distrustful of developers | 09:31 |
| poolie | which might be a reasonable setup for archive builds | 09:31 |
| poolie | but in this case seems strange | 09:31 |
| poolie | i'm glad we enforce test suite checks but i'm not sure it needs to be quite so harsh | 09:32 |
| poolie | we can reconsider this when we prototype tarmac | 09:32 |
| maxb | Compared with, say, renaming the ~bzr-pqm user to ~bzr-pqm-daemon, creating a ~bzr-pqm team, renaming the branches back, and adding the ~bzr-pqm-daemon and trusted devs to ~bzr-pqm | 09:32 |
| poolie | mm | 09:32 |
| poolie | i don't think that will be quite enough | 09:32 |
| vila | maxb: that won't give us access to the pqm instance | 09:32 |
| poolie | because pqm itself needs to be told about the new branches | 09:33 |
| maxb | oh, I see | 09:33 |
| poolie | but that's just kind of a bug in pqm, which tarmac may either fix or make tractable | 09:33 |
| lxsameer_ | hi does bazaar allow to clone just a subdirectory under the main repo , and not the whole repo | 10:59 |
| jelmer | sidnei: Nice blog post, interesting read! | 11:19 |
| jelmer | lxsameer_: no, it doesn't support partial checkouts. | 11:20 |
| jelmer | lxsameer_: there are some design docs about it but it hasn't yet been implemented. | 11:20 |
| lxsameer_ | jelmer, is it a DVCS that can do this ? | 11:20 |
| jelmer | lxsameer_: none of the bigger ones can | 11:20 |
| lxsameer_ | jelmer, :( thanks | 11:21 |
| Kamping_Kaiser | jelmer: you can do lightweight but not partial, is that correct? | 11:22 |
| jelmer | Kamping_Kaiser: yep | 11:23 |
| Kamping_Kaiser | jelmer: thanks for confirming :) | 11:25 |
| uffiole | hi. Is it fine to rename the main project folder ? | 11:59 |
| Glenjamin | uffiole: generally, yes | 12:34 |
| Glenjamin | although you might get related branches trying to point to it, which obviously wont work anymore | 12:34 |
| Glenjamin | is there any way to undo an update? | 12:43 |
| uffiole | ok thx , found out it works | 13:00 |
| uffiole | cu | 13:00 |
| vila | Glenjamin: It depends on whether you had uncommitted changes or not | 13:11 |
| vila | before doing the update | 13:11 |
| codingrobot | how can i go back to a revision nummber X? bzr update -r X and bzr revert -r X doesn't seem to do the job. bzr revno shows the latest rev. number | 14:05 |
| GaryvdM | codingrobot: update changes the basis tree, so it will show in qlog (not sure how to see this with cli) | 14:08 |
| GaryvdM | codingrobot: revert leaves the basis tree, so bzr status shows what changes it has made. | 14:09 |
| codingrobot | what?! i just want to get rid of the changes made in the previous 2 commits | 14:11 |
| GaryvdM | codingrobot: bzr revert -r -3 ; bzr commit -m "Revert xxxx" | 14:12 |
| codingrobot | and what is with bzr revno? should i ignore the output? | 14:14 |
| GaryvdM | codingrobot: the revno will only increment after you commit. | 14:15 |
| codingrobot | ok | 14:16 |
| GaryvdM | revert -r X does not commit the revert, it only modifies the working tree. | 14:17 |
| codingrobot | yes, thats how every other scm tool does it, but the revision nr. gets reverted too. thats what confused me a bit. | 14:18 |
| jam | jeremyw: morning | 14:52 |
| jam | hi vila | 14:52 |
| jam | james_w: if you're around, I'd be happy to chat about the merge stuff. I'm writing up another email. It looks like you are inherently criss-cross by the nature of what has happened | 15:14 |
| james_w | hi jam | 15:15 |
| james_w | that's quite possible | 15:15 |
| jam | james_w: just sent | 15:17 |
| jam | let me know when you get it, since I'd like to chat and refer to those graphs | 15:17 |
| maxb | james_w: Quick question for you: what do you think about an option for udd import-scripts which downloads source packages into a persistent BASE_DIR/downloads/PACKAGENAME/ instead of the transient BASE_DIR/updates/PACKAGENAME/ directory? It would be helpful for people testing on less-than-amazing internet connections. | 15:24 |
| james_w | jam: read it | 15:25 |
| james_w | maxb: I would be fine with that | 15:25 |
| jam | james_w: so, the next step that I can think of, is trying to figure out if we can fake a common base. | 15:25 |
| maxb | Great, MP will follow this evening, then | 15:26 |
| james_w | maxb: great, thanks | 15:26 |
| james_w | maxb: and I'll review your others today, sorry for the delay | 15:26 |
| james_w | jam: the "fake" you can do to get to the ideal case you refer to in the email is what we are currently doing as I understand it | 15:26 |
| jam | james_w: not from what you've said earlier, the issue is that the 3.0-1 import needs to be based on the fake 2.1-1 import | 15:27 |
| maxb | james_w: No problem, you've amazed me by reviewing part of my initial batch before I'd finished submitting all of them :-) | 15:28 |
| james_w | heh | 15:28 |
| james_w | jam: in these cases we don't have A-B-C, or at least those cases weren't the terrible behaviours that led me to this originally | 15:29 |
| james_w | we have B and C as two descendants of A, and the first thing we do is create a new revision that has B and C as parents, and the contents of whichever is later | 15:30 |
| jam | sure | 15:30 |
| jam | but I'm missing the other bits | 15:30 |
| gmpff | Hi. | 15:32 |
| gmpff | I'm struggling with a corrupted bzr repo. Any suggestions for where I start reading ? | 15:32 |
| gmpff | MD5 hashes of one of the pack don't match. | 15:32 |
| gmpff | s/pack/pack files/ | 15:32 |
| james_w | jam: thanks for your analysis though, it's pretty clear that we can never have a simple merge now | 15:33 |
| jam | james_w: an open question is whether we can get convergence after another merge | 15:34 |
| james_w | jam: my immediate concern was getting rid of the "you're in an intermediate state, and you have conflicts you need to resolve, but I can't really tell you where they came from, and I might ask you to solve the same ones again in a minute" | 15:34 |
| jam | honestly, --weave or a per-file 3-way merge would probably handle the "ask you to solve them again in a minute" | 15:34 |
| jam | but "where they came from" ? | 15:34 |
| jam | how does that occur | 15:34 |
| james_w | because that's a terrible user experience, but if doing the merge the other way leads to "worse" conflicts in the end then that might not be the best idea | 15:35 |
| james_w | it's more just a phrasing thing in the UI | 15:35 |
| james_w | it currently says: ('The upstream branches for the merge source and target have ' | 15:36 |
| james_w | 'diverged. Unfortunately, the attempt to fix this problem ' | 15:36 |
| james_w | 'resulted in conflicts. Please resolve these, commit and ' | 15:36 |
| james_w | 're-run the "merge-package" command to finish. ' | 15:36 |
| james_w | 'Alternatively, until you commit you can use "bzr revert" to ' | 15:36 |
| james_w | 'restore the state of the unmerged branch.') | 15:36 |
| jam | well, it may give you more *honest* conflicts | 15:38 |
| jam | which is a whole lot better than artificial ones | 15:39 |
| james_w | yeah | 15:41 |
| james_w | the main issue is that resolving twice is outside the normal workflow, so it's not comfortable for people, and we describe the problem really badly which doesn't help | 15:42 |
| james_w | the second issue is that you can end up having to resolve the same conflicts when you do the final merge as you just resolved in that intermediate step, which is frustrating, and leaves people feeling that they did something wrong | 15:43 |
| jam | james_w: I honestly wonder if you wouldn't find a big advantage to supporting "--weave" as the merge type | 15:59 |
| james_w | jam: I'm trying to find an example so we can have a go | 16:00 |
| Glenjamin | vila: yeah, it did. | 16:05 |
| Glenjamin | I did bzr up, then got conflicts, and wanted to reverse that action | 16:05 |
| === deryck is now known as deryck[lunch] | ||
| jeremyw | jam: So I've created a very simple repository browser for bzr. It's stupid fast, even without throwing bzr-history-db at it. | 16:31 |
| GaryvdM | jeremyw: May we see it? How does it differ from loggerhead? | 16:55 |
| === deryck[lunch] is now known as deryck | ||
| jam | jeremyw: good to hear, congrats | 16:56 |
| * GaryvdM waves at jam. | 16:57 | |
| jeremyw | I'm not trying to compete with loggerhead, and the UI is really minimal right now. I'm writing a tool that needs a VCS agnostic repository browser so I'm writing one. | 16:58 |
| jeremyw | Let me get you a screenshot. | 16:58 |
| === samgee__ is now known as samgee | ||
| jeremyw | http://i56.tinypic.com/20urgap.png | 17:15 |
| jeremyw | That's the root view of the bzr.dev branch. | 17:15 |
| jeremyw | Very minimal but it does work. Clicking a file shows contents while clicking a dir drills into that dir. You can even specify a revno to browse a particular revision. | 17:16 |
| jeremyw | It was done in a few hours so there isn't much effort into it. | 17:16 |
| GaryvdM | That's cool. | 17:17 |
| jeremyw | Eventually, you'd have a nicer UI and more features but for now, I'm going simple to flesh out my ideas. | 17:17 |
| GaryvdM | Clicking on NEWS probably works, unlike loggerhead.. (/me ducks and runs....) | 17:18 |
| jeremyw | It's like a frickin' rabbit hole though man. You get something working and you realize the N things that need to be fixed/added. | 17:19 |
| jeremyw | Single person teams suck. | 17:19 |
| GaryvdM | Yhea - I known the feeling. | 17:20 |
| GaryvdM | Would it not be possible to reuse bits of loggerhead? | 17:21 |
| jeremyw | Maybe but the idea is to have a VCS agnostic repository browser. | 17:24 |
| maxb | I have difficulty believing that such a thing is the right way to go. Different VCSes have different peculiarities which need browsing differently | 17:28 |
| jeremyw | I can see the concern but my plan isn't to have the most feature-rich repository browser, although I'm not sure why I couldn't. It's about providing a common UI and common features across different VCSes where applicable. | 17:30 |
| jelmer | maxb: well, loggerhead works against svn, hg and git too :-) | 17:30 |
| jeremyw | I didnt' know that. | 17:30 |
| jeremyw | Hmm... | 17:30 |
| jeremyw | And the real driver behind this is that the repository browser is only a small feature in the overall application. | 17:31 |
| jeremyw | We'll see. | 17:31 |
| jelmer | jeremyw: if it's blazingly fast then that's a big benefit over loggerhead though :-) | 17:31 |
| jeremyw | This really is fast, but I'm not doing as much as loggerhead just yet. I mean, this is the first working piece. haha | 17:32 |
| jeremyw | I think the speed right now is in the simplicity. | 17:33 |
| jelmer | I don't think loggerhead can really justify its overhead though, it's not that advanced. | 17:34 |
| jelmer | jeremyw: oh, I should clarify. loggerhead supports git, hg and svn because bzrlib does; it doesn't really have support for anything than bzrlib itself. | 17:39 |
| jeremyw | jelmer: I got you. Thanks for the clarification. :) | 17:39 |
| === zyga is now known as zyga-afk | ||
| === samgee_ is now known as samgee | ||
| jam | james_w: thanks for the brltty link, though looking at it, it just seems like a regular conflicts to me. Specifically, ubuntu was at 4.0-8ubuntu1, but debian had a 4.0-9 before the 4.1-1 stuff. (though 4.0-9 looks a whole lot like the 4.0-8ubuntu1 changes +/- some stuff which is what causes the conflicts) | 18:46 |
| james_w | right, but you saw the extra step of resolving conflicts? | 18:48 |
| jam | I did see that merge-package dumps out with a conflict of some sort | 18:48 |
| jam | is it meant that "upstream tags are new, and upgrading the upstream causes conflicts" ? | 18:48 |
| jam | in this case, though, why did it need to do the extra merging upstream step? | 18:49 |
| jam | upstream-4.0 is the direct parent of upstream-4.1 | 18:49 |
| james_w | take a look at the revision graph, it's more complex than that | 18:50 |
| james_w | the "pristine" branches of the Debian and Ubuntu are diverged | 18:50 |
| jam | ok, I see that now. but what is "import upstream version 4.0" if not "tag:upstream-4.0" | 18:51 |
| jam | or put another way | 18:51 |
| jam | why is there a "Import upstream version 4.0" which *isn't* the upstream-4.0 tag, but the "upstream-4.1" tag is based upon *it* and not "upstream-4.0" ? | 18:51 |
| jam | though I note that there are *tons* of differences between "Import upstream version 4.0" and what is tagged "upstream-4.0" | 18:52 |
| james_w | there are two "import upstream version 4.0" revisions, one of which has a slightly misleading commit message, as it isn't really an import, but a "merge" of the existing import in the other distro | 18:52 |
| jam | so the one that is tagged is the merge of the existing import? | 18:53 |
| jam | (as far as UI goes, why not just tell the user the tags involved? 'upstream-4.1 conflicted while merging into upstream-4.0', please try to resolve), however even once resolved, how is that communicated to future code? | 18:54 |
| jam | (or maybe it doesn't as I do see 2 "Prepared upstream tree for merging into target branch" messages) | 18:56 |
| === zyga-afk is now known as zyga | ||
| bialix | C-S: ping | 20:15 |
| bialix | hmmm, I'm not really sure is it bug? with bzr 2.2.0: `bzr branch lp:bzr-explorer-website` sets parent branch as: bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr-explorer-website/ | 20:25 |
| bialix | at least it weird | 20:25 |
| maxb | bialix: It is a recent change in Launchpad | 20:30 |
| maxb | Now, the SSH server is capable of resolving shortcut lp urls directly | 20:31 |
| maxb | With the goal of making the initial xml-rpc lookup unnecessary | 20:31 |
| bialix | ok, but bzr shows me this ugly %2B in URL | 20:31 |
| maxb | *shrug*, that's URL-encoding for you | 20:32 |
| bialix | I know, but it's weird anyway | 20:32 |
| maxb | perhaps ugly, but not weird | 20:33 |
| bialix | no, it's weird because there is bug somewhere | 20:33 |
| bialix | if I do `bzr branch lp:~bzr/bzr-explorer-website/trunk` then I end up wth parent branch: bzr+ssh://bazaar.launchpad.net/~bzr/bzr-explorer-website/trunk/ | 20:34 |
| bialix | no %2B! | 20:34 |
| GaryvdM | Hi bialix. | 20:34 |
| bialix | heya Gary! | 20:34 |
| bialix | will poolie be around today/tomorrow (depending on TZ) | 20:36 |
| Meths | Is the website correct that 2.2.1 is the current stable release? | 20:36 |
| bialix | ? | 20:36 |
| bialix | Meths: yes | 20:36 |
| Meths | Okay, thanks. (It's not in /topic.) | 20:37 |
| bialix | Meths: hmmm, yes. jam missed it | 20:37 |
| === GaryvdM changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: vila | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 are official | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| bialix | GaryvdM: it will be nice to review and land qdiff related patches | 20:38 |
| GaryvdM | bialix: Yes - sorry | 20:38 |
| bialix | GaryvdM: if you will look on them, then https://code.launchpad.net/~dorins/qbzr/qdiff-changes/+merge/34710 should be first; and https://code.launchpad.net/~s-dumbie/qbzr/ench_qdiff/+merge/33986 after that | 20:39 |
| GaryvdM | I've got a branch that I've been working for 2 months that I really want land. Soon hopefully. | 20:41 |
| bialix | logrefactoring? | 20:41 |
| GaryvdM | yip | 20:41 |
| GaryvdM | bialix: what do you think about this: http://www.youtube.com/watch?v=tMdE4GmFaDQ ? | 20:45 |
| GaryvdM | from a separate branch | 20:45 |
| GaryvdM | log refactor landed. :-) | 20:48 |
| GaryvdM | I hope to use that selection behaviour to fix bug 412035 | 20:51 |
| ubot5 | Launchpad bug 412035 in QBzr "qlog: Add ui to select parent to diff with. (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/412035 | 20:51 |
| bialix | GaryvdM: I'm not sure what you asking about that clip on youtube. either you gave ne a wrong link or I've lost my patience to see that asian boy after 1st minute | 20:53 |
| GaryvdM | bialix: the asian boy is you tube's dumb suggestions | 20:55 |
| GaryvdM | bialix: If you drag a selection, it only selects revisions that are ansestors of the top revision. | 20:56 |
| bialix | in qlog? | 20:56 |
| GaryvdM | Yes | 20:56 |
| GaryvdM | Changes made by revisions that are not ancestors of the top revision don't show in the diff, so I think it is more accurate. | 20:58 |
| bialix | I was looking at lp:~dorins/qbzr/qdiff-changes | 20:58 |
| bialix | it's pretty nice | 20:58 |
| * GaryvdM looks. | 20:58 | |
| bialix | GaryvdM: once I've used keyboard arrows on your qlog in trunk I've got traceback | 21:00 |
| bialix | also you made bug labels dark red, why? | 21:00 |
| bialix | GaryvdM: http://paste.ubuntu.com/506749/ | 21:01 |
| GaryvdM | I did not think I had changed the bug labels | 21:02 |
| bialix | I think I've pressed right arrow and want to expand merge | 21:02 |
| bialix | GaryvdM: maybe you don't but the text on the labels now black, it used to be white | 21:03 |
| GaryvdM | bialix: ok I'll take a look. | 21:03 |
| GaryvdM | bialix: Please could you check if bug 534963 still exists? | 21:04 |
| ubot5 | Launchpad bug 534963 in QBzr "qlog on shared repo: wrong twisty? (affected: 1, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/534963 | 21:04 |
| bialix | GaryvdM: re labels http://imagebin.ca/view/xaoMUEv.html | 21:05 |
| GaryvdM | bialix: One thing I hope you will like is test_loggraphviz.py | 21:07 |
| bialix | GaryvdM: re bug 534963: I don't have that tree around atm | 21:08 |
| ubot5 | Launchpad bug 534963 in QBzr "qlog on shared repo: wrong twisty? (affected: 1, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/534963 | 21:08 |
| bialix | maybe it at another computer, I'll check tomorrow | 21:08 |
| GaryvdM | Ok, thanks | 21:08 |
| bialix | vila should be happy about test_loggraphviz.py | 21:12 |
| bialix | your ascii graphs are funny | 21:12 |
| GaryvdM | bialix: keyboard nav bug fixed, and I think I've fixed the label color. | 21:21 |
| * bialix is pulling | 21:22 | |
| bialix | GaryvdM: yes, now it's better | 21:24 |
| bialix | GaryvdM: but I'm not sure what do you mean about dragging | 21:24 |
| GaryvdM | bialix: the stuff from the vid not landed yet. | 21:25 |
| bialix | ok | 21:26 |
| GaryvdM | I think I pushed to lp. /me checks | 21:26 |
| GaryvdM | lp:~garyvdm/qbzr/log_select | 21:28 |
| === zyga is now known as zyga-gone | ||
| GaryvdM | Hay, did they upgrade the mysql branches. | 21:33 |
| === frakturfreak_ is now known as frakturfreak | ||
| * GaryvdM pulls out the sketches made together with bialix at uds for qdiff. | 22:01 | |
| GaryvdM | I should try scan them. | 22:01 |
| GaryvdM | bla - no one we be able to read my handwriting. - Ill draw it in mockups. | 22:03 |
| === samgee_ is now known as samgee | ||
| sven_oostenbrink | I have a bzr crash on a bunch of files in ./.bzr/repository/indices/ being empty (0 bytes).. Can I remove those files and try again? | 22:16 |
| sven_oostenbrink | Since these are indices. I suppose they can be recreated again? | 22:16 |
| sven_oostenbrink | I cant do anything with this repo anymore and I have a crapload of commits ready to push.. :( Anybody who might be able to help out? | 22:24 |
| maxb | sven_oostenbrink: Last time someone asked this, the response was uncertainty whether they could actually be recreated, and a definite assertion that no code exists to do so | 22:24 |
| sven_oostenbrink | maxb: as in, Im screwed... | 22:25 |
| sven_oostenbrink | Besides that, what could be the reason for those files to be empty? I already submitted a crash report, but this is bad for me :( | 22:26 |
| maxb | Filesystem corruption, perhaps? | 22:27 |
| sven_oostenbrink | maxb: besides an fsck, the filesystem should be 100% ok, | 22:28 |
| maxb | I suggest posting to the Bazaar mailing list, to get people more expert than me involved | 22:29 |
| sven_oostenbrink | maxb: okay, thanks anyway! | 22:32 |
| lifeless | sven_oostenbrink: did you have a system crash? | 22:39 |
| lifeless | power failure? removed a hotplug drive without flushing? | 22:40 |
| sven_oostenbrink | lifeless: mmmmmm, thinking about it.. my laptop froze about... 45 minutes ago.. happens every day these days, some hardware failure I need to look into... mmmmmmm... | 22:40 |
| lifeless | thats the problem | 22:40 |
| sven_oostenbrink | but even so, AFAIK, bzr wasnt busy, and AFAIK, kernel should flush on a 5 seconds interval, no? | 22:41 |
| lifeless | you had file content in your OS buffer | 22:41 |
| lifeless | sven_oostenbrink: depends on the file system | 22:41 |
| sven_oostenbrink | lifeless: even so, there is no way to repair that? | 22:41 |
| lifeless | sven_oostenbrink: and mount options etc. what file system? | 22:41 |
| * lifeless bets on ect4 | 22:41 | |
| sven_oostenbrink | lifeless: bingo... why betting on ext4? | 22:41 |
| lifeless | sven_oostenbrink: because its very agressive about not writing to disk. | 22:42 |
| lifeless | during development of it there was a -huge- discussion about this; it was breaking kde and gnome configs in this exact way, *all* the time. | 22:43 |
| lifeless | sven_oostenbrink: I suggest mailing the list as maxb suggested; you may be lucky and be recoverable. | 22:43 |
| sven_oostenbrink | lifeless: I guess thats the reason why chromium isnt storing my open pages either after a crash? | 22:43 |
| lifeless | sven_oostenbrink: after a machine crash? yes. | 22:43 |
| maxb | sven_oostenbrink: This repository - is it public or private code? | 22:44 |
| sven_oostenbrink | lifeless: Meh, the WT is still okay, Im creating a new branch, copying the old WT there, and recommitting.. its a bitch, but I can recover.. | 22:44 |
| lifeless | sven_oostenbrink: basically ext4 isn't serialising file system operations for different files from the same process. | 22:44 |
| sven_oostenbrink | maxb: this specific one is public | 22:44 |
| lifeless | sven_oostenbrink: application authors then have a choice: | 22:44 |
| sven_oostenbrink | lifeless: not serializing as in writing out of sequence? | 22:45 |
| lifeless | yeah | 22:45 |
| lifeless | the file is 0 bytes long because the rename operation of a tmp file got flushed | 22:45 |
| maxb | well then, if you provide a tarball of the broken stuff, someone might be willing to poke at it and see if it is reparable | 22:45 |
| lifeless | but the file content didn't get flushed. | 22:45 |
| sven_oostenbrink | maxb: Not really needed I guess, Im already recommitting.. I had quite a few non-pushed commits, but thats life :) code is still preserved so | 22:46 |
| sven_oostenbrink | lifeless: that sounds kind of like cra... No way to work aroud that? | 22:47 |
| lifeless | sven_oostenbrink: if the pack got flushed, we -may- be able to recreate the index with enough effort, but if the pack didn't get flushed, we're boned. | 22:48 |
| lifeless | sven_oostenbrink: we could fsync at every little step, but fsync is the wrong hammer (we don't care about temp files being flushed, we care about a barrier approach - we want all ops before X to complete, then we have a small number of critical ops we could fsync on, and then we don't care after that. | 22:49 |
| lifeless | but user space barriers were slammed on lkml, so :( | 22:49 |
| lifeless | oh, and fsyncing will destroy performance on ext3 | 22:50 |
| sven_oostenbrink | lifeless: well, again, no biggie.. I mean, having to re-commit this much isnt fun, plus I had multiple commits for single files, so now those multiple commits become one.. its not a huge deal, just an anoyance, Im working on fixing it now | 22:50 |
| lifeless | sven_oostenbrink: if you're having regular crashes, I suggest lots of backups :( | 22:50 |
| sven_oostenbrink | lifeless: well, its becomming regular on this @#$*( laptop... I need a new one | 22:51 |
| peitschie | hi all :) | 23:01 |
| mkanat | lifeless: The proxy that does load-balancing on launchpad server processes, can it be dropped in front of loggerhead without any changes to it? | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
