From 47e4d194dc36adfcfd2577fa4630c9fcded005d3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 27 Oct 2013 19:15:06 +0100 Subject: IRC. --- hurd/translator/magic.mdwn | 262 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 259 insertions(+), 3 deletions(-) (limited to 'hurd/translator/magic.mdwn') diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn index 84bacdfb..2b0d1bf7 100644 --- a/hurd/translator/magic.mdwn +++ b/hurd/translator/magic.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2010, 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 @@ -9,7 +9,13 @@ 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]]."]]"""]] -The magic translator provides `/dev/fd`. +The `magic` translator returns magic retry results, which are then resolved by +[[glibc]]'s *name lookup* routines. + +[[!toc]] + + +# `/dev/fd`. $ showtrans /dev/fd /hurd/magic --directory fd @@ -20,3 +26,253 @@ individually like this: $ ls -l /dev/fd/0 crw--w---- 1 bing tty 0, 0 Nov 19 18:00 /dev/fd/0 + + +# `/dev/tty` + + $ showtrans /dev/tty + /hurd/magic tty + + +## Open Issues + +### IRC, OFTC, #debian-hurd, 2013-06-18 + + http://www.zsh.org/mla/workers/2013/msg00547.html + + +#### IRC, OFTC, #debian-hurd, 2013-06-19 + + youpi: http://www.zsh.org/mla/workers/2013/msg00548.html -- Is + that realistic? If yes, can someone of you test it? I though would expect + that if /dev/tty exists everywhere, it's a chardev everywhere, too. + that's not impossible indeed + I've noted it on my TODO list + + +#### IRC, OFTC, #debian-hurd, 2013-06-20 + + youpi: wrt the /dev/tty existance, + https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=hurd-i386&ver=46-2&stamp=1371553966 + For the build logs, demonstrate that /dev/null and /dev/tty + exist: + ls: cannot access /dev/tty: No such device or address + uh?! + ah, ENODEV + so that's what we was thinking, no tty -> no /dev/tty + + +#### IRC, OFTC, #debian-hurd, 2013-09-20 + + Hi. zsh still FTBFS on Hurd due to some test failure: + https://buildd.debian.org/status/package.php?p=zsh -- IIRC I checked last + time on some porterbox and couldn't reproduce the failure there. Any + insight if /dev/tty is not accessible on the buildds inside the chroot? + Or is it no character device there? I checked on strauss and there it is + a character device. + My only other option to debug this (didn't think of that yesterday + before the upload unfortunately) would be to override dh_auto_test with + "ls -l /dev/tty; dh_auto_test". Do you think that would be helpful? + i see /dev/tty on exodar, in the root system and in the chroot + pinotree: And it is a character device? + ... in both cases? + crw--w---- 1 pino tty 0, 0 Sep 20 10:20 /dev/tty + yes + pinotree: Hrm. + (/dev in the chroot is a firmlink to the system /dev, iirc) + pinotree: What is a firmlink? :) + pinotree: /dev/tty belongs to your user in the example above. + something between a (sym)link and an union mount + pinotree: Is it possible that /dev/tty is not visible if the + buildd runs without a connected terminal? + that i'm not sure + I see. + wouldn't it be possible to skip only that check, instead of the + whole test suite? + maybe something like + tty=$(find /dev/ -name 'tty*' -type c -print) + if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c $zerolength ]] + / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty ]] (no tty + found)' / [[ ! -c $zerolength ]] / fi + (never used zsh, so please excuse me if i wrote something silly + above) + re + pinotree: Yeah, sure. That would be one way to get the thing + building again, if that's really the cause. + i guess it would find any of the available tty* devices + it does that for block devices, why not with tty devices, after + all? :) + pinotree: I just wonder if the failing test is because the test + doesn't work properly on that architecture or because it indicates that + there is a bug in zsh which only is present on hurd. + wouldn't the change proposed above help in determining it? + If I'm sure that it's a broken test, I'll try to disable that + one. If not I'd report (more details) to upstream. :) + pinotree: Oh, indeed. + if you get no warning, then a tty device was found with find + (using its -type c option), so the failing condition would be a zsh (or + maybe something in the stack below) bug + with the warning, somehow there were no tty devices available, + hence nothing to test -c with + So basically doing a check with dash to see if we should run the + zsh test. + dash? + Well, whatever /bin/sh points to. :) + ah, do you mean because of $(find ...)? + Ah, right, -type c is from find not /bin/sh + pinotree: That's my try: + http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=ba5c7320d4876deb14dba60584fcdf5d5774e13b + o_O + isn't that a bit... overcomplicated? + pinotree: Yeah, it's a little bit more complicated as the tests + itself are not pure shell code but some format on their own. + why not the "thing" i wrote earlier? + pinotree: Actually it is what I understand you wanted to do, just + with more debug output. Or I dunderstood + pinotree: Actually it is what I understand you wanted to do, just + with more debug output. Or I understood your thing wrongly. + tty=$(find /dev/ -name 'tty*' -type c -print) + if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c + $zerolength ]] / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty + ]] (no tty found)' / [[ ! -c $zerolength ]] / fi + pinotree: Yeah, I know. + that is, putting these lines instead of the current two + tty=/dev/tty + following + imho that should be fit for upstream + pinotree: You mean inside C02cond.ztst? + yep + pinotree: No, IMHO that's a bad idea. + why? + pinotree: That file is to test the freshly compiled zsh. I can't + rely on their code if I'm testing it. + uh? + the test above for -b is basically doing the same + pinotree: Indeed. Hrm. + that's where i did c&p most of it :) + So upstream relies on -n in the testsuite before it has tested it? + Ugly. + if upstream does it, why cannot i too? :D + pinotree: You've got a point there. + Ok, rethinking. :) + otoh you could just move the testcase for -n up to that file, so + after that you know it works already + pinotree: Well, if so, upstream should do that, not me. :) + you could suggest them to, given the -n usage in the -b testcase + pinotree: Looks alphabetically sorted, so I guess that's at least + not accidentially. + pinotree: Ok, you've convinced me. :) + :D + Especially because this is upstream-suitable once it proved to fix + the Hurd FTBFS. :) + pinotree: The previous upstream code (laast change 2001) instead + of the hardcoded /dev/tty was btw "char=(/dev/tty*([1]))", so I suspect + that the find may work on Cygwin, too. + s/aa/a/ + ah, so that's that comment about globbing on cygwin was + referring to + Yep + cool, so incidentally i've solved also that small issue :9 + :) + pinotree: I hope so. :) + Then again, I hope, external commands like find are fine for + upstream. + then they should rework the already existing testcases ;) + pinotree: Ah, I fall again for the same assumptions. :) + Seems as I would really build test suites with a different + approach. :) + nothing bad in that, i'd say + I'd try to make the tests as far as possible independent from + other tools or features to be sure to test only the stuff I want to test. + Warning: Not testing [[ -c tty ]] (no tty found) + Interesting. I didn't expect that outside a chroot. :) + where's that? + pinotree: A plain "debuild on my Sid VM. + ah + Linux, amd64 + (and Debian of course ;-) + pinotree: Ah, my fault, I kept upstreams char= but didn't change + it in your code. :) + hehe + pinotree: Will be included in the next zsh upload. But I don't + want to upload a new package before the current one moved to testing (or + got an RC bug report to fix :-) + oh sure, that's fine + pinotree: + http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=22bc9278997a8172766538a2ec6613524df03742 + (I've reverted my previous commit) + \o/ + + +#### IRC, OFTC, #debian-hurd, 2013-09-30 + + Anyone knows why the building of zsh on ironforge restarted? It + was at something like "building 4h20m" when I looked last and it now is + at "building 1h17m" but there's no old or last log, so it does still look + like the first build. + most probably got stuck + Oh, ok. + pinotree: So there are cases where the log is not kept? + looks so + when the machine crashes, yes :) + youpi: Ooops. Was that me? + no, I just rebooted the box + I didn't easily find which process to kill + Ok. Then I'll check back tomorrow morning if pinotree's fix for + zsh's test suite on hurd worked. :) + it seems to be hung on + /build/buildd-zsh_5.0.2-5-hurd-i386-vO9pnz/zsh-5.0.2/obj/Test/../Src/zsh + ../Src/zsh ../../Test/ztst.zsh ../../Test/Y02compmatch.ztst + :( + At least pinotree's patch worked as it then likely passed + C02cond.ztst. :) + youpi: For how long? There are multiple tests which take at least + 3 seconds per subtest. + one hour already + Ok. + That's far too long + + +#### IRC, OFTC, #debian-hurd, 2013-10-01 + + pinotree: I've just checked + https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=hurd-i386&ver=5.0.2-5&stamp=1380608100 + manually: Your fix unfortunately seemed not to help, but another test + failed, too, and that one came later and was hence suspected as primary + failing issue. + pinotree: But "+ find: `/dev/tty': No such device or address" + gives some hint. I just have no idea, why find issues that message. + * XTaran really wonders how that message can be caused. + So find sees /dev/tty, but gets an error if it tries to access + (maybe only stat) it while not being connected to a terminal. + Bingo: This reproduces the issue (note the missing -t option to + ssh): ssh exodar.debian.net "find /dev/ -nowarn -maxdepth 1 -name 'tty*' + -type c -ls" + Even clearer: $ ssh exodar.debian.net "ls -l /dev/" | grep 'tty$' + ls: cannot access /dev/tty: No such device or address + ?????????? ? ? ? ? ? tty + I'd say this is a bug somewhere deep down, either in libc or the + kernel. + or in the console translator + pinotree: Never heard of that so far. :) + pinotree: Someone from zsh upstream suggests to use /dev/null or + /dev/zero instead of /dev/tty* -- will try that for the next upload. + ah right, /dev/null should be standard POSIX + I hope so. :) + http://pubs.opengroup.org/onlinepubs/9699919799/ check in POSIX + in any case, sorry for the troubles it is giving you... + pinotree: I'm more concerned about the hanging second test. I + think I can get that test working with using /dev/null. + Now that I've understood why the original test is failing. + pinotree: Shall I write a bug report for that issue? If so, + against which package? + XTaran: not sure it is worth at this stage, having a clearer + situation on what happens could be useful + it is something that can happen sporadically, though + pinotree: Well, it seems a definitely unwanted inconsistency + between what the directory listing shows and which (pseudo) files are + accessible. Independently of where the bug resides, this needs to be + fixed IMHO. + sure, nobody denies that + pinotree: I'd call it easily reproducible. :) + not really + ... once you know where to look for. -- cgit v1.2.3