Bug#970355: syslog-ng : segfault at 0 ip 00007fa46a2bf7b2 sp 00007ffed353fb30 error 6 in libsyslog-ng-3.19.so.0.0.0[7fa46a2a9000+5a000]

[SZALAY Attila]

Hi Jean-Marc,

Please check if a core file is available related to the segmentation
fault. If there is any please make it available for me/us.

Also, can you run syslog-ng-debun with the -r parameter and send the
generated report bundle?

Another question, is the segmentation fault reproducible? Is syslog-ng
crashing frequently?


signature.asc
Description: This is a digitally signed message part

Bug#970355: syslog-ng : segfault at 0 ip 00007fa46a2bf7b2 sp 00007ffed353fb30 error 6 in libsyslog-ng-3.19.so.0.0.0[7fa46a2a9000+5a000]

[SZALAY Attila]

Hi Jean-Marc,

Please check if a core file is available related to the segmentation
fault. If there is any please make it available for me/us.

Also, can you run syslog-ng-debun with the -r parameter and send the
generated report bundle?

Another question, is the segmentation fault reproducible? Is syslog-ng
crashing frequently?


signature.asc
Description: This is a digitally signed message part

Bug#969201: git-buildpackage: When tarball-dir configuation option is set but no orig.tar.gz exists extracting the source fails

[SZALAY Attila]

Package: git-buildpackage
Version: 0.9.14
Severity: normal

The problem is that the prepare_upstream_tarballs uses the output_dir option
to store the generated tarball, but later when the export_source is called
it tries to use the tarball_dir variable to find the file.

In default case the two variable (output_dir and tarball_dir) point to the
same directory, except when the tarball-dir option is used.

the problem is at gbp/scripts/buildpackage.py, line 541:
# Export to another build dir if requested:
if options.export_dir:
export_source(repo, tree, source, options, tmp_dir, tarball_dir)

where the tarball_dir should be output_dir

Debug log:
sasa@sasalaptop:~/tmp/boxfort/boxfort$ gbp buildpackage --git-verbose
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: /bin/true [] []
gbp:debug: ['git', 'status', '--porcelain']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/debian/latest']
gbp:debug: ['git', 'ls-tree', 'HEAD']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/changelog']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:info: Building with (cowbuilder) for sid
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
gbp:debug: ['git', 'log', '--pretty=format:%H', '--no-merges', 
'--grep=pristine-tar .* boxfort_0.0.0-git20200808-ac0507b\\.orig.tar\\.', 
'pristine-tar', '--']
gbp:debug: Found pristine-tar commit at 
'2423786d51396bd15dcf787521bbbaba91ef51cc'
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 
'2423786d51396bd15dcf787521bbbaba91ef51cc^0']
gbp:debug: ['git', 'show', 
'--pretty=format:%an%x00%ae%x00%ad%x00%cn%x00%ce%x00%cd%x00%s%x00%f%x00%b%x00', 
'-z', '--date=raw', '--no-renames', '--name-status', '--no-show-signature', 
'2423786d51396bd15dcf787521bbbaba91ef51cc']
gbp:debug: Determined compression type 'gzip'
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:debug: Looking for orig tarballs 
'boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz' at '../'
gbp:info: Tarballs 'boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz' not found at 
'../'
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:info: Creating 
/home/sasa/tmp/boxfort/build-area/boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:debug: pristine-tar [] ['checkout', 
'/home/sasa/tmp/boxfort/build-area/boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz']
gbp:debug: pristine-tar [] ['--help']
gbp:debug: pristine-tar [] ['verify', 
'/home/sasa/tmp/boxfort/build-area/boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/source/format']
gbp:info: Extracting 'boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz' to 
'/home/sasa/tmp/boxfort/build-area/boxfort-tmp'
gbp:debug: tar ['-C', '/home/sasa/tmp/boxfort/build-area/boxfort-tmp', '-a', 
'-xf', '../boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz'] []
tar: ../boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz: Cannot open: No such 
file or directory
tar: Error is not recoverable: exiting now
gbp:error: Couldn't unpack '../boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz': 
it exited with 2
sasa@sasalaptop:~/tmp/boxfort/boxfort$ ls -l ../build-area/
total 48
-rw-r--r-- 1 sasa sasa 41590 Aug 29 11:16 
boxfort_0.0.0-git20200808-ac0507b.orig.tar.gz
drwxr-xr-x 2 sasa sasa  4096 Aug 29 11:16 boxfort-tmp
sasa@sasalaptop:~/tmp/boxfort/boxfort$ ls -l ../build-area/..
total 8
drwxr-xr-x 9 sasa sasa 4096 Aug 29 11:15 boxfort
drwxr-xr-x 3 sasa sasa 4096 Aug 29 11:16 build-area
sasa@sasalaptop:~/tmp/boxfort/boxfort$ grep dir debian/gbp.conf 
export-dir = ../build-area/
tarball-dir = ../
sasa@sasalaptop:~/tmp/boxfort/boxfort$ 



-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.19.5+deb10u1
ii  git1:2.20.1-2+deb10u3
ii  man-db 2.8.5-2
ii  python33.7.3-1
ii  python3-dateutil   

Bug#969127: RM: libboxfort -- NBS; After a packaging change this package become empty, so removed from the control file

[SZALAY Attila]

Package: ftp.debian.org
Severity: normal

I also think that there is a bug somewhere in the cruft-report, as the
packages should have been in the daily report. The problem is that the
packages for the amd64 and the i386 architecture was automatically removed
but the armel and armhf was unremovable because of some reverse dependency.
And when that dependency were fixed, the leftover architectures were not
reconsidered by the dak, although:

sasa@coccia:~$ dak rm -b libboxfort -Rn
Will remove the following packages from unstable:

libboxfort | 0.0.0-git20200105-3e16c0a-2 | armel
libboxfort | 0.0.0-git20200105-3e16c0a-6 | armhf

Maintainer: SZALAY Attila 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Bug#969059: ITP: criterion -- cross-platform C and C++ unit testing framework

[SZALAY Attila]

Package: wnpp
Severity: wishlist
Owner: SZALAY Attila 

* Package name: criterion
  Version : 2.3.3
  Upstream Author : Franklin "Snaipe" Mathieu <http://snai.pe/>
* URL : https://github.com/Snaipe/Criterion
* License : MIT, WTFPL, BSD-2-Clause, bzip2
  Programming Lang: C, C++, Perl, Raku, Meson, Shell
  Description : cross-platform C and C++ unit testing framework

 Most test frameworks for C require a lot of boilerplate code to set up
 tests and test suites -- you need to create a main, then register new test
 suites, then register the tests within these suits, and finally call the
 right functions.
 .
 This gives the user great control, at the unfortunate cost of simplicity.
 .
 Criterion follows the KISS principle, while keeping the control the user
 would have with other frameworks:
 .
 * C99 and C++11 compatible.
 * Tests are automatically registered when declared.
 * Implements a xUnit framework structure.
 * A default entry point is provided, no need to declare a main unless you
want to do special handling.
 * Test are isolated in their own process, crashes and signals can be
reported and tested.
 * Unified interface between C and C++: include the criterion header and it
just works.
 * Supports parameterized tests and theories.
 * Progress and statistics can be followed in real time with report hooks.
 * TAP output format can be enabled with an option.
 * Runs on Linux, FreeBSD, Mac OS X, and Windows (Compiling with MinGW GCC
and Visual Studio 2015+).

This package is used by the syslog-ng as the new test framework.

Bug#968517: RM: libboxfort-dev [armel armhf] -- ANAIS; boxfort cannot be compiled/run reliably on 32 bit arm architecture and therefore removed from source

[SZALAY Attila]

Package: ftp.debian.org
Severity: normal

Bug#948216: ITP: boxfort -- simple, cross-platform sandboxing C library powering Criterion

[SZALAY Attila]

Package: wnpp
Severity: wishlist
Owner: SZALAY Attila 

* Package name: boxfort
  Version : 0.0.0-git20200105-3e16c0a
  Upstream Author : Franklin "Snaipe" Mathieu <http://snai.pe/>
* URL : https://github.com/Snaipe/BoxFort
* License : MIT/X
  Programming Lang: C
  Description : simple, cross-platform sandboxing C library powering 
Criterion

 BoxFort provides a simple API to run user code in isolated processes.
 .
 Although BoxFort provides some kind of security of the parent process from
 spawned sandboxes, a sandbox has by default the same system permissions and
 access than its parent, and is hence, without care, ill-fitted for security
 purposes.
 .
 The main goal of this project is not security, but portable code isolation
 -- if you want complete system isolation, consider using properly configured
 containers.


This package is a dependency of the Criterion C++ test library.
I'm planning to maintain this alone at first, but it looks like a team is 
forming
around the Criterion package and it's dependencies, so we might form a more
official team later.

Bug#908559: openvpn: Openvpn cannot run /sbin/ip if started from systemd

[SZALAY Attila]

Package: openvpn
Version: 2.4.6-1
Severity: important

Dear Maintainer,

The openvpn systemd unit cannot start because it cannot call the /sbin/ip
script. If I run the same script by hand it starts, so the problem should be
in the system unit file. I have been using the same config file for a while
(~8-10 years) and changed nothing, it happened when I upgraded my host at
the end of August after a long summber break.

It's hard to strace processes started from systemd (at least for me), but
with a while loop I was able to catch at least the end of the openvpn run
and I found this:

26815 clone(child_stack=NULL, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f3213eb9a90) = 26850
26850 set_robust_list(0x7f3213eb9aa0, 24 
26815 wait4(26850,  
26850 <... set_robust_list resumed> )   = 0
26850 getpid()  = 26850
26850 execve("/sbin/ip", ["/sbin/ip", "link", "set", "dev", "tun0", "up", 
"mtu", "1500"], 0x561a4f9e55d8 /* 48 vars */) = -1 EPERM (Operation not 
permitted)
26850 exit_group(127)   = ?
26850 +++ exited with 127 +++

There are no apparmor profile for openvpn (at least I didn't find any) nor I
can see any log message about denying this.

The host itself was installed at 1994 and then just upgraded so I'm not
totally sure every config is the default, althought it worked at May.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  iproute2   4.18.0-2
ii  libc6  2.27-5
ii  liblz4-1   1.8.2-1
ii  liblzo2-2  2.10-0.1
ii  libpam0g   1.1.8-3.8
ii  libpkcs11-helper1  1.25.1-1
ii  libssl1.1  1.1.0h-4
ii  libsystemd0239-8
ii  lsb-base   9.20170808

Versions of packages openvpn recommends:
ii  easy-rsa  3.0.4-2

Versions of packages openvpn suggests:
ii  openssl 1.1.0h-4
ii  resolvconf  1.79

-- debconf information:
  openvpn/create_tun: false

Bug#892023: autopkgtest-virt-qemu: Fails creating test environment sometimes

[SZALAY Attila]

Package: autopkgtest
Version: 5.1
Severity: important

Dear Maintainer,

Because I need some VM level separation, I have to use qemu for testing my 
package.
Unfortunately, when I run my tests (there are a fair amount of them), most of 
the
time one test fails with a virtual host creation issue. As far as I can tell it
usually fails at the same test case but I think this is happen because the bug
is depending on the number of the created virtual host not because of the test 
case
itself. Especially because I run the same test script just on different package
set.

Previously, when I was running the test with debug it has more chance to 
success, but
not any more.

By the way, the package, I try to use autpktest with is syslog-ng. The command 
I run is:
autopkgtest --debug syslog-ng_3.13.2-4~1.gbpa514e1_amd64.changes -- qemu 
/var/cache/autopkgtest/autopkgtest-sid.img

And the error message I receive is the following:
autopkgtest [09:35:09]: test basic:  - - - - - - - - - - results - - - - - - - 
- - -
basicPASS
autopkgtest: DBG: sending command to testbed: copyup 
/tmp/autopkgtest.a1psrU/basic-artifacts/ 
/tmp/autopkgtest.output.k7snm27u/artifacts/
autopkgtest: DBG: got reply from testbed: ok
autopkgtest: DBG: testbed command ['rm', '-rf', 
'/tmp/autopkgtest.a1psrU/basic-artifacts', 
'/tmp/autopkgtest.a1psrU/autopkgtest_tmp'], kind short, sout raw, serr pipe, 
env []
autopkgtest: DBG: testbed command exited with code 0
autopkgtest: DBG: no need to restore click AppArmor profiles
autopkgtest [09:35:10]: test basic: preparing testbed
autopkgtest: DBG: testbed reset: modified=False, 
deps_installed=['syslog-ng-core', 'syslog-ng-mod-mongodb'](r: False), 
deps_new=['syslog-ng-core', 'syslog-ng-mod-sql'](r: False)
autopkgtest: DBG: testbed reset
autopkgtest: DBG: sending command to testbed: revert
qemu-system-x86_64: terminating on signal 15 from pid 4318 (/usr/bin/python3)
qemu-system-x86_64: terminating on signal 15 from pid 4318 (/usr/bin/python3)
: failure: timed out on client shared directory setup
autopkgtest: DBG: TestbedFailure unexpected eof from the testbed
autopkgtest: DBG: testbed stop
autopkgtest: DBG: testbed close, scratch=/tmp/autopkgtest.a1psrU
autopkgtest: DBG: sending command to testbed: close
autopkgtest: DBG: TestbedFailure cannot send to testbed: [Errno 32] Broken pipe
autopkgtest: DBG: testbed stop
autopkgtest [09:35:36]: ERROR: testbed failure: cannot send to testbed: [Errno 
32] Broken pipe
autopkgtest: DBG: testbed stop

Last time I felt enough debug-fu in myself I discovered that when this happens, 
the
serial console is unaccessible. Unfortunately I know barely anything about qemu 
I just
get to know how it can be used. But if somebody points me in the right 
direction I
can do more tests.

By the way, I just run the test to check how long it need to show the error 
message, but
now it passed.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils   1.6~alpha7
ii  libdpkg-perl1.19.0.5
ii  procps  2:3.3.12-4
ii  python3 3.6.4-1
ii  python3-debian  0.1.32

Versions of packages autopkgtest recommends:
ii  autodep8  0.11.1

Versions of packages autopkgtest suggests:
pn  lxc  
pn  lxd-client   
ii  qemu-system  1:2.11+dfsg-1
ii  qemu-utils   1:2.11+dfsg-1
ii  schroot  1.6.10-4

-- no debconf information

Bug#845925: autopkgtest boostrap qemu

[SZALAY Attila]

Hi,

I run through this at DebConf when I tried to set up my new laptop for
debian work. The problem is, that vmdebootsrap is actually just create
a file, mount it through a loop device and after bootsrapping it it
will run the customizer script in the HOST environment. And if we think
about it, it is logical, because this allows the customizer script to
copy any file from the host os to the disk image if it want.

The mentioned customizer script (/usr/share/autopkgtest/setup-
commands/setup-testbed) also uses this feature when, for example, tries
to detect the used apt proxy.

So, all commands (especially installing packages) which the script want
to run inside the new image is run by/through the chroot command. For
example:

# install some necessary packages
# some tests use a lot of /dev/random, avoid hangs; eatmydata for fast
dpkg, a
# lot of tests expect a logind session
chroot "$root" apt-get install -y eatmydata dbus < /dev/null

And yes, the problem is, that in some cases the /etc/resolv.conf just a
symlink and point to a file which does not exists until the qemu guest
is booted up.

I'm not 100% sure, but I have the feeling that this depends on your
host environment. Because, I think, the debootstrap copies the
/etc/resolv.cong file as-is to the chroot environment.

My first idea was to use the AUTOPKGTEST_APT_PROXY environment
variable, but that did not work because the proxy only set at the end
of the customization script and all the apt-get install command already
 run.

So, my solution was, as a dirty hack, to copy the content of the
/etc/resolv.conf into the chroot. Something like this what is attached
to this email.--- /usr/share/autopkgtest/setup-commands/setup-testbed~	2017-04-30 13:09:57.0 -0400
+++ /usr/share/autopkgtest/setup-commands/setup-testbed	2017-08-06 17:22:16.942392522 -0400
@@ -196,6 +196,11 @@
 fi
 fi
 
+if [ "$root" != "/" ]; then
+chroot "$root" mv /etc/resolv.conf /etc/resolv.conf.backup
+cat /etc/resolv.conf > "$root/etc/resolv.conf"
+fi
+
 if [ -z "${AUTOPKGTEST_IS_SETUP_COMMAND:-}" ]; then
 chroot "$root" apt-get update || (sleep 15; chroot "$root" apt-get update)
 fi
@@ -288,3 +293,8 @@
 
 # avoid cron interference with apt-get update
 echo 'APT::Periodic::Enable "0";' > "$root/etc/apt/apt.conf.d/02periodic"
+
+
+if [ "$root" != "/" ]; then
+chroot "$root" mv /etc/resolv.conf.backup /etc/resolv.conf
+fi


signature.asc
Description: This is a digitally signed message part

Bug#872003: RM: eventlog -- ROM; eventlog library merged to syslog-ng and abandoned by upstream

[SZALAY Attila]

Package: ftp.debian.org
Severity: normal


The eventlog library is/was a reverse dependency of syslog-ng.  Lately it
was a bit neglected by upstream, there were no updates for ages.  Also there
were at least three different "official" version in the wild.  So I
convinced upstream that the best way to come out of this situation is to
merge the eventlog library into syslog-ng.  This happened with syslog-ng
version 3.11.1, so the libevtlog not needed by syslog-ng any more.  Also
there is/were no other reverse dependency of the project than syslog-ng.  So
it not needed in the archive any more.

Bug#775827: Is there any news

[SZALAY Attila]

Hi,

Is there any news about the ownership of this package?

I tried to reach Micah directly but was unable to, so I write to this
bug to reach a grater audience. I have a co-maintained package which is
depends on the grok package so I would like to see this package in a
good shape but I do not use it myself. And therefore I'm not sure it
would be a great idea to take over the package but if this is needed to
 let the bugs fixed I would do it.

signature.asc
Description: This is a digitally signed message part

Bug#844255: Possible solution

[SZALAY Attila]

Hi,

Meanwhile I traced down the issue and found that although the
satisfy_dependencies_string and the install_apt do have
shell_on_failure option, install_deos do not, therefore the chain is
broken.

I created a small patch to add this option to the required places.
diff --git a/lib/adt_testbed.py b/lib/adt_testbed.py
index dda1a69..cb2b8e9 100644
--- a/lib/adt_testbed.py
+++ b/lib/adt_testbed.py
@@ -330,7 +330,7 @@ class Testbed:
 self._opened(pl)
 self.modified = False
 
-def install_deps(self, deps_new, recommends):
+def install_deps(self, deps_new, recommends, shell_on_failure=False):
 '''Install dependencies into testbed'''
 adtlog.debug('install_deps: deps_new=%s, recommends=%s' % (deps_new, recommends))
 
@@ -338,7 +338,7 @@ class Testbed:
 self.recommends_installed = recommends
 if not deps_new:
 return
-self.satisfy_dependencies_string(', '.join(deps_new), 'install-deps', recommends)
+self.satisfy_dependencies_string(', '.join(deps_new), 'install-deps', recommends, shell_on_failure=shell_on_failure)
 
 def needs_reset(self):
 # show what caused a reset
diff --git a/runner/autopkgtest b/runner/autopkgtest
index 79d5751..4482b28 100755
--- a/runner/autopkgtest
+++ b/runner/autopkgtest
@@ -157,7 +157,7 @@ def run_tests(tests, tree):
 adtlog.info('test %s: preparing testbed' % t.name)
 testbed.reset(t.depends, 'needs-recommends' in t.restrictions)
 binaries.publish()
-testbed.install_deps(t.depends, 'needs-recommends' in t.restrictions)
+testbed.install_deps(t.depends, 'needs-recommends' in t.restrictions, opts.shell_fail)
 
 testbed.run_test(tree, t, opts.env, opts.shell_fail, opts.shell,
  opts.build_parallel)

Bug#844255: autopkgtest: --shell-fail does not work in case the tested package cannot be installed

[SZALAY Attila]

Package: autopkgtest
Version: 4.2
Severity: normal

Dear Maintainer,

If the package cannot be installed for whatever reason, the --shell-fail
option does not give a shell to examine the situation. Maybe it is related
to the bug #832751 (autopkgtest: aborts the entire test run when one test
has unsatisfiable dependencies) but my issue is not about aborting the test,
but that I'm unable to check the situation afterwards.

A current example:
root@sasa:/home/sasa# autopkgtest 
src/debian/syslog-ng/git2/build-area/syslog-ng_3.8.1-5_amd64.changes 
@autopkg_sid.cfg
autopkgtest: DBG: autopkgtest options: Namespace(apt_pocket=[], 
auto_control=True, build_parallel=None, built_binaries=True, copy=[], env=[], 
gainroot=None, installed_click=None, logfile=None, 
output_dir='/tmp/autopkg-output', override_control=None, 
packages=['src/debian/syslog-ng/git2/build-area/syslog-ng_3.8.1-5_amd64.changes'],
 set_lang=None, setup_commands=['(O=$(bash -o pipefail -ec \'apt-get update | 
tee /proc/self/fd/2\') ||{ [ "${O%404*Not Found*}" = "$O" ] || exit 100; sleep 
15; apt-get update; } || { sleep 60; apt-get update; } || false) && $(which 
eatmydata || true) apt-get dist-upgrade -y -o 
Dpkg::Options::="--force-confnew"'], setup_commands_boot=[], shell=False, 
shell_fail=True, summary=None, testname=None, timeout_build=None, 
timeout_copy=None, timeout_factor=1.0, timeout_install=None, 
timeout_short=None, timeout_test=None, user=None, verbosity=2)
autopkgtest: DBG: virt-runner arguments: ['lxc', 'autopkgtest-sid']
autopkgtest: DBG: actions: [('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-core_3.8.1-5_amd64.deb', None), 
('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-dbg_3.8.1-5_amd64.deb', None), 
('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-dev_3.8.1-5_amd64.deb', None), 
('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-add-contextual-data_3.8.1-5_amd64.deb',
 None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-amqp_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-geoip_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-graphite_3.8.1-5_amd64.deb',
 None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-journal_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-json_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-mongodb_3.8.1-5_amd64.deb', 
None), 
 ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-python_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-redis_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-riemann_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-smtp_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-sql_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng-mod-stomp_3.8.1-5_amd64.deb', 
None), ('binary', 
'src/debian/syslog-ng/git2/build-area/syslog-ng_3.8.1-5_all.deb', None), 
('source', 'src/debian/syslog-ng/git2/build-area/syslog-ng_3.8.1-5.dsc', False)]
autopkgtest: DBG: build binaries: False
autopkgtest: DBG: testbed init
autopkgtest [20:51:41]: version 4.2
autopkgtest [20:51:41]: host sasa; command line: /usr/bin/autopkgtest 
src/debian/syslog-ng/git2/build-area/syslog-ng_3.8.1-5_amd64.changes 
@autopkg_sid.cfg
autopkgtest: DBG: got reply from testbed: ok
autopkgtest: DBG: testbed open, scratch=None
autopkgtest: DBG: sending command to testbed: open
WARNING: ext3 signature detected on /dev/lxc/autopkgtest-lxc-dnxvsp at offset 
1080. Wipe it? [y/n]: [n]
  Aborted wiping of ext3.
  1 existing signature left on the device.
autopkgtest: DBG: got reply from testbed: ok 
/tmp/autopkgtest-virt-lxc.shared.lnp59a2q/downtmp
autopkgtest: DBG: sending command to testbed: print-execute-command
autopkgtest: DBG: got reply from testbed: ok 

Bug#841847: libmongoc-dev: Missing include file (mongoc-stream-tls-private.h) from the package

[SZALAY Attila]

Package: libmongoc-dev
Version: 1.4.1-1
Severity: important

Dear Maintainer,

mongoc.h includes mongoc-config.h which define ENABLE_MONGOC_SSL.  Later
mongoc.h, because ENABLE_MONGOC_SSL is defined, includes
mongoc-stream-tls.h, which tries to include mongoc-steam-tls-private.h. But
this file does not exists.

Because of this nothing can be built which needs libmongoc-dev.

See this build log:
https://buildd.debian.org/status/fetch.php?pkg=syslog-ng=mips=3.8.1-4=1476238134


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#840900: zorp: FTBFS (vector: No such file or directory)

[SZALAY Attila]

Hi,

Zorp and libzorpll is highly bonded and therefore it has the same maintainer.

The problem is that I had to upgrade the libzorpll first and only was able to 
start upgrading the Zorp after that. But unfortunatelly I found an issue with 
compiling the Zorp (SSLv3 is removed from openssl), so I reported it upstream 
and now Im waiting while upstrea fix it.

Also, to prevent the issue to happen again, I created a new -dev package, which 
is version dependent. But unfortunately it is not helps in the current case.

This is an unfortunate event, but hopefully it will have been solved before the 
freeze. :)

On 2016. október 20. 11:29:26 CEST, peter green  wrote:
>>
>> I tried to build this package in stretch with "dpkg-buildpackage -A"
>> (which is what the "Arch: all" autobuilder would do to build it)
>> but it failed:
>A few notes on this bug (note: i'm just a derivative maintainer taking
>a 
>quick look at the bug, not a maintainer of this package)
>
>1. It is not specific to building with dpkg-buildpackage -A [1][2]
>2. The actual failure seems to be caused by indirectly including a C++ 
>header while building with a plain C compiler.
>3. There currently appears to be an (apparently uncoordinated)
>libzorpll 
>transition going on which I suspect may be the trigger for this bug.
>
>[1] 
>http://buildd.raspbian.org/status/fetch.php?pkg=zorp=armhf=3.9.5-7.1%2Bb3=1476485016
>[2] 
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/zorp.html

Bug#839603: amanda: The /usr/lib/amanda/amcheck-device command SIGSEGV when called by amcheck

[SZALAY Attila]

Package: amanda-server
Version: 1:3.3.9-1
Severity: normal
File: amanda

Dear Maintainer,

After I upgraded my host this week (I do not know the exact date) I started
to receive an alert message from amanda with the following subject:
"Daily AMANDA PROBLEM: FIX BEFORE RUN, IF POSSIBLE"
Which told me, that:
"amcheck-device terminated with signal 11"

Also, I was able to reproduce the issue with running the amcheck by hand
with the following command line:
"su -s /bin/bash -l -c "ulimit -c unlimited; /usr/sbin/amcheck -m Daily" backup"

Seemingly the daily backup job is running without success (this is while it
is just normal), but not checked throroughly.

The strace show the following:
29840 stat("/backup/amanda/daily/vtapes/drive0/data//0.MyData08", 
{st_mode=S_IFREG|0600, st_size=32768, ...}) = 0
29840 getdents(5, /* 0 entries */, 32768) = 0
29840 close(5)  = 0
29840 lseek(4, 0, SEEK_SET) = 0
29840 write(4, "$STATE = {\n   'drives' => {\n 
'/backup/amanda/daily/vtapes/drive0' => {\n 
  'pid' => 29840\n  
   }\n   },\n   'meta' 
=> undef\n };\n", 317) = 317
29840 close(4)  = 0
29840 write(2, "found in slot 8:", 16)  = 16
29840 write(2, " volume 'MyData08'\n", 19) = 19
29840 write(10, "Sun Oct  2 20:33:32 2016: thd-0x1a4f200: amcheck-device: 
Amanda::Taper::Scan::traditional result: 'MyData08' on 
file:/backup/amanda/daily/vtapes/drive0 slot 8, mode 2\n", 167) = 167
29840 lstat("/backup/amanda/daily/vtapes/drive0/data", {st_mode=S_IFLNK|0777, 
st_size=8, ...}) = 0
29840 unlink("/backup/amanda/daily/vtapes/drive0/data") = 0
29840 rmdir("/backup/amanda/daily/vtapes/drive0") = 0
29840 open("/etc/amanda/Daily/changer", O_RDWR|O_CREAT, 0666) = 4
29840 fcntl(4, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, 
l_len=0}) = 0
29840 fstat(4, {st_mode=S_IFREG|0600, st_size=317, ...}) = 0
29840 read(4, "$STATE = {\n   'drives' => {\n 
'/backup/amanda/daily/vtapes/drive0' => {\n 
  'pid' => 29840\n  
   }\n   },\n   'meta' 
=> undef\n };\n", 317) = 317
29840 lseek(4, 0, SEEK_SET) = 0
29840 write(4, "$STATE = {\n   'drives' => {\n 
'/backup/amanda/daily/vtapes/drive0' => {}\n   },\n 
  'meta' => undef\n };\n", 169) = 169
29840 ftruncate(4, 169) = 0
29840 close(4)  = 0
29840 write(3, "\1\0\0\0\0\0\0\0", 8)   = 8
29840 futex(0x25370c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
29840 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---

And the dbg output is (I cannot find debug symbols neither for perl nor
amanda):
Reading symbols from /usr/bin/perl...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 29840]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/perl /usr/lib/amanda/amcheck-device Daily'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f24ced6e1fb in ?? () from 
/usr/lib/x86_64-linux-gnu/amanda/perl/auto/Amanda/MainLoop/libMainLoop.so
(gdb) bt full
#0  0x7f24ced6e1fb in  () at 
/usr/lib/x86_64-linux-gnu/amanda/perl/auto/Amanda/MainLoop/libMainLoop.so
#1  0x7f24d4975103 in g_timeout_dispatch (source=0x2311c10, 
callback=, user_data=) at ././glib/gmain.c:4672
timeout_source = 0x2311c10
again = 
#2  0x7f24d497468a in g_main_context_dispatch (context=0x25370b0) at 
././glib/gmain.c:3201
dispatch = 0x7f24d49750f0 
prev_source = 0x0
was_in_call = 0
user_data = 0x25d3af0
callback = 0x7f24ced6e090
cb_funcs = 
cb_data = 0x2169e90
need_destroy = 
source = 0x2311c10
current = 0x2309b80
i = 0
#3  0x7f24d497468a in g_main_context_dispatch 
(context=context@entry=0x25370b0) at ././glib/gmain.c:3854
#4  0x7f24d4974a40 in g_main_context_iterate (context=0x25370b0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
././glib/gmain.c:3927
max_priority = 0
timeout = 0
some_ready = 1
nfds = 1
allocated_nfds = 1
fds = 
#5  0x7f24d4974d62 in g_main_loop_run (loop=0x21b42f0) at 
././glib/gmain.c:4123
__func__ = "g_main_loop_run"
#6  0x7f24ced6ebe3 in _wrap_run_c () at 
/usr/lib/x86_64-linux-gnu/amanda/perl/auto/Amanda/MainLoop/libMainLoop.so
#7  0x004c1b30 in Perl_pp_entersub ()
#8  0x004ba106 in Perl_runops_standard ()
#9  0x00442f39 in perl_run ()
#10 

Bug#831908: Re-reading jurnal

[SZALAY Attila]

Hi,

I found an open issue in the upstream github repository which talks about a 
similar problem.

You should consider participating in this issue. 

https://github.com/balabit/syslog-ng/issues/1091

Bug#777979: Unable to reproduce

[SZALAY Attila]

Hi All,

The original issue was a timeout problem during a test case run.
I tried to reproduce the issue within my i386 system and then using the
debian building infrastructure, but without success.

The amd64 build logs:
https://buildd.debian.org/status/fetch.php?pkg=libzorpllarch=amd64ver=3.9.4.1-2stamp=1435531043

The status dashboard:
https://buildd.debian.org/status/package.php?p=libzorpllsuite=experimental


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718121: dh_install problem

[Szalay Attila]

Hi!

On k, 2013-08-20 at 12:18 -0400, Joey Hess wrote:
 Szalay Attila wrote:
  
  dh $@ --with autoreconf --fail-missing
  
  then dh will call all the helper scripts with -O--fail-missing. And
  dh_install does not like this. if I override the dh_install target and
  call the dh_install from it in it's normal way, then it works like a
  charm.

Maybe I wa not clear enough. In my package I worked around this problem
with the following code:

override_dh_install:
dh_install --fail-missing


 I don't see any similarity between that and bug #718121. You are asking
 dh to pass --fail-missing on to dh_install, and the option is,
 presumably, behaving as it's supposed to. 

Ok. I try to be more clear.

dh_install -O--fail-missing do nothing. Not even saying that it will do
nothing.

In other way, dh_install --fail-missing copy files. Which is not a big
suprise, because that is the job of the program.

 Please avoid sending unrelated stuff to RC bug reports in the future.
 Such bug reports are typically read by a lot of people, and adding such
 noise makes them harder to follow.

I do not thing that I sent unrelated thing. my problem is looking very
similar. dh_install wasn't copy ANY files, when it's called trough the
dh. Isn't this bug is about this?

I know what --fail-missing is do. And I use it in the way it should be
used. And I'm able to differentiate the error message about files left
in the tmp area and when dh_install say it could find nothing.

But - which is an other interesting thing - I could not reproduce the
problem in my building machine. So I could not produce evidence. :(


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718121: dh_install problem

[Szalay Attila]

Hi All,

I recognised a very similar problem with one of my package.

I started to rewrite the building procedure to use the dh script. And
when I tried to build my package the first time it failed. The files are
there, only dh_install doesn`t install them.

I played with it a bit and realized that if I add an extra parameter to
dh, for example like this:

dh $@ --with autoreconf --fail-missing

then dh will call all the helper scripts with -O--fail-missing. And
dh_install does not like this. if I override the dh_install target and
call the dh_install from it in it's normal way, then it works like a
charm.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713052: ITP: kzorp -- KZorp is kernel space helper for application level gateways, especially Zorp

[SZALAY Attila]

Package: wnpp
Severity: wishlist
Owner: SZALAY Attila s...@debian.org

* Package name: kzorp
  Version : 0.1.0
  Upstream Author : BalaBit IT LTd.
* URL : https://github.com/balabit/kzorp
* License : GPL
  Programming Lang: C, Python
  Description : KZorp is kernel space helper for application level 
gateways, especially Zorp

Kzorp is a open source set of mechanisms to implement mixed packet
filter/application level gateway functionality on Linux.
Kzorp is used by Zorp, and anyone is welcome to use it with other gateways.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#601991: zorp: file conflict [...]

[SZALAY Attila]

Hi All!

On Tue, 2010-11-02 at 17:16 +, Marcos Marado wrote:
 Am I wrong in assuming that the only issue here is that there's a
Replaces: libzorp2
Breaks: libzorp2
 missing?

Yes. You are right.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#513572: syslog-ng: Segfaults on HUP when 2 sources use udp()

[SZALAY Attila]

Hi!

On Fri, 2009-01-30 at 11:20 +, David Sheldon wrote:
 
 If you have 2 sources configured in your /etc/syslog-ng/syslog-ng.conf that 
 reference udp() then it will segfault when it recieves a HUP. This happens
 whenever the logs are rotated, thus leaving you without logging.
 
 To reproduce:
 
 Create your syslog-ng.conf file as:
 source s_network_1 {
 udp();
 };
 source s_network {
 udp();
 };

I will send it to upstream, but this is not a valid config. Not valid in
the meaning that you try to start two listener in one port. It will not
work reliably.




smime.p7s
Description: S/MIME cryptographic signature

Bug#511006: opensync-plugin-google-calendar: Failed to sync into goole because of a missing attribute

[SZALAY Attila]

Package: opensync-plugin-google-calendar
Version: 0.22-6
Severity: grave
Justification: renders package unusable

When I try to syncronize the calendar event and there are a missing event in
the google part it cannot send it. It's stop with the following error:

add gdata: ?xml version=1.0 encoding=utf-8?
entry xmlns=http://www.w3.org/2005/Atom; 
xmlns:gd=http://schemas.google.com/g/2005;title 
type=textIkeedo/titlecontent type=text/contentgd:when 
endTime=2009-01-06T17:30:00 startTime=2009-01-06T17:30:00/gd:where 
valueString=//entry
Traceback (most recent call last):
  File /usr/lib/opensync/google-cal-helper, line 453, in module
sys.exit(main(sys.argv))
  File /usr/lib/opensync/google-cal-helper, line 445, in main
return fn(argv)
  File /usr/lib/opensync/google-cal-helper, line 422, in oper_add
e = GCalEntry(atom=xml.documentElement)
  File /usr/lib/opensync/google-cal-helper, line 187, in __init__
self.parseAtom(atom)
  File /usr/lib/opensync/google-cal-helper, line 196, in parseAtom
self.editUri = self.elementValue('atom:li...@rel=edit]/@href')
  File /usr/lib/opensync/google-cal-helper, line 294, in elementValue
nodes = self.query(name)
  File /usr/lib/opensync/google-cal-helper, line 302, in query
return XPath.Evaluate(expr, context=ctx)
  File /usr/lib/python2.5/site-packages/Ft/Xml/XPath/Util.py, line 188, in 
Evaluate
retval = XPathParser.new().parse(expr).evaluate(con)
  File 
/usr/lib/python2.5/site-packages/Ft/Xml/XPath/ParsedRelativeLocationPath.py, 
line 18, in evaluate
nodeset = self._left.select(context)
  File /usr/lib/python2.5/site-packages/Ft/Xml/XPath/ParsedStep.py, line 30, 
in evaluate
node_set = self._predicates.filter(node_set, context, reverse)
  File /usr/lib/python2.5/site-packages/Ft/Xml/XPath/ParsedPredicateList.py, 
line 43, in filter
res = pred.evaluate(context)
  File /usr/lib/python2.5/site-packages/Ft/Xml/XPath/ParsedExpr.py, line 721, 
in evaluate
left = self._left.evaluate(context)
  File /usr/lib/python2.5/site-packages/Ft/Xml/XPath/ParsedStep.py, line 28, 
in evaluate
(node_set, reverse) = self._axis.select(context, self._nodeTest.match)
  File /usr/lib/python2.5/site-packages/Ft/Xml/XPath/ParsedAxisSpecifier.py, 
line 94, in select
result = [ attr for attr in context.node.xpathAttributes
AttributeError: Element instance has no attribute 'xpathAttributes'

My system is upgraded from etch where I installed opensynxml from third
party places. So I'm not sure that all my packages is from lenny.


-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages opensync-plugin-google-calendar depends on:
ii  libc6  2.7-16GNU C Library: Shared libraries
ii  libglib2.0-0   2.16.6-1  The GLib library of C routines
ii  libopensync0   0.22-etch2Synchronisation framework for emai
ii  libxml22.6.32.dfsg-5 GNOME XML library
ii  python 2.5.2-3   An interactive high-level object-o
ii  python-4suite-xml  1.0.2-5   An open-source platform for XML an
ii  python-httplib20.2.0-2   A comprehensive HTTP client librar

opensync-plugin-google-calendar recommends no packages.

opensync-plugin-google-calendar suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#482981: Processed: severity of 482981 is serious

[Szalay Attila]

Hi All!

On Thu, 2008-07-24 at 10:39 +, Debian Bug Tracking System wrote:
 Processing commands for [EMAIL PROTECTED]:
 
  # Automatically generated email from bts, devscripts version 2.10.28
  severity 482981 serious
 Bug#482981: Please compile with --enable-dynamic-linking
 Severity set to `serious' from `minor'

Maybe I'm too ignorant, but I do not think that compiling syslog-ng with
static libraries is a serious bug.

I'm not thinking that this thing is a bug at all.

In my opinion a program which stays in /sbin as a humble system logging
daemon should, should not depend on libraries in the /usr directory.

And yes, I know that if a library compiled statically into a program
that may cause problem, when a bug found in that library bat in my
opinion in this situation the static compiling is the lesser bad thing.



smime.p7s
Description: S/MIME cryptographic signature

Bug#477289: openoffice.org: OpenOffice.Org hang when try to save-as or export a file opened from samba share

[SZALAY Attila]

Package: openoffice.org
Version: 2.0.4.dfsg.2-7etch5
Severity: grave
Justification: causes non-serious data loss

It's may cause data loss, because I couldn't save my changes.

The problem is, that openoffice  (gnome vfs exactly) try to free an invalid 
pointer. Maybe just in an 64 bit environment.

This only happen when I upgraded from security branch.

*** glibc detected *** free(): invalid pointer: 0x2d21c000 ***

Program received signal SIGABRT, Aborted.
[Switching to Thread 47097076774832 (LWP 12135)]
0x2ad5a263c07b in raise () from /lib/libc.so.6
(gdb) bt
#0  0x2ad5a263c07b in raise () from /lib/libc.so.6
#1  0x2ad5a263d84e in abort () from /lib/libc.so.6
#2  0x2ad5a26725f9 in __libc_message () from /lib/libc.so.6
#3  0x2ad5a2679163 in _int_free () from /lib/libc.so.6
#4  0x2ad5a26791ee in free () from /lib/libc.so.6
#5  0x2d386459 in gnome_vfs_file_info_clear (info=0x7fff0b22ee60) at 
gnome-vfs-file-info.c:134
#6  0x2d384370 in gnome_vfs_directory_read_next (handle=0x1dd57f0, 
file_info=0x7fff0b22ee60) at gnome-vfs-directory.c:209
#7  0x2d239fb7 in gvfs::DataSupplier::getData () from 
/usr/lib/openoffice/program/ucpgvfs1.uno.so
#8  0x2d23a3b6 in gvfs::DataSupplier::getResult () from 
/usr/lib/openoffice/program/ucpgvfs1.uno.so
#9  0x2ad5a0c70cdf in ucb::ResultSet::next () from 
/usr/lib/openoffice/program/libucbhelper3gcc3.so
#10 0x2ad5a036c954 in 
svt::FileViewContentEnumerator::enumerateFolderContent () from 
/usr/lib/openoffice/program/libsvt680lx.so
#11 0x2ad5a0378618 in SvtFileView_Impl::GetFolderContent_Impl () from 
/usr/lib/openoffice/program/libsvt680lx.so
#12 0x2ad5a03789e4 in SvtFileView_Impl::GetFolderContent_Impl () from 
/usr/lib/openoffice/program/libsvt680lx.so
#13 0x2ad5a0378b92 in SvtFileView::Initialize () from 
/usr/lib/openoffice/program/libsvt680lx.so
#14 0x2aaab5f55b28 in svt::AsyncPickerAction::execute () from 
/usr/lib/openoffice/program/fps_office.uno.so
#15 0x2aaab5f6b21d in SvtFileDialog::executeAsync () from 
/usr/lib/openoffice/program/fps_office.uno.so
#16 0x2aaab5f6b379 in SvtFileDialog::OpenURL_Impl () from 
/usr/lib/openoffice/program/fps_office.uno.so
#17 0x2aaab5f73cca in SvtFileDialog::Execute () from 
/usr/lib/openoffice/program/fps_office.uno.so
#18 0x2aaab5f5e0e4 in SvtFilePicker::implExecutePicker () from 
/usr/lib/openoffice/program/fps_office.uno.so
#19 0x2aaab5f57350 in svt::OCommonPicker::execute () from 
/usr/lib/openoffice/program/fps_office.uno.so
#20 0x2aaab5f5c96d in SvtFilePicker::execute () from 
/usr/lib/openoffice/program/fps_office.uno.so
#21 0x2e939c1e in sfx2::FileDialogHelper_Impl::implDoExecute () from 
/usr/lib/openoffice/program/libsfx680lx.so
#22 0x2e93a198 in sfx2::FileDialogHelper_Impl::execute () from 
/usr/lib/openoffice/program/libsfx680lx.so
#23 0x2e93b48d in sfx2::FileDialogHelper::Execute () from 
/usr/lib/openoffice/program/libsfx680lx.so
#24 0x2e87a401 in ModelData_Impl::OutputFileDialog () from 
/usr/lib/openoffice/program/libsfx680lx.so
#25 0x2e87f126 in SfxStoringHelper::GUIStoreModel () from 
/usr/lib/openoffice/program/libsfx680lx.so
#26 0x2e818ccc in SfxObjectShell::ExecFile_Impl () from 
/usr/lib/openoffice/program/libsfx680lx.so
#27 0x2e8e42f4 in SfxShell::ExecuteSlot () from 
/usr/lib/openoffice/program/libsfx680lx.so
#28 0x2e8d2eff in SfxDispatcher::Call_Impl () from 
/usr/lib/openoffice/program/libsfx680lx.so
#29 0x2e8c7943 in SfxBindings::Execute_Impl () from 
/usr/lib/openoffice/program/libsfx680lx.so
#30 0x2e8f0103 in SfxDispatchController_Impl::dispatch () from 
/usr/lib/openoffice/program/libsfx680lx.so
#31 0x2e8f0a79 in SfxOfficeDispatch::dispatch () from 
/usr/lib/openoffice/program/libsfx680lx.so
#32 0x2f332d74 in framework::MenuBarManager::Select () from 
/usr/lib/openoffice/program/libfwk680lx.so
#33 0x2ad59fbbe506 in Menu::Select () from 
/usr/lib/openoffice/program/libvcl680lx.so
#34 0x2ad59fbb9a95 in Menu::ImplCallSelect () from 
/usr/lib/openoffice/program/libvcl680lx.so
#35 0x2ad59fc1b958 in ImplWindowFrameProc () from 
/usr/lib/openoffice/program/libvcl680lx.so
#36 0x2ad5a65a1d45 in SalDisplay::DispatchInternalEvent () from 
/usr/lib/openoffice/program/libvclplug_gen680lx.so
#37 0x2ad5a49bf668 in GtkXLib::userEventFn () from 
/usr/lib/openoffice/program/libvclplug_gtk680lx.so
#38 0x2ad5a63d8913 in IA__g_main_context_dispatch (context=0x592360) at 
gmain.c:2045
#39 0x2ad5a63db75d in g_main_context_iterate (context=0x592360, block=0, 
dispatch=1, self=value optimized out) at gmain.c:2677
#40 0x2ad5a63dbc7e in IA__g_main_context_iteration (context=0x592360, 
may_block=0) at gmain.c:2736
#41 0x2ad5a49c1078 in GtkXLib::Yield () from 
/usr/lib/openoffice/program/libvclplug_gtk680lx.so
#42 0x2ad59fa53330 in Application::Yield () from 

Bug#477289: Save-as problem

[Szalay Attila]

Hi!

I downgraded to the version 2.0.4.dfsg.2-7etch4 but the problem
remains. :(

-- 
Szalay Attila BalaBit IT Biztonságtechnikai Kft.
tel:(36-1)-371-05-40  HU-1115 Budapest, Bártfai u. 54
fax:(36-1)-208-08-75  http://www.balabit.hu/

Bug#477289: openoffice.org: OpenOffice.Org hang when try to save-as or export a file opened from samba share

[Szalay Attila]

On Tue, 2008-04-22 at 12:38 +0200, Rene Engelhard wrote:
 
  It's may cause data loss, because I couldn't save my changes.
 
 Err, not true. I believe you could save locally and move it to the smb
 share later?

No, I couldn't. The save-as windows is not able to appear.

  The problem is, that openoffice  (gnome vfs exactly) try to free an invalid 
  pointer. Maybe just in an 64 bit environment.
 
 And if you think libgnome-vfs is at fault why are you filing this
 against openoffice.org?

Because OpenOffice call it with wrong parameters. The file_info pointer
is seems to be wrong. And it's come from the openoffice side.

(gdb) frame 5
#5  0x2d386459 in gnome_vfs_file_info_clear (info=0x7fff0b22ee60) at 
gnome-vfs-file-info.c:134
134 in gnome-vfs-file-info.c
(gdb) p *info
$1 = {name = 0x0, valid_fields = 2701486917, type = 10965, permissions = 
186838880, flags = 32767, device = 30577888, inode = 30649040,
  link_count = 31360160, uid = 0, gid = 2904678872, size = 6906512, block_count 
= 11018464, io_block_size = 1208504, atime = 0, mtime = 31360240,
  ctime = 30577888, symlink_name = 0x1d3aad0 , mime_type = 0x2d21c000 
\177ELF\002\001\001, refcount = 2676487825, reserved1 = 0x2ad50001,
  reserved2 = 0x0, reserved3 = 0x7fff0b22f140, reserved4 = 0x2ad5a05c1ad8, 
reserved5 = 0x2d21e1d8}


  This only happen when I upgraded from security branch.
 
 And there were *NO* changes to any component affecting gnome-vfs in
 7etch5.

It's TRUE.

  0x2ad5a263c07b in raise () from /lib/libc.so.6
  (gdb) bt
  #0  0x2ad5a263c07b in raise () from /lib/libc.so.6
  #1  0x2ad5a263d84e in abort () from /lib/libc.so.6
  #2  0x2ad5a26725f9 in __libc_message () from /lib/libc.so.6
  #3  0x2ad5a2679163 in _int_free () from /lib/libc.so.6
  #4  0x2ad5a26791ee in free () from /lib/libc.so.6
 
 glibc
 
  #5  0x2d386459 in gnome_vfs_file_info_clear (info=0x7fff0b22ee60) 
  at gnome-vfs-file-info.c:134
  #6  0x2d384370 in gnome_vfs_directory_read_next (handle=0x1dd57f0, 
  file_info=0x7fff0b22ee60) at gnome-vfs-directory.c:209
 
 libgnome-vfs
 
  #7  0x2d239fb7 in gvfs::DataSupplier::getData () from 
  /usr/lib/openoffice/program/ucpgvfs1.uno.so

I think the problem is, that in this function a local variable is
corrupted.

-- 
Szalay Attila BalaBit IT Biztonságtechnikai Kft.
tel:(36-1)-371-05-40  HU-1115 Budapest, Bártfai u. 54
fax:(36-1)-208-08-75  http://www.balabit.hu/

Bug#461238: syslog-ng: Please update to 2.0.7

[Szalay Attila]

Hi!

On Thu, 2008-01-17 at 10:52 -0500, Micah Anderson wrote:
 
 2.0.6 was considered a 'brown-bag' release and 2.0.7 was released quite
 quickly afterwards, in a matter of a day or so.

Ehm. What does 'brown-bag' means?

But anyway I want to wait a little becouse of two thing.

First there is a serious bug in 2.0.7 so I don't want to upgrade into
that version right now.

Second I want to wait till the 2.0.6 goes to testig.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#449569: Please include syslog-ng_anon patch

[SZALAY Attila]

Hi!

I have a few question about this patch.

On Tue, 2007-11-06 at 13:46 -0500, Micah Anderson wrote: 
 diff -Naur syslog-ng-2.0.5.orig/src/filter.c syslog-ng-2.0.5/src/filter.c
 --- syslog-ng-2.0.5.orig/src/filter.c   2007-05-21 19:21:07.0 +0200
 +++ syslog-ng-2.0.5/src/filter.c2007-11-03 00:30:22.0 +0100
 @@ -226,6 +226,7 @@
  typedef struct _FilterRE
  {
FilterExprNode super;
 +  GString *replace;
regex_t regex;
  } FilterRE;
  
 @@ -310,6 +311,9 @@
  filter_re_free(FilterExprNode *s)
  {
FilterRE *self = (FilterRE *) s;
 +
 +  if (self-replace != NULL)
 + g_string_free(self-replace, TRUE);

regfree(self-regex);
g_free(s);
 @@ -494,3 +498,89 @@
self-super.eval = filter_netmask_eval;
return self-super;
  }
 +
 +FilterExprNode *
 +filter_strip_new(const gchar *re)
 +{
 +   if (g_ascii_strcasecmp(re, ips) == 0)
 +   return filter_replace_new(re, 0.0.0.0);
 +   return filter_replace_new(re, );
 +}
 +
 +#define FMIN(a, b) (a)  (b) ? (a) : (b)

Is there any difference between this macro and the MIN macro define in
glib?
(http://library.gnome.org/devel/glib/unstable/glib-Standard-Macros.html#MIN:CAPS)

 +#define NEW_MSG_SIZE 2048

Is there a reason to limit new message size to 2048 bytes?

 +
 +static gboolean
 +filter_replace_eval(FilterExprNode *s, LogMessage *log)
 +{
 +  FilterRE *self = (FilterRE *) s;
 +  gchar *buffer = log-msg.str;
 +  gint snippet_size;
 +  regmatch_t pmatch;
 +  gchar new_msg[NEW_MSG_SIZE];
 +  gchar *new_msg_max = new_msg + NEW_MSG_SIZE;
 +  gchar *new_msg_ptr = new_msg;
 +  gint replace_length = self-replace-len;
 +  gint error;
 +
 +  error = regexec(self-regex, buffer, 1, pmatch, 0);
 +  if (error)
 +return TRUE;
 +  while (!error)
 +{
 +  /* copy string snippet which preceeds matched text */
 +  snippet_size = FMIN(pmatch.rm_so, new_msg_max - new_msg_ptr);
 +  memcpy(new_msg_ptr, buffer, snippet_size);
 +  new_msg_ptr += snippet_size;
 +   
 +  /* copy replacement */
 +  snippet_size = FMIN(replace_length, new_msg_max - new_msg_ptr);
 +  memcpy(new_msg_ptr, self-replace-str, snippet_size);
 +  new_msg_ptr += snippet_size;
 +   
 +  /* search for next match */
 +  buffer += pmatch.rm_eo;
 +  error = regexec(self-regex, buffer, 1, pmatch, REG_NOTBOL);
 +}

Why do You not use GString and g_string_append_len?

 +   
 +  /* copy the rest of the old message */
 +  snippet_size = log-msg.len - (buffer - log-msg.str) + 1;
 +  snippet_size = FMIN(snippet_size, new_msg_max - new_msg_ptr);
 +  memcpy(new_msg_ptr, buffer, snippet_size);
 +  new_msg[NEW_MSG_SIZE-1] = '\0';
 +   
 +  g_string_erase((log-msg), 0, -1);

I think g_string_truncate is faster and explain more the intended
feature (to me). 

 +  g_string_append((log-msg), new_msg);
 +   
 +  return TRUE;
 +}
 +   
 +FilterExprNode *
 +filter_replace_new(const gchar *re, const gchar *replacement)
 +{
 +  FilterRE *self = g_new0(FilterRE, 1);
 +  gint regerr;
 +   
 +  if (!g_ascii_strcasecmp(re, ips))
 +re = 
 (25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])([\\.\\-](25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])){3};
 +   
 +  regerr = regcomp(self-regex, re, REG_ICASE | REG_EXTENDED);
 +  if (regerr)
 +{
 +  gchar errorbuf[256];
 +  regerror(regerr, self-regex, errorbuf, sizeof(errorbuf));
 +  msg_error(Error compiling regular expression:,
 +evt_tag_str(re, re),
 +evt_tag_str(error, errorbuf),
 +NULL);
 +  g_free(self);
 +  return NULL;
 +}
 +   
 +  self-replace = g_string_new(replacement);
 +  self-super.eval = filter_replace_eval;
 +  self-super.free_fn = filter_re_free;
 +   
 +  return self-super;
 +}
 +




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#436521: Does not stop syslog-ng upon removal

[SZALAY Attila]

Hi!

On Wed, 2007-08-08 at 04:31 +0200, Michael Biebl wrote:
 
 The best way to handle this is, to let dh_installinit take care of that.

I wouldn't like if the system logging is stopped when I upgrade. This is
the reason why I turn off dh_installinit.

But I'm going to search a solution.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#436521: Does not stop syslog-ng upon removal

[SZALAY Attila]

Hi!

On Sun, 2007-10-21 at 17:52 +0200, Michael Biebl wrote:
 
 I guess dh_installinit --no-restart-on-upgrade is what you are looking
 for then.
 It stops syslog upon removal (in prerm), and starts it upon installation
   (in postinst).

My experiment say someting else. I have tried all three way of
--no-start an --no-restart-on-upgrade but I couldn't find the right
setup. But I will continue the search.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#429273: syslog-ng fails to create pid file on boot

[SZALAY Attila]

Hi!

On Sat, 2007-06-16 at 20:24 +0200, David Geier wrote:
 
 When booting the system, syslog-ng does not create a pid file. This works 
 fine when invoked from shell.

Hmm. Interesting.

Could you send me the /etc/fstab, the /proc/mounts files and the listing
of the /etc/rc2.d directory?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427791: syslog-ng dies after cron.daily

[Szalay Attila]

Hi!

On Wed, 2007-06-06 at 11:34 +0100, Chris Taylor wrote:
 
 When trying to reproduce it manually, sending kill -HUP causes syslog-ng 
 to die shortly after it gets a new PID.
 I am able to consistently reproduce this.
 No data is written to the new logfile until I manually restart syslog-ng

Could you do it again and in the same time strace-ing the syslog-ng?
(strace -fo output -s 512 -p `pidof syslog-ng`) And after it please send
the output to me.

Thanks.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#428424: syslog-ng : numerous facilities are ignored after upgrade to Etch

[Szalay Attila]

Hi!

On Mon, 2007-06-11 at 18:16 +0200, Vincent LOUPIEN wrote:
 
 After an normal upgrade Sarge (stable) to Etch (Stable), all log (local and 
 remote) recevied via syslog services goes into /var/log/syslog as a result 
 and not to her log file destination. 

Could you send me (maybe in private) the config file which you use?

It would be even better if you could start syslog-ng by hand with
syslog-ng -d -e -F and /tmp/log 21. Then wait for some log and after
it send the /tmp/log file to me with the config file.

Thanks.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#398640: syslog-ng: Uninstallable on hurd-i386: util-linux Depends

[SZALAY Attila]

Hi All,

On Tue, 2006-11-14 at 18:45 +0100, Michael Banck wrote:
 
 syslog-ng builds fine on the Hurd, but it is uninstallable due to the
 versioned Dependency on util-linux (= 2.12-10).  Can you tell me what
 the reason for the Depends is, so that we can maybe find a different
 solution on hurd-i386?

This dependency has been added by an NMU because of a lintian error:

E: syslog-ng: depends-on-essential-package-without-using-version
depends: util-linux

I think that a better fix for this error is to remove util-linux
dependency. I'm going to do this in the nex release.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#384021: Syslog-ng dies whenever the network connection is broken

[SZALAY Attila]

On Sun, 2006-11-05 at 15:22 +0100, Christoph Biedl wrote:
 
 The problem is _not_ gone I'm afraid.

First of all, I think syslog-ng isn't die whenever network conection
broken. But you are right, not starting.

Bazsi wrote a patch today to fix it. I will upload the new version
before the weekend.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#384802: type of /dev/log

[SZALAY Attila]

Hi!

So, what do you want to gain from this change?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#357345: Information needed

[SZALAY Attila]

Hi!

Sorry for the late reaction.

I think a lot about this bug but I couldn't find the answer to the
question Why. And I couldn't reproduce it either.

Maybe could you send the config file? Or I have to close this bug as an
unreproducable bug.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#384021: Syslog-ng dies whenever the network connection is broken

[SZALAY Attila]

Hi!

On Sun, 2006-11-05 at 17:47 +0100, Christoph Biedl wrote:
 
 But _please_ bring this matter to the upstream. The bug is still present
 in the recently released syslog-ng 2.0.0.

Tomorrow I will say it to him. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#393875: syslog-ng 2.0 dies quiet after cron.daily

[SZALAY Attila]

Hi!

Do you log through network? (Or with other word do you have tcp or
especially udp destination?)

If yes, maybe this bug is your problem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384021

And if it is TRUE, Bazsi have fixed it.

-- 
Szalay Attila BalaBit IT Biztonságtechnikai Kft.
tel:(36-1)-371-05-40  HU-1115 Budapest, Bártfai u. 54
fax:(36-1)-208-08-75  http://www.balabit.hu/

Bug#384021: Syslog-ng dies whenever the network connection is broken

[SZALAY Attila]

Hi!

On Tue, 2006-10-24 at 00:19 +0200, Michael Tautschnig wrote:
 Apart from syslog-ng not starting (or rather immediately dying) at system 
 bootup
 in case the network connection is not yet available, it dies whenever the
 connection to the server is broken.

I have seen a patch in Bazsi's commit log which commited today and I
think related to this bug. I'm going to create a new package today or at
latest tomorrow.

-- 
Szalay Attila BalaBit IT Biztonságtechnikai Kft.
tel:(36-1)-371-05-40  HU-1115 Budapest, Bártfai u. 54
fax:(36-1)-208-08-75  http://www.balabit.hu/

Bug#384802: unix-dgram or unix-stream

[SZALAY Attila]

Hi!

On Fri, 2006-09-22 at 20:33 +0200, Marco d'Itri wrote:
 reopen 384802
 thanks
 
 On Sep 22, SZALAY Attila [EMAIL PROTECTED] wrote:
  Not exactly.
  If you use only the syslog(3) function, you are right, but if you open a
  connection to syslog with openlog(3) in the begining of your application
  then you will be in trouble when syslog-ng listen in unix-dgram and have
  been reloaded. At least with the version 1.6.X of syslog-ng.
 No. As you can verify using the attached program, the same system calls
 are used no matter if you use openlog(3) or not.

Yes, but in libc6 set a global variable when openlog called. (The fd
to /dev/log)

  It's possible that in version 2.0 the syslog-ng could keep unix-dgram
  connections between reload, but I'm too conservative to change it. (If
 There are no connections, datagram sockets are connectionless.

Yes, there are. In normal way (tcp/ip) that connection is virtual, but
in unix type socket there are no such type of connectionless socket.

  you read the Changelog you could recognize the time when I
  changes /dev/log from unix-stream to unix-dgram. And the funny thins
  _is_ that because of this change I have to restart every daemon which
  send log messages. Because the running daemons couldn't recognize that
  unix-dgram /dev/log is no more.
 Looks like your troubles were unrelated.
 It can be easily verified using the attached test program, which creates
 a datagram socket, that when the syslog daemon is restarted while it is
 running the socket is reopened:

I don't think so, just the libc6 is upgraded after that time.


 This does not justify closing the bug.

Hmm. I don't want to close the bug.

Anyway. What is the advantage of unix-dgram against unix-stream for you?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#384802: unix-dgram or unix-stream

[SZALAY Attila]

Hi,

On Wed, 2006-09-20 at 23:44 +0200, Marco d'Itri wrote:

 I do not understand. Datagram sockets are connectionless, and our
 default syslog daemon appears to cope with them.

Not exactly.

If you use only the syslog(3) function, you are right, but if you open a
connection to syslog with openlog(3) in the begining of your application
then you will be in trouble when syslog-ng listen in unix-dgram and have
been reloaded. At least with the version 1.6.X of syslog-ng.

It's possible that in version 2.0 the syslog-ng could keep unix-dgram
connections between reload, but I'm too conservative to change it. (If
you read the Changelog you could recognize the time when I
changes /dev/log from unix-stream to unix-dgram. And the funny thins
_is_ that because of this change I have to restart every daemon which
send log messages. Because the running daemons couldn't recognize that
unix-dgram /dev/log is no more.

So, the thruth is that I'm not too brave to do this change. (I have to
test a lot of daemons, before I could accept this change back.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#289235: Place of the news log file

[SZALAY Attila]

Hi All!

There is something what I doesn't understand related to this bug.

Some relevant peaces from the config file:

# these files are meant for the news system, and are kept separated
# because they should be owned by news instead of root
destination df_news_dot_notice { file(/var/log/news/news.notice 
owner(news)); };
destination df_news_dot_err { file(/var/log/news/news.err owner(news)); };
destination df_news_dot_crit { file(/var/log/news/news.crit owner(news)); };

# news.crit   /var/log/news/news.crit
log {
source(s_all);
filter(f_news);
filter(f_at_least_crit);
destination(df_news_dot_crit);
};

# news.err/var/log/news/news.err
log {
source(s_all);
filter(f_news);
filter(f_at_least_err);
destination(df_news_dot_err);
};

# news.notice /var/log/news/news.notice
log {
source(s_all);
filter(f_news);
filter(f_at_least_notice);
destination(df_news_dot_notice);

So it have to save logs for news system into /var/log/news/news.*

Hmmm.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#324818: this bug in other apps

[Szalay Attila]

Hi All!

I think, I found this bug in other apps too. Especially in evolution
(either in message viewing and message writing) and in mozilla too.

I only see from my letter the ``Hi'', ``I'', ``evolution'' and ``too.''
words. Funny.

But if I select something, the the whole lines appears. And If I
deselect it then the line stays visible untill scrolled out. Funny.

-- 
Szalay Attila BalaBit IT Biztonságtechnikai Kft.
tel:(36-1)-371-05-40  HU-1115 Budapest, Bártfai u. 54
fax:(36-1)-208-08-75  http://www.balabit.hu/

Bug#332554: Bug status

[SZALAY Attila]

Hi!

On Tue, 2006-07-18 at 08:17 -0700, [EMAIL PROTECTED] wrote:
 
 What is the status of this bug?  Has it been fixed in unstable?
 I'm using 1.6.5-2.2 on sarge and I'm seeing this problem with
 log messages from NetScreen devices.  syslog-ng is logging the
 null character at the end of the message so it's breaking all
 of my scripts that analyse our logs.

Somebody has found that the Debian patch cause the problem, but I don't
think so that release manager accept the patch for it to mainline.

I have tried it with another bug but I have failed.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#356616: sensord: repeat alarm message to syslog and screen

[SZALAY Attila]

Hi!

Sorry for the late answer.

I have to ask for your syslog configuration. Could you send me it,
please?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#345157: [PATCH] Sys::Syslog: remove NULL

[SZALAY Attila]

Hi,

On Wed, 2006-04-05 at 01:22 +1000, Brendan O'Dea wrote:
 
 syslog-ng maintainer:  I think that the program needs to be more liberal
 in what it accepts--remove non-printing chars (such as \0) and add \n if
 required.

syslog-ng do remove non-printing chars (such as \0).

But.

How could syslog-ng recognise end of the log message if there are no
sign of it?

In dgram mode there is an out-of-band mark (end of the _packet_), but in
stream mode there aren't any. Just in-band (ie. \n or \0)

So?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#345157: [PATCH] Sys::Syslog: remove NULL

[Szalay Attila]

Hi,

On Wed, 2006-04-05 at 18:32 +0200, SZALAY Attila wrote:
 
 syslog-ng do remove non-printing chars (such as \0).

Or at least it have to. :))

-- 
Szalay Attila BalaBit IT Biztonságtechnikai Kft.
tel:(36-1)-371-05-40  1116 Bp. Csurgoi ut 20/b
fax:(36-1)-208-08-75  http://www.balabit.hu/

Bug#357071: few non debug facilities matchs debug

[Szalay Attila]

Hi!

On sze, 2006-03-15 at 16:43 +0100, General Stone wrote:
 
 There are few non debug facilities which will match the debug facility
 in syslog-ng :-/
 
 Logs of 'named', 'sudo', 'ddclient' are some of the examples.

Could you please do some test with the configuration what Bazsi wrote in
the bug #350344? Because neither I nor the upstream author could
reproduce this problem. :(

Thanks.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#349697: syslog-ng: Logs infinitely the same message when priority is crit

[SZALAY Attila]

Hi!

On Tue, 2006-01-24 at 19:20 +0100, Laurent CARON wrote:
 
 When an event of priority crit is logged it is repeated until
 /var/log/syslog reaches 2Gb (2048Mb), and then the syslog-ng process
 dies.

Could you send me a small :)) part of the log file and the config? Is
there any difference between a good machine and the bad one?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#349697: syslog-ng: Logs infinitely the same message when priority is crit

[SZALAY Attila]

Hi!

On Wed, 2006-01-25 at 09:27 +0100, Laurent CARON wrote:
 #
 # filter f_attention { level(err .. emerg); };
 destination buckrogers { udp(buckrogers); };
 log { source(s_all); filter(f_attention); destination(buckrogers); };
 #

The problem is with the destination above. Sadly syslog-ng 1.9 cannot
resolve host names, so you can only use address not host name.

And because of this (and with kernel magic) all messages to this
destionation goes to 127.0.0.1 and syslog-ng will read it again. :(

I put this into the inner bug system with ticket ID 8174.

I don't close this bug, but I going to lover it's severity a bit if you
accept it. (This only can happen if you listen in wild and try to send
somewhere too.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#337652: ITP: libzorpll3.0.6 -- Low level library functions for Zorp

[SZALAY Attila]

Package: wnpp
Severity: wishlist
Owner: SZALAY Attila [EMAIL PROTECTED]

* Package name: libzorpll3.0.6
  Version : 3.0.6.2
  Upstream Author : Scheidler Balázs [EMAIL PROTECTED]
* URL : http://www.balabit.hu/downloads/zorp/libzorpll-src/
* License : GNU/GPL + permission to use OpenSSL
  Description : Low level library functions for Zorp

 Zorp is a new generation firewall. It is essentially a transparent proxy
 firewall, with strict protocol analyzing proxies, a modular architecture,
 and fine-grained control over the mediated traffic. Configuration decisions
 are scriptable with the Python based configuration language.
 .
 This package contains low level library functions needed by Zorp and
 associated programs.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.18
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Bug#337654: ITP: libevt0 -- Syslog event logger library

[SZALAY Attila]

Package: wnpp
Severity: wishlist
Owner: SZALAY Attila [EMAIL PROTECTED]

* Package name: libevtlog0
  Version : 0.2.3+20051031
  Upstream Author : Scheidler Balazs [EMAIL PROTECTED]
* URL : http://www.balabit.hu/downloads/syslog-ng/1.9/src/
* License : BSD
  Description : Syslog event logger library

 The EventLog library aims to be a replacement of the simple syslog() API
 provided on UNIX systems. The major difference between EventLog and syslog
 is that EventLog tries to add structure to messages.
 .
 EventLog provides an interface to build, format and output an event record.
 The exact format and output method can be customized by the administrator
 via a configuration file.
 .
 This package is the runtime part of the library.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.18
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#337705: ITP: libzorpll3.0.6-dbg -- Low level library functions for Zorp, debug version

[SZALAY Attila]

Package: wnpp
Severity: wishlist
Owner: SZALAY Attila [EMAIL PROTECTED]

* Package name: libzorpll3.0.6-dbg
  Version : 3.0.6.4
  Upstream Author :  Scheidler Balázs [EMAIL PROTECTED]
* URL : http://www.balabit.hu/downloads/zorp/
* License : GNU/GPL + permission to use OpenSSL
  Description : Low level library functions for Zorp, debug version

 Zorp is a new generation firewall. It is essentially a transparent proxy
 firewall, with strict protocol analyzing proxies, a modular architecture,
 and fine-grained control over the mediated traffic. Configuration decisions
 are scriptable with the Python based configuration language.
 .
 This package contains the same library as libzorpll but with debugging code
 enabled.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.18
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Bug#332796: syslog-ng: error handling is more subtle than I thought

[Szalay Attila]

On v, 2005-10-09 at 19:38 +0100, Roland Turner wrote:
 
  but still believe
 using --exec with --stop is unadvisable because it'll prevent
 a restart after an upgrade.

I know it and I have fixed it in version 1.6.5-3 already in
proposed-updates.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#327029: Non-functional with read-only /dev

[SZALAY Attila]

Hi All!


On Wed, 2005-09-07 at 00:02 -0700, Elliott Mitchell wrote:
 
 If /dev is read-only, syslog-ng will give the error message
 syslog-ngio.c: bind_unix_socket(): bind failed /dev/log (Address already
 in use). The relevant section from `ltrace -LSf`:

The problem is, that a sysklogd do just the same. Could you please send
an ltrace of sysklogd in the same situation.

Look at this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=84204;archive=yes



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#324816: syslog-ng: CONSOLE_LOG_LEVEL and KERNEL_RINGBUF_SIZE is of unaccepted value.

[Szalay Attila]

On sze, 2005-08-24 at 10:25 +0200, Marc Haber wrote:

 When starting syslog-ng with /etc/default/syslog-ng untouched, the two
 warnings
 CONSOLE_LOG_LEVEL is of unaccepted value.
 KERNEL_RINGBUF_SIZE is of unaccepted value.
 are printed. This is a policy violation, and can be fixed by applying
 this patch.

The fixed version of syslog-ng reached proposed-updates yesterday as
version 1.6.5-3



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#311497: ITP: eventlog -- Syslog event logger library

[SZALAY Attila]

Package: wnpp
Severity: wishlist
Owner: SZALAY Attila [EMAIL PROTECTED]

* Package name: eventlog
  Version : 0.2.3+20050116+1856
  Upstream Author : Scheidler Balazs [EMAIL PROTECTED]
* URL : http://www.balabit.hu/downloads/syslog-ng/1.9/src/
* License : BSD
  Description : Syslog event logger library

 The EventLog library aims to be a replacement of the simple syslog() API
 provided on UNIX systems. The major difference between EventLog and syslog
 is that EventLog tries to add structure to messages.
 .
 EventLog provides an interface to build, format and output an event record.
 The exact format and output method can be customized by the administrator
 via a configuration file.


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.18
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]