[[!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 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]]."]]"""]] 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 The `/dev/fd` directory holds the open [[unix/file_descriptor]]s for your current process. You can't see them with `ls -l /dev/fd/` but you can see them 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.