--- Log opened Thu Jan 22 00:00:07 2015 | ||
-!- heroux_ is now known as heroux | 02:06 | |
-!- clopez_ is now known as clopez | 02:16 | |
jeremybennett | olofk: Closing or32 bugs is fine by me. We're putting all the new work into the or1k tool chain | 08:50 |
---|---|---|
poke53282 | git really confuses me. | 08:51 |
stekern | poke53282: you mean you don't 'git it'? | 08:53 |
stekern | (pun stolen from John Romero - https://twitter.com/romero/status/555857253212123137) | 08:54 |
poke53282 | In the main qemu repository I can find parts of my code, that to my knowledge were not accepted by Jia Liu ( maintainer of the openrisc part). | 08:54 |
poke53282 | stekern: Exactly. | 08:54 |
poke53282 | Ok, this is fine | 08:54 |
poke53282 | But I can't find in the history of the file an entry the last year, who put it there. | 08:55 |
poke53282 | I loocked up my patches and the commit patches. I wrote that I included some variables. And I can find them in the main repository. | 08:56 |
stekern | git blame? | 08:56 |
poke53282 | How do I search for the first patch, which introduced a variable? | 08:58 |
stekern | have they changed since they were introduced? | 09:01 |
stekern | you can use git log -L | 09:02 |
stekern | to show a subset of lines | 09:03 |
olofk | jeremybennett: Good to know. Do you have any input on the remaining open bugs? Especially 21, 66 and 103 | 09:06 |
olofk | Fuck it. I'm closing 66. It works for or1k | 09:06 |
stekern | poke53282: appearantly you can use -S'string' to search for something to | 09:10 |
stekern | i.e.: git log -S'variablename' -- path/to/file | 09:10 |
jeremybennett | olofk: Sounds a good idea | 09:11 |
jeremybennett | 21 should be transferred to or1k - it is an issue that needs resolving | 09:13 |
jeremybennett | 103 needs checking that newlib is correctly configured in the standard scripts for or1k, then can be closed | 09:14 |
olofk | jeremybennett: Regarding 103, what is "correctly configured"? Are you saying that we should enable long long by default? I don't have much insight in how widely used this feature is or how much extra code it will bring in | 09:19 |
olofk | Some arches set it as default. Other don't | 09:22 |
olofk | wallento: What's the status on upstream newlib now? Did a fresh install (using upstream newlib git), and or1k-elf-gcc can't find stdio.h | 09:57 |
wallento | seriously? | 09:57 |
wallento | only the latest patch is missing (mlock) | 09:57 |
wallento | when I apply this patch to upstream and build, it works fine | 09:58 |
jeremybennett | olofk: I think we should support long long - it's part of C99. I didn't realize that newlib did not by default. | 10:15 |
poke53282 | git rebase drives me crazy | 10:17 |
stekern | if it drives you crazy, don't use it | 10:18 |
stekern | merge instead | 10:18 |
poke53282 | If there is a conflict, I should solve it and then do a "git add" | 10:19 |
poke53282 | and then git rebase --continue | 10:19 |
poke53282 | but it doesn't look like, that the patch is changed afterwards. | 10:19 |
stekern | but did it change? | 10:20 |
poke53282 | I did a rebase one time last week and fixed conflicts. | 10:20 |
poke53282 | And now it seems, that I have the same conflicts again. | 10:20 |
poke53282 | or maybe others. Not sure. | 10:21 |
poke53282 | stekern: I would like to have my changes on top and not in between. | 10:22 |
poke53282 | If I want to send this patches to a mailing list, I have to do something like this anyhow. | 10:24 |
stekern | right | 10:26 |
poke53282 | I think, that it is much better, to do it now, and not when whole stuff gets even more complicated. | 10:26 |
poke53282 | My problem is, that my second rebase doesn't work as expected. If I look at the patches with "git format-patches", it looks like, that they are unchanged | 10:40 |
poke53282 | Is there a changelog for a commit? | 10:43 |
ysangkok | git log <commitid> ? | 10:44 |
poke53282 | With git rebase I change an already commited patch. | 10:46 |
poke53282 | for example the title. | 10:47 |
poke53282 | But I don't see an information like "Changed at Dec. .... 2014" or something | 10:47 |
ysangkok | i think it would be best to ask in #git :P | 11:01 |
olofk | jeremybennett: That sounds like a good enough reason to support it. I'll cook up a patch and close the bug when that is applied | 11:05 |
stekern | poke53282: afaik, there's no history | 11:19 |
stekern | you can probably dig the old commit out from the reflog though | 11:20 |
olofk | Aha. I didn't know about git rebase. Only used git pull --rebase | 11:47 |
poke53282 | well, I have my commits in another branch. | 11:51 |
poke53282 | So I pull master first, and then I do a "git rebase master" on my branch | 11:51 |
poke53282 | Let's try an interactive rebase and change "pick" to "edit" | 11:53 |
poke53282 | stekern: Yes, the local reflog contains such information in some way. | 11:54 |
poke53282 | I simply want to know, why I can't find my previous solved conflicts. | 11:55 |
poke53282 | and why the commits are not updated with these solved conflicts. | 11:56 |
olofk | wallento: Just to check. Did you compile anything with the rebuilt tc? | 12:09 |
olofk | I could also try doing it again with your upstream branch instead of master :) | 12:10 |
olofk | wallento: I'm confused too now. Which repo and branch should I use? | 12:12 |
olofk | Hmm.. does git branch <name> automatically create a new branch <name>? | 12:14 |
olofk | Building for-upstream from open | 12:16 |
olofk | risc/newlib now | 12:16 |
olofk | Hope that's correct | 12:16 |
wallento | yes, thats correct | 12:23 |
wallento | thats upstream plus a fix | 12:23 |
poke53282 | After, I have run rebase three times, everytime with other conflicts, it doesn't complain anymore. | 12:23 |
wallento | git branch <..> does not work | 12:23 |
wallento | eh, solve the issue | 12:23 |
wallento | git checkout for-upstream creates new branch and goes to it | 12:24 |
wallento | http://liswww/jenkins/ | 12:24 |
wallento | build works but not for upstream :) | 12:24 |
poke53282 | It gets even better. He removed some of my commits. | 12:41 |
olofk | wallento: Not following you now. Have you seen problems with your for-upstream branch? | 12:55 |
olofk | poke53282: Sounds like you're not entirely impressed by the state of qemu right now :) | 12:59 |
poke53282 | well, I am not impressed by the way git handles my rebasing. | 13:00 |
poke53282 | But I think, it is done. | 13:01 |
poke53282 | QEMU doesn't run my openrisc binaries anymore. But otherwise I am fine. | 13:03 |
wallento | olofk: nope, I actually built from it | 13:05 |
wallento | and use it also | 13:05 |
wallento | for my software | 13:05 |
wallento | together with binutils upstream | 13:05 |
olofk | I suck :( | 13:11 |
ysionneau | 1:48 < poke53282> But I don't see an information like "Changed at Dec. .... 2014" or something < if you change the commit , the sha-1 hash will change, right? | 13:25 |
poke53282 | ysionneau | 13:30 |
poke53282 | ysionneau: Yes, looks like this is the case | 13:30 |
ysionneau | don't know if that was your issue when you said you fixed merge issues while rebasing but then you didn't see those changes when doing git show | 13:36 |
poke53282 | I have reset everything and have redone the rebase. It seems to work now. | 13:38 |
ysionneau | ok :o git mistery then | 13:42 |
wallento | olofk: still can't build? whats the error? | 13:46 |
olofk | It's building but can't find stdio.h when I compile a hello world program | 13:51 |
olofk | wallento: "echo | or1k-elf-gcc -v -x c -E - " gives me some warnings | 14:12 |
olofk | ignoring nonexistent directory "/opt/or1k-elf/lib/gcc/or1k-elf/4.9.1/../../../../or1k-elf/sys-include" | 14:12 |
olofk | ignoring nonexistent directory "/opt/or1k-elf/lib/gcc/or1k-elf/4.9.1/../../../../or1k-elf/include" | 14:12 |
olofk | That can't be good | 14:12 |
olofk | otoh it finds /opt/or1k-elf/lib/gcc/or1k-elf/4.9.1/include | 14:14 |
olofk | And there are a bunch of stdarg, stddef, stdint and stuff there, but no stdio | 14:14 |
olofk | But who uses stdio.h nowadays. I use a docker app running in the cloud instead | 14:15 |
wallento | mmh, works fine for me | 14:37 |
wallento | so, lets check if everything is identical | 14:37 |
olofk | Ok, let's do this carefully. What's on the first line of your configure.in? | 14:38 |
olofk | After we are done with that file we only have 5955 more files to compare | 14:39 |
wallento | binutils is at 6c1965f995bc8119c0775f2f9b648a1902e6e210 | 14:40 |
olofk | I'm using the 2.25 tarball | 14:40 |
wallento | okay | 14:40 |
wallento | mine should be the binutils-2_25 tag | 14:41 |
wallento | or1k-gcc is 50e11f73098c722676829ae73caf09246e81cd44 correct? | 14:41 |
olofk | nope. Mine is probably one commit behind yours. Is the previous commit 1ee8ef4190f85934479fa00abbc29e164af80f00? | 14:43 |
olofk | Did a pull now and got the same as yours, just in case | 14:43 |
wallento | okay, sorry, my boss needs computer support, will be back in an hour ;) | 14:44 |
olofk | Just a quick one. newlib is 5d9075b68b6d53ecd1895b77ee01ffb30a521bbf | 14:45 |
wallento | yes | 14:51 |
wallento | i will also run it again, just to be sure | 14:52 |
wallento | olofk: I am really sorry, but works for me | 15:14 |
olofk | I'm more sorry :) | 15:34 |
olofk | The mlock patch was applied now btw. | 15:35 |
olofk | Does that mean that everything is upstream now? | 15:35 |
wallento | yes | 15:35 |
wallento | ! | 15:35 |
wallento | yet another beertime | 15:35 |
wallento | :) | 15:35 |
olofk | Ahhh... so that's why :) | 15:35 |
wallento | getting upstream is a path ;) | 15:36 |
wallento | so, this one is "normal": ignoring nonexistent directory "/opt/or1k-elf/lib/gcc/or1k-elf/4.9.1/../../../../or1k-elf/sys-include" | 15:37 |
wallento | at least I have the same | 15:37 |
wallento | the other one disappeared after installing newlib | 15:37 |
wallento | did you forget to "make install" ;) | 15:37 |
olofk | I think it | 15:39 |
olofk | Aha! make install fails now | 15:39 |
olofk | or1k-elf-ar: ../sys/lib.a: No such file or directory | 15:40 |
olofk | wait a minute... | 15:40 |
olofk | oh... wrong newlib | 15:41 |
olofk | Oh well. I'll wait until upstream git is updated and try again after that | 15:41 |
wallento | sounds good | 15:53 |
wallento | olofk: GO! | 16:22 |
wallento | its in the git | 16:22 |
poke53282 | blueCmd: It is Ok, if I cherry pick some of your patches for QEMU? | 16:52 |
poke53282 | cherrz pick | 16:53 |
blueCmd | poke53282: of course | 16:54 |
poke53282 | I might merge and move them too. With my skill in git you might accidently lose official authorship ;) | 16:58 |
blueCmd | poke53282: yeah, that's fine. I'm sure you will do something sensible | 17:00 |
-!- _franck__ is now known as _franck_ | 19:19 | |
reinoud | hi folks | 20:37 |
reinoud | is this also the place to talk about riscv ? | 20:37 |
ysangkok | hahaha | 21:29 |
ysangkok | nice troll :D | 21:29 |
poke53282 | But indeed, looks like the riscv people don't have their own irc channel yet. | 21:31 |
poke53282 | there are a few persons in #riscv | 21:32 |
poke53282 | reinoud: I would suggest, that you ask this question on the risc-V mailing list. | 21:33 |
poke53282 | This chat room is not directly related to risc-v. | 21:36 |
poke53282 | However, we have discussed RISC-V in general here. I don't think, that you can ask special technical questions here. | 21:39 |
poke53282 | bluecmd: l.lwa/l.swa support (always succeeds, no atomic protection) -> Semi-fake atomics, now with less fake -> Eanbled stricter atomics, it still doesn't work for glibc but it's the Right Thing To Do -> Fix atomics | 22:37 |
poke53282 | :) | 22:37 |
poke53282 | Nice commit history | 22:37 |
poke53282 | Ok, I have cherry picked everything important. I will probably merge these patches to one. | 22:38 |
olofk | wallento: Building now | 22:43 |
olofk | I want to do an FFT on OpenRISC. Any ideas where to start? | 22:53 |
olofk | wallento: Bring out the beer! It's working now with binutils 2.25 tar ball and upstream newlib git | 23:03 |
--- Log closed Fri Jan 23 00:00:09 2015 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!