| mgrandi_ | and then it should be just | 00:01 |
|---|---|---|
| mgrandi_ | cp lib/filesystemwatcher lib/__filesystemwatcher.py | 00:02 |
| mgrandi_ | patch -p0 workaroundwahtever.patch | 00:02 |
| danielbrauer | Great, it appears to work now. | 00:02 |
| danielbrauer | Oh I see. I applied it manually. But it still works. (: | 00:02 |
| mgrandi_ | yeah | 00:02 |
| mgrandi_ | this seems to be a bug with QT | 00:02 |
| danielbrauer | That is unfortunate, since it already appears not to work on Windows. | 00:03 |
| mgrandi_ | well | 00:04 |
| mgrandi_ | yeah, i was commented out because of the same issue i believe | 00:04 |
| mgrandi_ | or the fact that files can lock themselves and that was causing problems | 00:04 |
| danielbrauer | Yeah, I think it was permissions on Windows, and "too many files" on Mac OS. | 00:04 |
| danielbrauer | Anyway, I've got to run. Thanks very much for pointing me to the right directory! | 00:05 |
| Jordan_U | I'm trying to confirm that a directory with source code that I'm about to build and put into production is in fact the latest version, (I'm pretty sure but I want to be certain) by running "bzr status". However, when I do this I get this long error message: http://paste.ubuntu.com/1290774/ | 00:23 |
| fullermd | Corrupted dirstate maybe. | 00:24 |
| Jordan_U | I'm using ubuntu 12.04, with bzr 2.5.1 and the directory is being accessed through Samba from a Windows file server, which I connected to using PCManFM, and actually navigated to in the terminal via ~/.gvfs . | 00:25 |
| fullermd | But you only use it on the 3rd and 5th days before a new moon, when Jupiter is in Aquarius, right? | 00:25 |
| Jordan_U | fullermd: Of course. | 00:26 |
| fullermd | Phew. | 00:26 |
| Jordan_U | Dodged that bullet. | 00:26 |
| fullermd | Well, that probably gives ample opportunity for dirstate corruption. I started whimpering in the corner just reading it. | 00:26 |
| fullermd | There's a command that blats out a clean one. I'll think of the name 30 seconds after someone else says it... | 00:27 |
| Jordan_U | fullermd: Should I be generally concerned about this or is it a simple and isolated problem? This repository is very important to me. | 00:27 |
| fullermd | Well, it's concerning any time files get corrupted. How would have some impact on where the concern lies. | 00:28 |
| fullermd | System crashes or the like (with a networked FS, a network dropout would be like) could cause it, and that's only concerning when you crash again. | 00:29 |
| fullermd | Network filesystems tend to introduce a lot more complication points around things like locking, which dirstate relies on. | 00:29 |
| fullermd | repair-workingtree, that's the command. | 00:29 |
| fullermd | That'll dump out a clean dirstate file, which means any explicit changes you've made (like added/deleted/moved files) bzr won't know about. | 00:31 |
| Jordan_U | fullermd: The output of "bzr repair-workingtree" http://paste.ubuntu.com/1290789/ (with the current directory being a temporary copy of the respository in /tmp/). | 00:32 |
| fullermd | Mmm. Probably really messed up then. | 00:33 |
| Jordan_U | The last thing I did was make a commit listing the revision as final and ready to ship, and that was about a year ago. | 00:33 |
| fullermd | Zero-length, maybe? | 00:33 |
| fullermd | What's .bzr/checkout/dirstate look like? | 00:34 |
| fullermd | Anyway, repair-workingtree takes a --revision, so if you're pretty sure it was at the head of the branch, doing a '-r-1' will be fine. | 00:34 |
| Jordan_U | fullermd: http://paste.ubuntu.com/1290793/ | 00:35 |
| fullermd | And that's the end of it, or did paste block off after the first null? | 00:36 |
| fullermd | It would be interesting and suggestive (of what, I don't know, but suggestive of something) if it did in fact get truncated right to the first nul. | 00:37 |
| Jordan_U | fullermd: That's certainly not all of it, I didn't expect the pastebinit command to do that. | 00:37 |
| fullermd | Right after that nul, it should have the revid. You can use that for `repair-workingtree -r` to be sure. | 00:38 |
| Jordan_U | fullermd: So I should run "bzr repair-workingtree -r jordan.uggla@gmail.com-20110513002446-lp90c9cig70b9ty8" ? | 00:39 |
| * fullermd nods. | 00:39 | |
| mgrandi_ | instead of using a networked filesystem you should probably be pushing/pulling from a repo on the server, i would think bzr protects against corruption in that case | 00:39 |
| mgrandi_ | using sftp:// or bzr+ssh:// | 00:40 |
| Jordan_U | fullermd: http://paste.ubuntu.com/1290799/ | 00:40 |
| mgrandi_ | that does not look good, trying to read data that it is expecting but its just not there | 00:41 |
| mgrandi_ | its probably borked =/ | 00:42 |
| fullermd | Yeah, but it looks like it's trying to read data from the dirstate. It shouldn't be doing that when the point of the command is to rebuild the dirstate :p | 00:42 |
| fullermd | OK, cheat. do a 'bzr branch' of it to a temp location, then copy the .bzr/checkout/dirstate file over. There's always a bigger hammer :p | 00:42 |
| Jordan_U | mgrandi_: Would the full dirstate file be useful to you? (It will take a little bit of work to copy it to my server to host it, but I can do so if it might help). | 00:42 |
| mgrandi_ | well it does call 'call dirblocks if needed', so maybe it needs some tof it in order to actually generate a new one? | 00:43 |
| mgrandi_ | or is that bug material | 00:43 |
| fullermd | I'm pretty sure that's bug material, since the point of the command is to recover from a horked dirstate. | 00:45 |
| Jordan_U | fullermd: OK, branching has gotten me a (seemingly) working repository. I'm not going to touch the main one today as I have to think about it more for safety. | 00:45 |
| mgrandi_ | yeah. the error itself isn't anything good, its just trying to read stuff that its not expecting to be gone | 00:46 |
| mgrandi_ | i'll file it later, and include le logs | 00:46 |
| Jordan_U | mgrandi_: You'll file it later? | 00:46 |
| mgrandi_ | im technically "working" at the moment so yeah =P | 00:46 |
| mgrandi_ | i'll do it when i get a free moment | 00:47 |
| Jordan_U | mgrandi_: Thanks. | 00:47 |
| mgrandi_ | just about the fact that repair-workingtree is dying | 00:47 |
| mgrandi_ | i dunno if that will help you | 00:47 |
| Jordan_U | mgrandi_: Yeah, but I appreciate you taking the time to file a bug report anyway. | 00:47 |
| mgrandi_ | an interesting test anyway | 00:48 |
| mgrandi_ | just put a repo on samba and yank out the cable during stuff | 00:48 |
| mgrandi_ | see what happens | 00:48 |
| mgrandi_ | but yes, in the future, dont access this via samba =P | 00:49 |
| mgrandi_ | have a branch on your local disk and then push to server using sftp:// or something that way if one gets borked you have the other | 00:49 |
| Jordan_U | I think that tomorrow I will take this branch that I just created with bzr branch, and copy the directory to the server using cp, replacing the current corrupt branch. This copy on the server was never meant to be pushed or pulled from (and never was that I can remember), at this point it's mostly documentation and verification that we have the latest code (by checking "bzr log" and seeing the "shipped" tag on the last revision), and ... | 00:58 |
| Jordan_U | ... maybe for someone in the future to branch from though that probably won't happen as all our future projects use Atmel rather than ST chips. | 00:58 |
| Jordan_U | Anyone see any problem with that solution (copying the branched repository to the server using cp)? | 00:59 |
| fullermd | Eh, you could just push. | 01:00 |
| Jordan_U | fullermd: Doesn't that introduce possible locking problems (I don't have access to the server to setup sftp for a proper push). | 01:05 |
| mgrandi_ | it could | 01:07 |
| mgrandi_ | if you keep using this over samba though its going to be the same problem,=/ | 01:08 |
| Jordan_U | mgrandi_: Does "bzr log" constitute "using"? | 01:08 |
| mgrandi_ | that doesn't change anything about the repo so you are fine there | 01:08 |
| fullermd | Well, purely branch-related stuff is surely safer than WT stuff. But yeah, if a smb filesystem is the only access you have to the server... urgh. | 01:09 |
| Jordan_U | Like I said, at this point the branch and history is only being used as verification and documentation. | 01:09 |
| mgrandi_ | bzr log shouldn't be changing anything about the branch so that should be fine | 01:10 |
| mgrandi_ | but don't push to it =P | 01:10 |
| mgrandi_ | kittens cry | 01:10 |
| === yofel_ is now known as yofel | ||
| User_007 | Hello, can you help me? the command "bzr bd -S" is returning a signfile error: secret key not available | 16:28 |
| User_007 | but i do have the key | 16:28 |
| User_007 | how to point the key to bzr? | 16:30 |
| User_007 | the error is about malformed e-mail | 16:36 |
| User_007 | it is using the e-mail of my user (user@computer) instead my real mail (user@mail.com) | 16:36 |
| User_007 | how does bazar know witch key do i want to use? | 16:40 |
| User_007 | ping? | 16:44 |
| User_007 | i solved the last problem, but now i get this error: Error: uploading files for distribution UNRELEASED to ppa not allowed | 17:00 |
| User_007 | i am on Quantal | 17:00 |
| jelmer | is | 18:44 |
| mark06 | why bash recursively runs /etc/profile or ~/.profile if I call a (shebanged) bash script from within these files? | 21:49 |
| bob2 | can't parse the question but the bash manpage explains which things are sourced when | 22:03 |
| mark06 | for example, in /etc/profile you have "do-something.sh" at the end | 22:03 |
| mark06 | in my case, do-something.sh starts executing /etc/profile again, which executes do-something.sh at the end, which... so it becomes endlessly recursive , with an infinitely growing list of bash processes raising in the OS | 22:06 |
| bob2 | ok as above | 22:08 |
| mark06 | ah, wrong channel. SORRY! | 22:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!