IRC channel logs

<mark_weaver>hmm.. well, investigation shows that the inode numbers returned by stat and getdents64 seem to sometimes get munged.

<mark_weaver>'pwd' is doing the job as follows: it gets the inode of the current directory, and then it reads the parent directory, looking for the entry whose inode matches the current directory.. and then it iterates.

<mark_weaver>however, some of the inode numbers seem to be incorrect.. and it reaches a point where it cannot find the entry in the parent whose inode matches the current directory.

<mark_weaver>however, I cannot reproduce the problem outside of guix-daemon.

<youlysses>So does inetutils come with: ifconfi, iwlist, iwspy, impriv, ifrename? :^U

*youlysses is trying to figure if he needs to package wireless_tools.

<mark_weaver>youlysses: inetutils includes: hostname, ifconfig, logger, ping, ping6, rcp, rexec, rlogin, rsh, telnet, tftp, traceroute, and whois.

<mark_weaver>youlysses: indeed, you will probably need wireless-tools

<youlysses>Okay, just making sure. :^) Civodul told me that net-tools was deprecated and inetutils had it covered anyways.

<mark_weaver>I'm not an expert on this subject, but my impression is that the 'iproute2' package is intended to replace 'net-tools'.

<mark_weaver>inetutils covers only a subset of the functionality.

<mark_weaver>unfortunately, it appears that 'iproute2' makes no attempt to work with kernels other than Linux.

<mark_weaver>but I think that answer will be to enhance 'inetutils' as needed.

<mark_weaver>s/that/the/

<mark_weaver>also, note that the tools in 'iproute2' have different names and usage than you are probably used to.

<youlysses>Should I bother packaging iproute2 as-well, then? :^P

<mark_weaver>I think it would be useful.

<mark_weaver>but not a high priority

<mark_weaver>for 99% of users, inetutils and wireless-tools will do everything that they need.

<youlysses>Okay, I'll bbl. o/

<viric>mark_weaver: can you try on jfs, about inode numbers? It sounds like the readdir trouble

<mark_weaver>viric: poppush tried it on JFS and got the same error

<mark_weaver>(he reported that here on this channel a few hours ago)

<mark_weaver>(actually, about 17 hours ago)

<mark_weaver>viric: how did the readdir trouble manifest itself?

<viric>ah ok

<viric>hm I think it's in that thread. It wasn't getcwd though.

<mark_weaver>getcwd is not where the problem is happening.

<viric>ah ok

<mark_weaver>the problem is that the inode number of a bind mount point has a different inode number when viewed from the outside using readdir than it does when viewed from the inside using ".".

<mark_weaver>well, actually, that's not even quite true. if I set up the bind mount manually, it works fine.

<mark_weaver>but when guix-daemon does it, the inodes don't match.

<viric>If you are happy with n32, please try a kernel like those I use on the fuloong, built by nixos

<mark_weaver>I'm trying to avoid downloading precompiled code, especially if I can't convincingly verify its authenticity.

<viric>ok, then pick a 3.7 or 3.8 kernel, and apply the patches of nixpkgs

<mark_weaver>well, for the moment I'm a large part of the way through compiling the variant of linux-libre-3.10.15 that'

<viric>ah ok, that may tell if upstream fixed anything in that regard, too

<mark_weaver>(the one that's used to create loongson packages for gnewsense)

<viric>I run 3.9 at most, in the fuloong. I haven't switched it on since then :)

<viric>I hate its noise.

<mark_weaver>it's been mentioned before on loongson-dev, and I'll repeat: the fan could certainly be replaced by a big heat sink.

<viric>it already has a not-small heat sink

<mark_weaver>though of course you'd have to make sure it was able to keep the processor cool.

<viric>yes, I'm not sure it's so trivial.

<viric>):

<viric>:)

<viric>it doesn't have a temperature sensor, does it?

<mark_weaver>the yeeloong certainly has temperature sensors.

<mark_weaver>when I had debian running on it, I installed some software that dynamically controlled the fan based on processor temp, and it worked quite well (reduced the noise quite a bit when relatively idle)

<mark_weaver>I'll have to look through my backup of that system to recover the configuration I used and the name of the software.

<mark_weaver>ah, the debian package name was 'fancontrol'

<viric>ah really? I didn't know that the fan could be controlled

<mark_weaver>viric: and here's the configuration I used: http://paste.lisp.org/+2ZJ8

<mark_weaver>I got that from some web searches long ago. anyway, it seemed to work reasonably well for me and didn't fry the motherboard :)

<viric>ah, the yeelong

<viric>I kept on talking about the fuloong

<mark_weaver>*nod* I realize that it might need a different configuration, but maybe that file contains some hints for where to find the relevant sensors in /sys/

<viric>I'm not sure it has pwm for the fan

<mark_weaver>viric: http://www.mail-archive.com/loongson-dev@googlegroups.com/msg00776.html

<viric>I remember the post

<viric>I think it may help to replace the box completely, by a bigger box

<viric>and then use huge usual heatsinks

<viric>box=case

<mark_weaver>yes, that would be a good solution, and probably easier.

<mark_weaver>if you do that, better have vents on the top of the box above the heatsink, as well as near the bottom somewhere, so that the hot air can be replaced with colder air fairly efficiently.

<mark_weaver>okay, the kernel is built. time to see if it works :)

<viric>it seems that mark can't boot

<civodul>Hello Guix!

IRC channel logs

2013-10-09.log