On 14/01/2008, Mel Gorman wrote: > The documentation is pretty decent but there is a lot of it. Rome wasn't built in a day? ;-) > > W: libhugetlbfs: shlib-with-executable-stack usr/lib/libhugetlbfs.so > > I give up, whats the right way of fixing this? Searching around says I > should be able to pass -Wa,--execstack via the compiler to the > assembler but it does not appear to be supporting by the binutils in > Debian testing. This is very likely a build issue in the upstream > package as well. Actually, I don't know. My first guess would be to ask upstream whether: it's wanted, and if so, if it's needed. Either they have to fix it, or you'll have to investigate how to deal with it. For those who didn't build this package, lintian outputs: | N: The listed shared libraries declares the stack as executable. | N: | N: Executable stack is usualy an error as it is only needed if the code | N: contains GCC trampolines or similar constructs which uses code on the | N: stack. One possible source for false positives are object files built | N: from assembler files which don't define a proper .note.GNU-stack | N: section. And there are assembler files: | $ find -name '*.S' | ./elf_i386.S | ./elf32ppclinux.S | ./elf64ppc.S | ./elf_x86_64.S Looks to me that it probably will only work on: i386, amd64, powerpc, you should ask upstream if support for more architecture is planned, and eventually change “Architecture: any” to an explicit list of supported architectures. Anyway, asking upstream to double-check that .note.GNU-stack thing should help. > I removed the shlibs file as it should have been possible to use > dh_makeshlibs. The rules file now calls it but it's still not > generating the shlibs file correctly (-v shows the script to be doing > nothing). The lintian error is > > E: libhugetlbfs: no-shlibs-control-file usr/lib/libhugetlbfs.so > N: > N: Although the package includes a shared library, the package does not > N: have a shlibs control file. If this is intentional, please override > N: this error. > N: > N: Refer to Policy Manual, section 8.6 for details. AFAICT, dh_makeshlibs might work better if you had proper library versioning (using SONAME). > I think that is a global override which doesn't feel like the right > thing to be doing. I suspect I'm missing something in the control file > or some other file is missing that tells dh_makeshlibs what to do. That would rather be “dh_makeshlibs -V” (but that is *only* to give you an idea of what you need to do, and not the final word on this. -V without parameters is dangerous and error-prone). But again, please take that to upstream and ask them for proper versioning (in case I didn't say that in my first mail, that would permit having a foo application linked against libhugetlbfs1 to keep on working while having another bar application linked against libhugetlbfs2, so that upgrades are as smooth as possible). > I updated the version to distinguish between initial release and when > feedback gets incorporated. This "hides" the lintian error. I'll need > to create an ITP bug before the end of this. Once you've asked upstream all these questions, you have plenty of time to open this ITP bug. ;) > > The upstream versioning needs work. I'll need to kick that > independently of this package or should I trying to add versioning > into the Debian version of the library? Please ask upstream first. That might be very painful to maintain a different versioning than upstream's. Particularly if that's a new exercise for you. > Thanks for the feedback, it's appreciated. Pointers on how to close > the other two lintian errors would be welcome. Trawling around the > policy documents and other packages did not reveal the answers but no > doubt I'm missing something obvious. It's not obvious, rather upstream have to do some job before you can progressively come to a (one of the possible) conclusion(s). As it's often the case: patience is the key. > The latest dsc file is at > http://mentors.debian.net/debian/pool/main/l/libhugetlbfs/libhugetlbfs_1.2-2.dsc. Another remark while I'm at it, your package isn't really clean, since the following files appear in the source package diff (diff.gz): | $ zcat ../libhugetlbfs_1.2-2.diff.gz | lsdiff | grep -v /debian/ | libhugetlbfs-1.2/Makefile | libhugetlbfs-1.2/libhugetlbfs_write_dirs_installs | libhugetlbfs-1.2/strace.out | libhugetlbfs-1.2/version.h If you're applying modifications to upstream's files, it's best practice to use a patch management system (like dpatch or quilt) to do so. If some of them are files that are just build logs/traces and so on, you could just remove them in the clean target. dpkg-source won't complain (just warn) about their deletion, and they won't appear in the source diff anymore. Looking at them: - libhugetlbfs-1.2/libhugetlbfs_write_dirs_installs might just go under debian, that'd be cleaner. - Makefile might deserve a dpatch/quilt patch. - strace.out might just disappear. - version.h could go along Makefile (in the same patch). I know you're still struggling with the build system, so that might be a burden to handle a patch management system. But in the long run, once you've sorted out versioning and stack troubles with upstream, switching to a patch management system will help you. Maybe not in the few next days or weeks, but you'll see for yourself. ;-) Cheers, -- Cyril Brulebois
Attachment:
pgpcn71mYGbHF.pgp
Description: PGP signature