Bug#771461: /var/state/samhain/
On Tue, Dec 02, 2014 at 01:23:13AM +0100, Andrea Claudi wrote: Hi, This patch should fix the problem, moving the non-volatile state for the samhain package to /var/lib/samhain. The patch creates the directory for new installations but it is worth noticing that the /var/state/samhain/ contains valid information that has to be preserved over upgrades (otherwise, the integrity database would be regenerated and not kept). Please, tell me if I need to fix something to make this acceptable. I'm committing your patch to Samhain's GIT but have made some adjustments. I will test upgrades from previous versions and if all goes well I'll upload a new package soon. Regards Javier signature.asc Description: Digital signature
Bug#736375: init script broken start behavior
On Wed, Jan 22, 2014 at 10:34:55PM +0100, Peter Palfrader wrote: Package: samhain Version: 2.8.3a-1+deb7u1 Severity: serious Hi, the samhain in stable-updates has an init script that fails on start if the service is already running: This was not a bug introduced in the update. The bug was already present in the stable version (and in sid) [I wouldn't be surprised if this issue was also present in testing/unstable.] It is actually. I will prepare a fix for unstable. If the RMs approve then I will upload it also to stable-updates. Regards Javier signature.asc Description: Digital signature
Bug#736375: init script broken start behavior
tag 736375 pending
thanks
On Wed, Jan 22, 2014 at 10:34:55PM +0100, Peter Palfrader wrote:
the samhain in stable-updates has an init script that fails on start
if the service is already running:
I have made improvements to the init.d script and uploaded a preliminary fix
for this bug into unstable.
The fix for this is attached and I will make an upload to stable-updates if
RM allows.
Regards
Javier
diff --git a/debian/changelog b/debian/changelog
index f54f8f9..5d8800e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+samhain (2.8.3a-1+deb7u2) stable; urgency=medium
+
+ * debian/samhain.init: Improve the init script
+ - Do not fail in 'start' if the daemon is already started, use --oknodo
+(Closes: #736375)
+ - Do not try to stop the daemon (and wait for it to stop) if it is not
+running
+ - If the pidfile has been lost, try to determine the status using the
+process name instead
+
+ -- Javier Fernández-Sanguino Peña j...@debian.org Thu, 23 Jan 2014 03:45:25 +0100
+
samhain (2.8.3a-1+deb7u1) stable; urgency=medium
* Backport fixes from unstable version to fix serious/important bugs
diff --git a/debian/samhain.init b/debian/samhain.init
index 30cffab..c9e5828 100644
--- a/debian/samhain.init
+++ b/debian/samhain.init
@@ -30,14 +30,17 @@ set -e
# Check if a daemon is running
running()
{
-# No pidfile, probably no daemon present
-#
-[ ! -f $PIDFILE ] return 1
-pid=`cat $PIDFILE`
-# No pid, probably no daemon present
-[ -z $pid ] return 1
-
-pidofproc -p $PIDFILE
+# Check with pidfile first, if available
+if [ -r $PIDFILE ] ; then
+ pid=`cat $PIDFILE`
+# No pid, probably no daemon present
+ if [ -n $pid ] ; then
+ pidofproc -p $PIDFILE
+ return $?
+ fi
+fi
+# Try to find the daemon by name
+pidof $DAEMON /dev/null
return $?
}
@@ -46,7 +49,7 @@ case $1 in
start)
[ ! -e /var/run/${NAME} ] mkdir -p /var/run/${NAME}
log_begin_msg Starting $DESC: $NAME
-start-stop-daemon --start --quiet --exec $DAEMON
+start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --exec $DAEMON
log_end_msg $?
;;
stop)
@@ -55,27 +58,39 @@ case $1 in
log_end_msg $?
;;
reload)
-log_begin_msg Reloading $DESC configuration files: $NAME
-start-stop-daemon --stop --signal 1 --quiet --exec $DAEMON
-log_end_msg $?
+ log_begin_msg Reloading $DESC configuration files: $NAME
+ if running ; then
+ start-stop-daemon --stop --signal 1 --quiet --exec $DAEMON
+ log_end_msg $?
+ else
+ log_daemon_msg ERROR: $DAEMON is not running.
+ log_end_msg 1
+ fi
+
;;
restart|force-reload)
log_begin_msg Restarting $DESC: $NAME
-start-stop-daemon --stop --quiet --retry 5 --oknodo --pidfile $PIDFILE --name $NAME
-for i in 1 2 3 ; do
-if ! running; then break ; fi
-sleep 1
-done
+ if running; then
+ start-stop-daemon --stop --quiet --retry 5 --oknodo --pidfile $PIDFILE --name $NAME
+ for i in 1 2 3 ; do
+ if ! running; then break ; fi
+ sleep 1
+ done
+ fi
if ! running ; then
-start-stop-daemon --start --quiet --exec $DAEMON
+start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
log_end_msg $?
else
-log_daemon_msg ERROR: $DAEMON did not die in the expected time, will not reload
+log_daemon_msg ERROR: $DAEMON did not die in the expected time, will not restart/force-reload
log_end_msg 1
fi
;;
status)
-status_of_proc -p $PIDFILE $DAEMON $NAME exit 0 || exit $?
+ if [ -e $PIDFILE ] ; then
+ status_of_proc -p $PIDFILE $DAEMON $NAME exit 0 || exit $?
+ else
+ status_of_proc $DAEMON $NAME exit 0 || exit $?
+ fi
;;
*)
N=/etc/init.d/${0##*/}
signature.asc
Description: Digital signature
Bug#733875: dnmalloc broken
On Tue, Jan 14, 2014 at 03:28:17PM +0100, Bastian Blank wrote: Some debugging shows that dnmalloc is broken. It is already disabled for ia64 and s390, so the maintainer obviously knows. Please disable for _all_ architectures until this code is known to work. I've disabled it for s390x just as I did for s390. Upstream currently lists the following architectures as problematic: The dnmalloc allocator doesn't work on: OpenBSD (problems with pthread internals), Cygwin (also pthread internals), and 64bit FreeBSD. On 64bit AIX, you need to compile as a 32bit application, or to forego dnmalloc. This is from http://www.la-samhna.de/samhain/manual/dnmalloc.html I will contact them in order to see if I can get a precise list of architectures where it is known to work and adjust debian/rules accordingly. Regards Javier signature.asc Description: Digital signature
Bug#660197: samhain: Installation fails
On Fri, Mar 09, 2012 at 03:20:10PM +0100, Gerfried Fuchs wrote:
I had it hanging like this for two week's time, and tried again if I am
able to reproduce it - it's absolutely reproducible. Doing this within a
cowbuilder chroot on an i386 machine.
So, things to reproduce it should be as simple as:
$ sudo cowbuilder --create --basepath squeeze --distribution squeeze
$ sudo cowbuilder --login --basepath squeeze
# apt-get install samhain
Sorry for the delay with this.
It is true, samhain does not install in a chroot environment. But the fact
is: samhain does not seem to work *at all* if run within a chroot. The
'samhain -t init' call does not prosper because it gets stuck, for some
reason, when opening /dev/urandom from within a chroot.
But neither does it work if you just try to get the help (or version).
Either way, I cannot reproduce this behaviour *outside* of a chroot.
If you strace the running process you might see something like this:
jflicio:samhain$ ps -ef |grep samhain
root 17782 17663 0 00:51 pts/300:00:00 /usr/bin/dpkg --status-fd 13
--configure libgpg-error0:i386 libgcrypt11:i386 libffi6:i386 libp11-kit0:i386
libtasn1-3:i386 libgnutls26:i386 libltdl7:i386 libprelude2:i386 samhain:i386
root 17840 17782 0 00:51 pts/300:00:00 /usr/bin/perl -w
/usr/share/debconf/frontend /var/lib/dpkg/info/samhain.postinst configure
root 17843 17840 0 00:51 pts/300:00:00 /bin/sh -e
/var/lib/dpkg/info/samhain.postinst configure
root 17844 17843 0 00:51 pts/300:00:00 samhain -t init
jfs 17846 8685 0 00:51 pts/200:00:00 grep samhain
s@silicio:samhain$ sudo strace -f -p 17844
Process 17844 attached - interrupt to quit
futex(0xb77aa454, FUTEX_WAIT_PRIVATE, 2, NULL
I have attached a ltrace and strace of the samhain program within a chroot.
The problem seems to lie in the program initialisation code.
In summary: Please try to reproduce it within a *live* system, not a chroot.
Until I get that information this bug stays as 'unreproducible'
Regards
Javier
pthread_mutex_lock(0xb7751454, 0xb71f93c4, 0, 0) = 0
sysconf(30, 0xb768c000, 0xbffb3b84, 0xb71cf4c0) = 4096
mmap64(0, 0x3000, 3, 98) = 0xb7661000
mprotect(0xb7661000, 4096, 0, 98)= 0
mprotect(0xb7663000, 4096, 0, 98)= 0
sysconf(30, 4096, 0, 98) = 4096
sysconf(30, 4096, 0, 98) = 4096
sysconf(30, 4096, 0, 98) = 4096
mmap64(0, 0x8002000, 3, 0x4062) = 0xaf183000
sysconf(30, 0x8002000, 3, 0x4062)= 4096
mprotect(0xaf183000, 4096, 0, 0x4062)= 0
sysconf(30, 4096, 0, 0x4062) = 4096
sysconf(30, 4096, 0, 0x4062) = 4096
sysconf(30, 4096, 0, 0x4062) = 4096
sysconf(30, 4096, 0, 0x4062) = 4096
sysconf(30, 4096, 0, 0x4062) = 4096
mprotect(0xb7184000, 4096, 0, 0x4062)= 0
sbrk(0) = 0xb8d3e000
sysconf(30, 4096, 0, 0x4062) = 4096
sysconf(30, 4096, 0, 0x4062) = 4096
sysconf(30, 0xb735d000, 0, 0xb72bf574) = 4096
mmap64(0, 0xe2000, 3, 98)= 0xaf0a1000
sysconf(30, 0xe2000, 3, 98) = 4096
mprotect(0xaf0a1000, 4096, 0, 98)= 0
sysconf(30, 4096, 0, 98) = 4096
sysconf(30, 4096, 0, 98) = 4096
mprotect(0xaf182000, 4096, 0, 98)= 0
sysconf(30, 4096, 0, 0x4062) = 4096
gettimeofday(0xbffb39ac, 0) = 0
sched_yield(0xbffb39ac, 0, 0xb768ef87, 0xb73632c8) = 0
open64(/dev/urandom, 0, 026732167607 unfinished ...
pthread_mutex_lock(0xb7751454, 1, 0, 0xb737c041execve(/usr/sbin/samhain, [samhain], [/* 29 vars */]) = 0
brk(0) = 0xb7ffd000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb766b000
open(/usr/lib/cowdancer/libcowdancer.so, O_RDONLY|O_CLOEXEC) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\16\0\0004\0\0\0..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=14544, ...}) = 0
mmap2(NULL, 17488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7666000
mmap2(0xb766a000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0xb766a000
close(3)= 0
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=10201, ...}) = 0
mmap2(NULL, 10201, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7663000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/libz.so.1, O_RDONLY|O_CLOEXEC) = 3
read(3,
Bug#692631: non-free files in upstream tarball (The Software shall be used for Good, not Evil)
merge 692071 692631 thanks On Wed, Nov 07, 2012 at 11:20:33PM +0100, Ansgar Burchardt wrote: The upstream tarball contains files under the non-free JSON license: This has already been reported. I'm merging this bug. Regards Javier signature.asc Description: Digital signature
Bug#692071: storymaps: includes non-free files (src/org/json/*)
On Thu, Nov 01, 2012 at 11:08:32PM +0100, Francesco Poli (wintermute) wrote: Hello Javier, it seems to me [1] that storymaps includes non-free files (src/org/json/*) released under the JSON license [2]. Yes, it does. (B) replace src/org/json/* files with a DFSG-free and GPL-compatible equivalent, if any is available (tools/jsmin.py from libv8, which is under a GPL-compatible 3-clause-BSD license, was mentioned [3] during the debian-legal discussion, but maybe it's a completely different thing...) Searching a little bit I've found Gson, which is a JSON implementation for Java using the Apache license. It is available here: http://code.google.com/p/google-gson/ Doing a cursory review Gson provides a JSON array implementation in Java, which is what Storymaps actually uses. So it could be an alternative for replacing Douglas' JSON. I will try to test replacing it and see where that takes me. (C) remove src/org/json/* files by repacking the orig.tar.gz upstream source archive, as long as storymaps is able to still be significantly useful without those files... No, storymaps cannot work without the JSON implementation. (D) move the package to the non-free archive This is probably what I will do in the short-term, however, as modifying and testing the code might take some time (if it works at all) Regards Javier signature.asc Description: Digital signature
Bug#690655: RM: openvas2 [wheezy] -- RoM; abandoned-upstream
Package: release.debian.org Version: N/A Priority: grave Tags: rm I would like to request the Release Managers to remove *all* of the OpenVAS 2.x packages from the current testing distribution. This includes the following packages: - libopenvas2 / libopenvas2-dev (version 2.0.4-2.1) - libopenvasnasl2 / libopenvasnasl2-dev (version 2.0.2-2.1) - openvas-client (version 2.0.5-1.1) - openvas-plugins-base / openvas-plugins-dfsg (version 1:20100705-2) - openvas-server / openvas-server-dev (version 2.0.3-6) In addition, please also remove the following package: - harden-remoteaudit: it depends on openvas-server (I have sent a bug to the package to update this dependency) Support for OpenVAS 2 was discontinued last year [2]. Providing OpenVAS 2 to our Debian 'stable' users in our upcoming release is not really a good idea. Even though the scanner/client works 'as it is', users will not be able to download new plugins for this release from the OpenVAs servers and it will not be possible for them to find recent vulnerabilities in hosts they scan. For the last 2 years I have provided experimental versions of OpenVAS 3, which seem to have not received to much attention from users. In any case since that version is also going to be discontinued upstream. Since the latest OpenVAS release is version 5 [1] (released May this year) I will work towards providing OpenVAS 5 in our unstable distribution. And, once available, will try to make backports available for Wheezy too. Removing the OpenVAS 2 packages from testing simplifies handling upgrades to the newer version and also installations of the backports of OpenVAS 5 packages in Wheezy. Regards Javier signature.asc Description: Digital signature
Bug#677810: snort: white/blacklist
On Tue, Jul 31, 2012 at 04:23:52PM +0800, Jim Barber wrote: I have also encountered this problem when installing snort for the first time on a freshly installed Debian host. To get the package to configure I did the following steps: (...) Thank you (and the other reports) for the additional information. Since the preprocessor which uses this white/black list is experimental I'm actually going to disable it in the next Snort release. For the benefit of the users that want to enable it. I'm going to change the relative paths to absolute paths so this (upstream) bug does not trigger here. Regards Javier signature.asc Description: Digital signature
Bug#679106: cron: multiple /etc/init.d/cron stop may kill unrelated processes
tag 679106 pending thanks Hi, After reviewing this bug I believe we did not fix it properly in 3.0pl1-117. In that version we did the following change: * debian/cron.init: - Don't call start-stop-daemon directly, use LSB init functions instead. Among other things, this works around the cron daemon not deleting its pidfile from /var/run/. Closes: #615855 But the bug (cron: does not clean up PID file on exit) was not properly addressed (or LSB's killproc behaviour has changed in the meantime). I have committed a fix through cron's init.d file . The init.d file will now remove the pidfile if it exists after killing the process. This should be fixed in cron itself (through it's SIG handler) but this fix is a quicker (and less complex) fix for this bug. The fix is now is available in GIT and can be found at http://anonscm.debian.org/gitweb/?p=pkg-cron/pkg-cron.git;a=commitdiff;h=e284ede4877465557c6846d391eabebd7077cbd6 I will upload this fix with a new cron version. Regards Javier signature.asc Description: Digital signature
Bug#674228: openvas-plugins-dfsg: FTBFS: missing build-deps
On Thu, May 24, 2012 at 01:03:27AM +0200, Cyril Brulebois wrote: $subject says it all: | [ clean = audit-plugins ] || dh clean --with quilt | dh: unable to load addon quilt: Can't locate Debian/Debhelper/Sequence/quilt.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at (eval 18) line 2. | BEGIN failed--compilation aborted at (eval 18) line 2. | | make: *** [clean] Error 2 A build-depends: on quilt is missin in debian/control, I will add it. Regards Javier signature.asc Description: Digital signature
Bug#671761: netselect-apt/testing needs a dependency link to netselect/testing
On Sun, May 06, 2012 at 02:09:23PM -0400, Brendan Byrd wrote: Apparently, the -D option is only in the testing branch of netselect. I can see two solutions: 1. Make sure netselect-apt can use netselect with or without the -D option. 2. Create a dependency link between netselect/testing and netselect-apt/testing. I will go towards the second option, I should have done that before. Regards Javier signature.asc Description: Digital signature
Bug#650060: snort: FTBFS with multiarch libmysqlclient-dev (now in unstable)
On Tue, May 01, 2012 at 04:19:41PM +0200, Christoph Egger wrote: severity 650060 serious bye Seems to happen now in unstable It does not seem to be the same bug (or the patch provided does not apply and fix this bug). The version of libmysqlclient-dev currently available in unstable (version 5.1.62-1) does not provide the '--variable=pkglibdir' option (i.e. it is not recognised for mysql_config). Regards Javier signature.asc Description: Digital signature
Bug#665876: not using html as source
On Tue, Apr 10, 2012 at 11:35:33AM -0500, Frank Loeffler wrote: Hi, What about parsing http://http.us.debian.org/debian/README.mirrors.txt for information about Debian mirrors instead of the HTML page? It didn't occur to me, but I'm not sure that parsing that text file is going to be easier than parsing the HTML page and, in the end, it might still be brittle since the format (spacing, column ordering, etc.) might change in the future. The best alternative would be to have a machine-parseable (i.e. XML file) with all the mirrors information. In any case, if you can work on a patch for it I could take a look :) Regards Javier signature.asc Description: Digital signature
Bug#665876: merge - but still affecting squeeze
On Tue, Apr 10, 2012 at 11:26:55AM -0500, Frank Loeffler wrote:
Hi
This is most likely a cause of #667985, which has been fixed in sid.
Yes, I've tested this in a Squeeze chroot and the behaviour in Squeeze
generates the error message that was reported.
The version in Squeeze is actually very brittle. I should backport the
version in unstable to backports and encourage users running stable to use
that one instead as many enhancements have been introduced in the latest
versions.
However, a similar bug also affects stable and can be fixed using a
similar simple patch:
- m@br'$SEARCH':.*a href=('$PROTO'://.*?)@i
+ m@br'$SEARCH':.*a.*?href=('$PROTO'://.*?)@i
I will prepare the fix and submit it to the Release Team, if they approve I
will do an upload to stable.
Regards
Javier
signature.asc
Description: Digital signature
Bug#667985: netselect-apt: fails to parse new rel=nofollow href links
On Sat, Apr 07, 2012 at 01:42:52PM -0700, Nameless wrote: Netselect-apt fails to parse newest mirrors list with rel=nofollow in href links. Attached patch which tweaks the relevant regexp restored normal functionality. Thanks for the patch. I will apply it, test it and update a new version ASAP. Regards Javier signature.asc Description: Digital signature
Bug#661264: ccal: causes dpkg-reconfigure to fail
ccal's postint script causes dpkg-reconfigure (-a) to fail with the following error message: dpkg-maintscript-helper: error: environment variable DPKG_MAINTSCRIPT_NAME is required I can reproduce this issue simply runnign 'dpkg-reconfigure ccal'. I will submit a fix to the postinst script so that the call to dpkg-maintscript-helper is only done when configuring the package. It does not make sense to do this on reconfiguration. Regards Javier signature.asc Description: Digital signature
Bug#660197: samhain: Installation fails
tags 660197 moreinfo unreproducible thanks On Fri, Feb 17, 2012 at 10:27:58AM +, George B. wrote: Package fails to install. Error message: I have done the install in a clean chroot and the installation does not fail. I cannot reproduce this bug in a clean environment. --- E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up samhain (2.6.2-1) ... Creating samhain's file integrity database (this can take some minutes) dpkg: error processing samhain (--configure): subprocess installed post-installation script returned error exit status 134 Errors were encountered while processing: samhain Press return to continue. In order to analyse this bug I would need more information. Please try to install samhain again setting up the following variable in your environment: DEBIAN_SCRIPT_DEBUG. To get a full log, do the following: # script /tmp/samhain.log # export DEBIAN_SCRIPT_DEBUG=y # dpkg --purge samhain # apt-get install samhain # exit Once finished, please send the /tmp/samhain.log file generated to this bug report. Thank you, Javier signature.asc Description: Digital signature
Bug#656289: Processed: notfixed 656289 in snort/2.9.2-1, notfound 656289 in snort/2.9.2-1
On Sun, Jan 29, 2012 at 10:25:30AM +0200, Stefano Rivera wrote: The BTS doesn't understand that a bug can be found in snort/2.9.2-1 and fixed in snort/2.9.2-1, so I removed the found in annotation. Thanks for the clarification, I misread the emails to control@b.d.o. Regards Javier -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656289: Processed: notfixed 656289 in snort/2.9.2-1, notfound 656289 in snort/2.9.2-1
On Mon, Jan 23, 2012 at 05:48:13PM +, Debian Bug Tracking System wrote:
# err, that didn't work
notfixed 656289 snort/2.9.2-1
Bug #656289 {Done: Javier Fernandez-Sanguino Pen~a j...@debian.org} [snort]
snort 2.9.1-1 is uninstallable and unbuildable in unstable due to dependency
on libdaq0 and build-dependency on libdaq-dev which are only in experimental
Bug No longer marked as fixed in versions snort/2.9.2-1.
Why is this not considered fixed? This was fixed with the upload of libdaq to
unstable.
I've reviewed the buildd logs for Snort and version 2.9.2-2 seems to have
been built properly across all architectures.
Regards
Javier
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656445: snort: fails to install - command not found in postinst
On Thu, Jan 19, 2012 at 02:03:42PM +0100, Andreas Beckmann wrote: during a test with piuparts I noticed your package failed to install. (...) Setting up snort (2.9.2-1) ... /var/lib/dpkg/info/snort.config: 15: /var/lib/dpkg/info/snort.config: ifconfig: not found /var/lib/dpkg/info/snort.postinst: 163: /var/lib/dpkg/info/snort.postinst: cannot create /var/lib/snort/snort.debian.conf.md5sum: Directory nonexistent (...) This is because of two issues: - the configuration script requires 'ifconfig'. I though that would be essential but it seems that now this belongs in the net-tools package which is important Priority only. - the directory where the md5sums does not get create properly and the postinst script fails. I will fix both of these and upload a new package to unstable. Thanks for reporting these issues. Regards Javier signature.asc Description: Digital signature
Bug#656289: snort 2.9.1-1 is uninstallable and unbuildable in unstable due to dependency on libdaq0 and build-dependency on libdaq-dev which are only in experimental
On Wed, Jan 18, 2012 at 01:17:05AM +, peter green wrote: as the title states this package is in unstable but it has (build)-dependencies that are only satisfiable in experimental. I have just uploaded daq (source+binaries) to unstable, thus closing this bug. Regards Javier signature.asc Description: Digital signature
Bug#651581: sac: diff for NMU version 1.9b5-2.1
On Sun, Dec 25, 2011 at 03:55:08PM +0100, gregor herrmann wrote: tags 651581 + pending thanks Dear maintainer, I've prepared an NMU for sac (versioned as 1.9b5-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks for the fix. I'm going to apply it and upload a new version right away. Regards Javier signature.asc Description: Digital signature
Bug#651463: honeyd: FTBFS (tagging.h:89:6: error: expected declaration specifiers or '...' before '(' token)
tag 651463 upstream thanks Thanks for the heads up, it seems that the bug-fix upload I sent yesterday triggered a rebuild of the package in all architectures and those who have libevent2 now in unstable do not compile any more. The issue is already known by upstream maintainer Niels Provos, who is also libevent's maintainer. Unfortunately, it is not clear when it will be fixed upstream. The folks at Gentoo have also reported this in https://bugs.gentoo.org/show_bug.cgi?id=333099. However, the patch they have fixes one issue but does not fix the full transition to libevent2. For more information see http://code.google.com/p/honeyd/issues/detail?id=19 Regards Javier signature.asc Description: Digital signature
Bug#632765: FTBFS with libevent 2.0 in experimental
On Tue, Jul 05, 2011 at 10:05:17PM +0200, Leo 'costela' Antunes wrote: After testing in a clean pbuilder, your package failed to build with the version of libevent in experimental (2.0.*). Hi, why do you infer this is an issue with the newest libevent? You can find a log of the build attempt attached. This log ends with: checking if we can access libc without dlopen... no checking if we can access libc with libc.so... no checking if we can access libc with /usr/lib/libc.so*... no configure: error: Couldn't figure out how to access libc make: *** [config.status] Error 1 so it really looks like it cannot file the library provided by libc6-dev. Maybe it's because the configure script does not work properly for amd64? Regards Javier signature.asc Description: Digital signature
Bug#632765: Unblocking this bug from libevent transition
unblock 631018 by 632765 thanks The #632765 is not related to the libc transition but, actually, seems to be a FTBFS in amd64 which does not appear in the buildd logs (see https://buildd.debian.org/status/fetch.php?pkg=honeydarch=amd64ver=1.5c-9stamp=1316385054) Regards Javier -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642352: FTBFS on armel: redefinition of 'struct user'
On Sun, Oct 30, 2011 at 04:09:11PM -0400, Daniel T Chen wrote: * honeydstats.[ch]: Rename struct user to honeyd_user to avoid collision on armel. Fixes FTBFS. (Closes: #642352) Thank you for the patch, I will review it and apply it to the package. Best regards, Javier signature.asc Description: Digital signature
Bug#618197: snort: FTBFS: cp: cannot stat `doc/snort_manual.pdf': No such file or directory
Build-Depends-Indep is out of date. gs-common is an empty package nowadays. Thanks for the solution, I wonder, however, why the gs-common didn't pull in the ghostscript package in this autobuilder I'm going to upload a new package to fix this bug right away anyway. Regards Javier signature.asc Description: Digital signature
Bug#620178: noshell: Transitional package for non-free package should live in non-free
On Wed, Mar 30, 2011 at 11:53:13AM -0700, Josh Triplett wrote: Package: noshell Severity: serious As a transitional package for the non-free titantools, noshell depends on titantools. Thus, noshell should not live in main. As a transitional package for a non-free package it should go in non-free. You are right, I will fix it right away. Regards Javier signature.asc Description: Digital signature
Bug#618197: snort: FTBFS: cp: cannot stat `doc/snort_manual.pdf': No such file or directory
On Sun, Mar 13, 2011 at 06:46:21PM +0100, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on amd64. It seems it is unable to build the Snort PDF Manual (using LaTeX). The manual is built as part of the arch-independent package. I will check the logs to see if I see why doesn't it build. Regards Javier signature.asc Description: Digital signature
Bug#603428: snort: prompting due to modified conffiles which where not modified by the user
On Tue, Dec 21, 2010 at 05:23:39PM +0100, Julien Cristau wrote: On Tue, Dec 21, 2010 at 17:07:09 +0100, Javier Fernandez-Sanguino wrote: Becas right now, with the current code, changes gets overwritten by debconf on package (re)configuration. That sounds like a serious bug in the maintainer scripts then. Why not fix that? I've work quite some time today trying to fix that and will upload new Snort packages shortly. This behaviour was there, actually, since at least the 1.6.3a-4 release (as early as january 2001). It was somewhat hidden since it affected only changes in a *part* of the configuration file and now moving it out of the configuration file to a separate file has highlighted it. It's surprising that nobody has reported it before and I have not noticed this earlier myself. In any case, the maintainer scripts need an important rewrite. There's too much duplicated code and the handling of some options should be done by snort-common and not by the binary snort, snort-pgsql or snort-mysql packages. Oh wel... Regards Javier signature.asc Description: Digital signature
Bug#603428: snort: prompting due to modified conffiles which where not modified by the user
On Fri, Dec 17, 2010 at 02:57:39PM +0100, Alexander Reichle-Schmehl wrote:
* Alexander Reichle-Schmehl toli...@debian.org [101216 14:14]:
The only part missing would to make sure, snort-{mysql,pgsql} write into
the new file instead of the old one, and purge the new file. But the
main part taking care of this bug can already be reviewed if someone
likes to do so ;)
Attached is now a proposal to solve this bug. I must confess, that I
didn't had the change to do extensive testing (I did only upgrade tests,
no functionality tests), but I think I covered most scenarios.
The only thing I can think of that might fail, is if a user modified his
/etc/snort/snort.conf himselve, and upgrades. In this case the db
configuration is splitt into a sepperate file, but the new include
line isn't added automatically, but the user will have the usual new
configuration file, but you modified it, look at it thing and hopefully
see the db releated chances. I'm not sure, if that problem can be solved
in a better way.
I see some issues with this bug. Some are minor (typos in the changelog and
the text) but the most important thing is: there is no NEWS file so
that users are forewarned of this (important) change.
I would like to pick it up and carry it over from here... if I may. It seems
you already did a NMU, so I might overwrite it with a new release (using your
patch).
Regards
Javier
signature.asc
Description: Digital signature
Bug#603428: snort: prompting due to modified conffiles which where not modified by the user
On Mon, Dec 20, 2010 at 03:24:57PM +0100, Javier Fernández-Sanguino Peña wrote: I see some issues with this bug. Some are minor (typos in the changelog and the text) but the most important thing is: there is no NEWS file so that users are forewarned of this (important) change. Upon review, I've found some additional issues: - The automatically generated configuration file does not include any header, to warn users from editing the file - The new file does not get chowned' to user root and group 'snort' and is not made readable only to these. Since the configuration file includes database user's and passwords it should be protected and access to it should be restricted. I am going to make an upload fixing this issues too. Regards Javier signature.asc Description: Digital signature
Bug#584383: #584383 still open in testing
On Wed, Dec 15, 2010 at 03:55:22PM +0100, Alexander Reichle-Schmehl wrote: I just noticed, that this bug is still open in testing, as fixed packages never migrated. If see it correctly, it doesn't migrate as a) there's no unblock request, yet b) It's outdated on kfreebsd-i386, kfreebsd-amd64 and mips. After my upload for kfreebsd-i386, kfreebsd-amd64 and mips it seems now its only missing hppa. Does hppa have a non-free auto-builder or should I also manually prepare packages for that arch? Regards Javier signature.asc Description: Digital signature
Bug#584383: #584383 still open in testing
On Wed, Dec 15, 2010 at 03:55:22PM +0100, Alexander Reichle-Schmehl wrote: I think there are no non-free autobuilders for these architectures. So I guess the easiest solution would be an arch removal. What do you think? Well, buidling this package in porterbox is pretty straightforward so I'm going to try to upload binary-only packages for all three architectures. It's been a while since I had to do this so I might not get it right on the first try... :-) Regards Javier signature.asc Description: Digital signature
Bug#600310: Preparing an upload
Hi, I'm preparing an upload right away to fix this bug (-115). I would appreciate it if you can test it right away to ensure that the bug is fixed before the release. Regards Javier signature.asc Description: Digital signature
Bug#600310: Preparing an upload
On Sat, Oct 16, 2010 at 01:29:06PM +0200, Javier Fernández-Sanguino Peña wrote: I'm preparing an upload right away to fix this bug (-115). I would appreciate it if you can test it right away to ensure that the bug is fixed before the release. Forgot to add: if you do not want for the autobuilders to build the package for your architecture you can get the sources from SVN: http://svn.debian.org/viewsvn/pkg-cron/tags/debian_version_3.0pl1-115/ Regards Javier signature.asc Description: Digital signature
Bug#584383: Not pending, disappeared from NEW ?
On Wed, Sep 22, 2010 at 06:55:30PM +0200, Luca Falavigna wrote: Il 22/09/2010 17:55, Didier 'OdyX' Raboud ha scritto: My RSS tells me that titantools 4.0.11-7 left NEW on 04.09.2010 02:00, but I can't get a trace of that anywhere on the packages.qa.d.o, on the buildd or on the archive (CC'ing ftpmaster to get a enlightening on that). It has been manually rejected, forwarding related message: I did not get that message (or it didn't go to the proper folder). I will do as requested by FTP masters. Regards Javier signature.asc Description: Digital signature
Bug#596954: bastille adds dpkg-statoverride entries that change permissions to 0000 after upgrade
severity 545052 serious merge 596954 545052 serious thanks On Wed, Sep 15, 2010 at 12:41:20PM +0200, Lukas Baxa wrote: After that bastille ran also the dpkg-statoverride command to prevent resetting the permissions on system upgrades. However, this part fails and bastille sets the override permissions to !!! Thanks for the bug report. Indeed, I have reviewed the Debian integration with bastille and it was missing code to setup the proper permissions in binaries. I'm preparing an upload which (hopefully) fixes this issue. If I cannot get it to be fixed properly I will remove the Would you like to set more restrictive permissions on the administration utilities? question (which defaults to 'NO'). Regards Javier signature.asc Description: Digital signature
Bug#524599: bastille-2.1.1-19 does not run on Debian-5.
On Tue, Aug 31, 2010 at 03:32:48PM +0700, Sthu Deus wrote: I have the same problem on Debian 5 (stable.testing) up-to-date: There is a problem with the bastille version in Lenny. Unfortunately, this is fixed currently only in the 'unstable' package you will find available at http://packages.debian.org/sid/bastille Unfortunately, bastille is currently not fully supported in Debian, that's why I asked it for the latest version (3.2.1) to be removed from Debian testing. I encourage you to install the package from unstable and give it a try if you are interested in Bastille, please report any bugs you find in it. Regards Javier signature.asc Description: Digital signature
Bug#585644: cron: Can't install
On Sat, Jun 12, 2010 at 05:51:21PM +0100, Anthony Campbell wrote: Package: cron Version: 3.0pl1-112 Severity: grave Tags: sid Justification: renders package unusable Cron refuses to install: error message is: Fixed in -113 version, which was just uploaded to sid. Regards Javier -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549772: Update?
On Mon, May 31, 2010 at 07:41:46AM +0200, Yves-Alexis Perez wrote: what's the status on this? Has the situation improved since january, or should the removal be asked to ftpmasters? The removal of this package should be requested. Regards Javier -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570695: Fails with absolute symlinks
On Sun, Mar 14, 2010 at 07:54:47PM +0700, Daiki Ueno wrote: The attached patch will fix the problem (I've already sent it to the upstream). Thanks for the patch, I will try to test it out soon and confirm that it indeed fixes the issue. Regards Javier -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549772: router-audit-tool: FTBFS: only nested arrays of non-refs are supported at /usr/share/perl/5.10/ExtUtils/MakeMaker.pm line 664
On Sat, Jan 23, 2010 at 08:53:04AM +0200, Niko Tyni wrote: Here's a trivial patch that's in line with the new upstream version at https://community.cisecurity.org/download/?redir=/cisco/rat-2.2-dist.sh.gz The problem is, that the new version of rat uses CIS's terms of use which are clearly non-free (see the disclaimer when you run the self extracting archive or the etc/CIS_TERMS.txt file it generates). I would like to upgrade to this latest version, but I'm afraid I can't. It looks like this package could really use some love. Due to the change in licensing terms, and the fact that it is not that much used by Debian users (based on popcon) I'm actually going to ask ftpmasters to remove this package. Regards Javier -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534846: Missing the openvas-nvt-sync script
On Sat, Jun 27, 2009 at 05:06:31PM +0200, Hans wrote: I am missing the script openvas-nvt-sync in this package, although it is in the source package. This script is part of openvas-plugins but will be included in openvas-server since upstream is not going to provide openvas-plugins anymore. You are right in the sense that without this script an openvas-server installation's plugins cannot be upgrade. I'm going to keep this bug open until we build a new openvas-server release with the script. Regards Javier -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523704: nessus-core: Please update build dep for libglib1.2
On Sat, Apr 11, 2009 at 08:09:12PM -0400, Barry deFreese wrote: Now that Gtk1.2 is removed we are also looking to remove glib1.2 from the archive. I've asked for the removal of nessus-core (see #534501) so this will not be an issue in the long term. Nessus-core seems to build-depend on libglib1.2-dev and libglib2.0-dev. Is this a mistake? It seems to build fine without libglib1.2-dev. Maybe, but I'm not inclined to change it now that I've asked its removal. Regards Javier signature.asc Description: Digital signature
Bug#528434: cron: Incomplete fix for CVE-2006-2607 (setgid() and initgroups() not checked)
On Tue, May 12, 2009 at 04:53:41PM -0500, Jamie Strandboge wrote: I then reviewed the Ubuntu and Debian packages and found that while the most serious issue of not checking setuid() was addressed in 3.0pl1-64, checks for setgid() and initgroups() were not added. Other distributions (eg Gentoo and RedHat) fixed these calls as well. I was then curious to see when these (...) Thanks for noticing this, I have just uploaded a package including this fix. Regards Javier signature.asc Description: Digital signature
Bug#494902: spikeproxy: patch which fix the bug
On Tue, Apr 21, 2009 at 11:01:43PM +0200, Emmanuel Bouthenot wrote: Attached is a patch which fix the bug. Feel free to do a NMU with this fix. Regards Javier signature.asc Description: Digital signature
Bug#515323: Depends on GTK 1.2
On Fri, Mar 13, 2009 at 04:54:06PM -0400, Barry deFreese wrote: tags 515323 + patch thank you Hi, Attached is a patch that will build with Gtk 2 as well as some packaging fixes. Probably needs better testing as Spanish is not my first language. I've tested the patch and there are some issues with ISO-8859-1 encoding, I get these: (i2e:27958): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() (i2e:27958): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() (i2e:27958): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() And the accented characteres don't show up properly. I have fixed this but still don't get the application to work properly (i.e. lookup words and show their translations). Regards Javier signature.asc Description: Digital signature
Bug#515323: Depends on GTK 1.2
On Fri, Mar 13, 2009 at 04:54:06PM -0400, Barry deFreese wrote:
Attached is a patch that will build with Gtk 2 as well as some packaging
fixes. Probably needs better testing as Spanish is not my first
language.
I have played with the patch a little bit and it does not work. I fixed the
issue with i2e not showing properly accented characters by converting the PO
file (for spanish) to UTF-8 and then fixing how the locale is set in the
program.
But I have been unable to make it work to get it to translate a simple word,
the changes for GTK+2 support break its functionality (it doesn't show
anything in the window frame and spouts a lot of gtk errors).
Since upstream is no longer active I'm tempted to ask for the removal of this
package. There are probably better alternatives out there (ktranslator in GUI
or translate in text-mode).
I'm going to tag this bug as help needed since I don't have the GTK
experience to fix this issue. If no help is forthcoming I will ask for its
removal.
Regards
Javier
diff -Nru i2e-0.5.1/debian/changelog i2e-0.5.1-gtk2/debian/changelog
--- i2e-0.5.1/debian/changelog 2009-03-14 18:14:34.0 +0100
+++ i2e-0.5.1-gtk2/debian/changelog 2009-03-14 13:43:11.0 +0100
@@ -1,3 +1,16 @@
+i2e (0.5.1-3) unstable; urgency=low
+
+ * Use patch provided by Barry deFreese (Debian QA):
+* Build with Gtk2. (Closes: #515323).
+ * Make clean not ignore errors.
+ * Bump debhelper build-dep to 5.0.0.
+ * Add debian/compat and set to 5.
+ * Bump Standards Version to 3.8.0.
++ Menu policy transition.
+ * Convert es.po file to UTF-8
+
+ -- Javier Fernandez-Sanguino Pen~a j...@debian.org Sat, 14 Mar 2009 13:43:06 +0100
+
i2e (0.5.1-2) unstable; urgency=low
* Lintian fixes:
diff -Nru i2e-0.5.1/debian/compat i2e-0.5.1-gtk2/debian/compat
--- i2e-0.5.1/debian/compat 1970-01-01 01:00:00.0 +0100
+++ i2e-0.5.1-gtk2/debian/compat 2009-03-14 13:23:06.0 +0100
@@ -0,0 +1 @@
+5
diff -Nru i2e-0.5.1/debian/control i2e-0.5.1-gtk2/debian/control
--- i2e-0.5.1/debian/control 2009-03-14 18:14:34.0 +0100
+++ i2e-0.5.1-gtk2/debian/control 2009-03-14 13:23:06.0 +0100
@@ -2,12 +2,12 @@
Section: text
Priority: optional
Maintainer: Javier Fernandez-Sanguino Pen~a j...@computer.org
-Build-Depends: gettext, libgtk1.2-dev, debhelper ( 3.0.0)
-Standards-Version: 3.5.8.0
+Build-Depends: debhelper ( 5.0.0), gettext, libgtk2.0-dev
+Standards-Version: 3.8.0
Package: i2e
Architecture: any
-Depends: gettext,${shlibs:Depends}
+Depends: gettext,${shlibs:Depends}, ${misc:Depends}
Description: English-Spanish translation dictionary
English to Spanish (and viceversa) translation dictionary.
It can be used both in X and text mode and has a learning
diff -Nru i2e-0.5.1/debian/menu i2e-0.5.1-gtk2/debian/menu
--- i2e-0.5.1/debian/menu 2009-03-14 18:14:34.0 +0100
+++ i2e-0.5.1-gtk2/debian/menu 2009-03-14 13:23:06.0 +0100
@@ -1,6 +1,6 @@
?package(i2e):\
needs=X11\
- section=Apps/Text\
+ section=Applications/Text\
description=English-Spanish dictionary\
title=i2e\
command=/usr/bin/i2e
diff -Nru i2e-0.5.1/debian/rules i2e-0.5.1-gtk2/debian/rules
--- i2e-0.5.1/debian/rules 2009-03-14 18:14:34.0 +0100
+++ i2e-0.5.1-gtk2/debian/rules 2009-03-14 13:23:06.0 +0100
@@ -22,7 +22,7 @@
rm -f build-stamp install-stamp
# Add here commands to clean up after the build process.
- -$(MAKE) clean
+ $(MAKE) clean
dh_clean
@@ -34,7 +34,7 @@
dh_installdirs
# Add here commands to install the package into debian/tmp.
- $(MAKE) install DESTDIR=`pwd`/debian/tmp
+ $(MAKE) install DESTDIR=$(CURDIR)/debian/i2e
touch install-stamp
diff -Nru i2e-0.5.1/i2e.c i2e-0.5.1-gtk2/i2e.c
--- i2e-0.5.1/i2e.c 2009-03-14 18:14:34.0 +0100
+++ i2e-0.5.1-gtk2/i2e.c 2009-03-14 15:30:43.0 +0100
@@ -43,7 +43,7 @@
return;
}
- str = (char *)g_malloc( strlen( clip-data ) + 1 );
+ str = (char *)g_malloc( strlen((char *)clip-data ) + 1 );
strcpy( str, (char *)clip-data );
ptr = strtrim( str );
@@ -80,13 +80,14 @@
/* sigue el estado del togglebutton traducir */
static void cambiaTraducir( GtkWidget *widget, gpointer data )
{
- char *direccion[2] = { _( Spanish - English ), _( English - Spanish ) };
parametros *datos = (parametros *)data;
- datos-i2c = gtk_toggle_button_get_active( GTK_TOGGLE_BUTTON( widget ));
datos-cambiado = TRUE;
- gtk_label_set_text( GTK_LABEL( GTK_TOGGLE_BUTTON( widget )-button.bin.child ),
- direccion[datos-i2c] );
+ if ( gtk_toggle_button_get_active( GTK_TOGGLE_BUTTON( widget )) )
+
+ gtk_label_set_text( GTK_LABEL( GTK_TOGGLE_BUTTON( widget )-button.bin.child ), _( English - Spanish ));
+ else
+ gtk_label_set_text( GTK_LABEL( GTK_TOGGLE_BUTTON( widget )-button.bin.child ), _( Spanish - English ));
gtk_entry_select_region( GTK_ENTRY( datos-entrada ), 0,
strlen( gtk_entry_get_text( GTK_ENTRY( datos-entrada ;
@@ -159,10
Bug#518868: ssmping: FTBFS: dereferencing pointer to incomplete type
On Sun, Mar 08, 2009 at 05:33:21PM -0700, Daniel Schepler wrote: From my pbuilder build log: ... cc -Wall -g -O2asmping.c ssmpngcl.o ssmpingc.o joingrp.o -o asmping cc -Wall -g -O2ssmpingd.c ssmpngcl.o ssmpingc.o -o ssmpingd ssmpingd.c: In function 'zerosrcinterface': ssmpingd.c:44: error: dereferencing pointer to incomplete type I cannot reproduce this error, can you please tell me which version of libc6-dev are you using and which architecture are you compiling in? It compiles fine with 2.7-18 so this might be an issue with newer glibc. Regards Javier signature.asc Description: Digital signature
Bug#515323: Depends on GTK 1.2
tags 515323 help thanks On Sun, Feb 15, 2009 at 05:24:52PM +0100, Moritz Muehlenhoff wrote: i2e build-depends on libgtk1.2-dev, which will be removed for Squeeze. I will look at it, the maintainer is not updating this software any more and I'm not a GTK wizard, so help in porting this would be appreciated. Regards Javier signature.asc Description: Digital signature
Bug#515254: cheops: Depends on legacy GTK 1.2 libs
tags 515323 help thanks On Sun, Feb 15, 2009 at 12:00:10PM +0100, Moritz Muehlenhoff wrote: Package: cheops Severity: serious cheops build-depends on libgtk1.2-dev, which will be removed for Squeeze. I will look at it, the upstream maintainer is not updating this software any more. Actually, a new effort started to improve it through 'cheops-ng', but this software is also build-depending on libgtk1.2-dev. I'm not a GTK wizard, so help in porting this would be appreciated. Regards Javier signature.asc Description: Digital signature
Bug#512486: Bug 512486: intention to sponsor NMU
On Sat, Jan 31, 2009 at 09:14:36PM +0100, Vincent Fourmond wrote: Hello, This bug has been know for ten days now, and patched for more than a week. I hereby express my intention to upload rather soon a NMU based on Evgeni's and fixing also the homepage/menu problems. (Evgeni, is that fine by you ??). Thanks for taking care of this bug and sponsoring the NMU. Regards Javier -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513963: etoken: Buggy, superceded upstream
Package: etoken Severity: serious Version: 0.3.9-5 I have recently been contacted by etoken's upstream author (seem ail below) and he recommends this package is removed. From upstream's page: This project is dead. While old copies are still available via sourceforge file archive, the software has many known bugs and should not be used. Instead you can use the (closed source) software provided by Aladdin itself. Or you can migrate to OpenCT a new open source software for linux/*ix to use usb crypto tokens such as the Aladdin eToken PRO as well as many alternatives and smart card readers. I have asked ftp masters to remove the package but I'm bugging the package at the same time so release managers remove it from the next release. Regards Javier - Forwarded message from Andreas Jellinghaus a...@dungeon.inka.de - From: Andreas Jellinghaus a...@dungeon.inka.de Date: Mon, 2 Feb 2009 20:05:30 +0100 To: debian-rele...@lists.debian.org, Javier Fernandez-Sanguino Pen~a j...@computer.org Subject: please remove etoken before release User-Agent: KMail/1.10.3 (Linux/2.6.27-11-generic; KDE/4.1.3; x86_64; ; ) Hi guys, debian still includes a software called etoken. that software is buggy, does not work properly (or at all?) and trying to use it can damage your hardware. so please be so kind and remove it? I'm the author of it, and I replaced it with some new open source project about 7 years ago, and even that one got replaced many years ago with another open source project: openct. part of debian for ages and working well. For reference: in debian the source is called etoken, the binary is called libetoken, and the upstream web page is http://etoken.sourceforge.net/ Thanks, Andreas - End forwarded message - signature.asc Description: Digital signature
Bug#505039: patch
On Sun, Nov 09, 2008 at 11:20:20AM +0800, LI Daobing (?) wrote: tag 505039 patch thanks a debdiff in attachment. On cursory glance it looks good to me. Please feel free to NMU. Regards Javier signature.asc Description: Digital signature
Bug#503282: Patch
On Fri, Oct 24, 2008 at 04:27:31PM +0100, Jonny Lamb wrote: I attach my patch for my NMU 3.2.2-7.1. Great! Thanks for NMUing. I wonder why this bug has been hidden for such a long time and was not noticed until recently... Regards Javier signature.asc Description: Digital signature
Bug#502715: acidlab: can be installed without a controlling tty
On Sun, Oct 19, 2008 at 01:09:48PM +0200, Lucas Nussbaum wrote: Package: acidlab Version: 0.9.6b20-23 Severity: serious User: [EMAIL PROTECTED] Usertags: piuparts piuparts-20081019 Hi, While testing packages with piuparts, I discovered the following problem with your package, which can also be reproduced by installing it in a clean lenny chroot (cleaned up using debfoster -o MaxPriority=required -o UseRecommends=no -f -n apt debfoster). Setting up acidlab (0.9.6b20-23) ... /var/lib/dpkg/info/acidlab.postinst: line 101: /dev/tty: No such device or address I certainly don't see the need to use /dev/tty in the postinst script at all... Regards Javier signature.asc Description: Digital signature
Bug#500325: xorp: FTBFS: Not using -fPIC to generate shared lib.
On Sun, Oct 12, 2008 at 09:10:35PM +0200, Adeodato Simó wrote: Wow, that's very unfortunate. I'm afraid there isn't really much point in a -5 that doesn't fix the FTBFS in the rest of arches. At least we can test if -5 really fixes the FTBFS. Things come one step at a time. Regards Javier signature.asc Description: Digital signature
Bug#500325: xorp: FTBFS: Not using -fPIC to generate shared lib.
On Sun, Oct 12, 2008 at 09:10:35PM +0200, Adeodato Simó wrote: Do you think you'll have the time to investigate that second FTBFS? Since a patch has been provided for that second FTBFS I'm updating the package uploaded to mentors (including also a fix for #498615) and will upload as soon as possible. Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499799: Patch for the 2.2.3-5 NMU of samhain
On Sun, Sep 28, 2008 at 05:46:23PM +0200, Christian Perrier wrote: (sorry, I inadvertently sent this as a maintainer upload...sorry ? javier) Ouch... It's ok though, thanks for the upload Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495083: remove libphp-phplot and acidlab from lenny
On Tue, Sep 16, 2008 at 05:04:04PM +0200, Thomas Viehmann wrote: Hi, as documented by #435176 and then #495083 libphp-phplot has been unusable since May 2007. In fact, it has been empty(!) since May 2008, i.e. for over four months, with no-one actually noticing until a bug report was filed in mid-August (unanswered for a month) - welcome to the wonderful world of diligent maintainer testing before upload. It has one reverse dependency, acidlab. No-one seems to have cared about acidlab being uninstallable or with unusable dependency for a year either. acidlab had previously been removed from unstable for neglect and libphp-phplot also had managed to raise QA concerns (#475757) which the maintainer violently. IMO it might be time to think about removal from unstable as well, but I'll leave that up to the QA people. Acidlab does not actually require libphp-phplot. Many users can use acidlab without the plotting functionality. On the other hand Acidlab has ben superseded by acidbase. Which is an enhanced fork that is being actively maintained (acidlab has not seen an upstream update for years and will probably not see one anymore). Acidlab use [1] has been diminishing in time whileas acidbase [2] has increased so it is probably time to remove one in favour of the other one. I cannot prepare a transition plan from one to the other (which should be more than just an empty package with a Depends: acidbase). If somebody is willing to help the existing Acidlab users with a transition package for lenny I would really appreciate it. If QA thinks that the best route is to RM this package that is fine too. Regards Javier [1] http://qa.debian.org/popcon.php?package=acidlab [2] http://qa.debian.org/popcon.php?package=acidbase signature.asc Description: Digital signature
Bug#495083: remove libphp-phplot and acidlab from lenny
On Tue, Sep 16, 2008 at 10:01:19PM +0100, Adeodato Simó wrote: Acidlab does not actually require libphp-phplot. Many users can use acidlab without the plotting functionality. However, acidlab Depends: on libphp-phplot, so libphp-phplot cannot be removed. So, since I think removing libphp-phplot would be good to do, maybe we could get an upload of acidlab dropping the dependency? (Or lowering to Suggests for documentation purposes, whatever.) But see below. Done. I don't know what QA thinks, but my opinion from a release point of view is that is sounds appropriate to remove it unless you (as the maintainer) have a more qualified opinion/reasons that it should stay for Lenny. Is that the case? I think that if acidlab is removed a clear upgrade path to the available fork (acidbase) should be defined. Unfortunately, I don't have the time to do implement one right now. Regards Javier signature.asc Description: Digital signature
Bug#341595: Adjusting severity
severity 341595 serious thanks Modifying conffiles through debconf prompts is a violation of the Debian policy, I'm adjusting the severity of this bug (even though it's fixed now :) Regards Javier signature.asc Description: Digital signature
Bug#496415: The possibility of attack with the help of symlinks in some Debian packages
severity 496415 important thanks On Sun, Aug 24, 2008 at 10:05:29PM +0400, Dmitry E. Oboukhov wrote: In some packages I've discovered scripts with errors which may be used by a user for damaging important system files or user's files. I'm fully aware of what a symlink overrun is. As for tiger, the one you've found in the 'genmsgidx' script exists but is not that important, that script is actually used only when the package is built it not used when any of the Tiger scripts are run as root. I will fix the bug for the benefit of those who autobuild packages in untrusted systems, but I'm lowering its severity. Regards Javier signature.asc Description: Digital signature
Bug#494223: Issue related to the kernel headers from 2.6.26
tags 494223 upstream thanks This looks like a problem with the Linux kernel headers. In my i386 environment I have linux-libc-dev version 2.6.25-6, which does *not* provide a /usr/include/linux/pim.h file. However, linux-libc-dev version 2.6.26-2 does include it, and its definitions do contradict with the definitions at mrt/include/netinet/pim.h (which come from BSD) I'm going to bring this upstream to see if they can fix it there. Unfortunately this issue is not fixed in the 1.5 release which was recently published. Regards Javier signature.asc Description: Digital signature
Bug#491503: dnscache-run: Postrm script does not call daemontools properly
Package: dnscache-run Version: 1:1.05-3 Severity: grave Tags: patch Dnscache-run's postrm script does not properly terminate the dnscache process because, AFAIK, it does not call properly the daemontools utility used to terminate processes (uses 'sv' instead of 'svc'). The attached patch fixes this issue. Regards Javier --- dnscache-run.postrm.orig 2008-07-19 23:30:59.0 +0200 +++ dnscache-run.postrm 2008-07-19 23:34:42.0 +0200 @@ -3,7 +3,7 @@ test $1 = 'purge' || exit 0 -sv force-stop /etc/sv/dnscache || : +svc -x /etc/sv/dnscache || : rm -rf /etc/sv/dnscache rm -rf /var/lib/supervise/dnscache /var/lib/supervise/dnscache.log for i in '@*' current config lock state; do signature.asc Description: Digital signature
Bug#488581: snort_2.8.1-2(ia64/experimental): impossible register constraint in 'asm'
On Sun, Jun 29, 2008 at 11:35:10PM +0200, Philipp Kern wrote: Package: snort Version: 2.8.1-2 Severity: serious There was an error while trying to autobuild your package: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../src -I../src/sfutil -I/usr/include/pcap -I../src/output-plugins -I../src/detection-plugins -I../src/dynamic-plugins -I../src/preprocessors -I../src/preprocessors/flow -I../src/preprocessors/portscan -I../src/preprocessors/flow/int-snort -I../src/preprocessors/HttpInspect/include -I../src/preprocessors/Stream5 -I../src/target-based -fno-strict-aliasing -g -O2 -D_GNU_SOURCE -Wall -pthread -DDYNAMIC_PLUGIN -fno-strict-aliasing -c snort.c snort.c: In function 'CleanExit': snort.c:1384: error: impossible register constraint in 'asm' cpuclock.h:107: error: impossible register constraint in 'asm' cpuclock.h:114: error: impossible register constraint in 'asm' Looks like maybe ia64 is not supported. I will look into this issue, but might have to drop that architecture. Help from porters to ia64 would be welcome indeed. Regards Javier signature.asc Description: Digital signature
Bug#483160: CVE-2008-1804: possibility to bypass detection rules
severity 483160 important thanks On Wed, May 28, 2008 at 01:11:44AM +1000, Steffen Joeris wrote: Package: snort Severity: grave Tags: security Justification: user security hole This is hardly a grave bug. Bypassing IDS has been possible since they were first invented, after all they are just a 'network signature matcher'. I'm reducing the severity but keeping the security tag. Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481119: gnome-screensaver: cannot unlock screen after upgrade
Package: gnome-screensaver Version: 2.22.2-1 Priority: serious After upgrading from gnome-screensaver version 2.20.0-2+b1 to 2.22.2-1 I've found that whenever the screensaver starts up (due to the timeout defined) and locks the screen I'm not presented the unlock dialog. All I can see is (temporarily) the mouse but the screen remains blank. No change (save disabling locking) in gnome-screensaver's preference tool has been able to fix this issue. When I've found the screen to be disabled I have only been able to unlock it by going from the X session to a VTY session and manually killing the screensaver process. Of course, a user that has no such knowledge can only fix this situation by killing (Ctrl+Alt+Del) the X session altogether and potentially losing all his data. I've poked into Gnome's registry and changed the value of /apps/gnome-screensaver/lock_dialog_theme from 'default' (which I understand from the schema that is the default value) to a blank value and *then* I'm presented a dialog to unlock the screen. I've tried changing it to 'system' and the dialog is also presented.. I'm not sure, however, if this is the proper fix for this issue. I think this behaviour (which probably only happens on upgrades) is completely unacceptable. If the default value of any of the keys in gnome-screensaver has been changed so as to make previous values incorrect then the program should detect this and (transparently to the user) fix the issue. Thus the 'serious' severity. signature.asc Description: Digital signature
Bug#481119: Additional info for bug #481119
Reviewing other bug reports (specially #45 which seems related) I've found a pointer to http://live.gnome.org/GnomeScreensaver/FrequentlyAskedQuestions#head-d50bc17e7d6f3a51c4715f02c657195e80e26c2c on how to generate debug information. I'm attaching to this bug report to samples of debug output: - gscreen-debug.ERR.txt.gz: in this one the value of lock_dialog_theme is 'default', I started up gnome-screensaver in debug mode, locked it up inmediately using 'gnome-screensaver-command -l' and then pressed shift three times. No dialog appears (but you can see that it goes through the unlock process) at all and I can not login. I end up the process killing it from a vty. - gscreen-debug.OK.txt.gz: in this case the value of lock_dialog_theme is set to 'system'. I follow the same procedure as above but when I press a key I inmediately get the login prompt and I'm able to unlock the screen. I killed the process from the terminal it was started from. Just in case this debug information is of use. Regards Javier gscreen-debug.ERR.txt.gz Description: Binary data gscreen-debug.OK.txt.gz Description: Binary data signature.asc Description: Digital signature
Bug#476069: nessus-libraries: FTBFS: configure: error: can only configure for one host and one target at a time
On Mon, Apr 14, 2008 at 01:41:09PM +0200, Lucas Nussbaum wrote: Package: nessus-libraries Version: 2.2.10-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080413 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is now the default on most architectures (even if it's not the case on i386 yet). Feel free to downgrade this bug to 'important' if your package is only built on i386, and this bug is specific to gcc 4.3 (i.e the package builds fine with gcc 4.2). The problem is not gcc 4.3, but dpkg-buildpackage setting now environment variables it did not set in the past. This bug is similar to bug #476036. Regards Javier signature.asc Description: Digital signature
Bug#445113: Reopening bug
On Sat, Mar 15, 2008 at 01:11:56PM -0400, James Vega wrote:
This bug is still present[0] and is holding up an RC bug fix for
Snort[1] from propagating to testing. The problem looks to be two-fold.
First, the check added in 2.7.0-9 to prevent building the documentation
will fail in dirty chroots. Since the latex packages take so long to
install and uninstall, it's not uncommon for the slower buildds to have
those packages pre-installed.
There is no way I can prevent that, chroots should *not* run the binary
target at all (just binary-arch). This is a flaw in the build environment,
not in Snort.
Second, the binary-arch and binary-indep targets in your rules file both
have the install target as a prerequisite. It seems like they should
have the associated install-{arch,indep} as a prerequisite instead.
This is not the reason why the buildd daemon tries to build the
documentation. It is building it because it is calling build, and not just
build-arch. I'm going to fix that, however.
[0] -
http://buildd.debian.org/fetch.cgi?pkg=snort;ver=2.7.0-11;arch=mipsel;stamp=1205557525
If you review the build log you will see that it fails because it doesn't
find a LaTeX .sty file, I'm adding texlive-latex-recommended to the
Build-Depends-Indep line, since it was missing.
If, however, the mipsel buildd is not fixed the next upload might still fail
to build there.
Regards
Javier
signature.asc
Description: Digital signature
Bug#445113: Reopening bug
On Sat, Mar 15, 2008 at 04:56:18PM -0400, James Vega wrote: On Sat, Mar 15, 2008 at 08:21:24PM +0100, Javier Fernández-Sanguino Peña wrote: On Sat, Mar 15, 2008 at 01:11:56PM -0400, James Vega wrote: This bug is still present[0] and is holding up an RC bug fix for Snort[1] from propagating to testing. The problem looks to be two-fold. First, the check added in 2.7.0-9 to prevent building the documentation will fail in dirty chroots. Since the latex packages take so long to install and uninstall, it's not uncommon for the slower buildds to have those packages pre-installed. There is no way I can prevent that, chroots should *not* run the binary target at all (just binary-arch). This is a flaw in the build environment, not in Snort. They don't run the binary target. They simply call binary-arch. The binary-arch target has a prerequisite on build which then causes the build-indep target to be run. I've attached a patch which fixes the build. I had no intention of uploading as an NMU, I just used the changelog to document the changes I made in the patch. I've already uploaded a new version with a similar patch. I also found out the bug of snort-common files in the process. Regards Javier signature.asc Description: Digital signature
Bug#445113: Reopening bug
On Sat, Mar 15, 2008 at 05:48:39PM -0400, James Vega wrote: On Sat, Mar 15, 2008 at 08:21:24PM +0100, Javier Fernández-Sanguino Peña wrote: This is not the reason why the buildd daemon tries to build the documentation. It is building it because it is calling build, and not just build-arch. I'm going to fix that, however. Just to clarify, your build target doesn't have to do anything[0] (as is the case in the patch I sent). In fact, it's recommended to have an empty build target and have the binary targets depend on the proper build targets if you have multiple configurations of packages or arch and arch-indep packages being built. Ok. I'll add that. The texlive-latex-recommended Build-Depends-Indep is unnecessary since texlive already Depends on it. Then why does the mipsel buildd don't have that installed? The build is failing there because of a missing style. Regards Javier signature.asc Description: Digital signature
Bug#464264: fortunes-es: FTBFS: dpkg-checkbuilddeps: error: syntax error in debian/control at line 21: duplicate field Depends found
On Sat, Mar 01, 2008 at 11:49:27PM +0100, Javier Fernández-Sanguino Peña wrote: Please file your improvements as separate patches. I don't appreciate NMUs which change things in the packages other than the bug they are trying to fix. I've uploaded fortunes-es 1.29 with the fixes you suggested. If you have more suggestions besides these please consider filing (wishlist) bugs. Thanks, Javier signature.asc Description: Digital signature
Bug#464265: clips-doc: FTBFS: dpkg-checkbuilddeps: error: syntax error in debian/control at line 11: duplicate field Recommends found
On Fri, Feb 29, 2008 at 04:19:52AM +0100, Cyril Brulebois wrote: Please find attached a diff for my NMU, to be uploaded to DELAYED/2 RSN. I find it quite surprising that you upload a fix to 2-day NMU when I'm not in the Low-threshold NMU list. -Build-Depends-Indep: debhelper +Build-Depends: debhelper This fix is not correct. Debian-doc is a binary: all package, and it shouldn't have been rebuilt on i386 by an autobuilder, as they don't support Build-Depends-Indep. Standards-Version: 3.6.1 +Homepage: http://www.ghg.net/clips/ This is in no way related to the bug report. -This package was put together by me, Javier Fernandez-Sanguino Pe?a +This package was put together by me, Javier Fernandez-Sanguino Peña Why this change? The previous version of clips-doc was, IIRC, converted to utf-8 and you are changing it to latin1 (ISO-8859-1) encoding. -# This is the debhelper compatability version to use. -export DH_COMPAT=4 Again, this is not something related to the bug report. Why did you change this? Regards Javier signature.asc Description: Digital signature
Bug#460514: cron: can't lock /etc/crond.pid, otherpid may be 6898: Resource temporarily unavailable
On Sun, Jan 13, 2008 at 11:49:57AM +0100, Axel Beckert wrote: At least since updating to this version of cron on kfreebsd-amd64 (maybe earlier), cron seems to look for the pid in /etc/crond.pid which doesn't work. It argues about it as follows: Ummm... there are several issues here, you should report them separately: a) The usage of /etc/crond.pid violates the FHS and therefore the Debian Policy Manual, section 9.1.1 Your architecture's /usr/include/paths.h (this is provided by the libc6-dev) header is missing the following line: #define_PATH_VARRUN /var/run/ This makes cron use /etc/ instead of /var/run. b) The init.d script is unable to stop or restart crond. Yes, that's because the pid file is not found. c) The init.d script does not return an exit code unequal to zero if it fails (see the prompts above). Init.d scripts which fail to stop should still return a code equal to zero (see the LSB specs). I don't parse your command lines, could you explain how can I infer that the exit code is not cero? Regards Javier signature.asc Description: Digital signature
Bug#460514: cron: can't lock /etc/crond.pid, otherpid may be 6898: Resource temporarily unavailable
On Sun, Jan 13, 2008 at 09:37:11PM +0100, Axel Beckert wrote: tag 460514 + patch thanks Hi, On Sun, Jan 13, 2008 at 05:38:59PM +0100, Javier Fernández-Sanguino Peña wrote: Ummm... there are several issues here, you should report them separately: Ok, I'll have a closer look at LSB what return code should be given if /etc/init.d/cron start fails and will eventually report it as own bug. Notice that my comment applied to the 'stop' action, not to 'start', which should exit with non-zero if it fails. Regards Javier signature.asc Description: Digital signature
Bug#455263: tftpd-ha: Uses undocumented virtual package 'tftpd'
Package: atftpd Version: 0.7.dfsg-3 Priority: serious Justification: Policy violation, section 3.6 Atftpd Provides: the 'tftpd' virtual package, but that package is not listed in the canonical virtual packages list at http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt This is a Policy violation and, what is worst, induces users to confusion as this (and tftpd-hpa) do not provide the same behaviour. For starters, atftpd users /tftpboot as the standard (non-FHS) location for files, whileas tftpd-hpa uses /srv/tftpboot and tftpd uses /var/lib/tftpboot Please either remove the provides or get together with other maintainers of tftpd daemons and determine what is the common interface (and location of files) so that users that install a package Providing: tftpd can make reasonable assumptions as to its behaviour and *then* ask debian-policy to add 'tftpd' as a virtual package. I would really encourage you to follow the second road, even if more complex, as it would be better overall for all our users. Regards Javier signature.asc Description: Digital signature
Bug#455262: tftpd-ha: Uses undocumented virtual package 'tftpd'
Package: tftpd-ha Version: 0.48-1 Priority: serious Justification: Policy violation, section 3.6 Tftpd-ha Provides: the 'tftpd' virtual package, but that package is not listed in the canonical virtual packages list at http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt This is a Policy violation and, what is worst, induces users to confusion as this (and aftpd) do not provide the same behaviour. For starters, tftpd-hpa uses /srv/tftpboot as the standard location for TFTP files whileas aftpd uses /tftpboot. Please either remove the provides or get together with other maintainers of tftpd daemons and determine what is the common interface (and location of files) so that users that install a package Providing: tftpd can make reasonable assumptions as to its behaviou and *then* ask debian-policy to add 'tftpd' as a virtual package. I would really encourage you to follow the second road, even if more complex, as it would be better overall for all our users. Regards Javier signature.asc Description: Digital signature
Bug#450479: tiger: FTBFS: rm: cannot remove `debian/tiger/': Not a directory
On Wed, Nov 07, 2007 at 01:45:25PM +0100, Lucas Nussbaum wrote: Package: tiger version: 1:3.2.1-37 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20071106 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. The problem seems to be that upstream's tarball ships a debian/tiger file I manually removed (but is not reflected in the diff). I'll see how I can fix this, thanks for reporting it. Regards Javier signature.asc Description: Digital signature
Bug#439642: Probably something debian buildd specific
tags 439642 -patch thanks On Sun, Sep 30, 2007 at 05:51:10AM +0200, Cyril Brulebois wrote: Why the hell is a package containing .so an Architecture: all package?! It seems to have been an omission in moving the /usr/lib contents from snort-common to the snort binary packages. I'd also advise to use ???-module -avoid-version??? to build plugins, no need to have .0.0.0 things for them, but please fix that bug first. Why shouldn't there be a versioning for the modules? If libraries are in a separate package (as they should be) versioninig might be appropiate. An NMU might happen before monday since there's an ongoing BSP. And where's the patch? Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429160: po4a: po4a-gettextize is vulnerable to symlink attacks in /tmp
On Mon, Sep 24, 2007 at 03:59:00PM +0200, Jens Seidel wrote: I don't want to reopen this bug but why is it OK to omit /tmp? The code is still vulnerable. Just assume po4a is started in /tmp or in another directory where an attcker has write access and the problem remains ... Yes, but only in that ocasion and not everytime. Users should not run stuff with their current directory pointing to /tmp. I agree that it is unlikely but I often work in /tmp to handle translations ... Then you might want to produce a patch that uses File::Temp's tempfile, since that honors TMPDIR setting and does the right thing. I just didn't find it would be necessary for this package but should be trivial to implement. Regards Javier signature.asc Description: Digital signature
Bug#440411: CVE assigned
On Tue, Sep 04, 2007 at 10:20:47AM +0200, Thijs Kinkhorst wrote: Hi, This is CVE-2007-3912. Please add it (retroactively) to the changelog. Done, will commit it in 0.35 Javier signature.asc Description: Digital signature
Bug#420044: Debdiff to fix FTBFS of etoken
On Sat, Sep 01, 2007 at 11:16:44AM +0200, Stephan Hermann wrote: Good Morning Gentlemen, please find attached the debdiff to fix this FTBFS. Thanks. I'm using this to fix the bug and will upload new packages right away. Javier signature.asc Description: Digital signature
Bug#440411: checkrestart: arbitrary root-privileged command execution
On Sat, Sep 01, 2007 at 12:42:19PM +0200, Thomas de Grenier de Latour wrote: The checkrestart program from debian-goodies (both latest 0.33 and stable 0.27) allows arbitrary command execution with root privileges. Thanks. I was not aware of this bug. Since this program is likely launched as a daily root cron job on some systems, I think this is a grave security hole. Actually, it should not be executed as a daily cron job, but should be run manually by an admin. This way, the command arguments are all well separated, without any shell interpretation. Thanks, I will test out the patch and fix this as soon as possible. PS: sorry for any mistake i may have done in the way i've reported this bug. I'm not a Debian user, so i'm not used to your system. Actually, (...) The bug has been reported just fine. Regards Javier signature.asc Description: Digital signature
Bug#439642: snort will not start
On Sun, Aug 26, 2007 at 01:26:00PM +0200, Hans-J. Ullrich wrote: Am Sonntag 26 August 2007 schrieb Javier Fernández-Sanguino Peña: file /usr/lib/snort_dynamicengine/libsf_engine.so.0.0.0 Hi Javier, thank you for your fast response. This is my output. Please take a look: (...) Did you also try removing the line from the configuration file? If so, what where the results? Javier signature.asc Description: Digital signature
Bug#439642: snort will not start
On Mon, Aug 27, 2007 at 07:08:02PM +0200, Hans-J. Ullrich wrote: sorry, which line do you mean ??? From my first mail: Could you please try and comment the following line from your snort.conf and restart it to see if it works? dynamicengine /usr/lib/snort_dynamicengine/libsf_engine.so Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439642: snort will not start
On Sun, Aug 26, 2007 at 11:25:07AM +0200, Hans wrote: ///usr/lib/snort_dynamicengine/libsf_engine.so: wrong ELF class: ELFCLASS32 I'm not a library expert, but this bug looks like the libsf_engine.so was built as a 32bit library, which cannot be loaded into a 64bit program. Could you please also do this: $ file /usr/lib/snort_dynamicengine/libsf_engine.so.0.0.0 $ file /usr/lib/snort_dynamicpreprocessor/libsf_* |grep -v symbolic and send me the output? Regards Javier signature.asc Description: Digital signature
Bug#439642: snort will not start
On Sun, Aug 26, 2007 at 11:25:07AM +0200, Hans wrote: Dear maintainers, on my AMD64 X2 system the latest version inhibits to start. It is looking like an dependency or lib related problem. It looks like the libraries that snort needs to use are not compiled properly in ADM64's autobuilders or they need something to work properly. This is out of the log: snip -- Aug 26 11:16:16 protheus2 snort[7724]: Rule application order: activation-dynamic-pass-drop-alert-log Aug 26 11:16:16 protheus2 snort[7724]: Log directory = /var/log/snort Aug 26 11:16:16 protheus2 snort[7724]: Loading dynamic engine /usr/lib/snort_dynamicengine/libsf_engine.so... Aug 26 11:16:16 protheus2 snort[7724]: FATAL ERROR: Failed to load //usr/lib/snort_dynamicengine/libsf_engine.so: ///usr/lib/snort_dynamicengine/libsf_engine.so: wrong ELF class: ELFCLASS32 Could you please try and comment the following line from your snort.conf and restart it to see if it works? dynamicengine /usr/lib/snort_dynamicengine/libsf_engine.so Please report back whether that works for you or not. Thanks Javier signature.asc Description: Digital signature
Bug#429160: po4a: po4a-gettextize is vulnerable to symlink attacks in /tmp
Package: po4a
Version: 0.29-1
Severity: grave
Tags: security patch
If you run po4a-gettextize on contents that do not get converted to PO files
due to some issue, the script will dump its results in
/tmp/gettextization.failed.po.
The script uses a file in the /tmp diretory but does not try to prevent a
symlink attack. A malicious user could create a symlink named liked that in
the temporary directory and pointing to one of the user's files so that when
a user runs po4-gettextize (and fails) the file the symlink pointed to would
get overwritten.
The fix is, IMHO, simple: just dump the results in the local directory, don't
use /tmp at all (it is, after all, unnecesary). The attached patch to
/usr/share/perl5/Locale/Po4a/Po.pm fixes this issue.
Regards
Javier
--- Po.pm.orig 2007-06-16 02:10:41.0 +0200
+++ Po.pm 2007-06-16 02:10:55.0 +0200
@@ -451,14 +451,14 @@
# Make sure both type are the same
#
if ($typeorig ne $typetrans){
- $pores-write(/tmp/gettextization.failed.po);
+ $pores-write(gettextization.failed.po);
die wrap_msg(dgettext(po4a,
po4a gettextization: Structure disparity between original and translated files:\n.
msgid (at %s) is of type '%s' while\n.
msgstr (at %s) is of type '%s'.\n.
Original text: %s\n.
Translated text: %s\n.
- (result so far dumped to /tmp/gettextization.failed.po)).%s,
+ (result so far dumped to gettextization.failed.po)).%s,
$reforig, $typeorig, $reftrans, $typetrans, $orig, $trans,$toobad);
}
signature.asc
Description: Digital signature
Bug#419454: Patch
On Sat, Apr 21, 2007 at 10:44:52AM -0700, Matt Kraai wrote: tag 419454 patch thanks The attached patch fixes this problem by changing fancyheadings to fancyhdr, which, according to the author of fancyheadings, is a 99%-compatible replacement. Thanks. I'm going to try it out and upload a new version of the package fixing the Build-Dependencies too. Regards Javier signature.asc Description: Digital signature
Bug#332782: Please explain the etch-ignore tag
On Sat, Apr 07, 2007 at 10:08:57PM +0900, Osamu Aoki wrote: So far, I could not be able to find any code or text marked with my account. Javi, how did you come up with my name? May be it was just your guess. Current checking script for translation version is now completely yours. Some text in installation guide (mouse section) may be mine but non in R-N I remember There was a commit log message that said: Added some suggestions provided by Osamu Asoki improving some text and segmenting recommendations (revision 1.186, commited by myself) and Add Osamu's suggestion of mentioning screen when using ssh (revision 1.185) IIRC they all come from the patch you provided at #401317. Regards Javier signature.asc Description: Digital signature
Bug#332782: Please explain the etch-ignore tag
On Fri, Apr 06, 2007 at 11:42:15PM +0900, Osamu Aoki wrote: Hi, Sigh... I understand it is nice if we had copyright section but after all this was note. Well, now it's a document over 50 pages long (for most architectures, anyway). So it should have its own license section. If Francesco feels strong about this issue, he should at least put his effort to send out licensing clarification notice to all involved with contactable address and give us how they respond to the licensing clarification to the GPL2 and move one. I think we only need to: a) add the GPL license, as it should have had when it moved from b-f's CVS to the DDP b) ask those that might not be aware that the document is GPL (as it lacked a copyright notice in the DDP CVS, but it had one in the main tarball when it was part of the boot-floppies). c) notify translators that they should be based on that license (some translations should already have the license as they were part of the original b-f CVS too) If anyone object, they should clarify what section they own copyright and, if they disagree, let them or Francesco report to us about their position. Then we remove that section. True. I don't expect anybody to disagree, however, but you never know. For the record, I sign up any DSFG compliant copyright notice. Thanks. Javier signature.asc Description: Digital signature
Bug#332782: Please explain the etch-ignore tag
On Sat, Apr 07, 2007 at 12:12:19AM +0200, Frans Pop wrote: On Friday 06 April 2007 23:59, Javier Fernández-Sanguino Peña wrote: a) add the GPL license, as it should have had when it moved from b-f's CVS to the DDP Add the whole GPL licence with all translation problems that brings? Hmmm.. actually I should have said add the GPL *disclaimer* and not the license itself. Note that even the GPL *disclaimer* should have those translation problems you might be thinking of. For example, see the disclaimer http://www.debian.org/doc/manuals/securing-debian-howto/index.en.html (it uses a liberal way to refer to the GPL, not exactly what the How to apply these terms to your new programs text from the GPL, as seen in http://www.gnu.org/licenses/gpl.html#SEC4, says) Based on that disclaimer translations can include a) the license in untranslated form b) the translated license *if* it has been approved by the FSF c) an unapproved translated license, together with the original license As there are no approved translations nobody should go to b) In the French translation of that document, they go for the a) approach with a twist (and additional disclaimer in French :), see: http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html I guess your comment is related to the discussion in d-i that changed how GPL translations were handled (Message-id: [EMAIL PROTECTED], may 2006), but I think it's perfectly OK to include just the GPL disclaimer and point to where the GPL is (maybe provide it in the CDs/DVDs themselves?) instead of including the full GPL license text in the document itself (as is done in d-i) Please not! Let's just have a simple statement and a reference to where the fill licence can be found. Full? In any case, your proposal was the same as mine, only mine was not properly worded. If that can't be done with the GPL, then let's please choose another DFSG compatible one. We sure can't change the license. If we assume the document is GPL-licensed (as it was part of b-f's codebase) then relicensing it would certainly mean asking *all* copyright holders. Going back to all contributors from 1999 to the present date is certainly not an option. I believe the GPL disclaimer is OK, after all, but we might want to have the debian-cd masters add the GPL itself in the same directory as the Release Notes, so that we can point to it locally (and not in a remote URL). Sounds like a good plan to you for (maybe) r1? Regards Javier signature.asc Description: Digital signature
Bug#332782: Please explain the etch-ignore tag
On Thu, Apr 05, 2007 at 11:02:00PM +0200, Francesco Poli wrote: Thank you for agreeing to the licensing[1], could you please tell me the relevant years, name and (optional) e-mail address, for the copyright notice? Hmm... as for names and e-mail addreses I think we need to dig that information first. Years would be 1999-2007, they seem to have been first written for slink (http://www.es.debian.org/releases/slink/#release-notes). The DDP CVS only has the Release Notes since woody (january 2003), previously they Release Notes resided in the boot-floppies' CVS. What do the other co-authors and contributors have to say about this licensing? Do you agree or disagree? Notice that many of the people listed as co-authors (such as Josip or Adam) are no longer subscribed to -doc. Some of the past co-authors/contributors might not even be Debian Developers (or contributors) anymore. Obviously enough, I'm *not* going to dig into the CVS logs to collect a comprehensive list of individual contributors, unless I first receive agreements from an encouraging number of main credited authors and some other contributors... ;-) I'm pretty sure most of the current editors agree with the licensing. They are, however, right now out of time to cater this issue (we are trying to release etch, after all). Digging into the CVS logs should not be that hard, in addition to the ones I listed (editors), I find (in a cursory glance): - Frédéric Bothamy - Daniel Nylander - Roberto C. Sánchez - Clytie Siddall - Frederik Schueler - Frank Lichtenheld - Adeodato Simón - Nobuhiro IMAI - Luk Cleas - A. Mennucc - Martin Michlmayr - Osamu Asoki - Steve Langasek - Jordi Polo It is worth noting that: a) Their contributions might not be present in the current RN anymore b) Some of the patches they provided might be just typo fixes and not actual text. I don't believe those grant one co-author status for a document. Additionally, references to bugs in the BTS should be reviewed, as some logs refer to bugs which might have included a patch from the submitter. Obtaining a contributors list from 1999-2003 might be more difficult, however, and it still might be relevant. For example, contents of the following patch from Chris Tillman for woody's release notes seems to still be present in etch's Release Notes: http://lists.debian.org/debian-doc/2001/12/msg00023.html (sent and applied by Rob Bradford) The boot-floppies CVS (which held that information) seems not to be available anymore (or at least I cannot find it in gluck). Does anyone keep a backup of that one? Regards Javier signature.asc Description: Digital signature
Bug#332782: Please explain the etch-ignore tag
On Sat, Mar 24, 2007 at 05:58:27PM -0700, Steve Langasek wrote: Anyway, if a license change was properly announced beforehand contributors that feel that their rights are violated would have ample time to express their concerns. Are there really so many substantial contributors that it would be hard to ask them all? Can't tell for sure. But digging the information can be really hard, the release notes have been written since 1999. This bug has changed into exactly the same type of discussion that prevents #388141 from being fixed any time soon, even though all the web pages have a footer that says this text is copyright SPI and no contributor has ever said that the copyright statement should be ammended to include *him*. Well, sorry, but that's a bug in the documentation team's process for not proactively requiring copyright disclaimers. Well, I mean, you could argue that it's a bug in copyright law, but we don't have the power to fix that bug... You could say that the Release Notes were first in the realm of the boot-floppies team (in its CVS) and, actually, were outside the scope of the documentation team's. Hmm... Now that I think of it, one could say that since the Release Notes were originally part of the boot-floppies sources, and since the boot-floppies were fully under the GPL (or so does their debian/copyright file say) then the current Release Notes (derived work of that one) can only be under the GPL license. Right? I've just checked on archive.debian.org, slink's boot-floppies package sources available at http://archive.debian.org/dists/Debian-2.1/main/source/admin/boot-floppies_2.1.12.tar.gz advertise themselves as being under the GPL. The debian/copyright file is (more or less) unchanged in the different incarnations of the source. Even if the SGML file in itself does not carry the license (like b-f's install manual did, which got carried over to d-i's) FWIW, in slink the RN were translated to Spanish, Finnish, French, German, Czech, Japanese, Polish, Portuguese, Russian, Slovenian and Hungarian. So the GPL license would apply to those too (and to Catalonian and Danish) Regards Javier signature.asc Description: Digital signature
Bug#413458: Information introduced in the Release Notes
tags 413458 pending thanks This information has been introduced now in the Release Notes. It should be available tomorrow at http://www.debian.org/releases/etch/i386/release-notes/ch-upgrading.en.html#s4.6.1 Please review and let us know if this is sufficient Regards Javier signature.asc Description: Digital signature
Bug#413458: Information introduced in the Release Notes
On Tue, Mar 27, 2007 at 05:06:43PM -0700, Steve Langasek wrote: So please revert the comments about 'coreutils' under 4.6.1. Ok. Will do. Javier signature.asc Description: Digital signature
