Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hi Tim, On Fri, 05 Jun 2015, Raphael Hertzog wrote: On Wed, 03 Jun 2015, Tim wrote: Yeah, it's sad. I need some one to *help* me package it and take ownership of the packaging. There's very little maintenance at this point, since there's not really any active feature development and infrequent releases. It's just a matter of getting over the major build changes betwween 0.12 and later versions. At one point one of the DFF guys said they created debian packages for it, but in a brief search I haven't been able to find them. My intervention here is directly related DFF. In Kali we got this request: https://bugs.kali.org/view.php?id=2290 We will update reglookup in Kali and contribute the changes back to Debian. We started working on this update but there are multiple problems: * The library is not versioned, you need to have proper SONAME management for libraries packaged in Debian. https://wiki.debian.org/UpstreamGuide#Libraries (this is really important for us, only versioned libraries can be represented in the automatic library dependency mechanism) * SCons does not allow us to inject hardened build flags in CFLAGS, LDFLAGS, CPPFLAGS: https://wiki.debian.org/UpstreamGuide#SCons * SCons does not allow us to install files in a destination directory different from / (we use the DESTDIR variable for this) * SCons is not standardized at all and thus debhelper has no support for it... which means that we can't benefit freely from stuff like multiarch support which requires us to install the libraries in an architecture-specific path. And also some things which could be improved: * please rename pyregfi-distutils.py to setup.py so that it can be automatically detected by our build tools * don't call ldconfig (we do not run build process as root, the install step is run under fakeroot and any operation requiring real root rights will fail) In general, it would be nice if you could use something else than SCons... You can also have a look at other sections of the upstream guide that I linked to as you might find some useful data that would make our lives easier. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hi Raphael, We started working on this update but there are multiple problems: Ok, so this is the kind of feedback I've been hoping to hear for some time. * The library is not versioned, you need to have proper SONAME management for libraries packaged in Debian. https://wiki.debian.org/UpstreamGuide#Libraries (this is really important for us, only versioned libraries can be represented in the automatic library dependency mechanism) I'll have to read up on this. I'm somewhat fuzzy on how this stuff is normally handled. * SCons does not allow us to inject hardened build flags in CFLAGS, LDFLAGS, CPPFLAGS: https://wiki.debian.org/UpstreamGuide#SCons This is easy to add. * SCons does not allow us to install files in a destination directory different from / (we use the DESTDIR variable for this) I actually do have DESTDIR support. Let me know if it isn't using the path appropriately. Be sure to check the trunk version. I'm not sure if the latest release has this. In general, let's work off of the trunk until you're satisfied with my build script. * SCons is not standardized at all and thus debhelper has no support for it... which means that we can't benefit freely from stuff like multiarch support which requires us to install the libraries in an architecture-specific path. What environment variables are used to specify architecture-specific paths? If CC, CFLAGS, LDFLAGS and the like are all accepted properly, what else would you need for cross-compiling? And also some things which could be improved: * please rename pyregfi-distutils.py to setup.py so that it can be automatically detected by our build tools Ok, I'll look into this. * don't call ldconfig (we do not run build process as root, the install step is run under fakeroot and any operation requiring real root rights will fail) Does my uid check not work for you? In general, it would be nice if you could use something else than SCons... You can also have a look at other sections of the upstream guide that I linked to as you might find some useful data that would make our lives easier. I find make to be awful. I've been using it off and on for years, but I've decided it is antiquated. SCons has nice advantages (you know it is actually portable), though it can certainly use more work. I find that guide you linked to is just a tad rigid and closed-minded about using alternative tools. Let's just get SCons working like Debian's build scripts expect. SCons just runs python scripts afterall, so it can't be that hard to make it accept whatever inputs you need it to. Besides what you mentioned above, I see the guide mentions in passing a variety of other environment variables that should be accepted: If you choose to use SCons anyway, please ensure that the usual environment compiler variables (CC, CFLAGS, ...) and path variables (DESTDIR, BINDIR, LIBDIR, ...) are honoured. There is a recipe, that addresses some of these. It would be *great* of *all* environment variables were listed somewhere, instead of just a few and a hand wave... =P Let me know if you have a more complete reference somewhere. thank you! tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#644019: reglookup: Please package latest upstream (1.0.1)
I don't have a good reference either, but I just found this: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN95 At least it gives you the command line to use to define the SONAME of the library. You want your library to have a SONAME of libregfi.so.1 installed in a file of the same name (or with more digits: libregfi.so.1.0.0). libregfi.so is a development symlink pointing to the current version of the library (the one to use when you link with gcc -lregfi). You can also read the Debian policy about libraries: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html Ok, still on my TODO list. Hum, this was not in the 1.0.1 release. We tend to work with what's officially released. We'll take a look at the trunk... I agree it is best to stick with releases when you can. In this case, right after my last release I had a maintainer from another distro ask for the DESTDIR support and after adding it they were satisfied with trunk. I didn't bother making another release just for that. Before I knew it, 4 years had passed and yeah, it's still only in trunk. Once we get the pieces in place you need for a debian package, I'll make another release and then you can track releases again. Another wrinkle: Google is shutting down Google Code, which is a bummer. I need to migrate my SVN mirror to someplace else. Probably github, along with the rest of the uncouth masses. I'll let you know when I do, so you can start working from that. For multiarch support we install libraries in different path, for autoconf packages, debhelper automatically feeds appropriate parameters. debhelper doesn't support SCons because there's no standard parameters or target to use... Anyway, LIBDIR should be enough for our cases, we then have to setup this variable to point to an architecture specific path. /usr/lib/x86_64-linux-gnu for amd64, /usr/lib/i386-linux-gnu for i386 and so on. Ok, so I think I already have LIBDIR support as well. Just added CFLAGS and LDFLAGS to a local version. It is possible that some of the flags I have in each of these by default could cause you problems on other architectures, but I suppose we'll just have to deal with those as they pop up. And also some things which could be improved: * please rename pyregfi-distutils.py to setup.py so that it can be automatically detected by our build tools Ok, I'll look into this. That way we can rely on python packaging tools directly, but in that case, it would be nice if we could disable the python part done by scons itself too... Ok, that makes sense. Right now the python library installation is all lumped in with the install target. You could build binaries without interference, but once you tried to install just certain pieces, the python wrappers will always install, which is probably not what you want. Would it make sense to create sub-targets, say install_python, install_lib, etc so that you can call the appropriate one depending on which sub-package you're building? Or would you suggest another approach? No, fakeroot lets you believe that you are root. But a good work-around is to not call ldconfig at all when DESTDIR is non-empty. $ fakeroot python Python 2.7.10 (default, May 26 2015, 13:10:44) [GCC 4.9.2] on linux2 Type help, copyright, credits or license for more information. import os os.getuid() 0 I was aware of fakeroot, but I must have assumed a while back that fakeroot wouldn't be that tricky. I've added a DESTDIR check as well as you suggest. Possibly this: https://www.gnu.org/software/autoconf/manual/autoconf.html#Environment-Variable-Index There's no standard environment variable for installation directories AFAIK. Only DESTDIR is sort of standardized... BTW, the sample recipe linked from the guide can be found here: https://web.archive.org/web/20141126004350/http://www.scons.org/wiki/Installer (since the URL is currently down). Thank you for the links. I'll look into more of this later to ensure I haven't missed anything. As it stands, LIBDIR, BINDIR, MANDIR, INCLUDEDIR, and PREFIX are all already accepted from the environment. Am I using them correctly? Who knows! ;-) Best, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
