Re: Investigation of the failing build of gnat-4.9 using fakeroot-hurd
Hello :) Quoting Svante Signell (2015-02-02 12:26:06) > Confusing thing is: Printouts in > libnetfs/dir-lookup.c:netfs_S_dir_lookup() are not triggered, but > libdiskfs/dir-lookup.c:diskfs_S_dir_lookup are. > libnetfs is built into fakeroot itself, but not libdiskfs, which is > built into ext2fs.static. libdiskfs functions does not seem to be faked. That's not so surprising. fakeroot does not fake all functions, any message it does not understand is passed through as-is. Also, in the case of dir_lookup, fakeroot does some of the dir_lookup-related stuff (like retries) on behalf of the client. That could explain why you see messages from libdiskfs and not from libnetfs. I don't see why that could cause problems though. In your particular case, did you check whether the error is right, i.e. it tried to do something to the file on the ext2fs that the user is not allowed to do ? Justus -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150203111036.12304.60...@thinkbox.jade-hamburg.de
Re: Investigation of the failing build of gnat-4.9 using fakeroot-hurd
On Tue, 2015-02-03 at 12:10 +0100, Justus Winter wrote: > Hello :) > > Quoting Svante Signell (2015-02-02 12:26:06) > > Confusing thing is: Printouts in > > libnetfs/dir-lookup.c:netfs_S_dir_lookup() are not triggered, but > > libdiskfs/dir-lookup.c:diskfs_S_dir_lookup are. > > libnetfs is built into fakeroot itself, but not libdiskfs, which is > > built into ext2fs.static. libdiskfs functions does not seem to be faked. > > That's not so surprising. fakeroot does not fake all functions, any > message it does not understand is passed through as-is. Also, in the > case of dir_lookup, fakeroot does some of the dir_lookup-related stuff > (like retries) on behalf of the client. That could explain why you > see messages from libdiskfs and not from libnetfs. I don't see why > that could cause problems though. > > In your particular case, did you check whether the error is right, > i.e. it tried to do something to the file on the ext2fs that the user > is not allowed to do ? Well, the printouts from libdiskfs shows a uid and gid of 1000, i.e they are not faked. Nevertheless, libdiskfs logs show: Block 1: libdiskfs/diskfs_S_dir_lookup: check perms on existing node libdiskfs/diskfs_S_dir_lookup: np->dn_stat.st_uid=1000, np->dn_stat.st_gid=1000 libdiskfs/diskfs_S-dir_lookup: np->dn_stat.st_mode=100444 libdiskfs/diskfs_S-dir_lookup: idvec_contain gotit (op)=0 Block 2: libdiskfs/diskfs_S_dir_lookup: check perms on existing node libdiskfs/diskfs_S_dir_lookup: np->dn_stat.st_uid=1000, np->dn_stat.st_gid=1000 libdiskfs/diskfs_S-dir_lookup: np->dn_stat.st_mode=100444 libdiskfs/diskfs_S-dir_lookup: idvec_contain gotit (op)=0 libdiskfs/diskfs_S_dir_lookup: flags & O_WRITE libdiskfs/diskfs_S_dir_lookup: flags & O_READ=1, flags & O_WRITE=2, flags & O_EXEC=0 libdiskfs/diskfs_S-dir_lookup: np->dn_stat.st_mode=100444 libdiskfs/diskfs_S_dir_lookup: error = Permission denied (and so on) when issuing /usr/bin/fakeroot-hurd sh -c "debian/rules binary" (fails): Block 1 + Block 2 but not with /usr/bin/fakeroot-hurd sh -c "make" (succeeds): Block 1 cat Makefile default: dh_md5sums -plibgnatvsn4.9-dev and dh_md5sums is python code issuing: cd debian/libgnatvsn4.9-dev >/dev/null; find . -type f ! -regex './DEBIAN/.*' -printf '%P\0' | LC_ALL=C sort -z | xargs -r0 md5sum > DEBIAN/md5sums As Block 2 above shows "dir_lookup flags & O_WRITE !=0" and the test if (!error && (flags & O_WRITE)) causes the EACCESS error. So the flags are not correctly set?? The files are moved from debian/tmp/usr/lib/ada/adalib/gnatvsn/ to debian/libgnatvsn4.9-dev/usr/lib/ada/adalib/gnatvsn with a previous dh_movefiles command. All files *.ali have file mode 10444 e.g. -r--r--r-- 1 srs srs 2267 Dec 18 00:38 alloc.ali There are other permission denied messages later on in the build, I've just recreated a subset of the package build process. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1422963752.5057.57.ca...@g3620.my.own.domain
Bug#776965: llvm-toolchain-3.6: FTBFS on hurd-i386
Source: llvm-toolchain-3.6 Version: 1:3.6~+rc2-1 Severity: important Tags: patch User: debian-hurd@lists.debian.org Usertags: hurd Hello, Currently llvmtoolchain-3.6 (~+rc1-1 and ~+rc2-1) fails to build from source due to usage of a reserved identifier in C/C++11/POSIX.1, see e.g.: http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier Other restrictions might apply. For example, the POSIX standard reserves a lot of identifiers that are likely to show up in normal code: *Names beginning with a capital 'E' followed a digit or uppercase letter *may be used for additional error code names. http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html Some additional classes of identifier names are reserved for future extensions to the C language or the POSIX.1 environment. While using these names for your own purposes right now might not cause a problem, they do raise the possibility of conflict with future versions of the C or POSIX standards, so you should avoid these names. ... Names beginning with a capital ‘E’ followed a digit or uppercase letter may be used for additional error code names. See Error Reporting. http://docs.oracle.com/cd/E19205-01/819-5265/bjaky/index.html Sun Studio 12: C User's Guide 6.8.3 Names Reserved for Expansion In addition to all the names explicitly reserved, the 1990 ISO/IEC C standard also reserves (for implementations and future standards) names matching certain patterns: Table 6–3 Names Reserved for Expansion errno.h E[0-9A-Z].* ISO/IEC 9899:TC3 Committee Draft — September 7, 2007 WG14/N1256 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf page 166: 7.1.3 Reseved Identifiers The attached patch hurd.diff fixes that by renaming EIOIO to E_IOIO. The already included patch: hurd-EIEIO-undef.diff is non-functional and should be removed. Since this is a standard violation, this patch should be submitted upstream. Test summary from the build is: Expected Passes: 7892 Expected Failures : 14 Unsupported Tests : 23 Unexpected Failures: 16 Additionally the patch debian_rules.diff adds an option to help2man: --no-discard-stderr to get output even if --help is written to stderr. This changes is made unconditionally, but could be modified of course if it causes problems for other architectures. Thanks! Index: llvm-toolchain-3.6-3.6~+rc1/lib/Target/PowerPC/PPCInstrInfo.td === --- llvm-toolchain-3.6-3.6~+rc1.orig/lib/Target/PowerPC/PPCInstrInfo.td +++ llvm-toolchain-3.6-3.6~+rc1/lib/Target/PowerPC/PPCInstrInfo.td @@ -3134,7 +3134,7 @@ def ISYNC : XLForm_2_ext<19, 150, 0, 0, def ICBI : XForm_1a<31, 982, (outs), (ins memrr:$src), "icbi $src", IIC_LdStICBI, []>; -def EIEIO : XForm_24_eieio<31, 854, (outs), (ins), +def E_IEIO : XForm_24_eieio<31, 854, (outs), (ins), "eieio", IIC_LdStLoad, []>; def WAIT : XForm_24_sync<31, 62, (outs), (ins i32imm:$L), --- a/debian/rules.orig 2015-01-14 19:45:58.0 +0100 +++ b/debian/rules 2015-02-02 03:15:49.0 +0100 @@ -256,7 +256,7 @@ CMDS="llvm-dwarfdump llvm-mc llvm-mcmarkup llvm-objdump llvm-rtdyld llvm-size llvm-tblgen llvm-ranlib macho-dump lldb clang-format clang-modernize clang clang-tblgen clang-check clang-tidy clang-apply-replacements pp-trace"; \ for f in $$CMDS; do \ echo "Generating manpage of $$f"; \ - LD_LIBRARY_PATH=$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ help2man --version-string=$(LLVM_VERSION) $(TARGET_BUILD)/Release/bin/$$f > debian/man/$$f-$(LLVM_VERSION).1; \ + LD_LIBRARY_PATH=$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ help2man --no-discard-stderr --version-string=$(LLVM_VERSION) $(TARGET_BUILD)/Release/bin/$$f > debian/man/$$f-$(LLVM_VERSION).1; \ done override_dh_auto_install:
Re: Investigation of the failing build of gnat-4.9 using fakeroot-hurd
Hello :) Quoting Svante Signell (2015-02-03 12:42:32) > > In your particular case, did you check whether the error is right, > > i.e. it tried to do something to the file on the ext2fs that the user > > is not allowed to do ? > > Well, the printouts from libdiskfs shows a uid and gid of 1000, i.e they > are not faked. Nevertheless, libdiskfs logs show: It is *really* hard to interpret your log w/o seeing what you print where, i.e. the diff with the printfs. [...] > As Block 2 above shows "dir_lookup flags & O_WRITE !=0" and the test > if (!error && (flags & O_WRITE)) causes the EACCESS error. > So the flags are not correctly set?? Apparently not: > The files are moved from debian/tmp/usr/lib/ada/adalib/gnatvsn/ to > debian/libgnatvsn4.9-dev/usr/lib/ada/adalib/gnatvsn with a previous > dh_movefiles command. All files *.ali have file mode 10444 e.g. > -r--r--r-- 1 srs srs 2267 Dec 18 00:38 alloc.ali I would expect the test whether we may write to the file to fail if we may not write to the file. Justus -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150203145844.5246.78...@thinkbox.jade-hamburg.de
