Bug#843219: reglookup-doc: Please don't depend on firefox-esr
I agree, it doesn't really make sense to depend on a specific browser. At most, "recommend" a generic browser virtual package, like www-browser, but even then I don't know that it is necessary. tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#644019: closed by Giovani Augusto Ferreira <giov...@riseup.net> (Bug#644019: fixed in reglookup 1.0.1+svn287-1)
Great, thank you! tim On Mon, Oct 10, 2016 at 12:03:10PM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the reglookup package: > > #644019: reglookup: Please package latest upstream (1.0.1) > > It has been closed by Giovani Augusto Ferreira <giov...@riseup.net>. > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Giovani Augusto Ferreira > <giov...@riseup.net> by > replying to this email. > > > -- > 644019: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644019 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > Message-Id: <e1btzfy-0007vb...@franck.debian.org> > Content-Type: text/plain; charset="utf-8" > Return-path: <envel...@ftp-master.debian.org> > From: Giovani Augusto Ferreira <giov...@riseup.net> > To: 644019-cl...@bugs.debian.org > Date: Mon, 10 Oct 2016 12:00:34 + > Subject: Bug#644019: fixed in reglookup 1.0.1+svn287-1 > > Source: reglookup > Source-Version: 1.0.1+svn287-1 > > We believe that the bug you reported is fixed in the latest version of > reglookup, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 644...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Giovani Augusto Ferreira <giov...@riseup.net> (supplier of updated reglookup > package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Wed, 28 Sep 2016 21:00:32 -0300 > Source: reglookup > Binary: libregfi1 libregfi-dev reglookup python-pyregfi python3-pyregfi > reglookup-doc > Architecture: source amd64 all > Version: 1.0.1+svn287-1 > Distribution: experimental > Urgency: medium > Maintainer: Debian Forensics <forensics-devel@lists.alioth.debian.org> > Changed-By: Giovani Augusto Ferreira <giov...@riseup.net> > Description: > libregfi-dev - utility to analysis for Windows NT-based registry (develop. > files > libregfi1 - utility to analysis for Windows NT-based registry (shared > library > python-pyregfi - Python Bindings for reglookup > python3-pyregfi - Python 3 Bindings for reglookup > reglookup - utility to analysis for Windows NT-based registry > reglookup-doc - developer documentation for libregfi and python-pyregfi > Closes: 644019 > Changes: > reglookup (1.0.1+svn287-1) experimental; urgency=medium > . >* New upstream release. (Closes: #644019) >* New co-maintainer. >* Update DH level to 10. >* debian/clean: create to clean before build. >* debian/control: >- Added dependencies required by new release to build and install. >- Added entries for new binaries and libraries. >- Bumped Standards Version to 3.9.8. >- Improved all descriptions. >- Updated the Vcs-* fields to use https instead of http and git. >* debian/copyright: >- Removed entries of unused files. >- Updated licenses and copyright years. >* debian/libregfi1*: files created to build the library package. >* debian/patches: >- fix-FTBFS-with-ld removed, the new release do not use the Makefile. >- fix-install.patch added, patch to fix the install paths and add >GCC Hardening. >- fix-spelling.patch added, fix a typo in manpage. >- fix-string-error removed, the upstream provides in new release. >- fix-version.patch added, fix package version. >* debian/reglookup-doc.*: files created to build the documentation package. >* debian/rules: updated to new build method. >* debian/watch: >- Bumped to version 4. >- Added a mangle rule to handle the '+svn287' suffix. >- Removed the useless entry. > Checksums-Sha1: > 24c9e9594659ee3a7b92ddd2d05937d6e9b9a397 2379 reglookup_1.0.1+svn287-1.dsc > f2a909fb4cdbfe3015a9c1a73dd01e3935b29461 183216 > reglookup_1.0.1+svn287.orig.tar.gz > 0e1f967478a5ba82e2d4ec949ea7df1a0bb6cce8 7040 > reglookup_1.0.1+svn287-1.debian.tar.xz > d05d20fb4f64a9d2ac63319c26f6f3c43f
Bug#644019: reglookup: Please package latest upstream (1.0.1)
> Honestly, I don't care about SVN or GIT. What I do care about is that you > provide me a usable tarball and you don't do that currently. At least > GitHub can build tarball on the fly for me... but only when I want > everything in the repository. Ok, I'm sorry for the trouble. The ground has shifted under my feet with Google locking down my main project site, so it will take me a while to figure out the best solution. I realize now that GitHub's SVN support sucks. Don't bother with it. I will send you a tarball privately that you can try out. > gcc -o lib/libregfi.so.0.0.0 -shared -fPIC -Wl,-z,relro -shared > -Wl,-Bsymbolic -Wl,-soname=libregfi.so.0 lib/regfi.os lib/winsec.os > lib/range_list.os lib/lru_cache.os lib/void_stack.os -Llib -L/usr/local/lib > -lm -lpthread -ltalloc > Install file: "lib/libregfi.so.0.0.0" as "/usr/local/lib/libregfi.so.0.0.0" > scons: *** [/usr/local/lib/libregfi.so.0.0.0] > /usr/local/lib/libregfi.so.0.0.0: Permission denied > scons: building terminated because of errors. I'm honestly not sure how you get this error. I didn't have this problem with either my SVN tree check out or the tarball I just built (and will send you shortly). > Do you agree that "scons bin doc doc-devel" should not fail when without > root rights? Yes, these should complete without root privileges, though you shouldn't need to run 'doc'. That's because I run it when I build the tarball and distribute man pages as static files. FYI 'doc-devel' requires dependencies doxygen and graphviz. Not sure if I documented that previously. Stay tuned, 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)
> - then the package fails to build for us with "scons" 3.6 that is present
> in unstable... somehow it tries to install the library in the target
> where we are trying to build it. I did not understand why...
Ok, so I'm not sure what you're running into here. I cleaned out all
build artifacts my build tree and those installed on my system ("scons -c"
and "sudo scons -c install", respectively) and then did a fresh install
into a temporary directory using PREFIX. It seems to work fine as
shown in the transcript below. Let me know if I can provide more
info or run things differently.
thanks,
tim
===
tim@pauling:~/reglookup/trunk$ mkdir /tmp/reglookup
tim@pauling:~/reglookup/trunk$ sudo PREFIX=/tmp/reglookup scons install
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o src/reglookup.o -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -Iinclude -I/usr/local/include src/reglookup.c
gcc -o lib/regfi.o -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -Iinclude -I/usr/local/include lib/regfi.c
lib/regfi.c:672:13: warning: regfi_offset_in_hbin defined but not used
[-Wunused-function]
static bool regfi_offset_in_hbin(const REGFI_HBIN* hbin, uint32_t voffset)
^
gcc -o lib/winsec.o -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -Iinclude -I/usr/local/include lib/winsec.c
gcc -o lib/range_list.o -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -Iinclude -I/usr/local/include lib/range_list.c
gcc -o lib/lru_cache.o -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -Iinclude -I/usr/local/include lib/lru_cache.c
gcc -o lib/void_stack.o -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -Iinclude -I/usr/local/include lib/void_stack.c
ar rc lib/libregfi.a lib/regfi.o lib/winsec.o lib/range_list.o lib/lru_cache.o
lib/void_stack.o
ranlib lib/libregfi.a
gcc -o lib/regfi.os -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -fPIC -Iinclude -I/usr/local/include lib/regfi.c
lib/regfi.c:672:13: warning: regfi_offset_in_hbin defined but not used
[-Wunused-function]
static bool regfi_offset_in_hbin(const REGFI_HBIN* hbin, uint32_t voffset)
^
gcc -o lib/winsec.os -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -fPIC -Iinclude -I/usr/local/include lib/winsec.c
gcc -o lib/range_list.os -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -fPIC -Iinclude -I/usr/local/include lib/range_list.c
gcc -o lib/lru_cache.os -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -fPIC -Iinclude -I/usr/local/include lib/lru_cache.c
gcc -o lib/void_stack.os -c -std=gnu99 -pedantic -Wall -D_FILE_OFFSET_BITS=64
-fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2 -fPIC -Iinclude -I/usr/local/include lib/void_stack.c
gcc -o lib/libregfi.so.1.0.1 -fPIC -Wl,-z,relro,-z,now -shared -Wl,-Bsymbolic
-Wl,-soname=libregfi.so.1 lib/regfi.os lib/winsec.os lib/range_list.os
lib/lru_cache.os lib/void_stack.os -Llib -L/usr/local/lib -lm -lpthread -ltalloc
gcc -o src/reglookup -fPIC -Wl,-z,relro,-z,now src/reglookup.o -Llib
-L/usr/local/lib -lm -lpthread -lregfi -ltalloc
Install file: "src/reglookup" as "/tmp/reglookup/bin/reglookup"
gcc -o src/reglookup-recover.o -c -std=gnu99 -pedantic -Wall
-D_FILE_OFFSET_BITS=64 -fvisibility=hidden -DREGFI_VERSION='"1.0.1.283"' -fPIE
-pie -fstack-protector -D_FORTIFY_SOURCE=2 -Iinclude -I/usr/local/include
src/reglookup-recover.c
gcc -o src/reglookup-recover -fPIC -Wl,-z,relro,-z,now src/reglookup-recover.o
-Llib -L/usr/local/lib -lm -lpthread -lregfi -ltalloc
Install file: "src/reglookup-recover" as "/tmp/reglookup/bin/reglookup-recover"
Install file: "bin/reglookup-timeline" as
"/tmp/reglookup/bin/reglookup-timeline"
docbook2x-man -
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hi guys, Just got back from vacation myself. > So we tried to update the package but failed rather miserably: > - first your version number generator is broken since it tries to embed a > SVN revision number that no longer exists now that you migrated on > GitHub (we worked around that by dropping that part of the version) > - then the package fails to build for us with "scons" 3.6 that is present > in unstable... somehow it tries to install the library in the target > where we are trying to build it. I did not understand why... > > I stopped at that point and could not review how the result would > have looked. > > We also noticed that the GitHub is a not very useful import of the SVN > repository... it's not possible to use git archive to export a copy of > reglookup because the repository contains more than this and the reglookup > source code is one level deeper (in trunk). Could you actually just try using subversion? I may be mirroring it on GitHub, but that doesn't mean I use git. I'm not convinced I even like git. Far too complex for simple projects. Anyway, I'm just pushing a mirror of my SVN repo to GitHub right now. Can you try using a subversion client to access the repo? e.g.: $ svn co https://github.com/ecbftw/reglookup This should address the SVN version generator and bypass any git archive issue. As for building with scons 3.6... I'm on Debian sid right now and the latest version is 2.3.6, so I suspect that is what you mean. I'll take a look at my build and make sure it behaves as I expect. thanks, 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)
On Mon, 08 Jun 2015, Raphael Hertzog wrote: we just tried the trunk. It's better but there are still multiple problems: - LDFLAGS is not used when you link the executables (it's only used when you link libregfi) - the default value for LDFLAGS is wrong, -z relro is an option for ld but when you pass it through gcc you need -Wl,-z,relro - I saw you tried to hack up some code to setup the SONAME... it does set the SONAME on the library but the library is still installed under the wrong name (libregfi.so instead of the name set in the SONAME) - the SONAME must not encode the full version... it's only a simple counter of API/ABI compatibility. Please use libregfi.so.0 as the first SONAME (and then bump to libregfi.so.1 when you break the ABI/API, etc.) (and 99.99.99.X looks really wrong as a version number :)) Tim, I hope you can fix those issues quickly now that we have identified how to properly handle versioned libraries and that you can make a new release. Hi Raphael, I finally had a chance to take another crack at this. I've attempted to address all of the items listed above. I integrated your guys' soname patch and tweaked it a bit to use a partial reglookup version number as the ABI version. The way it behaves right now is to assign 1.0.1 as the version when working from trunk. When working from a release version, it will use just the first two portions of the version (e.g. 1.0). The reason for this is that I don't change my API in minor point releases, but I typically do when the upper version numbers change. I did not integrate the other patch that strips python installs, since users need that if they compile from source. Can you simply run these two targest to achieve the same result? scons install_bin scons install_lib I fixed the two LDFLAGS issues you pointed out as well. Let me know if you think it is up to snuff now. Best, 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)
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
Bug#644019: reglookup: Please package latest upstream (1.0.1)
4 years later Debian still has 0.12 :-( If you can prepare an updated package, I might look at sponsoring it. 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. tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
[no subject]
Are you in any kind of financial difficulties? Do you need an urgent finance to pay off your bills or to start up a new business? Contact us for further details: jjamesrobin...@outlook.commailto:jjamesrobin...@outlook.com Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my organization shall be understood as neither given nor endorsed by it. ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#705326: broken formatting in the manual pages
This is a known issue that I believe was fixed in 0.5.0. Debian can't upgrade to this version because there is no package available for the latest reglookup (a dependency). This has been an outstanding issue for a couple of years and I haven't had time to build a debian package. I believe the DFF guys have built some packages for these. It may be a simple matter of borrowing their version and incorporating into mainline debian if someone wants to take that on. tim On Sat, Apr 13, 2013 at 03:14:42PM +0800, Paul Wise wrote: Package: grokevt Version: 0.4.1-7 Severity: normal The grokevt-* manual pages have broken formatting, usually starting at the synopsis section and including the section after that. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grokevt depends on: ii python 2.7.3-4 ii python-support 1.0.15 ii reglookup 0.12.0-1 -- bye, pabs http://wiki.debian.org/PaulWise ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: Debian Forensic IRC meeting, 2011-12-03 - meeting notes
Thanks for the helpful meeting guys.
reglookup will be updated by Christophe Monniez
- Adian will update reglookup trunk with build changes
submitted by Adam Golebiowski of PLD Linux
- Mika will help in packaging (scons CO)
I've attached a patch of my changes to the base SConstruct file.
It does 3 things:
- Adds some link flags and sets the regfi library soname
- Adds environment variables to set various installation paths,
including a fake root path
- Only executes ldconfig if the install runs as uid 0
Hopefully that will address some of the issues you've had in previous
attempts to package the newer reglookup versions.
I also wanted to mention that pyregfi supports both python 2.7+ and
python 3. I don't know what the normal way to package libraries that
do this. Clearly the combinations of dependencies and build order can
be complex, so it may require two separate packages (or virtual
packages?), one for each version, so that downstream applications can
depend on the version of the library they want without pulling in a
version of Python that they don't.
It might be helpful to schedule another IRC chat session for a time
when you guys plan on working on the reglookup packaging so I can be
immediately available to help out.
Thanks!
tim
Index: SConstruct
===
--- SConstruct (revision 276)
+++ SConstruct (revision 278)
@@ -23,7 +23,8 @@
# Libraries
libregfi_static = env.Library(lib_src)
-libregfi = env.SharedLibrary(lib_src, LIBS=['m','pthread', 'talloc'])
+libregfi = env.SharedLibrary(lib_src, LIBS=['m','pthread', 'talloc'],
+ LINKFLAGS=-shared -fPIC -Wl,-soname,libregfi.so.%s % REGFI_VERSION)
# Executables
@@ -45,28 +46,33 @@
man_reglookup_timeline = env.ManPage('doc/reglookup-timeline.1.docbook')
# Installation
-prefix='/usr/local/'
-if 'PREFIX' in os.environ:
- prefix = os.environ['PREFIX']+'/'
+prefix = os.environ.get('PREFIX','/usr/local')+'/'
+destdir= os.environ.get('DESTDIR','')
+bindir = os.environ.get('BINDIR', prefix + 'bin')
+libdir = os.environ.get('LIBDIR', prefix + 'lib')
+includedir = os.environ.get('INCLUDEDIR', prefix + 'include')
+mandir = os.environ.get('MANDIR', prefix + 'man')
-install_items = [prefix+'bin',
- prefix+'lib',
- prefix+'include/regfi',
- prefix+'man']
+install_items = [destdir + bindir,
+ destdir + libdir,
+ destdir + includedir + '/regfi',
+ destdir + mandir]
-env.Install(prefix+'bin', [reglookup, reglookup_recover, 'bin/reglookup-timeline'])
-libinstall = env.Install(prefix+'lib', [libregfi, libregfi_static])
-env.Install(prefix+'include/regfi', Glob('include/*.h'))
-env.Install(prefix+'man/man1', [man_reglookup, man_reglookup_recover,
-man_reglookup_timeline])
-env.AddPostAction(libinstall, 'ldconfig')
+env.Install(destdir+bindir, [reglookup, reglookup_recover, 'bin/reglookup-timeline'])
+libinstall = env.Install(destdir+libdir, [libregfi, libregfi_static])
+env.Install(destdir+includedir+'/regfi', Glob('include/*.h'))
+env.Install(destdir+mandir+'/man1', [man_reglookup, man_reglookup_recover,
+ man_reglookup_timeline])
+if os.getuid() == 0:
+ env.AddPostAction(libinstall, 'ldconfig')
+
if sys.version_info[0] == 2:
install_items.append('pyregfi2-install.log')
env.Command('pyregfi2-install.log', ['python/pyregfi/__init__.py',
'python/pyregfi/structures.py',
'python/pyregfi/winsec.py'],
- python pyregfi-distutils.py install | tee pyregfi2-install.log)
+ python pyregfi-distutils.py install --root=/%s | tee pyregfi2-install.log % destdir)
python_path = os.popen('which python3').read()
if python_path != '':
@@ -74,7 +80,7 @@
env.Command('pyregfi3-install.log', ['python/pyregfi/__init__.py',
'python/pyregfi/structures.py',
'python/pyregfi/winsec.py'],
- python3 pyregfi-distutils.py install | tee pyregfi3-install.log)
+ python3 pyregfi-distutils.py install --root=/%s | tee pyregfi3-install.log % destdir)
# API documentation
regfi_doc = env.Command('doc/devel/regfi/index.html',
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: Debian Forensic IRC meeting, 2011-12-03
My Saturday schedule just opened up a bit so I should be able to make it to this. I may be a bit late, but am looking forward to it. thanks, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: state of reglookup, developer IRC meeting?
Elías Alejandro did work on the reglookup package (thanks!), but it seems not to be uploaded yet. Is there anything specific outstanding? Since Tim probably incorporate those patches for the next release, I wonder if we can hope by it, or apply those patches directly. I do hope to fully assess those patches soon, but I've just been crazy busy. Also, I was hoping for some feedback from you guys to determine if those patches actually did address the problems you were having, or if I would need to make some other changes as well. Once I do check them in to trunk, I probably won't make a release any time soon though, since there aren't any other outstanding bugs that I know about. You could either maintain the patches in your build until a new release comes out, or I could give you a trunk package that you could use once I get them checked in. I'm agree. btw I'm elias in irc. Ok, great. I think it would be very useful to have a short meeting on IRC with you guys to debug things. I sent mika my availability off-list. cheers, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: about reglookup
Hi guys, Sorry for any trouble my hacky library installation may be causing you. I recently received a couple of patches out of the blue from Adam Golebiowski, a PLD Linux package maintainer: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/reglookup/reglookup-soname.patch?rev=HEAD http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/reglookup/reglookup-paths.patch?rev=HEAD These seem to be related and may fix the soname problem, but I haven't had the time to evaluate them yet. I will probably incorporate some variation of these into the next upstream release. Let me know if there are other things I can change to help you out. thanks, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: Things to be done / discussed
I could take a look to reglookup this weekend. Regards, -- Elías Alejandro Thanks Elías, I will look at your work to learn how to handle scons in Debian packages. I can test the package once it's done. -- Christophe Monniez christophe.monn...@fccu.be Thanks for taking a look at these. Don't hesitate to ping me if you get hung up on any of the build process for my packages. It has probably been a decade since I built a debian package (/me feels old), but I'll jump in and help where ever I can. Just let me know what you need. Best regards, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: Educational Software News - April 2009
unfortunately, there's nothing i can do about it. the spam that gets through comes through some alioth queue we can't control (like the bug messages or so; they also get in 'unfiltered'). Who controls it? Can't it just be restricted to subscribers only? it is already subscribers only afaik. Really? newslet...@discount-educational-software.org is subscribed? Can we remove it from the list then? I just hate seeing a list like this being used to exacerbate the spam problem. I can follow up with the list admin if you point me in the right direction. thanks, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
RegLookup 0.99.0 (release candidate) packaging
Hi Christophe, I released a preview version of the new RegLookup today. I wanted to drop you a note because it will require some major changes in how it needs to be packaged. I envision that we'll eventually need to have several packages built from the source package. Here's a first stab at what the dependencies might look like: Build dependencies: scons libtalloc2 libtalloc-dev python2.6+ or python3.1+ doxygen Derived packages and runtime dependencies: libregfi: libtalloc2 libregfi-dev: libtalloc-dev libregfi-doc: (none) python-pyregfi: libregfi (python2.6+ or python3.1+) reglookup: libregfi libc6 We'd probably want some recommends/suggests in there too. Maybe libregfi-dev suggests libregfi-doc, since doc would contain the developer/API documentation for both libregfi and the new python bindings. python-pyregfi should also suggest/recommend libregfi-doc. Currently the default behavior of the scons build scripts is to build all of the files that would be included in the above packages with the exception of those for libregfi-doc. Once you run 'scons doc-devel', then you'll find all relevant files in the doc/devel sub directory. I would expect the man pages (under doc/) to remain in the reglookup package. Since this is just a release candidate right now, it is not a high priority for packaging, but I wanted to give you the chance to see what the changes will be some time before the stable version is released. Feel free to suggest any changes to the build scripts if it will help you add the debian specific stuff. Thanks much, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Re: Debian-Forensics team working towards Squeeze?
Hi mika, everyone, * make sure all our packages are up2date (matching current upstream release) In regard to this, I'm in one of my active development cycles on RegLookup. I'm getting some help from a certain Australian whiz kid and he's inspiring me to push the development further. I was hoping to make one more release sometime soon and get it into squeeze if possible. What do you guess my timeline would be on that? * check out which new additional packages should be integrated, related to http://wiki.debian.org/DebianForensics/TODO In a quick look at that list, I'd love to see these be packaged: air fmem libpff dc3dd pyflag would of course be cool too, but it may be a lot more effort on short notice. I agree with mika that hydra shouldn't be a high priority. The few times I've used it, it either didn't do what I wanted or it crashed. medusa seems to be much more stable, if lightly documented. It's bloody fast too. Of course this is all talk and no action. Unfortunately, I don't have time right now to learn how to create debian packages and integrate them with the build system, so do what you think is best. I'd work on a new wiki page at http://wiki.debian.org/DebianForensics for coordinating the efforts if some of you are interested in joining. If you guys do have any nasty bugs in a package, let me know and I can try to help with the debugging/resolution or working with the upstream. Best, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Bug#574544: [afflib] contains files released under a non-free license
I didn't noticed this last sentence. I will send this to the uptream author and see if he is able to give more freedom. I find the last sentence pretty comical since the previous sentences explicitly stated the code was placed into the public domain. Once you place something into the public domain, you no longer hold copyright. If you have no copyright, you can't enforce any license agreements on that copyright. I'm definitely not a lawyer, but that last sentence seems completely unenforceable. If not, the only solution that I see is to remove afflib from Debian. When you contact Simson, you may want to mention the above oxymoron. thanks, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Bug#574638: reglookup: License is GPLv3 since 0.9.0 (not GPLv2+)
Package: reglookup Version: 0.11.0-2 Severity: serious Justification: Policy 2.3 I just noticed that the debian packages for reglookup appear to advertise a GPLv2 or later license. RegLookup was GPLv2 from the beginning until version 0.4.0, and GPLv3 from 0.9.0 until the present. It has never been GPLv2 or later or GPLv3 or later. It's not a big deal, since all of the code I have borrowed from other sources has been GPLv2 or later. It's just my modifications that are more restrictive. (I just want to be able to read what Stallman and crew cook up before switching to it.) Oh, I guess I do have some LGPL code in the borrowed talloc stuff, so that's a special case, but pretty much everything else is straight GPLv3. When you have a chance to package 0.12.0, please update this as well. Thanks! -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages reglookup depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib reglookup recommends no packages. reglookup suggests no packages. -- no debconf information ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
New upstream reglookup (0.12.0)
Hello, I just released version 0.12.0 of RegLookup which offers some modest of solid improvements over 0.11.0. There shouldn't be any changes that introduce gotchas on the packaging. If you would like me to submit a wishlist bug for this to be packaged, I can. Thanks, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Re: Updates
Yes, my changes where only about the PREFIX and ETC_PREFIX. I did the same kind of changes to tableau-parm too. It's not a real problem for me, so you can make it the way you prefer in upstream. Ok, will do. You could maybe use a config script from autotools ? I'd rather not go down that path if possible... I often see people using automake/autoconf as a crutch not to write portable software from the get-go. However, I have often thought of moving away from Makefiles as my primary build framework, and if I do, I'll maybe write a config script that has similar usage. Thanks much, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Re: Updates
Hey Christophe, New upstream versions for safecopy and tableau-parm. Fixed a not yet discovered critical bug in grokevt. For GrokEVT, was your change just the PREFIX and ETC_PREFIX installation variables? Or was there something else? Let me know if you have suggestions on how to make this piece easier on you for packaging. As for tableau-parm, is there a place I can grab a built package of 0.2.0, or would I need to pull from git and build myself? thanks, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Bug#549164: tableau-parm: New upstream version (0.2.0)
Package: tableau-parm
Version: 0.1.0-5
Severity: wishlist
Hello,
I just wanted to let you know that I released a new tableau-parm
version today. See:
http://projects.sentinelchicken.org/tableau-parm/news
There are no major functional changes for Linux, as it's more of a
portability release for other platforms. It does, however, introduce
a dependency on sg3_utils which may mean a libsgutils{1|2}-dev build
dependency and a libsgutils{1|2} run time dependency needs to be
added.
I am also curious to know, when you find time to package this version,
if there are any things I could do to make your job easier down the
road with the build process.
Thanks,
tim
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tableau-parm depends on:
ii libc6 2.9-26 GNU C Library: Shared libraries
tableau-parm recommends no packages.
tableau-parm suggests no packages.
-- no debconf information
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Re: fatback_1.3-1_i386.changes REJECTED
the files fatback-manual.* state
Copyright @copyright{} 2000-2001 DoD Computer Forensics Lab
This manual and the Fatback program are for @strong{government and law
enforcement use only}.
which is incompatible to the DFSG.
The above copyright statement seems to be a weak attempt to restrict
usage of the fatback program, but this is likely not enforceable.
Works of the US Goverment are, in general, not copyrightable at all.
See: http://www.copyright.gov/title17/92chap1.html
105. Subject matter of copyright: United States Government works
Copyright protection under this title is not available for any
work of the United States Government, but the United States
Government is not precluded from receiving and holding copyrights
transferred to it by assignment, bequest, or otherwise.
Perhaps the copyright were transferred, but I would be surprised. In
any case, I agree that some investigation may need to be done before
establishing that it is indeed in the public domain.
tim
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Bug#524983: reglookup: typo in manpage
line 13 in reglookup.1.gz writes: \fR.SH Description The \fR should be deleted. Thanks for the report. This is due to a bug in the docbook2x package and I logged a bug against it (#516165) a little while back. In the next upstream release, I will try to remember to manually fix the man pages generated by that tool before publishing. I can't guarantee I'll always remember to do this though, so hopefully the docbook2x folks will get this nipped in the bud. regards, tim ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Re: Educational Software News - April 2009
Is there a reason we put up with this junk on the list? Can't it just be restricted to subscribers only? cheers, tim On Thu, Apr 09, 2009 at 02:47:31PM -0700, Educational Software Newsletter wrote: Adobe Acrobat Professional 9.0 available at the promotional price of $99.95 while supplies last! Don't miss out on this great deal! See details below. Computer Products for Education is pleased to provide Educational Software News to current students, faculty, staff, and schools with news, pricing, and availability of Academic Edition Software from Microsoft, Adobe, Corel, Autodesk, Quark, EndNote, FileMaker, and many other major software manufacturers. Please visit our website for more information: http://www.discount-educational-software.org or call 800-679-7007. Educational software is exclusively available to qualified Students, Teachers, Faculty, Staff, and Schools of Higher Education and K-12 institutions. (see below for details) ... ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Based on Your Credibility...
GREETINGS BASED ON YOUR CREDIBILITY.. I am TIM MCCARRON the Fund Manager of Fidelity Investment International. The World Largest Fund Management Company with over 1.2Trillion Capital Investment Fund and over 900 thousand investors all over the world. Nevertheless, as The Fidelity Fund Manager, I handle all our Investor's Direct Capital Funds (financial funds). As a routine, every investor gets the percentage profit or dividend from the total cash he or she invested into the company annually. Last year it was announced that the profit margin was 20% after calculating carefully I found out that the profit margin was 21.1% that is an excess of 1.2% on each investor so I secretly extracted 1.2% Excess Maximum Return Capital Profit (EMRCP) per annum on each of the Investor's Marginal Capital Fund and created a separate account where the total sum of the extraction was kept as an expert, the account has a value of 8, 745, 000, 00.(pounds) Now, I am looking for someone who I can trust to stand as an Investor to receive the fund as Annual Investment Proceeds from Fidelity Marginal Capital Fund. All confirmable and legal documents to back up the claims will be made available to you as soon as possible. Meanwhile, I have worked out the modalities and technicalities whereby the funds can be claimed in any of our 6 Clearing Houses without any hitches. Our sharing ratio will be 50-50. If you are interested, get back to me through email so that I will provide you more information about the transaction or you provide me with phone number to reach you for more details. Yours Truly TIM MCCARRON TIM MCCARRON. Fund Manager: Fidelity Investments International Oak hill House, 130 Ton bridge Rd Hildenborough Tonbridge , Kent TN11 9DZ , London timconsultant...@mail2consultant.com N/B: REMEMBER I HAVE NOTHING BUT THE TRUTH TO OFFER AND ALSO FOR THE OPTIMUM SECURITY OF THIS TRANSACTION PLEASE CONTACT ME ON THIS MAIl. - Berhubung melalui perbualan pada profil rangkaian, blog atau mana-mana tapak web peribadi! Yahoo! membolehkan anda untuk IM dengan Pingbox. Cubalah ciri ini! - Dapatkan nama E-mel keutamaan anda! Kini anda boleh @ymail.com dan @rocketmail.com. - Mencari semua rakan di Yahoo! Messenger? Anda boleh dengan mudah menjemput rakan anda dari Hotmail, Gmail ke Yahoo! Messenger hari ini!___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
