From 9933cec0a18ae2a3d752f269d1bb12c19f51199d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 21 Jul 2013 15:35:02 -0400 Subject: IRC. --- community/gsoc/2013/nlightnfotis.mdwn | 450 ++++++++++++++++++++++++++++++++++ 1 file changed, 450 insertions(+) create mode 100644 community/gsoc/2013/nlightnfotis.mdwn (limited to 'community/gsoc/2013/nlightnfotis.mdwn') diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn new file mode 100644 index 00000000..43f9b14c --- /dev/null +++ b/community/gsoc/2013/nlightnfotis.mdwn @@ -0,0 +1,450 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2013-06-29 + + so, how is your golang port going? + I just started working on it. I had been reading + documentation so far. Maybe over reading as people told me when I asked + for their feedback + but I will report on what I have done (technically tomorrow, + and post it in the mailing list too. + + Hey guys, what could possibly cause the following error + message when executing a program in the Hurd? "./dumper: Could not open + note: (system server) error with unknown subsystem" + My program is one that opens a file and dumps it into stdout + pinotree: the code I am using is the one present here + http://www.gnu.org/software/hurd/hacking-guide/hhg.html under paragraph + 6.1 + I investigated it a bit but can not find a lead. I seem to + have all the rights to open the file that I want to dump to stdout + what if you reset errno to 0 just after all the declarations in + main, before the instructions? + will check this out and get back to you. + sure :) + pinotree: Now it suggests that it can't get the number of + readable files, which the source suggests that is normal behavior. + Thanks for your assistance. + + +# IRC, freenode, #hurd, 2013-07-01 + + youpi: from my part I can report that I have started working + with the code, and doing as Thomas suggested. I was about to write my + report yesterday, but I am facing some build errors on the HURD, which I + would like to investigate further before I write my report. + that's why I decided to write it later in the day. + I don't think you have to wait + you can simply write in your report that you are having build + errors + ok. I will have it written and delivered later in the day. + braunr: that's cool. I think my reading has paid for + itself. And you may be pleased to know that I have gotten my hands dirty + with the code. I was about to write report yesterday, but some build + errors with the gcc (that I am investigating atm) are holding me + off. Will have that written later in the day. + don't hesitate to ask help about build errors + don't wait too much + you need to progress on what matters, and not be blocked by + secondary problems + I will see myself asking for help rather sooner than later, + but I would like to investigate it myself, and attempt to solve the + issues that occur to me before resort to bugging you guys. + sure + just not too long + too long being a day or so + these were my build_results on the hurd + they were linker errors + + https://gist.github.com/NlightNFotis/5896188#file-build_results + I am trying to build gcc on a linux 32 bit environment. It + also has some issues but not linker errors + will resolve them to see if the linker errors are + reproducible on linux + oh, lex stuff + should be easy enough + + +# IRC, freenode, #hurd, 2013-07-05 + + I have not made much progress, but I see myself working with + it. + I have managed to build gcc go on Linux + but Hurd seems to have some issues + it seems to randomly crash + the build process? + not quite randomly it seems to be though + yeah + I have noticed that there is a pattern + it does crash after some time + ^^ + but it doesn't crash at specific files + define crash + at some times it may crash during compiling insn-emit.c + (hello guys) + hi braunr :) + braunr: hey there! It does seem to keep on compiling this + file for a very long time (I have let it do so for 10, 20, 30 minutes) + but the result is the same + and it does so for different files for different build + options + ok so it doesn't crash + it just doesn't complete + is the virtual machine eating 100% cpu during that time ? + I can still type at the terminal, but I can't send a term + signal + I can report that QEMU does hold 100% of one core at that + time, (like it keeps processing) but there is no output on the terminal + ok + of course I can type at the terminal + but nothing happens + any idea of the size of the files involved ? + I am checking it out right now + before this goes any further, let me report on my + investigation + i expect that to be our classic writeback thread storm issue + initially, I thought it might be that it run out of memory + even though I know that compilation is not memory intensive, + rather, cpu intensive + anyway I increased the size of ram available to the vm + from 1024 mb to 1536 + that didn't seem to have any effect. The "crash" still + happens at the same time, at the same files + use freeze + not crash + crash is very misleading here + freeze it is then. + anyway + then it striked me that it might be that the hard disk size + (3gb) might be too small (considering the gcc git repo is 1gb+) + so I resized the qemu image to 8gb of hdd size + the new size is acknowledged by the vm + for gcc in debug mode? might still not be enough + but still it has no effect - it seems to follow its freezing + patterns + giving your work, i'd have not less than 15-20 + i'd use 32 + *given + but that's because i like power of twos + pinotree: thanks for the advice. Right now I was gonna + increase the swap size + according to vmstat in the hurd + swap size is 173 mb + don't know if it does have an impact + it may but before rushing + if you need swap, you're doomed anyway + consider swap highly unreliable on the hurd + please show the output of df -h on the file system you're using to + build + ideally, i'd recommend using separate / and /home file systems + it really improves reliability + I don't think it swaps to be honest; however that's + something that my mentor thomas had suggested (increasing swap size) so I + am gonna try it at some time. + or have a separate file system in a subdi and work on it + yes, /home or whatever suits you + just not / + braunr: pinotree: thanks both for your advice. Will do now, + and report on the results. + that's not all + 11:17 < braunr> please show the output of df -h on the file system + you're using to build + braunr: I am on it. Oh and btw, everytime I am forced to + close the vm (due to the freezes) when I restart it ext2 reports that the + file system was not cleanly unmounted and does some repair to some + files. I am trying to find an explanation for that, but I can think of + many things + well obviously + ext2 has no journaling + the file system was not cleanly unmounted since you restarted it + with a cold reset + braunr: df -h comes out with this: "df: cannot read table of + mounted file systems" + also, even if you manage to always shut down correctly, when + fsck runs because of the maximum mount count it'd find errors anyway (so + we have some bug) + nlightnfotis: df -h /path/to/build/dir + pinotree: not really bugs but it could be cleaned up + filesystem: - Size 2.8G Used 2.8G Avail 0 Use% 100% Mounted + on / + wow + nlightnfotis: see + that seems to explain many things + ^^ + thanks for that braunr! + you resized the disk, but not the partition and the file system + braunr: well, if something in ext2 (or its libs) leaves issues + in the fs, i'd call that a bug :> + yeah, that was utterly stupid of me + pinotree: they're not issues + nlightnfotis: be careful, mach needs a reboot every time you + change a partition table + nlightnfotis: important thing is that you found the issue :) + then only, you can use resize2fs + braunr: weird, I thought mach nowadays can reload the partition + tables? + braunr: doesn't d-i need that? + maybe a recent change i forgot + or maybe fdisk still reports the error although it's fine + in doubt, rebooting is still safe :p + or maybe youpi hacked it into d-is gnumach + i doubt it would be there for the installer only :) + if it's there, it's there + i just don't know it + braunr: teythoon: and everyone else that helped me. Thanks + you all guys. This was something that was driving me crazy. Will do all + that you suggested and report back on my status + + +# IRC, freenode, #hurd, 2013-07-08 + + tschwinge, I have managed to overcome most of the obstacles + I had initially faced with my project + but I still had some build errors, that's why I have not + reported yet. Wanna try to see if I can resolve them today, and write my + report in the afternoon. + nlightnfotis: So, from a quick look into the IRC backlog, it + was a "simple" out of disk space problem? %-) That happens. + nlightnfotis: And yes, GCC needs a lot of disk space. + nlightnfotis: What kind of build errors are you seeing now? + tschwinge, yeah I felt stupid at the time, but it didn't + actually strike me that the file system didn't see the extra space. Also + it took me some time to figure out that in order to mount the new + partition, I only had to edit /etc/fstab + always tried to mount it with the ext2 translator + and the translator kept dying + but it's all figured out now + the latest build errors I am seeing are these + nlightnfotis: o_O you used fstab and it worked? + yeah + nlightnfotis: that's unexpected from my perspective... + I only had to add the new partition into fstab + teythoon: I can pastebin my fstab if you wanna take a look + at it + tschwinge: these were my latest build errors + https://www.dropbox.com/s/b0pssdnfa22ajbp/build_results + nlightnfotis: I'm pretty sure that mount -a isn't done on hurd + w/o pinos runsystem.sysv + weird + tschwinge: I have also tried to build gcc with "make -w" + which from what I know supresses the errors that stopped compilation + but the weird thing is that gcc nearly took forever to build + nlightnfotis: could you do a showtrans /your/mountpoint? + teythoon: /hurd/ext2fs /dev/hd0s3 + nlightnfotis: ok, so you've set a passive translator and an + active is started on demand + it must be a passive translator + nlightnfotis: this is the hurd way of doing things, fstab is + unrelated + it seems to persist during reboots + yes, exactly + teythoon: my fstab if you wanna take a look + http://pastebin.com/ef94JPhG + after I added /dev/hd0s3 to fstab along with its mountpoint, + and restarting the hurd, only then I did manage to use that partition + before doing so I tried pretty much anything involving + mounting the partition and setting the ext2fs translator for it, but it + kept dying + of course it was a ext2 filesystem + err, perhaps adding to fstab simply triggered an fsck at reboot? + nlightnfotis: might have been that you needed to reboot mach so + that it picks up the new partition table + youpi: I thought this was fixed, the partition reloading I mean? + that is needed, yes + let me check + youpi: it could be, though, to be honest, my hurd system + does an fsck all the time at boot + how do you manage to do that w/o rebooting for d-i? + (I don't remember whether device busy is detected) + teythoon: by making all translators go away, iirc + nlightnfotis: btw, you have ~/gcc_new as mountpoint in your + fstab, pretty sure that this cannot work, the path has to be absolute and + no ~ expansion is done + tbh it does work, and it's weird + nlightnfotis: it works b/c of the passive translator you set, + not b/c of the fstab entry + teythoon: should I change it? + probably, yes + Well, that is probably not used anywhere. + tschwinge: not yet but soon ;) + Isn't /etc/fstab only consulted for fsck. + atm yes + Anyway, it is definitely a very good idea to have a partition + separate from the rootfs for doing actual work. + I think I described that in one of the first GSoC coodridation + emails. In the long one. + teythoon: Oh it struck me now! Is it because tilde expansion + is only happening in bash, but /etc/fstab is read before bash is + initialized? + nlightnfotis: Instead of fumbling around with partitioning of + disk images, it may be easier in your KVM/QEMU setup to simply add a new + disk using -hdb [file] (or similar). + nlightnfotis: Basically, yes. + nlightnfotis: fstab is not related with bash in any way + anyway, it shouldn't matter now, it seems to be working, and + I wouldn't like fiddling around with it and messing it up now. I will + continue with resolving the gcc issues. + But /etc/fstab has its very own "language" (layout), so tilde + expansion will never be done there. + nlightnfotis: df -h ~/gcc_new/ + tschwinge: size 24G Used: 4.2G Avail 18G + OK, that's fine. + As you can see on + , GCC + will easily need some GiB. + tschwinge: I have some questions about GCC: out of curiosity + how much time does it take to compile it on your machine? Because + yesterday I tried a -w (suppress warnings) build and it seemed to take + forever + mind you the vm has 1536 ram available (I have read + somewhere that it can utilise such an amount) and the vm is KVM enabled + without disabling g++, it can easily take hours + nlightnfotis: The build error is unexpected, because I had + addressed that issue in a recent patch. :-) + nlightnfotis: This is wrong: »checking whether setcontext + clobbers TLS variables... [...] yes«. Please check your sources, that + they correspond to the current version of the upstream + tschwinge/t/hurd/go branch. + nlightnfotis: Quoting from that wiki page: »This takes up + around 3.5 GiB, and needs roughly 3.5 h on kepler.SCHWINGE and 15 h on + coulomb.SCHWINGE.« The latter is my Hurd machine. + That's however with Java and Ada enabled, and a full + three-stages bootstrap. + ah, right, there's java & ada too + tschwinge: git branch (in the repo): master, + *tschwinge/t/hurd/go + in debian they are built separately + What I asked you to do is configure »--disable-bootstrap + --enable-languages=go«. + So that should be a lot quicker. + tschwinge: oh yes, everytime I have tried to compile gcc I + have done with these configurations + But still a few hours perhaps. + that's what I did yesterday too. + OK, good. :-) + A bootstrap build is a good way to check the just-built GCC for + sanity, but we expect that it is fine, as we concentrate on the GCC Go + port. + the only "extra" configuration yesterday was my "-w" flag to + make, because those errors were actually triggered by -Werror + Let me read up what make -w does. ;-) + ah, yes, d/w I have read and understood what the bootstrap + build is. Seems like we don't need it atm + afaik it suppresses all warnings + youpi: gcj no more + the way gcc builds, it does convert (some) warnings to + errors + Hmm. -w, --print-directory Print a message containing the + working directory before and after other processing. + youpi: doko folded gcj and gdc into gcc-4.8 to "workaround" + Built-Using + nlightnfotis: Ah, that'S configure --enable-werror or something + like that. + pinotree: right + yep, and -w suppresses it + (from what I have understood) + nlightnfotis: Are you thinking about make -k? + Yeah, I guess. + let me see what -k does + youpi: (just to make builds even more lightweight, eh) + yeah, -k should do too, I shall try it + But: if gcc -Werror fails, even with make -k, the build will + not be able to come to a successful end, because that one complation + artefact that failed will be missing. + so I shall try again with -w (supressed warnings) + Configureing with --disable-werror (or similar) will "help" if + -Werror is the default, and the build fails due to that. + from what I have understood these "errors" are not something + critical: it's only that function prototypes for these functions are + missing + I have seen the code there, and even "default" gcc generated + prototypes (from the first usage of the function) should do, so I can't + understand why it might be a serious problem if I tell gcc to skip that + point + nlightnfotis: Ah, now I see. You don't mean make -w, but + rather gcc -w: »-w Inhibit all warning messages.« + But really, there shouldn't be such warnings/errors that make + the build fail. + yeah + nlightnfotis: In your GCC sources directory, what does this + tell: git rev-parse HEAD + And, is the checkout clean: git status + The latter will take some time. + git status takes an awful amount of time + last I checked + but git rev-parse HEAD + produces this result: + 91840dfb3942a8d241cc4f0e573e5a9956011532 + OK, that's correct. So probably some of the checked out files + are not in a pristine state? + I shall run a git clean and see. If that doesn't work too, + maybe I shall reclone the repository? + there's nothing foreign to the repo that I have added, only + lib gmp, lib mpc and lib mpfr (and they are in their own folders inside + my gcc working directory) + nlightnfotis: You shouldn't need to do the latter if you + instead run: apt-get build-dep gcc-4.8 + I remember having done that inside the Hurd, but it always + resulted in an error from what I can recall + let me check this out + yes + nlightnfotis: Whenever you use Git on Hurd, pass the --quiet + flag, to avoid the rare but possible corruption issue described on + + and . + tschwinge: Forgive me for that. I will set up an alias + immediately. + nlightnfotis: I don't know if an alias is possible, because -- + I think -- you'll need to do things like: git fetch --quiet + So pass --quiet to subcommands. + oh. ok. + nlightnfotis: What you can also do, is shut down your Hurd VM, + and mount the disk image on GNU/Linux (mount with offset to get the right + partition), and then run a diff -ru against a Git clone done on + GNU/Linux, and see whether there are any unexpected differences outside + of the .git/ directory. + sounds like a plan. I will check this out today then :) + tschwinge: if all else fails, then recloning the repo with + --quiet passed should work, right? + Yes, that's probably the most straight-forward check to do. + Heh, yes to both these questions. :-) + nlightnfotis: Oh, you don't even have to re-clone, but rather + re-check-out the branch. + I was thinking of recloning just to bring the whole + repository to a pristine state + So something like (inside the source directory): rm -rf ./* + (remove any files, but leave .* in place, in particular the .git/ + directory), followd by git checkout -f HEAD --quiet + nlightnfotis: But before doing that, please do the diff first, + so that we know (hopefully) where the erroneous build results were coming + from. + considering the Copyright assignment files, I have sent them + from day 1 (that is the 20th of June). I have not heard anything about + those documents to date (sadly) + what's worst is that although I have a reference number to + track those documents, their (greek postal office) tracking service sucks + so badly, that one day it's offline, the next it suggests it can't find + the object in their database, the next it says it is still in the local + post office + let me check it out now + still nothing from their online service + let me call them + tschwinge: I called the post office regarding the copyright + papers. They told me that the same day (the 20th of June) it left from + Herakleion, Crete to Athens and the same day it must have left the + country heading towards the US. They also told me it takes about 1 week + for it to arrive. + nlightnfotis: OK, so probably waiting at the FSF office to be + processed. Let's allow for some more time. After all, this is not + critical for your progress. -- cgit v1.2.3