> 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
> - 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
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
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
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
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
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
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
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.
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
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
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
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
13 matches
Mail list logo
