1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
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
<teythoon> so, how is your golang port going?
<nlightnfotis> 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
<nlightnfotis> but I will report on what I have done (technically tomorrow,
and post it in the mailing list too.
<nlightnfotis> 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"
<nlightnfotis> My program is one that opens a file and dumps it into stdout
<nlightnfotis> 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
<nlightnfotis> 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
<pinotree> what if you reset errno to 0 just after all the declarations in
main, before the instructions?
<nlightnfotis> will check this out and get back to you.
<pinotree> sure :)
<nlightnfotis> 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
<nlightnfotis> 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.
<nlightnfotis> that's why I decided to write it later in the day.
<youpi> I don't think you have to wait
<youpi> you can simply write in your report that you are having build
errors
<nlightnfotis> ok. I will have it written and delivered later in the day.
<nlightnfotis> 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.
<braunr> don't hesitate to ask help about build errors
<braunr> don't wait too much
<braunr> you need to progress on what matters, and not be blocked by
secondary problems
<nlightnfotis> 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.
<braunr> sure
<braunr> just not too long
<braunr> too long being a day or so
<nlightnfotis> these were my build_results on the hurd
<nlightnfotis> they were linker errors
<nlightnfotis>
https://gist.github.com/NlightNFotis/5896188#file-build_results
<nlightnfotis> I am trying to build gcc on a linux 32 bit environment. It
also has some issues but not linker errors
<nlightnfotis> will resolve them to see if the linker errors are
reproducible on linux
<braunr> oh, lex stuff
<braunr> should be easy enough
# IRC, freenode, #hurd, 2013-07-05
<nlightnfotis> I have not made much progress, but I see myself working with
it.
<nlightnfotis> I have managed to build gcc go on Linux
<nlightnfotis> but Hurd seems to have some issues
<nlightnfotis> it seems to randomly crash
<teythoon> the build process?
<nlightnfotis> not quite randomly it seems to be though
<nlightnfotis> yeah
<nlightnfotis> I have noticed that there is a pattern
<nlightnfotis> it does crash after some time
<teythoon> ^^
<nlightnfotis> but it doesn't crash at specific files
<braunr> define crash
<nlightnfotis> at some times it may crash during compiling insn-emit.c
<braunr> (hello guys)
<teythoon> hi braunr :)
<nlightnfotis> 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
<nlightnfotis> and it does so for different files for different build
options
<braunr> ok so it doesn't crash
<braunr> it just doesn't complete
<braunr> is the virtual machine eating 100% cpu during that time ?
<nlightnfotis> I can still type at the terminal, but I can't send a term
signal
<nlightnfotis> 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
<braunr> ok
<nlightnfotis> of course I can type at the terminal
<nlightnfotis> but nothing happens
<braunr> any idea of the size of the files involved ?
<nlightnfotis> I am checking it out right now
<nlightnfotis> before this goes any further, let me report on my
investigation
<braunr> i expect that to be our classic writeback thread storm issue
<nlightnfotis> initially, I thought it might be that it run out of memory
<nlightnfotis> even though I know that compilation is not memory intensive,
rather, cpu intensive
<nlightnfotis> anyway I increased the size of ram available to the vm
<nlightnfotis> from 1024 mb to 1536
<nlightnfotis> that didn't seem to have any effect. The "crash" still
happens at the same time, at the same files
<braunr> use freeze
<braunr> not crash
<braunr> crash is very misleading here
<nlightnfotis> freeze it is then.
<nlightnfotis> anyway
<nlightnfotis> 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+)
<nlightnfotis> so I resized the qemu image to 8gb of hdd size
<nlightnfotis> the new size is acknowledged by the vm
<pinotree> for gcc in debug mode? might still not be enough
<nlightnfotis> but still it has no effect - it seems to follow its freezing
patterns
<pinotree> giving your work, i'd have not less than 15-20
<braunr> i'd use 32
<pinotree> *given
<braunr> but that's because i like power of twos
<nlightnfotis> pinotree: thanks for the advice. Right now I was gonna
increase the swap size
<nlightnfotis> according to vmstat in the hurd
<nlightnfotis> swap size is 173 mb
<nlightnfotis> don't know if it does have an impact
<braunr> it may but before rushing
<braunr> if you need swap, you're doomed anyway
<braunr> consider swap highly unreliable on the hurd
<braunr> please show the output of df -h on the file system you're using to
build
<braunr> ideally, i'd recommend using separate / and /home file systems
<braunr> it really improves reliability
<nlightnfotis> 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.
<pinotree> or have a separate file system in a subdi and work on it
<braunr> yes, /home or whatever suits you
<braunr> just not /
<nlightnfotis> braunr: pinotree: thanks both for your advice. Will do now,
and report on the results.
<braunr> that's not all
<braunr> 11:17 < braunr> please show the output of df -h on the file system
you're using to build
<nlightnfotis> 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
<braunr> well obviously
<pinotree> ext2 has no journaling
<braunr> the file system was not cleanly unmounted since you restarted it
with a cold reset
<nlightnfotis> braunr: df -h comes out with this: "df: cannot read table of
mounted file systems"
<pinotree> 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)
<braunr> nlightnfotis: df -h /path/to/build/dir
<braunr> pinotree: not really bugs but it could be cleaned up
<nlightnfotis> filesystem: - Size 2.8G Used 2.8G Avail 0 Use% 100% Mounted
on /
<nlightnfotis> wow
<braunr> nlightnfotis: see
<nlightnfotis> that seems to explain many things
<teythoon> ^^
<nlightnfotis> thanks for that braunr!
<braunr> you resized the disk, but not the partition and the file system
<pinotree> braunr: well, if something in ext2 (or its libs) leaves issues
in the fs, i'd call that a bug :>
<nlightnfotis> yeah, that was utterly stupid of me
<braunr> pinotree: they're not issues
<braunr> nlightnfotis: be careful, mach needs a reboot every time you
change a partition table
<teythoon> nlightnfotis: important thing is that you found the issue :)
<braunr> then only, you can use resize2fs
<teythoon> braunr: weird, I thought mach nowadays can reload the partition
tables?
<teythoon> braunr: doesn't d-i need that?
<braunr> maybe a recent change i forgot
<braunr> or maybe fdisk still reports the error although it's fine
<braunr> in doubt, rebooting is still safe :p
<teythoon> or maybe youpi hacked it into d-is gnumach
<braunr> i doubt it would be there for the installer only :)
<braunr> if it's there, it's there
<braunr> i just don't know it
<nlightnfotis> 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
<nlightnfotis> tschwinge, I have managed to overcome most of the obstacles
I had initially faced with my project
<nlightnfotis> 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.
<tschwinge> nlightnfotis: So, from a quick look into the IRC backlog, it
was a "simple" out of disk space problem? %-) That happens.
<tschwinge> nlightnfotis: And yes, GCC needs a lot of disk space.
<tschwinge> nlightnfotis: What kind of build errors are you seeing now?
<nlightnfotis> 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
<nlightnfotis> always tried to mount it with the ext2 translator
<nlightnfotis> and the translator kept dying
<nlightnfotis> but it's all figured out now
<nlightnfotis> the latest build errors I am seeing are these
<teythoon> nlightnfotis: o_O you used fstab and it worked?
<nlightnfotis> yeah
<teythoon> nlightnfotis: that's unexpected from my perspective...
<nlightnfotis> I only had to add the new partition into fstab
<nlightnfotis> teythoon: I can pastebin my fstab if you wanna take a look
at it
<nlightnfotis> tschwinge: these were my latest build errors
https://www.dropbox.com/s/b0pssdnfa22ajbp/build_results
<teythoon> nlightnfotis: I'm pretty sure that mount -a isn't done on hurd
w/o pinos runsystem.sysv
<teythoon> weird
<nlightnfotis> tschwinge: I have also tried to build gcc with "make -w"
which from what I know supresses the errors that stopped compilation
<nlightnfotis> but the weird thing is that gcc nearly took forever to build
<teythoon> nlightnfotis: could you do a showtrans /your/mountpoint?
<nlightnfotis> teythoon: /hurd/ext2fs /dev/hd0s3
<teythoon> nlightnfotis: ok, so you've set a passive translator and an
active is started on demand
<nlightnfotis> it must be a passive translator
<teythoon> nlightnfotis: this is the hurd way of doing things, fstab is
unrelated
<nlightnfotis> it seems to persist during reboots
<teythoon> yes, exactly
<nlightnfotis> teythoon: my fstab if you wanna take a look
http://pastebin.com/ef94JPhG
<nlightnfotis> after I added /dev/hd0s3 to fstab along with its mountpoint,
and restarting the hurd, only then I did manage to use that partition
<nlightnfotis> before doing so I tried pretty much anything involving
mounting the partition and setting the ext2fs translator for it, but it
kept dying
<nlightnfotis> of course it was a ext2 filesystem
<youpi> err, perhaps adding to fstab simply triggered an fsck at reboot?
<teythoon> nlightnfotis: might have been that you needed to reboot mach so
that it picks up the new partition table
<teythoon> youpi: I thought this was fixed, the partition reloading I mean?
<youpi> that is needed, yes
<youpi> let me check
<nlightnfotis> youpi: it could be, though, to be honest, my hurd system
does an fsck all the time at boot
<teythoon> how do you manage to do that w/o rebooting for d-i?
<youpi> (I don't remember whether device busy is detected)
<youpi> teythoon: by making all translators go away, iirc
<teythoon> 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
<nlightnfotis> tbh it does work, and it's weird
<teythoon> nlightnfotis: it works b/c of the passive translator you set,
not b/c of the fstab entry
<nlightnfotis> teythoon: should I change it?
<teythoon> probably, yes
<tschwinge> Well, that is probably not used anywhere.
<teythoon> tschwinge: not yet but soon ;)
<tschwinge> Isn't /etc/fstab only consulted for fsck.
<youpi> atm yes
<tschwinge> Anyway, it is definitely a very good idea to have a partition
separate from the rootfs for doing actual work.
<tschwinge> I think I described that in one of the first GSoC coodridation
emails. In the long one.
<nlightnfotis> 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?
<tschwinge> 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).
<tschwinge> nlightnfotis: Basically, yes.
<youpi> nlightnfotis: fstab is not related with bash in any way
<nlightnfotis> 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.
<tschwinge> But /etc/fstab has its very own "language" (layout), so tilde
expansion will never be done there.
<tschwinge> nlightnfotis: df -h ~/gcc_new/
<nlightnfotis> tschwinge: size 24G Used: 4.2G Avail 18G
<tschwinge> OK, that's fine.
<tschwinge> As you can see on
<http://darnassus.sceen.net/~hurd-web/open_issues/gcc/#index4h1>, GCC
will easily need some GiB.
<nlightnfotis> 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
<nlightnfotis> 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
<youpi> without disabling g++, it can easily take hours
<tschwinge> nlightnfotis: The build error is unexpected, because I had
addressed that issue in a recent patch. :-)
<tschwinge> 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.
<tschwinge> 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.
<tschwinge> That's however with Java and Ada enabled, and a full
three-stages bootstrap.
<youpi> ah, right, there's java & ada too
<nlightnfotis> tschwinge: git branch (in the repo): master,
*tschwinge/t/hurd/go
<youpi> in debian they are built separately
<tschwinge> What I asked you to do is configure »--disable-bootstrap
--enable-languages=go«.
<tschwinge> So that should be a lot quicker.
<nlightnfotis> tschwinge: oh yes, everytime I have tried to compile gcc I
have done with these configurations
<tschwinge> But still a few hours perhaps.
<nlightnfotis> that's what I did yesterday too.
<tschwinge> OK, good. :-)
<tschwinge> 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.
<nlightnfotis> the only "extra" configuration yesterday was my "-w" flag to
make, because those errors were actually triggered by -Werror
<tschwinge> Let me read up what make -w does. ;-)
<nlightnfotis> ah, yes, d/w I have read and understood what the bootstrap
build is. Seems like we don't need it atm
<nlightnfotis> afaik it suppresses all warnings
<pinotree> youpi: gcj no more
<nlightnfotis> the way gcc builds, it does convert (some) warnings to
errors
<tschwinge> Hmm. -w, --print-directory Print a message containing the
working directory before and after other processing.
<pinotree> youpi: doko folded gcj and gdc into gcc-4.8 to "workaround"
Built-Using
<tschwinge> nlightnfotis: Ah, that'S configure --enable-werror or something
like that.
<youpi> pinotree: right
<nlightnfotis> yep, and -w suppresses it
<nlightnfotis> (from what I have understood)
<tschwinge> nlightnfotis: Are you thinking about make -k?
<tschwinge> Yeah, I guess.
<nlightnfotis> let me see what -k does
<pinotree> youpi: (just to make builds even more lightweight, eh</irony>)
<nlightnfotis> yeah, -k should do too, I shall try it
<tschwinge> 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.
<nlightnfotis> so I shall try again with -w (supressed warnings)
<tschwinge> Configureing with --disable-werror (or similar) will "help" if
-Werror is the default, and the build fails due to that.
<nlightnfotis> from what I have understood these "errors" are not something
critical: it's only that function prototypes for these functions are
missing
<nlightnfotis> 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
<tschwinge> nlightnfotis: Ah, now I see. You don't mean make -w, but
rather gcc -w: »-w Inhibit all warning messages.«
<tschwinge> But really, there shouldn't be such warnings/errors that make
the build fail.
<nlightnfotis> yeah
<tschwinge> nlightnfotis: In your GCC sources directory, what does this
tell: git rev-parse HEAD
<tschwinge> And, is the checkout clean: git status
<tschwinge> The latter will take some time.
<nlightnfotis> git status takes an awful amount of time
<nlightnfotis> last I checked
<nlightnfotis> but git rev-parse HEAD
<nlightnfotis> produces this result:
<nlightnfotis> 91840dfb3942a8d241cc4f0e573e5a9956011532
<tschwinge> OK, that's correct. So probably some of the checked out files
are not in a pristine state?
<nlightnfotis> I shall run a git clean and see. If that doesn't work too,
maybe I shall reclone the repository?
<nlightnfotis> 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)
<tschwinge> nlightnfotis: You shouldn't need to do the latter if you
instead run: apt-get build-dep gcc-4.8
<nlightnfotis> I remember having done that inside the Hurd, but it always
resulted in an error from what I can recall
<nlightnfotis> let me check this out
<nlightnfotis> yes
<tschwinge> nlightnfotis: Whenever you use Git on Hurd, pass the --quiet
flag, to avoid the rare but possible corruption issue described on
<http://darnassus.sceen.net/~hurd-web/open_issues/git_duplicated_content/>
and <http://darnassus.sceen.net/~hurd-web/open_issues/git-core-2/>.
<nlightnfotis> tschwinge: Forgive me for that. I will set up an alias
immediately.
<tschwinge> nlightnfotis: I don't know if an alias is possible, because --
I think -- you'll need to do things like: git fetch --quiet
<tschwinge> So pass --quiet to subcommands.
<nlightnfotis> oh. ok.
<tschwinge> 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.
<nlightnfotis> sounds like a plan. I will check this out today then :)
<nlightnfotis> tschwinge: if all else fails, then recloning the repo with
--quiet passed should work, right?
<tschwinge> Yes, that's probably the most straight-forward check to do.
<tschwinge> Heh, yes to both these questions. :-)
<tschwinge> nlightnfotis: Oh, you don't even have to re-clone, but rather
re-check-out the branch.
<nlightnfotis> I was thinking of recloning just to bring the whole
repository to a pristine state
<tschwinge> 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
<tschwinge> nlightnfotis: But before doing that, please do the diff first,
so that we know (hopefully) where the erroneous build results were coming
from.
<nlightnfotis> 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)
<nlightnfotis> 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
<nlightnfotis> let me check it out now
<nlightnfotis> still nothing from their online service
<nlightnfotis> let me call them
<nlightnfotis> 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.
<tschwinge> 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.
|