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
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hi,
On Mon, 14 Sep 2015, Tim wrote:
> 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
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.
I was not aware that you could use SVN with GitHub... but in any case
it doesn't seem to let me export a sub-tree:
$ svn export https://github.com/ecbftw/reglookup/trunk reglookup
Areglookup
Areglookup/README.md
Areglookup/SConstruct
Areglookup/releases
Areglookup/releases/0.10.0
It doesn't export the content of the "trunk" sub-directory. I can work
it out manually, but those extra steps are annoying...
> 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.
Yes, I meant 2.3.6.
On Mon, 14 Sep 2015, Tim wrote:
> 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.
Actually the error I have is during build and not during install.
The build step runs "scons bin doc doc-devel" and should not install
anything yet. Yet it tries to install something and since I have not
set DESTDIR/PREFIX at this step, it fails to install the file due to lack of
permissions.
Here's how it fails on my side (not the latest svn version but the regression
in scons affects former packages too):
debian/rules override_dh_auto_build
make[1]: Entering directory '/«BUILDDIR»/reglookup-1.0.1+svn282'
scons bin doc doc-devel
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o src/reglookup-recover.o -c -std=gnu99 -pedantic -Wall
-D_FILE_OFFSET_BITS=64 -fvisibility=hidden -DREGFI_VERSION='"99.99.99.277"' -g
-O2 -fstack-protector-strong -Wformat -Werror=format-security -Iinclude
-I/usr/local/include src/reglookup-recover.c
[...]
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.
Do you agree that "scons bin doc doc-devel" should not fail when without
root rights?
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/
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 --to-stdout doc/reglookup-recover.1.docbook|sed 's/.SH
DESCRIPTION/\n.SH DESCRIPTION/'| gzip -9 > doc/reglookup-recover.1.gz
Install file: "doc/reglookup-recover.1.gz" as
"/tmp/reglookup/man/man1/reglookup-recover.1.gz"
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
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hello Tim, sorry for the delay of my answer but August was DebConf and vacation... On Fri, 07 Aug 2015, Tim wrote: > 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 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). > 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 Sure, that's possible. 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/
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Control: tag -1 + patch
Hi,
On Fri, 05 Jun 2015, Eriberto Mota wrote:
I can update reglookup. However, I need 10 days, because I am
traveling now and I can't use my GPG key.
You can now base your work on this updated package:
http://http.kali.org/pool/main/r/reglookup/reglookup_1.0.1+svn282-0kali2.dsc
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.
For reference, we only have the attached two patches in use in Kali.
One to disable the build of the python module (we do it ourselves
in debian/rules) and one to use a proper versioned library.
While lookinto in Scons support for versioned shared library I found this:
http://stackoverflow.com/questions/2997001/how-to-get-shared-library-names-like-libhello-so-0-0-1-with-scons
http://www.scons.org/doc/production/HTML/scons-user/apb.html#b-SharedLibrary
The attached patches make use of that.
but does not seem
to make any difference between the version used in the filename (ideally
libfoo.so.X.Y.Z) and the SONAME which is usually simpler (libfoo.so.X and
which is the reason why the symlinks libfoo.so.X are needed when you
install the library as libfoo.so.X.Y.Z). I would thus suggest to pass a
single integer to SHLIBVERSION and not care about having a filename
encoding the full version.
full version filename and the SONAME
That part of my last message was not supposed to be there. It's some
random text left from an initial draft that assumed that upstream support
was not working like I expected it.
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/
Description: add version to shared library liregfi
Update SConstruct file to manage the version for the shared library
libregfi.
Author: Sophie Brun sop...@freexian.com
Origin: vendor
Last-Update: 2015-06-09
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/SConstruct
+++ b/SConstruct
@@ -9,10 +9,9 @@ cflags = '-std=gnu99 -pedantic -Wall -D_
cflags += ' -DREGFI_VERSION=\'%s\' ' % REGFI_VERSION
cflags += os.environ.get('CFLAGS','-fPIE -pie -fstack-protector -D_FORTIFY_SOURCE=2')
-linkflags = -shared -fPIC -Wl,-soname,libregfi.so.%s % REGFI_VERSION
+linkflags = -shared -fPIC
linkflags += os.environ.get('LDFLAGS','-z relro -z now')
-
lib_src = ['lib/regfi.c',
'lib/winsec.c',
'lib/range_list.c',
@@ -31,7 +30,7 @@ env = Environment(ENV=os.environ,
# Libraries
libregfi_static = env.Library(lib_src)
libregfi = env.SharedLibrary(lib_src, LIBS=['m','pthread', 'talloc'],
- LINKFLAGS=linkflags)
+ SHLIBVERSION = '0.0.0', LINKFLAGS=linkflags)
# Executables
@@ -64,7 +63,7 @@ install_bin = [destdir + bindir, destdir
install_lib = [destdir + libdir, destdir + includedir + '/regfi']
env.Install(destdir+bindir, [reglookup, reglookup_recover, 'bin/reglookup-timeline'])
-libinstall = env.Install(destdir+libdir, [libregfi, libregfi_static])
+libinstall = env.InstallVersionedLib(destdir+libdir, [libregfi, libregfi_static], SHLIBVERSION='0.0.0')
env.Install(destdir+includedir+'/regfi', Glob('include/*.h'))
env.Install(destdir+mandir+'/man1', [man_reglookup, man_reglookup_recover,
man_reglookup_timeline])
Description: drop python packages build and install by scons
Do not use scons for the python packages build and install. Use dh-python
(pybuild) and the setup.py provided by upstream to build automatically the
packages python and python3
Author: Sophie Brun sop...@freexian.com
Origin: vendor
Last-Update: 2015-06-09
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/SConstruct
+++ b/SConstruct
@@ -72,22 +72,6 @@ env.Install(destdir+mandir+'/man1', [man
if os.getuid() == 0 and destdir == '':
env.AddPostAction(libinstall, 'ldconfig')
-install_pyregfi = []
-if sys.version_info[0] == 2:
- install_pyregfi.append('pyregfi2-install.log')
-
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hi Raphael, You can now base your work on this updated package: http://http.kali.org/pool/main/r/reglookup/reglookup_1.0.1+svn282-0kali2.dsc Thanks much for putting this together. 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. I'll try. I'm super busy this summer, as I was accepted as a Blackhat speaker and have a lot of prep to do. It is definitely on my list. For reference, we only have the attached two patches in use in Kali. One to disable the build of the python module (we do it ourselves in debian/rules) and one to use a proper versioned library. While lookinto in Scons support for versioned shared library I found this: http://stackoverflow.com/questions/2997001/how-to-get-shared-library-names-like-libhello-so-0-0-1-with-scons http://www.scons.org/doc/production/HTML/scons-user/apb.html#b-SharedLibrary The attached patches make use of that. Great, thanks for the info. tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hello Tim,
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 :))
While lookinto in Scons support for versioned shared library I found this:
http://stackoverflow.com/questions/2997001/how-to-get-shared-library-names-like-libhello-so-0-0-1-with-scons
http://www.scons.org/doc/production/HTML/scons-user/apb.html#b-SharedLibrary
So it looks like it's supported since version 2.3.0... I just tried this
and got good results:
--- a/SConstruct
+++ b/SConstruct
@@ -9,10 +9,9 @@ cflags = '-std=gnu99 -pedantic -Wall -D_
cflags += ' -DREGFI_VERSION=\'%s\' ' % REGFI_VERSION
cflags += os.environ.get('CFLAGS','-fPIE -pie -fstack-protector
-D_FORTIFY_SOURCE=2')
-linkflags = -shared -fPIC -Wl,-soname,libregfi.so.%s % REGFI_VERSION
+linkflags = -shared -fPIC
linkflags += os.environ.get('LDFLAGS','-z relro -z now')
lib_src = ['lib/regfi.c',
@@ -31,7 +30,7 @@ env = Environment(ENV=os.environ,
# Libraries
libregfi_static = env.Library(lib_src)
libregfi = env.SharedLibrary(lib_src, LIBS=['m','pthread', 'talloc'],
- LINKFLAGS=linkflags)
+ SHLIBVERSION='0.0.0', LINKFLAGS=linkflags)
# Executables
@@ -64,7 +63,7 @@ install_bin = [destdir + bindir, destdir
install_lib = [destdir + libdir, destdir + includedir + '/regfi']
env.Install(destdir+bindir, [reglookup, reglookup_recover,
'bin/reglookup-timeline'])
-libinstall = env.Install(destdir+libdir, [libregfi, libregfi_static])
+libinstall = env.InstallVersionedLib(destdir+libdir, [libregfi,
libregfi_static], SHLIBVERSION='0.0.0')
env.Install(destdir+includedir+'/regfi', Glob('include/*.h'))
env.Install(destdir+mandir+'/man1', [man_reglookup, man_reglookup_recover,
man_reglookup_timeline])
but does not seem
to make any difference between the version used in the filename (ideally
libfoo.so.X.Y.Z) and the SONAME which is usually simpler (libfoo.so.X and
which is the reason why the symlinks libfoo.so.X are needed when you
install the library as libfoo.so.X.Y.Z). I would thus suggest to pass a
single integer to SHLIBVERSION and not care about having a filename
encoding the full version.
full version filename and the SONAME
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/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hi, On Fri, 05 Jun 2015, Tim wrote: 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? That should work, yes. 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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hi, 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. 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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hi, I am trying update all 'abandoned' packages in Forensics Team. I started this work in December 2014. I can update reglookup. However, I need 10 days, because I am traveling now and I can't use my GPG key. Cheers, Eriberto 2015-06-05 7:25 GMT-03:00 Raphael Hertzog hert...@debian.org: Hi, 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. 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-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644019: reglookup: Please package latest upstream (1.0.1)
On Fri, 05 Jun 2015, Tim wrote: * 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. 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 * 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. 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... * 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? 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. 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... * 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? 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 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. 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). 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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644019: reglookup: Please package latest upstream (1.0.1)
On Wed, Jun 03, 2015 at 07:54:31AM -0700, Tim wrote: Yeah, it's sad. I need some one to *help* me package it and take I have this same problem currently. I would be very happy to upload other new versions too in forensics-area and also fix bugs. Mika can probably sponsor our uploads. Not sure if this is up-to-date: https://people.debian.org/~mika/forensics/maintainer.html -- Henri Salo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Hello, On Sat, 01 Oct 2011, Tim wrote: I released 1.0.1 today. Since 0.99.0, RegLookup has included Python wrappers that are now used by third-party projects, including Registry Decoder and DFF. It would help those projects' packaging efforts a lot if a recent version of RegLookup were in Debian. Some of the suggested guidelines for packaging the upstream source are here: http://projects.sentinelchicken.org/reglookup/dependencies Please let me know if resources are not available to update the package so I can put it on my TODO list. 4 years later Debian still has 0.12 :-( If you can prepare an updated package, I might look at sponsoring it. 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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644019: reglookup: Please package latest upstream (1.0.1)
Package: reglookup Version: 0.12.0-1 Severity: wishlist Tags: upstream I released 1.0.1 today. Since 0.99.0, RegLookup has included Python wrappers that are now used by third-party projects, including Registry Decoder and DFF. It would help those projects' packaging efforts a lot if a recent version of RegLookup were in Debian. Some of the suggested guidelines for packaging the upstream source are here: http://projects.sentinelchicken.org/reglookup/dependencies Please let me know if resources are not available to update the package so I can put it on my TODO list. Thanks much, tim -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37 (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.13-11Embedded GNU C Library: Shared lib reglookup recommends no packages. reglookup suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
