Bug#661873: Closing bugs
Version: 1.3.8-11 -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#662588: unhide: incorrect use of alternatives
Hi Piotr, Le lundi 05 mars 2012 à 09:09:48 (+0100 CET), Piotr Engelking a écrit : The unhide postinst script switches the unhide alternative to manual mode, which is a violation of section 3 of the wheezy RC policy. The manual mode is provided for the system administrator. The use of the alternative is also broken: it decides which binary to run based on which kernel was used at the package install time, which is not necessarily the kernel that is used at run time. Please remove the alternatives. One correct replacement would be to use a wrapper to choose the binary. This is, however, no longer necessary, since Debian doesn't support pre-2.6 Linux kernels anymore, so a simpler solution is to just use the 2.6 features unconditionally on Linux systems. Thanks for spotting this - will work on this during the week-end, latest within the end of next week. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#662128: rkhunter: Check for suspicious files message triggers warnings found e-mail
Hi Thomas, Le dimanche 04 mars 2012 à 11:33:50 (+0100 CET), Thomas Lamy a écrit : [...] After configuring rkhunter, filtering false positives etc, I get this daily report: --- Warning: Checking for files with suspicious contents [ Warning ] And what triggers this warning? You can check this in /var/log/rkhunter.log I guess you have missed a file in your whitelist or something like that. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#657103: rkhunter: Invalid BINDIR configuration option: Invalid directory found: ~/bin
Le mardi 31 janv. 2012 à 09:02:59 (+0100 CET), Jesse Molina a écrit :
Sorry for slow reply.
--echo $PATH
~/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
--egrep PATH= .bash*
.bash_profile:PATH=/usr/local/sbin:/usr/sbin:/sbin:${PATH}
.bash_profile:PATH=~/bin:${PATH}
OK, I have finally managed to get this behaviour, ~/bin is not expanded...
[...]
The question as to why BINDIR in the config file is being ignored remains.
Read around line 2122 of rkhunter:
# The BINPATHS list is prepended with the root PATH. However,
# any specified BINDIR directories beginning with a '+' will
# be prepended before the root PATH.
#
# Once that has been done, we check that each directory begins
# with a '/'. We remove any non-existent directories, but we do
# not flag this as an error. We also remove any duplicate directories.
Hence the root PATH is then always considered, contrary to what I had
originally thought. The behaviour you describe is IMHO normal, the cause is
the fact you don't allow ~/bin to be expanded to /home/user/bin.
Simply change your .bash_profile to state PATH=~/bin:${PATH} and it should
work as expected.
Cheers,
Julien
--
.''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org
: :' : Debian Developer Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#652170: new libprocps0 package
Le mercredi 11 janv. 2012 à 23:50:12 (+0100 CET), Craig Small a écrit : Hello, Apologies for the rough ride around the libprocps library change. The latest procps now has split out the shared library into its own package. This should mean that there is less of this problem in future. You will need to download libprocps0-dev and re-link the program to -lprocps. There is also a pkg-config file if you need that. I've tested it with xmem and it builds fine with 2 small changes. In future, there will be a large API change but that will be in a new library version package so it won't be like the programs suddenly stop working like before. Thanks Craig for your work, I have just built guymager against libprocps0-dev and uploaded it to the archive. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#654583: WARNING: gnome-keyring:: no socket to connect to
reassign 654583 gnome-keyring thanks Hi, Le mercredi 11 janv. 2012 à 14:51:32 (+0100 CET), Teodor MICU a écrit : 2012/1/10 Julien Valroff jul...@debian.org: So, on Jan 08 it appeared on two jobs (00logwatch and apt). I'm undecided to which package to reassign: cron or gnome-keyring? What do you think? What happens if you run such a cron job by hand when not in an X session? Today I watched the Cron run without X/gnome/gdm running at all. The result was the same: # Date: Wed, 11 Jan 2012 07:34:27 +0200 /etc/cron.daily/00logwatch: WARNING: gnome-keyring:: no socket to connect to I have never seen this behaviour, maybe you have any specific configuration? I don't think so. On all systems (desktops, servers) I have 'ssmtp' to provide the 'sendmail' interface, thus no SMTP daemon. One think I've noticed a few days ago is that something was changing the hostname from the FQDN (frost.DOMAIN -- set from /etc/hostname) to just 'frost' but I didn't investigate further. Also, today I obtained this message while doing packages upgrades: | Processing triggers for man-db ... | Processing triggers for menu ... | Processing triggers for desktop-file-utils ... | Processing triggers for gnome-menus ... | Processing triggers for hicolor-icon-theme ... | Processing triggers for cups ... | Starting Common Unix Printing System: cupsd. | WARNING: gnome-keyring:: no socket to connect to | WARNING: gnome-keyring:: no socket to connect to | Updating PPD files for postscript-hp ... | Updating PPD files for splix ... | Processing triggers for gconf2 ... Usually this warning appears on the email from Cron. Other ideas? No idea on my side but given your answers, it seems this is an issue with gnome-keyring, I hence reassign this bug to the appropriate package. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: afflib package - bug #645915
Hi Christophe, Le lundi 09 janv. 2012 à 08:10:18 (+0100 CET), Christophe Monniez a écrit : Le samedi 07 janvier 2012 à 17:10 +0100, Julien Valroff a écrit : [...] BTW, is there any good reason you use git-dch? I find it very hard to follow the work because of it (but may be due to the fact I am not used to using it). Well, I have no good reason to use it. We really should update our workflow to see who works on what. Does it really matter? I am OK to work on any package but I do not use all of them which explains why I always prefer a regular user tests the changes I have made before uploading. The packages for which I am an uploader means I use it and I am OK to take care of it on a regular basis (ie. follow upstream development, package new releases, fix bugs ASAP etc.). But if someone of the team steps up and upload such a package before I can do it, I am perfectly fine with it. Maybe what we should do is make sure nobody else works on a given package before doing it ourselves (this would avoid duplicate work, but I do not think it has happened in the recent past). It was once said that it's up to the uploader to maintain the changelog because it's automatically generated by git (I suppose git-dch). So, when I work on a package, I don't update the changelog, to not interfere with the uploader work. Am I wrong ? What is the good way of doing it ? I am not used to using git-dch and *I* think it is not needed in our workflow, but I was not aware of the discussion you already had on this point. Remember I am new in the team, and still must have to learn your habits ;) Sorry if I have broken these rules. Now, my question was also on a practical level: what do you see as advantage working with git-dch? I am personally used to debcommit which allows me to keep the standard workflow (eg. dch --team) while still making git commit logs useful. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#655055: rkhunter: a couple of (debian specific?) warnings
Hi Karl,
Le dimanche 08 janv. 2012 à 06:56:21 (+0100 CET), Karl Goetz a écrit :
Package: rkhunter
Version: 1.3.6-4
Severity: minor
Hi,
I've got a couple of comments after running rkhunter, hopefully you'll
agree they are bugs :)
* it warns that /sbin/chkconfig has been replaced by a script, but its
shipped as a (perl) script in debian. Could this be included in
SCRIPTWHITELIST please?
chkconfig is not widely used on Debian and the default rkhunter
configuration should take this into account. I would hence avoid adding this
even as a commented example.
* With etckeeper becoming popular, could the config example include
/etc/.etckeeper and /etc/.{git,bzr}ignore as comments in
ALLOWHIDDENDIR and ALLOWHIDDENFILE?
I have added them as comments in the default configuration file.
Cheers,
Julien
--
.''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org
: :' : Debian Developer Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: Bug#634412: ext3grep: FTBFS: superblock.h:35:99: error: 'EXT2_FRAG_SIZE' was not, declared in this scope
Le samedi 10 déc. 2011 à 09:35:07 (+0100 CET), Julien Valroff a écrit : tags 634412 + pending thanks Hi Peter, Le samedi 10 déc. 2011 à 08:14:27 (+0100 CET), peter green a écrit : I just did a test build on current sid and ran into failures but they were different from the failure reported in the bug report. I guess the headers have changed again since this bug was reported. Anyway the attatched patch makes the code build in current sid. Thanks Peter for your help. I have pushed your patch to the git repository for the upcoming package upload. Could anyone familiar with ext3grep test the new release so that we can upload it to sid ASAP? ping The upload would fix 2 RC bugs. cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#634412: ext3grep: FTBFS: superblock.h:35:99: error: 'EXT2_FRAG_SIZE' was not, declared in this scope
Le dimanche 08 janv. 2012 à 03:07:39 (+0100 CET), peter green a écrit : Thanks again for your patch. Everything seems to work OK but as I normally don't use ext3grep, I let regular users test by themselves and will then upload the package. It doesn't seem any regular users responded to your request, I tried to put the word out wider on debian-user and the debian forums but noone responded there either. Where do we go from here? I have pinged other members of the forensics team. As a user of ext3grep, do you want me to build packages that you could test? If so, which architecture? P.S. a duplicate of this bug has been filed, I guess the filer didn't spot this one because it was marked as pending. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654201 I have just forcibly merged these bugs. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Bug#651119: rkhunter: False positives when checking running processes for suspicious files
package rkhunter
tags 651119 + moreinfo
thanks
Hi Rory,
Le lundi 05 déc. 2011 à 22:52:34 (+0100 CET), Rory Campbell-Lange a écrit :
Package: rkhunter
Version: 1.3.6-4
Severity: important
Processes that match any of the checked strings (noted after the colon after
...were found) trigger rkhunter alerts.
For instance /usr/bin/dbus-daemon --system appears to trigger an alert.
Warning: Checking running processes for suspicious files [ Warning ]
Warning: One or more of these files were found: backdoor, adore.o,
mod_rootme.so, phide_mod.o, lbk.ko, vlogger.o, cleaner.o, cleaner, ava,
tzava, mod_klgr.o, hydra, hydra.restore, ras2xm, vobiscum, sshd3,
system, t0rnsb, t0rns, t0rnp, rx4u, rx2me, crontab, sshdu, glotzer,
holber, xhide, xh, emech, psybnc, mech, httpd.bin, mh, xl, write,
Phantasmagoria.o, lkt.o, nlkt.o
Check the output of the lsof command 'lsof -F n -w -n'
One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)
Thanks for reporting this issue.
However, I am not sure to understand what you mean: do you thin you get a
warning because system is found in a running process name?
I fail to understand how this could happen, at least in the current code, as
the possible suspicious *files* are grepped in the lsof output using the
following code:
FOUNDFILES=`grep /${FNAMEGREP}$ ${RKHLSOF_FILE}`
In the version 1.3.6 you use, the following code is used:
FILENAME=`${LSOF_CMD} -wnlP -F n | grep '^n/' | sed -e 's/^n//' | ${SORT_CMD}
| ${UNIQ_CMD} | egrep /(${SUSP_FILES})\$`
which means, in your example, that '--system' could not be matched.
Also, note that the suspicious files listed in the warning are checked with
the output of lsof which lists open files, and not running processes (as
does ps). 'dbus-daemon --system' is not a file, but a running process.
I hence fail to understand what triggers the warning you get. Have you
checked the logfile and the lsof output?
Cheers,
Julien
--
.''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org
: :' : Debian Developer Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
___
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
Hi, Le dimanche 04 déc. 2011 à 00:56:33 (+0100 CET), Michael Prokop a écrit : Hi, thanks everyone for attending the Debian Forensic IRC meeting. The meeting took place from 21:00 until 00:42 CET, with 6 people attending overall. Thanks for sending these meeting minutes. Packaging of libbfio (http://sourceforge.net/projects/libbfio/) - Julien will fill ITP - lessyv will help in packaging related questions - call for testing once someone is ready Preliminary source package is available in git [0]. Reviews and comments are welcome. I am wondering about the multiarch status of our libraries, has anyone already thought about converting them? Cheers, Julien [0] http://anonscm.debian.org/gitweb/?p=forensics/libbfio.git -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 signature.asc Description: Digital signature ___ 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
Le jeudi 01 déc. 2011 à 00:01:25 (+0100 CET), Michael Prokop a écrit : Hi, sorry for not coming back earlier WRT the Debian Forensic IRC meeting, but finally I managed to talk to Christophe on IRC and we just decided to make a IRC meeting this weekend so we can push work a bit. :) On this Saturday, 3rd of December 2011 we'll meet online on IRC (#debian-forensics), starting at 21:00 / 9 p.m. CET. Feel free to join if you have time and interest in Debian Forensic! Hope to see you there :) I'll try and be there for a while - I have to wake up early on Sunday, hence might not be able to stay for long though. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 signature.asc Description: Digital signature ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: rkhunter backport for squeeze?
Hi Alexander, Le jeudi 03 nov. 2011 à 16:15:00 (+0100 CET), Alexander Reichle-Schmehl a écrit : Hi! Many thanks for your work on the rkhunter package, I'm using it on quite some machines. However, I would be very interested in having backports of the package available (via backports.d.o). Backporting rkhunter seems also to be quite easy, but being just a user and not deeper involved in it's packaging or development, I'm wondering if there could be a reason not to backport it? Surely I'm not the first one interested in one. Actually, yes, you are the first one to ask for it which partly explains why there is no backport for rkhunter. If there's no reason, would you mind if I upload a backport to the archive, or would you prefer to do it on your own? I can do this myself if that's fine for you. I however would like to upload the 1.3.8-10 version first which fixes the bug you have just reported (BTW, thanks for the patch), as well as #644326. I also agree there shouldn't be any problem with the backport, hence I'll upload it as soon as the new version enters in testing. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: About Unhide.rb
Hi Yago, Le dimanche 23 oct. 2011 à 19:59:00 (+0200 CEST), Yago Jesus a écrit : Hi Julian (and all Debian Forensics team) First, I want to thank you for your quick response. I like the new description but, I have a doubt. Why 10 times faster? Who made this test? Is always 10x faster? is it in both 32 and 64 bits enviroments? Im agree Unhide.rb is faster (due to the less deep tests) but I don't know exactly how much. You are right, I haven't tested it myself. Then, what about just stating much faster? Moreover if you want to highlight this feature I think it is also fair to highlight the question about static binaries VS non static Ruby Binary. With a security point of view, I think the fact that Unhide should be compiled and shipped in static mode makes Unhide inmune to the most popular rootkits (based in LD_PRELOAD). On the other hand Unhide.rb due to their Ruby dependency could be compromised. So, yes Unhide is more secure than Unhide.rb Here is a new proposal: Unhide.rb is a forensic tool to find processes hidden by rootkits. . It looks for active processes in many different ways. Processes found by some means but not others are considered to be hidden, and are reported to the user. . Unhide.rb is a tentative of rewrite in Ruby of the original Unhide, which is written in C. While being much faster, it does not implement all the diagnostics of the original version. It is also less secure as it cannot be statically compiled. . This package can be used by rkhunter in its daily scans. FYI, here is the current description of the unhide package: Unhide is a forensic tool to find processes and TCP/UDP ports hidden by rootkits, Linux kernel modules or by other techniques. It includes two utilities: unhide and unhide-tcp. . unhide detects hidden processes using three techniques: * comparing the output of /proc and /bin/ps * comparing the information gathered from /bin/ps with the one gathered from system calls (syscall scanning) * full scan of the process ID space (PIDs bruteforcing) . unhide-tcp identifies TCP/UDP ports that are listening but are not listed in /bin/netstat through brute forcing of all TCP/UDP ports available. . This package can be used by rkhunter in its daily scans. I understand your perspective about reporting. Unhide.rb is more compact but I think it is more important the fact about finding the exact hidden command (and in some scenarios, the path where rogue-binary lives) But it is subjective I consider both tools as complementary and not as competitors, depending on the use case. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: Packages that seems ready for upload
Le mercredi 12 oct. 2011 à 22:24:35 (+0200 CEST), Julien Valroff a écrit : Le mercredi 12 oct. 2011 à 20:16:42 (+0200 CEST), Julien Valroff a écrit : Le mercredi 12 oct. 2011 à 00:14:41 (+0200 CEST), Christophe Monniez a écrit : Hi, I tried to build and test some packages today and some of them seems ready to upload. Here they are: - dc3dd 7.1.614 - sleuthkit 3.2.3 - ssdeep 2.7 - wipe 0.22 - undbx 0.20 Thanks for all work on these packages Julien. I'll check them again and will upload them tonight / tomorrow evening. All done but Sleuthkit, it needs a few fixes according to lintian: I: libtsk3-3: spelling-error-in-binary usr/lib/libtsk3.so.3.4.0 extention extension E: libtsk3-3: symbols-file-contains-current-version-with-debian-revision on symbol _ZN7TskAuto13findFilesInFsEP11TSK_FS_INFO@Base and 4 others I: sleuthkit: hyphen-used-as-minus-sign usr/share/man/man1/tsk_recover.1.gz:43 Done as well. Hopefully I haven't fu**ed up the symbols files. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: Packages that seems ready for upload
Le mercredi 12 oct. 2011 à 00:14:41 (+0200 CEST), Christophe Monniez a écrit : Hi, I tried to build and test some packages today and some of them seems ready to upload. Here they are: - dc3dd 7.1.614 - sleuthkit 3.2.3 - ssdeep 2.7 - wipe 0.22 - undbx 0.20 Thanks for all work on these packages Julien. I'll check them again and will upload them tonight / tomorrow evening. I also need some help on libpff. What do you need exactly? Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: Packages that seems ready for upload
Le mercredi 12 oct. 2011 à 20:16:42 (+0200 CEST), Julien Valroff a écrit : Le mercredi 12 oct. 2011 à 00:14:41 (+0200 CEST), Christophe Monniez a écrit : Hi, I tried to build and test some packages today and some of them seems ready to upload. Here they are: - dc3dd 7.1.614 - sleuthkit 3.2.3 - ssdeep 2.7 - wipe 0.22 - undbx 0.20 Thanks for all work on these packages Julien. I'll check them again and will upload them tonight / tomorrow evening. All done but Sleuthkit, it needs a few fixes according to lintian: I: libtsk3-3: spelling-error-in-binary usr/lib/libtsk3.so.3.4.0 extention extension E: libtsk3-3: symbols-file-contains-current-version-with-debian-revision on symbol _ZN7TskAuto13findFilesInFsEP11TSK_FS_INFO@Base and 4 others I: sleuthkit: hyphen-used-as-minus-sign usr/share/man/man1/tsk_recover.1.gz:43 I won't have time to work on this for now, I would appreciate if you could do this. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: aimage
Le mardi 11 oct. 2011 à 07:12:57 (+0200 CEST), Christophe Monniez a écrit : Le lundi 10 octobre 2011 à 20:59 +0200, Julien Valroff a écrit : [...] Christophe, what do you think? [...] I asked to remove aimage from the archive because it was not maintained anymore. At this time, I sent a mail to the upstream author and he replied me that he had no more time to work on it anymore. A few days later, he decided to fix aimage, probably because that I was not the only one ask for it. I now understand, thanks for sharing this. This new version fixes #618087, am I right? I think that aimage have a place in Debian because there is no other command line tool that does the job. I use it all the time at work because a lot of our machine does not have a graphical interface. I do agree it still has a place in Debian if it is used and usable. The popcon figures [0] aren't very high but I guess it is normal for such a specialized tool. The actual package seems to work, I used it two time yesterday without any problem. Great, still need to be tested after the changes I have made (I had to reapply the patch which had been applied on the files directly rather than via a quilt patch). I'll look at copyright informations. The changelog should also mention that the package is back to Debian. Once you have been able to check all this again, I will be happy to upload it. Cheers, Julien [0] http://qa.debian.org/popcon.php?package=aimage -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: aimage
Hi Christophe, Le mercredi 12 oct. 2011 à 00:05:19 (+0200 CEST), Christophe Monniez a écrit : Le mardi 11 octobre 2011 à 20:06 +0200, Julien Valroff a écrit : (...) I now understand, thanks for sharing this. This new version fixes #618087, am I right? That's the bug we asked to fix. It should [1] Then it should be stated in the changelog as well. I am however not sure if this should be done in the official way (I mean closing the bugs which are already closed). (...) I do agree it still has a place in Debian if it is used and usable. The popcon figures [0] aren't very high but I guess it is normal for such a specialized tool. True, and I'm pretty sure that most forensics people do not participate to popcon even if anonymity is guaranteed. You're 100% right. BUt still, they should ;) [...] The changelog should also mention that the package is back to Debian. I will look at how to do that... if there is a Debian way to mention that. Not that I know. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: aimage
Le lundi 10 oct. 2011 à 13:27:07 (+0200 CEST), Christophe Monniez a écrit : Hi all, I did a build (amd64) of aimage package from our git repository. It build without any problem. I then tried the program on another machine and it worked without any error. So I think it's ready for upload if any dd have time enough. I'll take care of this. Thanks for testing Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: aimage
Le lundi 10 oct. 2011 à 18:42:59 (+0200 CEST), Julien Valroff a écrit : Le lundi 10 oct. 2011 à 13:27:07 (+0200 CEST), Christophe Monniez a écrit : Hi all, I did a build (amd64) of aimage package from our git repository. It build without any problem. I then tried the program on another machine and it worked without any error. So I think it's ready for upload if any dd have time enough. I'll take care of this. Thanks for testing Now, I am puzzled: I have just pushed further changes and was reviewing the package when I have came across #637818 - you have requested aimage to be removed from the archive. Are you sure you want it back? If it is not maintained upstream, I don't think it is a good idea. Cheers, Julien [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637818 -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: aimage
Le lundi 10 oct. 2011 à 20:36:26 (+0200 CEST), Don Raikes a écrit : Just to add my 2 cents: the aimage package was replaced with guymage. However, as a blind computer forensics wannabe, I have tested guymage and it is totally inaccessible to a blind person while aimage being a command-line application is not inaccessible. That's a good point you might want to report upstream as well (I mean thank aimage developers and ask for a more accessible UI to guymager developers). I would push to have it maintained as an available package. In the mean time, I have checked and notices the 3.2.5 version of aimage was released on 17.11.2011 which shows the upstream development is still active. I think the package shouldn't have been removed from the archive at all. Still, the package needs to be more carefully checked to ensure everything is ok. It eg. misses copyright information for files under debian/. Christophe, what do you think? Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: libphash
Hi Christoph, Le vendredi 19 août 2011 à 16:10:19 (+0200 CEST), Christophe Monniez a écrit : Le vendredi 19 août 2011 à 15:45 +0200, Julien Valroff a écrit : Hi, I have been working on libphash to refresh the packaging and include the patch for #638243 (tested successfully when building against ffmpeg -dev packages available in experimental). I have also worked on adding support for multiarch. Could someone test the result (and especially the -dev package following to the swtich to multiarch)? Cheers, Julien I'll test it next week. Have you had a chance to test libphash? cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
libphash
Hi, I have been working on libphash to refresh the packaging and include the patch for #638243 (tested successfully when building against ffmpeg -dev packages available in experimental). I have also worked on adding support for multiarch. Could someone test the result (and especially the -dev package following to the swtich to multiarch)? Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: rsakeyfind: invalid maintainer address
Le vendredi 22 juil. 2011 à 12:15:52 (+0200 CEST), Niels Thykier a écrit : Hi, Any news on this? ~Niels PS: I decided to explicitly CC forensics-devel@lists.alioth.debian.org, since the broken maintainer address might prevent the bug email to reach otherwise. I have just uploaded an updated package, thanks for thinking of CC'ing the list. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: unhide packaging
Hi Christophe, Le samedi 11 juin 2011 à 10:38:06 (+0200 CEST), Christophe Monniez a écrit : Le samedi 11 juin 2011 à 09:57 +0200, Julien Valroff a écrit : Le dimanche 05 juin 2011 à 13:35:51 (+0200 CEST), Julien Valroff a écrit : [...] undbx and dc3dd seem also ready for upload but would need more testing. Is anyone able to do this? I'll do that on monday ! Have you been able to test undbx? Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: updating extundelete
Le lundi 13 juin 2011 à 01:07:49 (+0200 CEST), Elías Alejandro a écrit : [...] Also, I have noticed the comments in src/extundelete.cc state the program is distributed under GPL-2 and not GPL-2+. I've Added this copyright/license. You have forgotten to change the License field for 'Files: *' accordingly. The rest seems now OK. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: updating extundelete
Hi Elías, Le dimanche 12 juin 2011 à 00:46:24 (+0200 CEST), Elías Alejandro a écrit : Hi Julien, First all, thanks for your help and advices. Here some answers Thanks for *your* work on this package. On Mon, Jun 06, 2011 at 08:55:37PM +0200, Julien Valroff wrote: [...] * debhelper compatibility should be bumped to 8 given you build-depend on = 8.0.0 Done. Actually, not yet fixed: `echo 8 debian/compat' will fix this (or reduce debhelper version to 7 in the build-dependencies if you prefer). Also, I have noticed the comments in src/extundelete.cc state the program is distributed under GPL-2 and not GPL-2+. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: unhide packaging
Le dimanche 05 juin 2011 à 13:35:51 (+0200 CEST), Julien Valroff a écrit :
Le mercredi 01 juin 2011 à 18:36:05 (+0200 CEST), Julien Valroff a écrit :
Hi!
Le mercredi 01 juin 2011 à 13:05:55 (+0200 CEST), Michael Prokop a écrit :
{...}
What I've on my TODO list are:
* undbx
* ssdeep (file conflicts)
* sleuthkit
* dc3dd
* md5deep
If you can help here we'd highly welcome that.
I'll take a deeper look at sleuthkit as I had already commited some changes
after Chritophe's email about the package.
I'll see what I can do for the others. md5deep and ssdeep interest me also.
unhide and md5deep were updated and uploaded.
As already discussed, sleuthkit needs some testing, just as would ssdeep.
These are tools I do not know at all…
I'll try and give some love to undbx and dc3dd this afternoon.
undbx and dc3dd seem also ready for upload but would need more testing. Is
anyone able to do this?
Cheers,
Julien
--
.''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org
: :' : Debian Developer Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
signature.asc
Description: Digital signature
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: pritine-tar data
Le mardi 07 juin 2011 à 08:49:36 (+0200 CEST), Christophe Monniez a écrit : Le dimanche 05 juin 2011 à 14:12 +0200, Julien Valroff a écrit : [...] Do you use git-import-orig with i --pristine-tar option to automatically do this job? I use the method described here: http://documentation.debian-projects.org/other/debian-packaging-git/ Mainly the 4.3 Adding new Upstream version point. I think this method is somehow outdated now that we have a very reliable tool which takes care of that automatically: git-buildpackage Using git-import-* tools and gbp-clone makes the workflow very easy, I suggest you have a look at these tools. I have also in the meantime managed to understand why gbp fails to detect the compression format with imports from your method. It is linked to the commit message which is based on the following template when using git-import-orig: pristine-tar data for package_version.orig.tar.gz I haven't checked the code though, but here is the verbose output of git-buildpackage: gbp:debug: ['git', 'log', '--pretty=format:%H', '--grep=pristine-tar .* extundelete_0.2.0\\.orig.tar\\.', 'pristine-tar', '--'] gbp:debug: ['git', 'log', '-n1', '--pretty=format:%s', 'pristine-tar'] gbp:debug: Determined compression type 'None' gbp:warn: Unknown compression type of Adding pristine-tar version 0.2.0., assuming gzip The pristine-branch contains: extundelete_0.2.0.orig.tar.gz.delta extundelete_0.2.0.orig.tar.gz.id But the commit log only states: Adding pristine-tar version 0.2.0. Which means the --grep cannot lead to any result. I don't think it is a problem, as gbp is meant to be used with git-import-orig and not in a different worfklow. Give me your thoughts on gbp, I thin kit's worth having a look at it. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: updating extundelete
Hi Elías, Le dimanche 05 juin 2011 à 22:50:02 (+0200 CEST), Elías Alejandro a écrit : Hi I've just updated extundelete[1]. Any member willing to review it?. Thanks for your good work. I think todo is: - Add Christophe Monniez copyright. - Sync date under debian/changelog to be agree with Debian Policy 3.9.2 (if not lintian warning). I had a quick look at the package, and it looks mainly ok, though here are some tiny improvement suggestions beside the above points: * Remove useless comments from debian/rules * You don't need to refer to your patch in the changelog, it's a new package. The README.Debian also seems useless. Both things can easily be replaced by using DEP-3 formatted headers in the patch file itself. * Again about this patch: have you forwarded it to upstream developers? If so, have they accepted it? I think it is a good idea to try and keep the Debian package as close as possible to the upstream tarball, and hence avoid unnecessary patches. * Have you also forwarded the manpage you have written? I guess this can * be useful for upstream to include it in their tarball. * You should use a standalone license paragraph for (at least) GPL-2+ (see DEP-5 for details) * debhelper compatibility should be bumped to 8 given you build-depend on = 8.0.0 - Someone willing DD under uploader field, to finally upload it. I'd be happy to upload this package for you once these points are fixed. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: unhide packaging
Le mercredi 01 juin 2011 à 18:36:05 (+0200 CEST), Julien Valroff a écrit :
Hi!
Le mercredi 01 juin 2011 à 13:05:55 (+0200 CEST), Michael Prokop a écrit :
{...}
What I've on my TODO list are:
* undbx
* ssdeep (file conflicts)
* sleuthkit
* dc3dd
* md5deep
If you can help here we'd highly welcome that.
I'll take a deeper look at sleuthkit as I had already commited some changes
after Chritophe's email about the package.
I'll see what I can do for the others. md5deep and ssdeep interest me also.
unhide and md5deep were updated and uploaded.
As already discussed, sleuthkit needs some testing, just as would ssdeep.
These are tools I do not know at all…
I'll try and give some love to undbx and dc3dd this afternoon.
Cheers,
Julien
--
.''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org
: :' : Debian Developer Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
signature.asc
Description: Digital signature
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
pritine-tar data
Hi,
While working on several packages, I have noticed that upstream tarballs
were incorreclty imported to pristine-tar, leading to the following warning
when using git-buildpackage:
gbp:warn: Unknown compression type of Adding pristine-tar version 0.20.,
assuming gzip
This means gpb cannot detect which compression format to use to re-generate
the upstream tarball (and falls back to gzip). gbp --git-compression option
could be used, but then, it's up to the maintainer to guess the compression
format.
I am not sure why gbp fails to detect this format, I haven't been able to
find how it tries to guess it (not enquire so much though).
Do you use git-import-orig with i --pristine-tar option to automatically do
this job?
This error is fixed by removing the .id and .delta files for a particular
version, and re-importing it manually as follows:
% uscan --force-download
% git checkout pristine-tar
% git rm pkg-name_pkg-version.orig.tar.gz.{id,delta}
% git commit -a
% pristine-tar commit ../pkg-name_pkg-version.orig.tar.gz
Here is a good link from Joey Hess's blog about using pristine-tar checkout
and commit commands:
http://kitenet.net/~joey/blog/entry/generating_pristine_tarballs_from_git_repositories/
Hope this helps.
Cheers,
Julien
--
.''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org
: :' : Debian Developer Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: unhide packaging
Le mercredi 01 juin 2011 à 08:59:23 (+0200 CEST), Christophe Monniez a écrit : Le mardi 31 mai 2011 à 18:54 +0200, Julien Valroff a écrit : Hi there, I am wondering if it is ok for me to update unhide to the latest upstream version and add me as an uploader for the package. Sure, no problem, that's why we are a team :) As I am new in the team, I still don't know the specific rules, hence prefer asking ;) [...] I can push my changes straight away, and wait for Christophe to have a look at the changes (he knows the package better than I do). That's not totally true, this package, like some others is an old heritage from 2009 when Daniel left debian Forensics. At this moment, he had too much package and he asked me to get all forensics related packages that he was responsible for. The fact is that it's too much packages for me too and I don't have time to manage all of them. That's why the forensic team is a great opportunity to divide the workload. I see... I'd like to do more for the team, but will go step by step. If there are any package which need to be updated, I can have a look rather quickly. So, for this package, I have to admit that I don't know it very well and if you want, you can set you as maintainer instead of me. OK, I'll do this as it is directly related to rkhunter and unhide.rb. I had even worked on the initial packaging I think. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: unhide packaging
Hi!
Le mercredi 01 juin 2011 à 13:05:55 (+0200 CEST), Michael Prokop a écrit :
{...}
I see... I'd like to do more for the team, but will go step by step. If
there are any package which need to be updated, I can have a look rather
quickly.
Cool!
What I've on my TODO list are:
* undbx
* ssdeep (file conflicts)
* sleuthkit
* dc3dd
* md5deep
If you can help here we'd highly welcome that.
I'll take a deeper look at sleuthkit as I had already commited some changes
after Chritophe's email about the package.
I'll see what I can do for the others. md5deep and ssdeep interest me also.
I'll take care of xmount and guymager soon. Sorry for not being more
active, but real life was too busy and I've to catch up with lots of
stuff...
So, for this package, I have to admit that I don't know it very well and
if you want, you can set you as maintainer instead of me.
OK, I'll do this as it is directly related to rkhunter and unhide.rb. I had
even worked on the initial packaging I think.
Thanks for your efforts Julien, very much appreciated!
Thanks for your warm welcome.
BTW: Do you plan to attend DebConf11?
Unfortunately, I won't have this chance.
Cheers,
Julien
--
.''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org
: :' : Debian Developer Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
signature.asc
Description: Digital signature
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
unhide packaging
Hi there, I am wondering if it is ok for me to update unhide to the latest upstream version and add me as an uploader for the package. The new version was released in January, and the package hasn't been updated for more than 1 year. I'd also like to add a call to a trigger allowing rkhunter to update its database when unhide is installed as a dependency of rkhunter (or at the same time). This would allow me to fix #607224 in rkhunter, and begin working on finding a solution for the 2.5 years old #512087… I can push my changes straight away, and wait for Christophe to have a look at the changes (he knows the package better than I do). Thanks in advance Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel
Re: sleuthkit
Le mercredi 04 mai 2011 à 10:14:57 (+0200 CEST), Christophe Monniez a écrit : Hi, I worked on sleuthkit and after a long search, I discover that some files were missing in the git repos. I don't know what kind of mistake I made when I imported upstream the first time. Anyway, I imported usptream again and now it builds fine. I think that this version is now ready for upload. I'll have a look at it during the week-end. It seems however several changes need to be applied to make lintian happy: I: sleuthkit source: missing-debian-source-format W: sleuthkit source: no-human-maintainers W: sleuthkit source: build-depends-on-1-revision build-depends: libewf-dev (= 20100226-1) W: sleuthkit source: changelog-should-mention-nmu W: sleuthkit source: source-nmu-has-incorrect-version-number 3.1.3-1 W: sleuthkit source: patch-system-but-direct-changes-in-diff Makefile.am and 110 more E: sleuthkit: embedded-library usr/bin/tsk_loaddb: sqlite W: sleuthkit: manpage-has-errors-from-man usr/share/man/man1/hfind.1.gz 98: warning [p 2, 6.2i]: cannot adjust line I: sleuthkit: hyphen-used-as-minus-sign usr/share/man/man1/tsk_comparedir.1.gz:33 I: sleuthkit: hyphen-used-as-minus-sign usr/share/man/man1/tsk_gettimes.1.gz:17 I: sleuthkit: hyphen-used-as-minus-sign usr/share/man/man1/tsk_gettimes.1.gz:25 I: sleuthkit: hyphen-used-as-minus-sign usr/share/man/man1/tsk_loaddb.1.gz:35 I: sleuthkit: hyphen-used-as-minus-sign usr/share/man/man1/tsk_loaddb.1.gz:38 I: sleuthkit: hyphen-used-as-minus-sign usr/share/man/man1/tsk_recover.1.gz:31 E: libtsk3-3: embedded-library usr/lib/libtsk3.so.3.3.1: sqlite E: libtsk3-3: symbols-file-contains-current-version-with-debian-revision on symbol _ZN7TskAuto10closeImageEv@Base and 233 others Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Re: sleuthkit
Le samedi 07 mai 2011 à 09:46:02 (+0200 CEST), Christophe Monniez a écrit : Le samedi 07 mai 2011 à 09:15 +0200, Julien Valroff a écrit : Unfortunately, I have too much work this week and will not be able to work on sleuthkit package before mai 12th. I will probably need help on how to de-embed sqlite and I don't really understand the last Error. I have just pushed the easy changes. I am unfortunately not skilled for de-embedding sqlite. The last error roughly means you have to update the symbols file (dpkg-gensymbols keeps the debian revision from the auto-generated symbols file). Hope this helps somehow... Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
