similar to: hivex: lintain being pedantic about spelling!

Whilst cleaning up the lintian reports in preparation for the Debian/Ubuntu hivex package one of the issues is: E: libhivex-perl: binary-or-shlib-defines-rpath ./usr/lib/perl/5.10.1/auto/Win/Hivex/Hivex.so /tmp/buildd/hivex-1.2.1/perl/../lib/.libs I've temporarily dealt with this by using chrpath in the build and a rule to delete the RPATH from "auto/Win/Hivex/Hivex.so". I wonder

xen source: lintian output: 'license-problem-gfdl-invariants stubdom/grub.patches/00cvs invariant part is: with no invariant sections, with the front-cover texts being a gnu manual, and with the back-cover texts as in (a) below', automatically rejected package. xen source: If you have a good reason, you may override this lintian tag. xen-utils-4.11: lintian output:

The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be looking at

These were flagged by the [Lintian] [spelling-error-in-binary] rule. [Lintian]: https://github.com/Debian/lintian [spelling-error-in-binary]: https://lintian.debian.org/tags/spelling-error-in-binary.html Signed-off-by: Kevin Locke <kevin@kevinlocke.name> --- v2v/rhv-upload-plugin.py | 4 ++-- v2v/rhv-upload-vmcheck.py | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git

The symbols file generated in the Debian package to aid the package maintainer automatically detect future changes shows internal library and helper function names, whereas it should only be exporting hivex_* function names. This page may help with this: http://gcc.gnu.org/wiki/Visibility Symbols: asnprintf at Base 1.2.1 c_isalnum at Base 1.2.1 c_isalpha at Base 1.2.1 c_isascii at Base

Put the "=back" to close the list only after the last element. --- regedit/hivexregedit | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/regedit/hivexregedit b/regedit/hivexregedit index 02c382b..cd49063 100755 --- a/regedit/hivexregedit +++ b/regedit/hivexregedit @@ -248,8 +248,6 @@ You should only use this option for quick hacking and debugging of the hive

This patch series improves, but does not complete, OS X support for hivex. There are several outstanding issues before hivexml and hivexsh can run: * hivexsh uses open_memstream, which doesn't exist in OS X as near as I can see. Unfortunately, I'm inexperienced with autoconf, so I'm not sure how to employ AC_CHECK_FUNCS([open_memstream]) to conditionally add 'sh' to the

Hello all, I've been testing hivexml in OS X, and came across an inconsistency in building. Some while back, I hit a snag with iconv in OS X, where basically this would happen when a hive of any sophistication (greater than hivex/images/small) was processed: >$ xml/hivexml images/large >test.xml >dyld: lazy symbol binding failed: Symbol not found: _iconv_open > Referenced from:

Since some modules (`getopt', for example) may copy files into the build directory, `top_builddir/lib' is needed as well as `top_srcdir/lib'. -- GNU Gnulib manual, section 2.2 Initial import This fixes an in-tree build failure on a Debian/sid system (see below). hivexml could be built out-of-tree, but it turned out that due to a missing include path, in this case the

--- ruby/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ruby/Makefile.am b/ruby/Makefile.am index b6654d3..e78ab59 100644 --- a/ruby/Makefile.am +++ b/ruby/Makefile.am @@ -51,7 +51,7 @@ RUBY_SITEARCH := $(shell $(RUBY) -rrbconfig -e "puts RbConfig::CONFIG['sitearchd install: $(MKDIR_P) $(DESTDIR)$(RUBY_SITELIB) $(MKDIR_P)

Hello, to build + packages dovecot I use the usual Debian tool chain. That includes build with selected GCC options and running lintian. I notice since a long time (read: many earlier versions, up to 2.2.35) this lintian warnings: I: dovecot-core: hardening-no-fortify-functions usr/lib/dovecot/auth N: N: This package provides an ELF binary that lacks the use of fortified libc N:

Hi, libhivex seems to do a great job at parsing hives most of the time, but there are some issues with a few registry keys. These can be worked around in the application that uses libhivex, but I think it'd be better if libhivex handled these itself. 1. UTF16 string in REG_SZ that has garbage after the \0\0 There is code in hivex.c to handle this already but I think it has a typo: /*

Hi, Few changes in hivex, sent as series to be clearly identified as hivex ones. After these patches, what about a new release of it? The last one is basically one year old, and the changes after 1.3.11 make hivex build and work fine on FreeBSD (and maybe more non-Linux OSes). Thanks, Pino Toscano (3): Fix shebang in perl scripts Update gnulib to latest. Update .gitignore with more

Hai Guys, ? The following has been done:?4.10.6?for Debian Buster (10) is ready. Short version of the changes: The settings are updated with latest Official Debian Samba packages, and its more focused on builds with python3. ? The changes logs of these changes, including the debian changes. ( see below ) Repo Info?: http://apt.van-belle.nl/ Buildlogs?: http://downloads.van-belle.nl/ ? ---?

Move the temporary output of pod2man to the correct name only if pod2man did not fail: this also makes the whole command fail if pod2man fails, e.g. because of wrong markup. --- lib/Makefile.am | 2 +- regedit/Makefile.am | 2 +- sh/Makefile.am | 4 ++-- xml/Makefile.am | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/Makefile.am b/lib/Makefile.am index

Otherwise we get "Can't open ..." warnings which don't seem to be fatal. --- regedit/Makefile.am | 2 +- sh/Makefile.am | 4 ++-- xml/Makefile.am | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/regedit/Makefile.am b/regedit/Makefile.am index 7977334..476c059 100644 --- a/regedit/Makefile.am +++ b/regedit/Makefile.am @@ -39,6 +39,6 @@

Hi all, The linking problem I found yesterday appears to be because of the built-in iconv in OS X. So, this is a request for patch or pointers: What needs to happen with configure.ac or the iconv.m4 macro file to link an iconv library _besides_ the one in /usr/local/lib? That's the tl;dr, full explanation follows. That library lacks the x86_64 architecture: $ file

Hi As my cross platform registry editor (FRED available from https://www.pinguin.lu (sorry for advertising but I couldn't resist ;-))) is evolving, I recently added write support to it. While under Linux everything worked nice, the Windblows build didn't. It seems that Windows opens files by default in text mode (O_TEXT) which is a problem. The attached patch adds the O_BINARY flag to

Hi, > -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Marcio Merlone via samba > Verzonden: donderdag 19 maart 2020 20:59 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] One more upgrade question > > Great, many thanks! > > I expect to also upgrade some 4.7 member file servers on a further >

--- configure.ac | 2 +- images/Makefile.am | 5 +++-- lib/Makefile.am | 14 +++++++------- ocaml/Makefile.am | 3 ++- ocaml/t/hivex_300_fold.ml | 3 +-- python/run-python-tests | 25 ------------------------- python/run-python-tests.in | 25 +++++++++++++++++++++++++ 7 files changed, 39 insertions(+), 38 deletions(-) delete mode