IRC logs for #openrisc Wednesday, 2013-10-16

--- Log opened Wed Oct 16 00:00:41 2013
poke53281stekern: Can you take a look at this patch for QEMU
poke53281It speeds up QEMU by a factor of two02:07
stekernpoke53281: ah, makes sense03:42
stekernI can assume that happens a lot, copy one register to another03:43
stekernnice finding03:44
poke53281I have expanded the patch a little bit for movi instructions.03:44
poke53281nbench is running at the moment03:44
poke53281Let's see03:44
poke53281If you are Ok with the patch I will send it to the mailing list03:45
poke53281I get strange readings on the nbench results with the new patch right now. Maybe I went to far. Let's see.03:46
stekernI'm not the qemu maintainer, so you don't need me review your qemu patches before sending them ;)03:50
poke53281Uhmm, the ASSIGNMENT is now 0.2 instead of 2.6703:51
stekernbut I think they make sense03:51
poke53281Four eyes are better then two eyes.03:52
stekernis that odd linebreak after else and before if some qemu coding style thing?03:54
poke53281no, this is poke53281 style :)03:54
poke53281and it is not odd03:54
stekernhehe, ok, might wanna fix that before sending though03:55
stekernI've never seen it before ;)03:55
stekernI'm not so sure about the l.ori optimisation, might be possible that the ifs becomes more costly than the actual operation there03:56
poke53281And now the ASSIGNMENT jumps to 2.46 after a second run. No change. What the hell is nbench doing here03:56
poke53281It seems that not everything is translated. Only loops and so on.03:57
poke53281So I am not sure.03:58
poke53281I think the main profit you gain from the l.addi change.03:58
stekernyeah, I think so too03:58
poke53281All my other changes seem to have almost no effect.03:59
poke53281But I have also seen that i386 translates much more to machine code than openrisc.04:00
poke53281stekern: Is it allowed to change r0 by software?04:26
poke53281The specifications seems to say yes here.04:27
poke53281So my first patch is fine.04:32
hansfbaierstekern: isn't r0 supposed to be always constant zero, or am I mixing it up with ARM....04:51
hansfbaiersorccy, poke53281 ^04:51
stekernpoke53281: ah, you bring up the the good ol' r005:05
stekernwe have discussed that a lot and I think the consensus have been (and what the spec now says) that it's implementation specific whether r0 is hardwired to 0 or implemented as a "normal" register05:07
poke53281Can you interpret chapter 4.4 for me. For me it is definitely free.05:08
stekernwriting to r0 is allowed in the sense that it should not have any side-effects05:09
stekerni.e. it should either write the value to r0 or it could be a nop05:09
stekernso qemu as an implementation is free to allow software to write values to r005:10
poke53281specification says: "R0 should05:12
poke53281always hold a zero value. It is the responsibility of software to initialize05:12
poke53281If this is not hardwired than I have two ways to get root rights as a user now.05:13
stekernpossible, but that's an sw issue05:15
poke53281After the initialization it is hardwired. Am I correct?05:16
stekernit can be hardwired or just a normal register05:16
stekernin mor1kx and or1200, it's just a normal register05:17
hansfbaierstekern: why so? Rationale?05:19
poke53281Also in QEMU it is a normal register. In jor1k too. But most of the time because of performance reasons,05:19
stekernhansfbaier: because the registers are implemented as a ram, so giving r0 special treatment would just require extra logic05:19
poke53281Neither the Linux kernel entry nor gcc set this value. The whole toolchain assumes that it is hardwired.05:20
hansfbaierstekern: no flipflops?05:20
poke53281Also syscal05:20
poke53281Also syscall does not set r005:20
hansfbaierwhat would happen if a user program modified it? Couldn't that upset everything?05:21
stekernpoke53281: gcc of course doesn't set it, it's the job of the startup code to do that, and newlib/libgloss do set it05:21
poke53281And this very fast I suppose.05:21
stekerndid that ever get applied (apart from the obvious delay-slot misunderstand change)?05:23
stekernso, yes, there might be bugs in the kernel that makes writing to r0 exploitable05:23
poke53281This is the first time I am seeing this patch05:27
poke53281This patch makes sense05:28
stekernthere wasn't any follow-up on Jonas comments on it, I guess that's why it never got applied05:29
hansfbaierLet's hope the OpenRISC based satellite doesn't run Linux :)05:36
hansfbaierstekern: Can you give me the dts for your de0_nano kernel?05:38
hansfbaierstekern: If I compile my own based on jonas' master, I'll get a crash on boot05:39
hansfbaierstekern: But I still use the or32-linux toolchain for that05:39
poke53281Well, it's not so bad. As long as they don't give user rights on this satellite to me nothing can happen ;)05:39
hansfbaierpoke53281: Yes, but cosmic radiation possibly doesn't ask for user rights ...05:40
poke53281Yes, there are nice stories about cosmic radiation and ECC memory.05:42
poke53281Companies who have bought the same device one manufacturer and complain about, why their system show so much more corrected errors in their ECC log.05:43
mor1kx[mor1kx] skristiansson pushed 1 new commit to master:
mor1kxmor1kx/master 78b7a88 Stefan Kristiansson: bus_if_avalon: remove vector size from OPTION_AVALON_BURST_LENGTH...05:44
poke53281The reason is, that one company has its server farms a few hundred meters higher than the other one.05:44
stekernhansfbaier: it doesn't work with the orpsocv2-de0_nano dts, because orpsocv3-de0_nano doesn't have spi05:45
stekernnor i2c05:45
olofkI see that the never ending r0 story is revived :)05:47
stekernhansfbaier: I don't see how cosmic radiation is related to the r0 exploitability though05:47
stekernolofk: I added i2c support to orpsoc-cores last night05:48
stekernand wrote a i2s core05:49
hansfbaierstekern: I use this:
hansfbaierBut still crashes...05:49
stekernok, that should work05:49
hansfbaierstekern: OpenCores had an I2S controller that looked quite nice to me05:49
olofkstekern: Cool. I'll look for a pull request soon then05:49
hansfbaierstekern: But it might have been VHDL05:49
stekernhansfbaier: i2s is dead simple, it took me less than an hour to write it yesterday05:50
hansfbaierstekern: Yes, it's nice and tidy05:50
olofkI never truly understood why we couldn't just hardwire r0 to zero. The exploitability was exactly what I was worrying about.05:51
hansfbaierstekern: But with that dts, the kernel still crashes...05:51
stekernit became alot cleaner than the ugly implementation that I wrote 4 years ago05:54
stekernmaybe one day I'll become a decent rtl hacker...05:54
hansfbaierstekern: Parallel only has one 'l' at the end05:58
hansfbaierSorry, popped into my eye. Collateral damage from writing a lot of docs05:58
stekernyes, you're right, it's my Swedish origin that shines through there...06:00
hansfbaierstekern: A question: Why do you have three always blocks with the same sensitivity list? What is the difference to one block?06:00
hansfbaierBetter readability?06:01
stekernif you think about them as hw, they are three different "logic circuits"06:06
stekerna clocked counter with reset, gated flip-flops06:11
stekernyou could of course still smack them in a big always block06:12
stekernmatter of taste, I guess...06:13
stekernthere's some difference in regard to event driven simulations when you read a signal from a different block, but I can't remember the details of that06:14
olofkSimulators like to have as few processes as possible06:15
olofkBut changing what you did in i2s.v because of that would just be bike shedding at it's finest06:16
hansfbaierstekern: How would I debug this, any idea:
stekernhansfbaier: oooh, sorry.... now I know...06:29
stekernI completely forgot about that06:29
hansfbaierstekern: It works! Amazing. How did you find that out from the trace?06:35
hansfbaierbio: create slab <bio-0> at 006:35
hansfbaierXGpio: /gpio@91000000: registered06:35
hansfbaierAh I see, that's just when the gpio was initialized.06:35
stekernolofk: we could hardwire r0, but it doesn't remove the problem in the kernel06:35
stekernhansfbaier: intuition06:36
stekernnah, I obviously had hit that problem myself earlier06:36
stekernbut always when you see a bus error on some 0xbc000000 address, it's some peripheral access that have failed06:40
hansfbaierstekern: good to know, thanks.06:50
PowermaniacInteresting news, I visited UniSA today. And well they seem to think what you guys have done is impossible...07:43
PowermaniacIn a sense that is what they said...07:43
PowermaniacMore they said for one person to do what you have done would be impossible.07:44
PowermaniacBut on a related note I was wondering how much has been implemented on the ORPSoCv3 as in how much in the way of peripheral devices running through it has it got working/running already?07:44
PowermaniacBut yeah it was more they thought my idea, making an entirely open source computer,  wasn't really possible07:52
PowermaniacOr well I just don't have enough time according to them to learn everything and get up to scratch before even going to uni.07:52
stekernwell, we're not one person, and the openrisc project have been going on for over ten years07:53
PowermaniacYeah I know the OpenCores/OpenRISC team isn't one person07:53
PowermaniacThey seem to not be up to date with how much progress you guys have made07:53
PowermaniacWhich I was surprised about07:53
PowermaniacBut I didn't try and ram it home that you have basically done what I wish to already for me.07:53
PowermaniacWell not for me exactly , but you get what I mean07:54
stekerndid they know about the project at all?07:58
PowermaniacYeah one of the guys knew about the project07:58
PowermaniacBut he said he knew about it from a fair while ago07:59
PowermaniacThey seemed surprised that I had learnt so much since I first emailed them like 3 weeks back. All thanks to you guys08:03
PowermaniacNote both of them were professors at UniSA08:06
hansfbaierstekern: ping, does this arrive?08:39
stekernhansfbaier: pong08:41
hansfbaierstekern: Thanks, I get those annoying messages that I have been banned because my IP address is on dronebl.org08:42
hansfbaierstekern: Banned: Open proxy or TOR (auto-detected; hansfbaier!~jack) (2013/10/16 10.29)08:42
hansfbaierstekern: But obviously irc still works. Maybe got the wrong dynamic IP address08:42
hansfbaierstekern: anyway, orpsocv3 on de0_nano seems to be pretty anaemic still, no i2c/spi, etc, etc....08:44
hansfbaierstekern: also, wouldn't it be a nice idea to put the serial on one of the top headers by default... I could do the changes and fork the repo if you like....08:46
stekernthe changes are already done in julius repo08:49
stekernwhat's wrong with the one in the bottom?08:50
stekernmost breakoutboards seemed to use the top headers, that's why I choose that08:50
hansfbaierstekern: I can't put the nano flat on the table...08:50
hansfbaierstekern: I see.08:51
hansfbaierstekern: And I don't have a 13 pin header cable...08:51
hansfbaierstekern: What would you recommend, using julius' repo for de0_nano and yours for sockit?08:52
stekernno, use opencores/orpsoc-cores08:52
stekernerr openrisc/orpsoc-cores08:52
stekernjulius was for the workshop08:53
stekernand sockit should be added there as well08:54
hansfbaierstekern: So I could discontinue using your repo in the tutorial too?08:54
hansfbaierstekern: I can't see sockit in there, yet.08:54
hansfbaierso no.08:54
stekernnot yet08:55
hansfbaierstekern: de0_nano has no spi/i2c there yet, too.08:57
stekernfeel free to add them as an exercise08:57
hansfbaierstekern: Yes, I'd love to.08:58
stekernI'll send out the i2c.core addition right away to give you a bit of help with that ;)09:00
hansfbaierstekern: Where should I fetch the cores from, opencores directly, or are there more up to date versions somewhere on
stekernthere are no cores on openrisc.net09:03
hansfbaierstekern: but in your github for example09:03
stekernthe SPI core used in orpsocv2 was from opencores09:04
stekernbut with a lot of changes09:04
stekernor some changes, I haven't checked how much09:04
hansfbaierstekern: What would be best there? Use opencores and supply patch?09:04
hansfbaierstekern: upstreaming?09:05
stekernso, what you need to do is do a diff between the SPI core from opencores and the one in orpsocv2 and generate patches for the differences (that makes sense)09:05
hansfbaierstekern: or directly use orpsocv2 as a repo. Would be kind-of-upgly for orpsoc3 to depend on v2...09:05
hansfbaierstekern: OK.09:05
stekernusing orpsocv2 as a repo would be a nono ;)09:06
stekernyou can look at the vga_lcd core for an example09:07
hansfbaierstekern: or jtag_tap.core?09:09
hansfbaieror uart 16550...?09:09
hansfbaierI'll use the uart09:09
hansfbaierstekern: OK got it.09:10
stekernpersonally, I prefer git formatted patches09:11
stekernbut olofk seems to like diff style patches too09:11
stekernso I guess it's up to you to choose which style to choose09:12
hansfbaierstekern: Can I build a single core, or do I have to include it into a system first, before it checks the core out from svn? (The latter I suppose...)09:21
stekernwhat do you mean by "build"09:22
stekernI don't think you can just fetch it, if that's what you mean09:23
stekernolofk, fill in...09:23
hansfbaierstekern: Ah, fetch is not yet in the command line description?09:24
stekernI don't know09:24
stekernuse the source, warrior!09:24
stekernI would like to have a seperate prepare command09:25
stekernthat populates the build/src directory09:26
hansfbaierstekern: Any rules for commit messages?09:29
hansfbaierstekern: make them look similar like the others, I suppose...09:29
stekernmake them good ;)09:32
stekernolofk: didn't you apply this?
stekernhansfbaier: i2c:
hansfbaierstekern: Hey, I was about to do that.09:38
stekern08:48 < stekern> olofk: I added i2c support to orpsoc-cores last night09:39
hansfbaierstekern: So I'll go straight to SPI?09:40
hansfbaierand forget about i2c?09:40
stekern12:00 < stekern> I'll send out the i2c.core addition right away to give you a bit of help with that ;)09:40
hansfbaierstekern: why revision 74 instead of 76?09:40
stekernyes, hop-on SPI straight away09:40
stekernumm, typo perhaps?09:41
stekernlemme check09:41
hansfbaierstekern: 76 seems to be latest...09:42
stekernah... I was in rtl/verilog when I checked the revision, 74 is the latest change there09:42
stekernso 74 or 76, doesn't matter09:43
hansfbaierstekern: should I base SPI on latest?09:43
stekernI suppose09:43
hansfbaierstekern: diff ok like this?
hansfbaierstekern: I probably should remove the a/ b/ paths, right?09:55
stekernask olofk, as I said *I* prefer git formatted patches09:55 in the vga_lcd core09:55
hansfbaierolofk: ^09:56
hansfbaierstekern: Or I just commit and send him a pull request...09:56
stekernbecause, there, the commit messages are preserved09:57
hansfbaierstekern: So I should try to get the orig commit from orpsocv2 instead of diffing myself.09:57
stekernthat might be hard... but, if you can pinpoint, it probably doesn't hurt to make a comment about it in the commit message09:58
hansfbaierstekern: But the diffs look totally different than the diffs to current.09:59
hansfbaierstekern: You still leave me seriously confused as to where I should get the git diff.10:02
stekernyes, hence the "that might be hard...."10:03
hansfbaierstekern: maybe the diff from orpsocv2 was based on a different revision....10:04
hansfbaierstekern: and the first diff looks much prettier10:04
hansfbaierI would tend to take the first one10:04
hansfbaierstekern: I got the second with git log -p *.v10:05
hansfbaierstekern: that should get me the history on those files10:05
stekernwhat I meant was that: break the diffs out like in the diff you pasted first, if you use git format patch to produce it, add a note in the commit message: "this was taken from a big code dump commit to orpsocv2"10:05
stekernor something like that10:05
stekernjust to note where the change origined from10:05
stekernjust my opinion10:06
hansfbaierstekern: Ah, I get it.10:06
PowermaniacIs the ORPSoCv3 also available in VHDL?10:10
PowermaniacAs UniSA only teaches VHDL not Verilog...10:10
hansfbaierPowermaniac: No, you can't get good open source tools for VHDL.10:11
PowermaniacAhh okay10:11
PowermaniacVerilog it is then...10:11
hansfbaierPowermaniac: So the open source scene seems to mainly zoom in to verilog10:11
hansfbaierPowermaniac: icarus verilog and verilator rule10:11
hansfbaierPowermaniac: icarus has recently been added support for synthesizable VHDL too10:12
hansfbaierPowermaniac: good news10:12
PowermaniacMaybe you might find this interesting, hansfbaier. I was told today by two professors that what I wish to do isn't really possible for one person...See they didn't seem to realise you guys have sort of done most the work for me10:12
PowermaniacThe idea of making a fully open source computer10:12
hansfbaierstekern: Sorry to bother you again, the top file has been renamed in orpsoc, how would I handle that?10:12
hansfbaierPowermaniac: Tell the profs the open source community isn't one person and whether they heard of opencores.org10:13
Powermaniachansfbaier: I've forgotten again, sorry. But how did you learn verilof?10:13
hansfbaierPowermaniac: different sources10:13
PowermaniacOh okay10:14
PowermaniacAny of them in English?10:14
stekernhansfbaier: *shrug*, the same change was in i2c, I didn't bother to create a diff for that10:14
Powermaniachansfbaier: Oh and I told them about opencores and openrisc. And one of them knew about it but from a fair while ago it seems and they didn't seem to realise how much you have already all done.10:15
stekernit's a bit ugly with the _top when instantiating the cores, but other than that, it does no harm.10:15
PowermaniacSo can someone enlighten me on how much is actually implemented on the ORPSoCv3 to connect periphereals that are open source themselves and prat of OpenCores?10:16
Powermaniachansfbaier: Oh thank you.10:17
hansfbaierPowermaniac: got those on the web10:17
hansfbaiergoogle is your friend :)10:17
hansfbaierPowermaniac: the .core files in orpsoc-cores/cores10:18
stekernPowermaniac: VHDL and verilog isn't that different in the end, digital design is more about "thinking the right way" anyway, language choice is just a matter of syntax10:19
Powermaniacstekern: Oh okay10:19
stekernthere's a few gotchas and things you can't do in VHDL and vice vers, but apart from that most constructs are directly translatable10:21
stekernespecially on novice level10:21
hansfbaierstekern: So should I let the _top be, but How do I tell orpsoc if to rename?10:21
PowermaniacSo is there a hdmi connection, ethernet (I assume there is ethernet because aren't you using ethernet with the ORPSoCv3 on one of your FPGA boards?), usb (Also asume it has this), all compatible and running on the ORPSoCv3>10:22
stekernhansfbaier: tell orpsoc what?10:22
Powermaniacyou* being stekern*10:22
hansfbaierstekern: to rename the simple_spi_top.v -> simple_spi.v10:22
Powermaniachansfbaier: Are these the cores you were talking about:
hansfbaierPowermaniac: yes10:23
hansfbaierThere you find the reference where each one is from10:23
stekernhansfbaier: you either remove the _top or you don't10:24
stekernI don't understand the problem10:24
hansfbaierstekern: Like this maybe?
stekernthat looks ugly, what are you trying to show?10:28
stekernsorry for being dense...10:29
hansfbaierstekern: in the svn checkout the file is named simple_spi_top.v, in orpsocv2 it's named simple_spi.v10:30
hansfbaierstekern: Yes the diff looks ugly, but i didn't do it ..... 8-P10:30
stekernyou don't need to make it *exactly* look like orpsocv210:31
hansfbaierstekern: Will orpsoc rename it after it is checked out, if the diff looks like this?10:31
hansfbaierstekern: So it's okay, if still named simple_spi_top.v ?10:31
stekernthere might be stuff there that we *don't* want to move into orpsocv310:32
stekernI say it's ok if it's still named simple_spi_top.v10:32
stekernIMO, we should only create patches that are really needed10:33
hansfbaierstekern: But the diff looks bad in another way: It seems to throw away new / cleaner functionality10:33
hansfbaierstekern: Ok, just the orig, and patch if things blow up? Would be much cleaner10:33
hansfbaierstekern: I dont like the patch on _top10:33
hansfbaierstekern: and the #1 annotations don't hurt too, since they are just ignored by the synthesizer....10:34
PowermaniacWell I'm need to disappear. So goodnight everyone!10:35
hansfbaierstekern: Should I fork orpsoc-cores and send pull requests?10:39
hansfbaierstekern: or just send patches?10:39
stekernI think olofk likes pull requests10:40
hansfbaierstekern: ok10:40
hansfbaiernvmind: Please notify me when you are done with your thesis. I'm interested10:43
hansfbaiernvmind: Or if I can help10:43
nvmindbtw I found out why I wasn't able to connect to the jtag on board :)10:48
nvmindI made another silly mistake10:48
stekernin hindsight most mistakes are silly ;)10:49
nvmindI was exposing a positive reset signal that was attached to a normally high button :)10:49
hansfbaiernvmind: You will get a very stable system.... :)10:51
stekernI wonder how many hours have been wasted on reset polarity problems...10:51
nvmindIn my case? A couple of weeks10:51
nvmindbut that give me the time to move to openocd10:52
stekernI've certainly have a fair amount of hours on that account as well10:52
hansfbaierstekern: for a humble start10:56
hansfbaierolofk: ^10:57
hansfbaierstekern: I'll care about diffs tomorrow.10:57
hansfbaierstekern: with a fresh mind.10:57
stekernfair enough ;)11:01
_franck_nvmind: great to hear it works now11:45
nvmind_franck_: :)15:09
rahstekern: is the ethernet controller core in your atlys image "encumbered"?15:46
rahstekern: is it restricted by an NDA from Marvell?15:49
juliusbrah: what model is it? there's some *8811* one which always was under NDA, annoyingly16:05
rahjuliusb: my question is about the core though16:08
juliusboh you mean the ethernet MAC RTL?16:09
rahjuliusb: I'm concerned about whether the core has been developed under NDA, which I presume would mean it could not be licensed freely16:09
juliusbis it an encrypted netlist or something? or encumbered because it's poorly written?16:09
juliusboh, if it's the OpenCores one, then no, it's under the LGPL, so intended to be freely used and available16:09
rahjuliusb: there's a misunderstanding16:10
rahjuliusb: I'm asking what core is used16:10
rahjuliusb: I don't know whether it's an OpenCores core, I'm asking whether it is16:11
juliusbhighly likely it is16:45
stekernrah: the MAC core that is used is the ethmac core from opencores16:51
stekernyou are speaking about the PHY, which is an external chip16:51
rahstekern: no, the MAC core16:52
rahstekern: from :16:53
rah"The tri-mode Ethernet physical requires the EDK, so you can't use it directly with WebPack. Additionally, Marvell in their infinite wisdom don't let you read their data sheet until you sign an NDA. There are various efforts underway to get ethernet working without using encumbered cores or datasheets, but so far I've not checked any of them."16:53
stekernthe only thing that is under NDA is the datasheet for the marvell PHY16:54
stekernregardless of what you think you read out of that page16:55
stekernthe "encumbered" ethernet MACs he is speaking about is Xilinx MAC core, which is not under NDA, but you need(ed) a ISE license to be able to use it16:59
stekernbut, we are not using that, we are using the LGPL opencores MAC17:00
rahstekern: I'm glad to hear you're usnig an LGPL core19:03
rahstekern: my concern though was that the core in the image might have been non-free because the NDA prohibited distributing source for cores developed using the information that was disclosed in the datasheet19:05
amsrah: an nda isn't a copyright license, if you violate the nda you violate the nda, not the copyright license.19:23
amswhich is why it is perfecly legal for companies to develop GPL software, but prohibiting their employees from distributing the changes.19:25
rahams: an nda is just an agreement, it can mean pretty much anything19:27
amsrah: no, not really.19:27
rahams: and "pretty much anything" includes agreements not to freely license copyrighted works created using disclosed information19:27
hansfbaierstekern: I merged the changes from orpsocv2 into svn revision 10. Would you please review:
hansfbaierstekern: first timit RTL hacking...19:28
hansfbaierstekern: I also wonder why it says if (~spe | rst_i) and not if (~spe | ~rst_i) in the code since rst_i is active low, but I didn't want to change the semantics of the old code if it works19:29
stekernrah: I guess it's time for some ethernet 101... An ethernet solution consists of a MAC and a PHY, those are connected via an MII interface. the MII interface consists of two parts, the actual data exchange and a management interface19:29
stekernboth are standard protocols19:30
rahstekern: I know19:30
hansfbaierstekern: Note: git patch format :)19:30
stekernthe management interface consist of a set of registers, which of some are standardized19:30
stekernthe marvell NDA covers a set of registers not covered by the standard19:31
stekernthe MAC doesn't need to know *anything* about the registers in the management interface, it just have to present a mean to access them19:32
stekernthus, a MAC implementation have nothing to do with the marvell NDA19:33
rahI see19:33
rahto what does the MAC present a means to access the registers, the driver?19:33
rahI see19:34
* hansfbaier -> bed19:34
rfajardohello there, have anyone seen this lately?20:21
rfajardo*** Missing UAPI file /Users/Raul/development/or1k/linux/include/uapi/linux/netfilter/xt_CONNMARK.h.  Stop.20:21
rfajardoby installing the Linux headers?20:22
rfajardoIt seems it wasn't there because my connection dropped when cloning…21:03
--- Log closed Thu Oct 17 00:00:43 2013

Generated by 2.15.2 by Marius Gedminas - find it at!