Bug#823297: libbotan: security update breaks monotone

2016-05-09 Thread Tim Weippert
HI, 

On Mon, May 09, 2016 at 11:18:42AM +0200, Tim Weippert wrote:
> On Wed, May 04, 2016 at 06:19:25PM +0200, Markus Koschany wrote:
 
[ ... ]
 
> I try to rebuild monotone on the system against the updated lib and get back 
> to you. 

Rebuild of monotone fixed the issue. For more informations ldd/informations of 
mtn pull:

Before Security Update:

root@lab-server01:~/XXX# mtn pull
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to 'mtn://XXX/'
mtn:   include pattern  'XXX.*'
mtn:   exclude pattern  ''
mtn: finding items to synchronize:
mtn: certificates | keys | revisions
mtn:   51,019 |  118 |16,837
mtn:  bytes in | bytes out | certs in | revs in
mtn: 1.4 k | 1.5 k |  0/0 | 0/0
mtn: successful exchange with 'XXX'

root@lab-server01:~/XXX# ldd `which mtn`
linux-vdso.so.1 (0x7ffdac731000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7fee7d5d3000)
libbotan-1.10.so.0 => /usr/lib/libbotan-1.10.so.0 (0x7fee7d0d5000)
liblua5.1.so.0 => /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 
(0x7fee7cea8000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fee7cbdf000)
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 
(0x7fee7c9ab000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fee7c79)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fee7c485000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fee7c184000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fee7bf6e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fee7bbc3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fee7b9a6000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fee7b796000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
(0x7fee7b39b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fee7b197000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x7fee7af14000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fee7ad0c000)
/lib64/ld-linux-x86-64.so.2 (0x7fee7d841000)


After Security Update:

root@lab-server01:~/XXX# mtn pull
mtn: Symbol `_ZTVN5Botan17DataSource_MemoryE' has different size in shared 
object, consider re-linking
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to 'mtn://XXX/'
mtn:   include pattern  'XXX'
mtn:   exclude pattern  ''
mtn: finding items to synchronize:
mtn: certificates | keys | revisions
mtn:   51,019 |  118 |16,837
mtn: fatal signal: Segmentation fault
this is almost certainly a bug in monotone.
please send this error message, the output of 'mtn version --full',
and a description of what you were doing to 
<https://code.monotone.ca/p/monotone/issues/>
do not send a core dump, but if you have one, 
please preserve it in case we ask you for information from it.
Segmentation fault

root@lab-server01:~/XXX# ldd `which mtn`
linux-vdso.so.1 (0x7fff3d39)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7fb7a19f3000)
libbotan-1.10.so.0 => /usr/lib/libbotan-1.10.so.0 (0x7fb7a14f2000)
liblua5.1.so.0 => /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 
(0x7fb7a12c5000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fb7a0ffc000)
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 
(0x7fb7a0dc8000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fb7a0bad000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fb7a08a2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fb7a05a1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fb7a038b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb79ffe)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fb79fdc3000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fb79fbb3000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
(0x7fb79f7b7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb79f5b3000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x7fb79f33)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fb79f128000)
/lib64/ld-linux-x86-64.so.2 (0x7fb7a1c61000)

After Rebuild of monotone:

root@lab-server01:~/XXX# mtn pull
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to 'mtn://XXX/'
mtn:   include pattern  'XXX.*'
mtn:   exclude pattern  ''
mtn: finding items to synchronize:
mtn: certificates | keys | revisions
mtn:   51,019 |  118 |16,837
mtn:  bytes in | bytes out | cert

Bug#823297: libbotan: security update breaks monotone

2016-05-09 Thread Tim Weippert
On Wed, May 04, 2016 at 06:19:25PM +0200, Markus Koschany wrote:

[ ... ]

> I can't reproduce the segmentation fault on my system. Could you share
> some information about your setup? What exactly did you do before the
> segfault happened? Did you restart the monotone-server after the
> upgrade? Can you confirm that a rebuild fixes the issue?

It is not the monotone-server i running, it is an mtn update/pull/sync action 
from an
monotone-server. The System is an basic jessie vm on an kvm environment located 
by an hoster.

> I haven't seen other issues with the security update of libbotan1.10 so
> far but if monotone needs a rebuild, this bug should be reassigned to
> monotone.

I try to rebuild monotone on the system against the updated lib and get back to 
you. 

cheers, 
tim

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8



Bug#823297: libbotan: security update breaks monotone

2016-05-03 Thread Tim Weippert
Package: libbotan-1.10-0
Version: 1.10.8-2+deb8u1
Severity: grave
File: libbotan
Justification: renders package unusable

Dear Maintainer,

it seems that the recent security update breaks monotone:

mtn: Symbol `_ZTVN5Botan17DataSource_MemoryE' has different size in shared 
object, consider re-linking
mtn: updating along branch 'net.dn42.registry'
mtn: fatal signal: Segmentation fault
this is almost certainly a bug in monotone.
please send this error message, the output of 'mtn version --full',
and a description of what you were doing to 

do not send a core dump, but if you have one, 
please preserve it in case we ask you for information from it.
Segmentation fault

Maybe the bug should also be sent to monotone for rebuilding?

cheers, 
tim

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

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

Versions of packages libbotan-1.10-0 depends on:
ii  libbz2-1.0   1.0.6-7+b3
ii  libc62.19-18+deb8u4
ii  libgcc1  1:4.9.2-10
ii  libgmp10 2:6.0.0+dfsg-6
ii  libssl1.0.0  1.0.1k-3+deb8u4
ii  libstdc++6   4.9.2-10
ii  zlib1g   1:1.2.8.dfsg-2+b1

libbotan-1.10-0 recommends no packages.

libbotan-1.10-0 suggests no packages.

-- no debconf information



Bug#804644: RFS: flashybrid/0.19 [ITA]

2015-12-17 Thread Tim Weippert
Hi Mattia, 

i had talked to Thibaut and I'am willing to took maintainership for this 
packages, 
currently i'am working on an new Upload to incorporate the review from 
Gianfranco and the suggestions
he mention.

If i'am ready i will announce it for review on the debian-mentors mailinglist.

regards, 
tim 

On Thu, Dec 17, 2015 at 05:28:30PM +, Mattia Rizzolo wrote:
> On Wed, Nov 25, 2015 at 06:42:36PM +0100, Thibaut Varène wrote:
> > I suppose what I need is having people take over my packages and call
> > it a day, tbh. With my upload rights revoked there’s not much meaning
> > in being a DD.
> 
> Not really.
> There are several active DDs who got their key removed due to the 1024
> purge and still have packages sponsored.
> Sponsoring a DD is also easier, you know that most probably the
> sponsoree is already aware of good conventions, etc.
> 
> Don't give up just for this inconvenience, ask for sponsorship and as
> soon as you manage to get your key back into the keyring you can come
> back full steam :)
> 
> 
> 
> PS: @Tim: what about this RFS?
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  http://mapreri.org  : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-



-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8



Bug#804644: RFS: flashybrid/0.19 [ITA]

2015-11-09 Thread Tim Weippert
Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package "flashybrid"

* Package name: flashybrid
  Version : 0.19
  Upstream Author : Joeyh Hess initial
* URL : http://hacks.slashdirt.org/sw/flashybrid/
* License : GPLv2 or later
  Section : admin

It builds those binary packages:

flashybrid - automates use of a flash disk as the root filesystem

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/flashybrid

Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/f/flashybrid/flashybrid_0.19.dsc

As the current Maintainer isn't capable for uploading anymore, i talk to him to 
get permission to take maintainership
of this package. The Package indicates the maintainership change and leaves the 
original maintainer as Uploader. (See Bug #784890).
The permit isn't public available, but the current maintainer can be contacted.

Currently the Package isn't functional with the latest systemd bind mount 
modifications on an Jessie/systemd system.

Changes since the last upload:

 flashybrid (0.19) unstable; urgency=medium
 .
   [ Thibaut VARENE ]
   * Fix init to cope with systemd new bind mount defaults (Closes: #784890)
 .
   [ Tim Weippert ]
   * New maintainer upload
   * Changed Uploaders for Thibaut VARENE
   * Added italian translation (Closes: #778383)

Regards,
Tim Weippert

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8



Bug#784890: flashybrid: Unable to Sync ramstore directories ...

2015-11-08 Thread Tim Weippert
HI, 

DM's not allowed to do an NMU Upload. Sorry, can't help. 

cheers, 
tim

On Sun, Nov 08, 2015 at 10:55:03AM +0100, Tim Weippert wrote:
> HI, 
> 
> i prepared an NMU and try to upload it. Don't know if i'm allowed to do so 
> ... will see.
> 
> I also included the italian translation to the new package and your fix. 
> Hopefully it is ok.
> 
> Cheers, 
> tim
> 
> On Sun, May 17, 2015 at 03:00:24PM +0200, Thibaut Varène wrote:
> > OK, thanks everybody.
> > 
> > For the records, I'm attaching source for flashybrid-0.19 and a patch from 
> > 0.18 to this bug report. I can't upload it to the archive, but if some DD 
> > wants to, let them be my guest.
> > 
> > T.
> > 
> > 
> 
> 
> 
> 
> 
> -- 
> Tim Weippert
> http://weiti.org - we...@weiti.org
> GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8



Bug#784890: flashybrid: Unable to Sync ramstore directories ...

2015-11-08 Thread Tim Weippert
HI, 

i prepared an NMU and try to upload it. Don't know if i'm allowed to do so ... 
will see.

I also included the italian translation to the new package and your fix. 
Hopefully it is ok.

Cheers, 
tim

On Sun, May 17, 2015 at 03:00:24PM +0200, Thibaut Varène wrote:
> OK, thanks everybody.
> 
> For the records, I'm attaching source for flashybrid-0.19 and a patch from 
> 0.18 to this bug report. I can't upload it to the archive, but if some DD 
> wants to, let them be my guest.
> 
> T.
> 
> 





-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8



Bug#784890: flashybrid: Unable to Sync ramstore directories ...

2015-05-14 Thread Tim Weippert

On Thu, May 14, 2015 at 08:09:23PM +0200, Thibaut Varène wrote:
 
  Le 14 mai 2015 à 18:07, Stefan Blochberger stefan.blochber...@mail.de a 
  écrit :
 
  tmpfs (rw,relatime,size=122880k) tmpfs on /ram/var/run.flash type
  tmpfs (rw,nosuid,noexec,relatime,size=25272k,mode=755) tmpfs on
  /run type tmpfs (rw,nosuid,noexec,relatime,size=25272k,mode=755) 
  
 
 
  But /var/run still in use ;(
 
 See the above two lines. I suspect in Jessie, /var/run is by default a bind 
 mount of /run. Try commenting it out from /etc/flashybrid/ramstore and see if 
 anything breaks.
 
 In case that wasn’t obvious, I don’t have (yet) a Jessie machine to check 
 this out.

All fine, commented /var/run in ramstore and fh-sync is syncing without error.
 
  You just have to add --make-private to all mounts in
  /etc/init.d/flashybrid
 
 That makes sense. From the Debian Wiki it’s obvious systemd broke everything 
 by overriding the kernel default for bind mounts. This comment in the bug 
 thread aligns nicely with my personal opinion on the matter:
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739593#97

Yes, the --make-privat flag in the init script seems to resolve the problem.
I will check the system for a longer time and get my results back.

Cheers,
tim

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8


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



Bug#784890: flashybrid: Unable to Sync ramstore directories ...

2015-05-13 Thread Tim Weippert

On Mon, May 11, 2015 at 09:15:54PM +0200, Thibaut Varène wrote:
 On 11 mai 2015, at 19:32, Tim Weippert we...@weiti.org wrote:
 
 
  If i found another CF card i will try to install an fresh wheezy and update 
  to jessie without migration to systemd (think this should be possible)
  maybe then we know if it is an systemd or kernel fault.
 
 Thanks. First ensure it's working fine in Wheezy.

I just installed an plain wheezy and all is fine with flashybrid. Attached is 
an output of some mount statements (flashybrid-wheezy-orig.txt).
Second i installed an 3.16 Kernel from Backports just to see if it is an kernel 
issue (flashybrid-wheezy-bpo.txt), and with this scenario all fine, too.

And third i made an dist-upgrade to jessie with the bpo kernel running ...

after the dist-upgrade process finished and before reboot i got the odd 
situation with the tmpfs twice mounts:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=31202,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=25272k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=92920k)
tmpfs on /ram type tmpfs (rw,relatime,size=122880k)
tmpfs on /tmp type tmpfs (rw,relatime,size=122880k)
tmpfs on /run/lock type tmpfs (rw,relatime,size=122880k)
tmpfs on /var/lib/dhcp type tmpfs (rw,relatime,size=122880k)
tmpfs on /var/lib/misc type tmpfs (rw,relatime,size=122880k)
tmpfs on /var/lib/urandom type tmpfs (rw,relatime,size=122880k)
tmpfs on /var/tmp type tmpfs (rw,relatime,size=122880k)
/dev/sda1 on /ram/var/lib/exim4.flash type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /var/lib/exim4 type tmpfs (rw,relatime,size=122880k)
/dev/sda1 on /ram/var/lib/logrotate.flash type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /var/lib/logrotate type tmpfs (rw,relatime,size=122880k)
/dev/sda1 on /ram/var/log.flash type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /var/log type tmpfs (rw,relatime,size=122880k)
tmpfs on /ram/var/run.flash type tmpfs 
(rw,nosuid,noexec,relatime,size=25272k,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=25272k,mode=755)
/dev/sda1 on /ram/root.flash type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /root type tmpfs (rw,relatime,size=122880k)
/dev/sda1 on /ram/var/spool.flash type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /var/spool type tmpfs (rw,relatime,size=122880k)
/dev/sda1 on /ram/var/mail.flash type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /var/mail type tmpfs (rw,relatime,size=122880k)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)

For this i think it isn't an kernel issue, it is like you imagined, maybe an 
systemd issue.
After the reboot this situation stays the same.

BUT, if i startup with init=/lib/sysvinit/init to get an sysvinit start system 
back, 
problem persistsi (flashybrid-jessie.txt). I don't know if we had an full 
sysvinit system or some systemd invocations, but
i don't see any systemd processes running. Maybe an other change in some utils? 
mount? or similar ...

Then i tried the following:

Booted with Backport Kernel for Wheezy + init=/lib/sysvinit/init and voila: 
Flashybrid works as expected (flashybrid-jessie-wheezy-bpo-kernel-sysvinit.txt).

Now i'm a little confused ... Kernel AND systemd issue?

Cheers, 
tim

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8

root@indoor01:~# more /etc/debian_version 
7.8

root@indoor01:~# uname -a
Linux indoor01 3.2.0-4-486 #1 Debian 3.2.68-1+deb7u1 i586 GNU/Linux

root@indoor01:~# mount | grep root
/dev/disk/by-uuid/cf1604e5-2ea0-4411-94cc-5e0eecf87185 on /ram/root.flash type 
ext4 (ro,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)
tmpfs on /root type tmpfs (rw,relatime,size=122880k)

root@indoor01:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=31529,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=25500k,mode=755)
/dev/disk/by-uuid/cf1604e5-2ea0-4411-94cc-5e0eecf87185 on / type ext4 
(ro,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=93380k)
tmpfs on /ram type tmpfs (rw,relatime,size=94208k)
tmpfs

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

2015-05-11 Thread Tim Weippert
Hi Thibaut, 

yes i can confirm, this happens in an fresh and newly started Jessie System.

The Config Files are the Files from the Package, i only commented /etc in 
ramstore File. /root is there already. No change from
my side.

I haven't started any daemons/processes rather than connect via SSH to the 
System. For your information my mount table looks after 
clean start like this:

weiti@indoor01:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=29791,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=50556k,mode=755)
/dev/sda1 on / type ext4 (ro,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /ram type tmpfs (rw,relatime,size=122880k)
tmpfs on /tmp type tmpfs (rw,relatime,size=122880k)
tmpfs on /run/lock type tmpfs (rw,relatime,size=122880k)
tmpfs on /var/lib/dhcp type tmpfs (rw,relatime,size=122880k)
tmpfs on /var/lib/misc type tmpfs (rw,relatime,size=122880k)
tmpfs on /var/lib/urandom type tmpfs (rw,relatime,size=122880k)
tmpfs on /var/tmp type tmpfs (rw,relatime,size=122880k)
/dev/sda1 on /ram/var/lib/exim4.flash type ext4 
(ro,relatime,errors=remount-ro,data=ordered)
tmpfs on /var/lib/exim4 type tmpfs (rw,relatime,size=122880k)
tmpfs on /ram/var/lib/exim4.flash type tmpfs (rw,relatime,size=122880k)
/dev/sda1 on /ram/var/log.flash type ext4 
(ro,relatime,errors=remount-ro,data=ordered)
tmpfs on /var/log type tmpfs (rw,relatime,size=122880k)
tmpfs on /ram/var/log.flash type tmpfs (rw,relatime,size=122880k)
tmpfs on /ram/var/run.flash type tmpfs (rw,nosuid,relatime,size=50556k,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=50556k,mode=755)
tmpfs on /ram/var/run.flash type tmpfs (rw,nosuid,relatime,size=50556k,mode=755)
/dev/sda1 on /ram/root.flash type ext4 
(ro,relatime,errors=remount-ro,data=ordered)
tmpfs on /root type tmpfs (rw,relatime,size=122880k)
tmpfs on /ram/root.flash type tmpfs (rw,relatime,size=122880k)
/dev/sda1 on /ram/var/spool.flash type ext4 
(ro,relatime,errors=remount-ro,data=ordered)
tmpfs on /var/spool type tmpfs (rw,relatime,size=122880k)
tmpfs on /ram/var/spool.flash type tmpfs (rw,relatime,size=122880k)
/dev/sda1 on /ram/var/mail.flash type ext4 
(ro,relatime,errors=remount-ro,data=ordered)
tmpfs on /var/mail type tmpfs (rw,relatime,size=122880k)
tmpfs on /ram/var/mail.flash type tmpfs (rw,relatime,size=122880k)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
rpc_pipefs on /ram/var/run.flash/rpc_pipefs type rpc_pipefs (rw,relatime)
rpc_pipefs on /ram/var/run.flash/rpc_pipefs type rpc_pipefs (rw,relatime)

My thoughs are that these situation are my problem:

/dev/sda1 on /ram/root.flash type ext4 
(ro,relatime,errors=remount-ro,data=ordered)
tmpfs on /root type tmpfs (rw,relatime,size=122880k)
tmpfs on /ram/root.flash type tmpfs (rw,relatime,size=122880k)

It seems that root.flash gets mounted twice, on ro from the cf card which is 
ok, the other (later?) mount
is an rw tmpfs ... and every sync while go to the tmpfs i think. And after an 
reboot these changes are lost, because
the tmpfs get cleared.

When i change fh-sync to do an remount,ro,bind, no errors occures, but changes 
weren't synced to CF also.

HTH, 
tim

On Sun, May 10, 2015 at 08:26:23PM +0200, Thibaut Varène wrote:
 tags 784890 moreinfo
 thx
 
 On 10 mai 2015, at 09:57, Tim Weippert we...@weiti.org wrote

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

2015-05-11 Thread Tim Weippert
Hi, 

On Mon, May 11, 2015 at 06:09:32PM +0200, Thibaut Varène wrote:
 
 On 11 mai 2015, at 08:46, Tim Weippert we...@weiti.org wrote:
 
  Hi Thibaut, 
  
  yes i can confirm, this happens in an fresh and newly started Jessie System.
  
  The Config Files are the Files from the Package, i only commented /etc in 
  ramstore File. /root is there already. No change from
  my side.
 
 ok.
 
  I haven't started any daemons/processes rather than connect via SSH to the 
  System. For your information my mount table looks after 
  clean start like this:
  
  weiti@indoor01:~$ mount
  tmpfs on /ram type tmpfs (rw,relatime,size=122880k)
  tmpfs on /tmp type tmpfs (rw,relatime,size=122880k)
  tmpfs on /run/lock type tmpfs (rw,relatime,size=122880k)
  tmpfs on /var/lib/dhcp type tmpfs (rw,relatime,size=122880k)
  tmpfs on /var/lib/misc type tmpfs (rw,relatime,size=122880k)
  tmpfs on /var/lib/urandom type tmpfs (rw,relatime,size=122880k)
  tmpfs on /var/tmp type tmpfs (rw,relatime,size=122880k)
  /dev/sda1 on /ram/var/lib/exim4.flash type ext4 
  (ro,relatime,errors=remount-ro,data=ordered)
  tmpfs on /var/lib/exim4 type tmpfs (rw,relatime,size=122880k)
 ^ Up to this, it's fine
  tmpfs on /ram/var/lib/exim4.flash type tmpfs (rw,relatime,size=122880k)
 ^ But this is wrong

Yes, these are my thoughts too.

  /dev/sda1 on /ram/var/log.flash type ext4 
  (ro,relatime,errors=remount-ro,data=ordered)
  tmpfs on /var/log type tmpfs (rw,relatime,size=122880k)
 ^ again, that's correct
  tmpfs on /ram/var/log.flash type tmpfs (rw,relatime,size=122880k)
 ^ that shouldn't be there.

Jep. And so on ...

 
  My thoughs are that these situation are my problem:
  
  /dev/sda1 on /ram/root.flash type ext4 
  (ro,relatime,errors=remount-ro,data=ordered)
  tmpfs on /root type tmpfs (rw,relatime,size=122880k)
  tmpfs on /ram/root.flash type tmpfs (rw,relatime,size=122880k)
  
  It seems that root.flash gets mounted twice, on ro from the cf card which 
  is ok, the other (later?) mount
  is an rw tmpfs ... and every sync while go to the tmpfs i think. And after 
  an reboot these changes are lost, because
  the tmpfs get cleared.
 
 There's an extraneous (and wrong) mount, and I can't quite figure out where 
 it's coming from.
 
 Maybe you could try adding a -x to /etc/init.d/flashybrid first line:
 #!/bin/sh -x
 
 and then record the boot output and add it to this bug report. 

Attached is the output ... but i think flashybrid makes all correct, and also 
it starts at the correct place/order. I think that
the problem is the additional tmpfs mount, too. But i can say if it is an 
kernel or systemd thing ... 

If i found another CF card i will try to install an fresh wheezy and update to 
jessie without migration to systemd (think this should be possible)
maybe then we know if it is an systemd or kernel fault.

Cheers, 
tim

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8
-- Logs begin at Mon 2015-05-11 19:23:17 CEST, end at Mon 2015-05-11 19:25:52 
CEST. --
May 11 19:23:18 indoor01 flashybrid[143]: + . /lib/lsb/init-functions
May 11 19:23:18 indoor01 flashybrid[143]: + run-parts --lsbsysinit --list 
/lib/lsb/init-functions.d
May 11 19:23:18 indoor01 flashybrid[143]: + [ -r 
/lib/lsb/init-functions.d/20-left-info-blocks ]
May 11 19:23:18 indoor01 flashybrid[143]: + . 
/lib/lsb/init-functions.d/20-left-info-blocks
May 11 19:23:18 indoor01 flashybrid[143]: + [ -r 
/lib/lsb/init-functions.d/40-systemd ]
May 11 19:23:18 indoor01 flashybrid[143]: + . 
/lib/lsb/init-functions.d/40-systemd
May 11 19:23:18 indoor01 flashybrid[143]: + _use_systemctl=0
May 11 19:23:18 indoor01 flashybrid[143]: + [ -d /run/systemd/system ]
May 11 19:23:18 indoor01 flashybrid[143]: + [ -n  ]
May 11 19:23:18 indoor01 flashybrid[143]: + [ 1 -ne 1 ]
May 11 19:23:18 indoor01 flashybrid[143]: + export _SYSTEMCTL_SKIP_REDIRECT=true
May 11 19:23:18 indoor01 flashybrid[143]: + [ 0 = 1 ]
May 11 19:23:18 indoor01 flashybrid[143]: + FANCYTTY=
May 11 19:23:18 indoor01 flashybrid[143]: + [ -e /etc/lsb-base-logging.sh ]
May 11 19:23:18 indoor01 flashybrid[143]: + true
May 11 19:23:18 indoor01 flashybrid[143]: + CONFDIR=/etc/flashybrid
May 11 19:23:18 indoor01 flashybrid[143]: + [ -e /etc/flashybrid/config ]
May 11 19:23:18 indoor01 flashybrid[143]: + . /etc/flashybrid/config
May 11 19:23:18 indoor01 flashybrid[143]: + FLASHMOUNT=/
May 11 19:23:18 indoor01 flashybrid[143]: + RAMMOUNT=/ram
May 11 19:23:18 indoor01 flashybrid[143]: + FULL_CMDS=mount -o remount,rw /
May 11 19:23:18 indoor01 flashybrid[143]: + EMBED_CMDS=mount -o remount,ro /
May 11 19:23:18 indoor01 flashybrid[143]: + FLASH_MAX=120m
May 11 19:23:18 indoor01 flashybrid[143]: + ENABLED=no
May 11 19:23:18 indoor01 flashybrid[143]: + [ -e /etc/default/flashybrid ]
May 11 19:23:18 indoor01 flashybrid[143]: + . /etc/default/flashybrid
May 11 19:23:18 indoor01 flashybrid[143]: + ENABLED=yes
May 11 19:23:18 indoor01 flashybrid[143]: + VERBOSE=yes
May 11

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

2015-05-10 Thread Tim Weippert
Package: flashybrid
Version: 0.18
Severity: important

Dear Maintainer,

i hav an fresh jessie installation on an Alix Board (alix 2d13) with an CF 
Card. I tried flashybrid
for the first time and was unable to sync ramstore directiories to real CF 
Location. 

fh-sync run reports the following errors:

root@indoor01:~# fh-sync
Syncing flashybrid system... 
Synchronizing /var/lib/exim4mount: /ram/var/lib/exim4.flash is busy
.
Synchronizing /var/logmount: /ram/var/log.flash is busy
.
Synchronizing /var/runmount: /ram/var/run.flash is busy
.
Synchronizing /rootmount: /ram/root.flash is busy
.
Synchronizing /var/spoolmount: /ram/var/spool.flash is busy
.
Synchronizing /var/mailmount: /ram/var/mail.flash is busy
.
done.

I tried different things but can't get an sync to the real CF flash disk. I 
removed /etc from ramstore to be able
to deactivate flashybrid in a normal way (mountrw - systemctl disable 
flashybrid - reboot). And i changed the max RAMDISK
space ...

I think the problem is, that all ramstore directories get bind mounted twice 
and the upper layer is an bind mount to an tmpfs
in rw ... i think all syncs will be done in the tmpfs place and not in the 
underlying CF Disk.

If i add on fh-sync remount command an ,bind, i get no error upon running 
fh-sync but the syncronisation isn't reached at
CF Disk level. Maybe there is an change in the FS and Bind Mount behaviour with 
the jessie kernel/system?

If i can help in investigation of the problem, please contact me.

Cheers, 
tim

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i586)

Kernel: Linux 3.16.0-4-586
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flashybrid depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  rsync  3.1.1-3

flashybrid recommends no packages.

flashybrid suggests no packages.

-- Configuration Files:
/etc/flashybrid/config changed:
FLASHMOUNT=/
RAMMOUNT=/ram
FULL_CMDS=mount -o remount,rw /
EMBED_CMDS=mount -o remount,ro /
FLASH_MAX=120m

/etc/flashybrid/ramstore changed:
/var/lib/exim4
/var/log
/var/run
/root
/var/spool
/var/mail


-- debconf information:
* flashybrid/remove:


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



Bug#709151: Are you MIA?

2013-07-22 Thread Tim Weippert
Hi Mathieu, 

i'm not MIA, just high load from my company. 

I will react on the bugreports within this week. If you are willing to
prepare an git on git.debian.org this will be fantastic!

cheers,
tim

On Tue, Jul 16, 2013 at 06:07:02PM +0200, Mathieu Parent wrote:
 Hi Tim,
 
 I'm wondering what is your status regarding your Debian packages. I
 have a bunch of patches for c-icap and c-icap-modules.
 
 Can you put the packaging source online (git.debian.org seems
 appropriate)? May I include my patches their?
 
 If you don't have time, I can do all this. But please reply to the bug 
 reports!
 
 Note: without a note from your side within a month, I will consider
 that you are MIA[1] (as the c-icap package has not seen update since
 2012-04-30 and version 0.2 is out since 2012-06-28).
 
 Regards
 --
 Mathieu Parent
 
 [1]: https://wiki.debian.org/Teams/MIA

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8


signature.asc
Description: Digital signature


Bug#696676: python-fife: Memory leak in conjunction with unknown-horizons

2012-12-25 Thread Tim Weippert
Package: python-fife
Version: 0.3.3+r3-1.1
Severity: normal

Dear Maintainer,

with the game unknown-horizons, there seems an memory leak within the 
python-fife package. These logs are written to console window:

swig/python detected a memory leak of type 'FIFE::MouseEvent *', no destructor 
found.
swig/python detected a memory leak of type 'FIFE::MouseEvent *', no destructor 
found.

As i found on the fife trac system, these is an known problem, maybe it can be 
tweaked and backported. ( http://fife.trac.cvsdude.com/engine/ticket/699 ).

I tried attached patch and get smoother mouse movements and no messages on 
console.

cheers, 
tim


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

Kernel: Linux 3.2.0-4-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/dash

Versions of packages python-fife depends on:
ii  libboost-filesystem1.49.0  1.49.0-3.1
ii  libboost-regex1.49.0   1.49.0-3.1
ii  libboost-system1.49.0  1.49.0-3.1
ii  libc6  2.13-37
ii  libgcc11:4.7.2-4
ii  libgl1-mesa-glx [libgl1]   8.0.5-3
ii  libglee0d1 5.4.0-1
ii  libguichan-0.8.1-1 0.8.2-10+b1
ii  libguichan-opengl-0.8.1-1  0.8.2-10+b1
ii  libguichan-sdl-0.8.1-1 0.8.2-10+b1
ii  libogg01.3.0-4
ii  libopenal1 1:1.14-4
ii  libpng12-0 1.2.49-1
ii  libpython2.6   2.6.8-0.2
ii  libpython2.7   2.7.3~rc2-2.1
ii  libsdl-image1.21.2.12-2
ii  libsdl-ttf2.0-02.0.11-2
ii  libsdl1.2debian1.2.15-5
ii  libstdc++6 4.7.2-4
ii  libtinyxml2.6.22.6.2-1
ii  libvorbis0a1.3.2-1.3
ii  libvorbisfile3 1.3.2-1.3
ii  libxcursor11:1.1.13-1
ii  python 2.7.3~rc2-1
ii  python2.6  2.6.8-0.2
ii  python2.7  2.7.3~rc2-2.1

python-fife recommends no packages.

python-fife suggests no packages.

-- no debconf information
Index: /trunk/engine/core/eventchannel/eventchannel.i
===
--- /trunk/engine/core/eventchannel/eventchannel.i	(revision 3775)
+++ /trunk/engine/core/eventchannel/eventchannel.i	(revision 3949)
@@ -59,5 +59,5 @@
 		virtual std::string getDebugString() const;
 		virtual const std::string getName() const;
-		virtual ~IEvent() {}
+		virtual ~Event() {}
 	private:
 		Event();
@@ -71,5 +71,5 @@
 		virtual bool isMetaPressed() const;
 		virtual bool isShiftPressed() const;
-		virtual ~IInputEvent() {}
+		virtual ~InputEvent() {}
 	private:
 		InputEvent();
@@ -154,5 +154,5 @@
 		virtual MouseEventType getType() const;
 		virtual MouseButtonType getButton() const;
-		virtual ~IMouseEvent();
+		virtual ~MouseEvent();
 	private:
 		MouseEvent();


Bug#645122: wrong permissions for /var/run/c-icap/c-icap.ctl named pipe

2012-03-21 Thread Tim Weippert
Hi Stephane, 

thanks for your investigation on this issue, my comments below.

On Wed, Oct 12, 2011 at 08:17:53PM +0100, Stephane Chazelas wrote:
 Package: c-icap
 Version: 1:0.1.6-1
 Severity: normal
 
 Hiya,
 
 The named pipe used to send control requests to the c-icap
 server has incorrect permissions. That could even be considered
 as a security issue as any user on the system can cause some of
 the requests to c-icap to not be delivered to it or be
 misinterpreted (by reading that file).
 
 $ ll /var/run/c-icap/c-icap.ctl
 prwxr--r-- 1 c-icap nogroup 0 Oct 12 19:20 /var/run/c-icap/c-icap.ctl|
 
 Anybody can read from that fifo. Also, the gid is nogroup.
 That group shouldn't have any right. See the execution bit for
 the user which doesn't make sense here either.

Your right, the permission isn't optimal. The GID ist choosen from the config
file and therefore can be changed. I will update the package soon to 0.1.7 and
will implement an c-icap group and switch default config to use this group.
 
 Also,  /usr/share/doc/libc-icap-mod-clamav/README.Debian
 instructs how to configure freshclam so that c-icap reloads the
 virus db when it gets updated, but because freshclam is running
 as clamav, those instructions don't work because clamav
 doesn't have right access to that named pipe.
 
 IMO, the permissions should be:
 
 prw--w c-icap c-icap
 
 The c-icap group should be added and c-icap should run as
 c-icap:c-icap, the clamav user shoud be made member of that group.

Will look into this, if we do it via install scripts or just inform user about
the steps. Maybe someone don't want this integration or maybe someone runs
clamav on some other userid.

 As it happens, the permissions of the named pipe are hardcoded
 in the the c-icap source code. It would be nice to have a
 configuration parameter to specify that mode, or be able to use
 umask to set it.

You can use umask to change the permissions, as the source code uses
mkfifo which can be tweak by umask settings within the init script (umask
option for start-stop-daemon). Problem i think is that you can not set the
initial mode for the file, so umask fiddling is just hard.
 
 Also, it seems c-icap puts itself in background *before*
 creating that pipe, which makes it difficult to fix the
 permissions reliably in c-icap init.d startup script.

Yes, but if we use proper named pipe creation within the Package installation
scripts, we can create the named pipe, the daemon will not mess with the named
pipe if it already exists.

But will look for an patch for hardcoded mode settings and discuss this with
upstream.

cheers, 
tim

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8


signature.asc
Description: Digital signature


Bug#242264: dhcp3-relay: does not forward DHCP-reply if it comes in on different interface

2011-08-04 Thread Tim Weippert
Hi, 

don't know if this bugreport is still active ...
on current version of dhcp3-relay (squeeze) you can add -m forward to 
/etc/default/dhcp3-relay
options and the relay agent will forward the packets.

HTH, 

tim

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8


signature.asc
Description: Digital signature


Bug#627368: Please add Tim Weippert as a Debian Maintainer

2011-05-19 Thread Tim Weippert
Package: debian-maintainers
Severity: normal

Please add my key to Debian Maintainers Keyring.

Thanks, 
tim

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8
Comment: Add Tim Weippert we...@weiti.org as a Debian Maintainer
Date: Fri, 20 May 2011 07:15:47 +0200
Action: import
Recommended-By: 
  Jochen Friedrich joc...@scram.de
Agreement: 
  http://lists.debian.org/debian-newmaint/2011/05/msg5.html
Advocates: 
  http://lists.debian.org/debian-newmaint/2011/05/msg00052.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.11 (GNU/Linux)
  
  mQINBEzvrjsBEADlLuRZxp4cKKqcNnYpa8Ml54nt1IkgVDg3cNyzr1XyswuUA6pA
  J7L0eTUscWmjvww2cDQ65eSH6EYG0zLjvj6DOgAn9kmiusSfAq7pVBKQdokWUdHF
  RlvU70sTzUbS7D6Bw6Xx5ziq/hV8r9nHYT2NUdd7pjtslP49nlHYz1vtotqvQmSu
  pdoEM2HdRQwIXpobznYAXjazjPQIsaMukqrOX12EnBGRaOaNZTT7W1sV/RgzVWd/
  08D6szLM8LhYhgEVLoMoUkK3ToRLl/tLY8jBYrxEMInwK1N9ZcCXsNYy06MW6Exi
  a6iD8UDpVV4U12LJgCKrcZIt127EuJCxBcrMz92kMwsvTKaFKbfauDdFuLJqiN4s
  WdN/svllQmFo5Mw96hltfQNk6jAIXdSR37/QciRVr6v5+sCUq46DUkhWsIcKJR/T
  8DfM6lfgpOIFHjFLQJhPhy2oP1bexJkJrQ8/nYiGS3vNVFzDcCpkZbpEuEwWY+gF
  VLMUTGemyO/4sGXv67SBvJPxn87OXKJqbfsHLHeQPg1v9Rosorj4ay/cNyz2Noym
  HHGoc/R5r7WAZkIUtLdy90YJdqT1TNOUfddC99/CFk0P0fg8kUm/3IWzZoLoib9d
  Z1ves/NNZwkYk17HdZsp0wHDo48CEt1HkRgFzILckBHPXYBfYQvQaZEw+wARAQAB
  tB5UaW0gV2VpcHBlcnQgPHdlaXRpQHdlaXRpLm9yZz6JAjgEEwECACIFAkzvrjsC
  GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGfylK5ZlX3Y+o4QAKC2dRik
  mAJmYJiMHXrIEfvaPHCN+LisANNunHTWNFWat6oFa9gJGc1EVwpnz7+ZgMVyP7/y
  xQTKF+Scm1z8bG+3HRBGXGRUTlScwsWXzajPOCxJXD970YcmhNZTLcX9KCDnF8Cf
  BOMyjkWycawEMAWP1ye06KDsY6Xe2QU1T6/lw8crHa4NVvAfbIfA6VWgzBFR1DJI
  lWLkPtvw6IPhLNktUJ3WX02mgHNZwhXUJBXQTgvrDTNGPwbuyTSXCsHRHfPr7/Xf
  0qb9hdlifTS8iz11ei3IceZ57VMzV0CGdS/8oKoZi2Pv7bV1rTtEwSMrPayaMc1J
  IjILAZSnYq9goNne2iEfWJ00L4E6vdkJ9lxxpY72AhclwW80GtNffz9cQpwJpwZm
  bIbs9s2k/fW06eOfHmtFodqpH6M6mqlfA4c913N++k+fuSPs88MWe3G3ePuWN2Fz
  EiyRrI9M4LfrsjEhj1sEPCUIAcvj3dCBBAm2iwFxBbklbnNJ1enuDKbFRGnLjhC7
  c60By30DHnkQr70ZSeYX4dx8ZDodMe7ycGHVCbSeKqj+aj4d962fWRRPbaFu7YOo
  kkwCwJtO6skAPOGFyecLaLYs8e6VYC/0pFU26sWPF9ept72TIsl3TH3EHwmBT6YO
  U1bILSnorGJChk+/uYIBnDVtWxnMFW3URP/RiEYEEBECAAYFAk0gXD0ACgkQrqCh
  +a/53FIijwCeI1RZEqPSa6UT5v1PqIep9J+jSOwAnRvcz9DvTQu6Iy+F1Mk0X/UQ
  zgbuiGsEEBECACsFAk0gXdoFgwHihQAeGmh0dHA6Ly93d3cuY2FjZXJ0Lm9yZy9j
  cHMucGhwAAoJENK7DQFl0P1YjqsAoJ54yT2SuoRZtRMih9dvCX55BVE4AKCWpE9r
  IqZrdMeVVyIF9pLK0Kvy8YkC8AQSAQoA2gUCTT/TMMASGmh0dHA6Ly9tYXJ0aW4t
  a3JhZmZ0Lm5ldC9ncGcvY2VydC1wb2xpY3kvNTVjOTg4MmQ5OTliYmNjNC8yMDA5
  MDcxMjE4MzM/c2hhNTEyc3VtPWYzM2IxN2M5YWY1MTViZDk4YjI5MjdjYjQ1M2E5
  OTJkM2Q3NTAwZTlmNjcxOTY2NjE2ZTkwNTEwYjk5NDA4OTUxMDhkMjQxNjQ4ZDFh
  MGViNDZiMzJiY2JmMzI1MWExMzZhNmVlMWUyMjc1NzQ1ZTExYmIzMjhjMTRlN2U3
  MjYzAAoJEFXJiC2Zm7zEKI4P/1CNb2VRG1SL4nKWZxM6/0KaVuD3lHRv+BW11PF8
  SHUcYqwdw75yehj4uP0ayJppb7Ry9UtBHyzfgF2aWFz0WXP1BJGa6U38gAvnyedt
  k30FzBM/BKTl5Z6AqsazfpxaN+i4O6MLPfd5RqthH7kAopwwjIqTrVF8CjZjmrdx
  bNNbGvukdK/miukhXhXQb5xNd5szp8ttP9g6HFJJXyZV4fZYWo0SNWYowtMzJcOQ
  hZS0MGO325TaMi7oBGTQVf7GXT35WLHGvBic/w8hjAo9w3Ue3VjlA+90Ki8c6Iat
  hxGOseS5IiBadOkcUJQknTjW7OtI75/eZwXl5+S6qLDADxqRvo71guS7Ne0pSBoR
  U4XKU6/YEwrKP9auxDaJ0eCImXRBXyYP7GCKsjTPZy8XhPv0j74VaQBxGeGTb56c
  zUdY8wVjwU/4ssJ+zEC8CVZbv7YEeXdF7kKh3+tla4TG7rvpILkaz4w7xGbklrYL
  gCZXFMsCvLv+o8Vjn2xyEYxodeHsKqsiFLY4+fIzRat21eteafwbg3VIhLpDG0zR
  zy9kWJ9xYRloEniU6fc7zHJGLP7fyUpM70OuLX19L2sOqpIU7yXZ8AGieNDNLzDg
  0rTBKwhjk8z4uulYpeposygUrJ55u4BC++KTrNO8xexHmW9eWy544N0FQTKML2/t
  DvPNiGsEEBECACsFAk2m5i4FgwHihQAeGmh0dHA6Ly93d3cuY2FjZXJ0Lm9yZy9j
  cHMucGhwAAoJENK7DQFl0P1YW6MAmwVkzzvW0sdvSXfQjDj9mC2/rP5LAJ9nhC8f
  PowLvNaPgXxHEiT7yhZKpYhGBBMRAgAGBQJNwCRVAAoJEBr0MuMU0bARYb4AnA2D
  OpXKBq0xAwd6YFrkiRswptQlAJ4+4TvhVeONtEiT9eKQRHiSA3Rq8YhGBBMRAgAG
  BQJNwCReAAoJEIREPYdyIPnEpaYAnjXUTqEMfzP8Lw8Vb8Mcdpvt+XDgAJ9ETL28
  oRUpT3QATU3AWRoHvaoNkIhGBBARAgAGBQJNwDYjAAoJEHCyAyE69Z0WOiMAoJpJ
  qrkhnfbq4A2ITYiLm3EB9rmUAJ9EdDarVdBjb1C7NDb1S/9lc80N4rkCDQRM7647
  ARAAxSAkOl0vs6inaU6ISygm0BYh/F9K/oIbti8WUEwLR96WL9IBIezYZRpeLfI5
  UfZtHaCQhp2MrLuW1LrBLRVarX7tEVczNlXIpFVfJYA5HB7lTUlTXTAOqxG9Gxt2
  CRimjmyo68Z/U0i1EZ/oPJfTfeJnGKZlcG0VEycAabfgYkUdwEVL7uqX+jp2iC+X
  KYmK8mXW/gIz1szxs8yHPFwhWQb3Z5rNwKD5WCn0NhnLdnx0GQULDLIsdTOHYzjg
  oYD7aKtTaxIfoBB/PLPH+pgkhtEPVlqgDFESCzyppc6A6O8a2UfT7N+wuBhk90mH
  f1tSuTWt5quh/TUT0typ6NSGzC6lcIliOYrY0lTVwGIZgwST7L5YT3uObQDupoG/
  25rVD4euSjoHAPQ/g4TMh2a6PKGvvvNYehP29a1sL6c1lGr983cuRsutETvXhMJh
  TBs1hiAkDVGlxKm4meuURp+GcmkZ1X5soTPyl8NyY3FVDBHYHyc1lZ5o0xeQMeYH
  8hwAAHw0jnY0t8BmMHNp1gNLEihCdTaJchHGTrgpu1BjeRybLu8yW2eMT8V84eGc
  Bof4DarJlTKufTL5ExphF3zwypqU3JmTVH4RdjH9q+vtKfGW1u0H+5RJz6v3mjgV
  4wl+bnqkQkdzwATNwS/iOgp6zfphaee4IqiSauubGF4dEEsAEQEAAYkCHwQYAQIA
  CQUCTO+uOwIbDAAKCRBn8pSuWZV92CWxEACZAZjlGmaVrXBGbBg7djTeqEe7Z/Cp
  5suVKFp93rQVT5wByn4DbZtVjXrwEVFyQqcT8WjMNJ4/j1FCZ6QIWVDgCskMN/Rh
  fAau+TlYgXv69tbFPzUASBf5M+4s4434q+Cn4//ukkfmHRUHLUS5sknRU2EfSmIa
  ccvww1xK2hzqUhVVfRUDLe3Tp79EfdwxYfw7Qt/gAAC2xpZ3PjQHPnKnq4bWbLbZ

Bug#612925: /usr/lib/libtommath.la removed from package (-dev)

2011-02-13 Thread Tim Weippert

Hi, 

sorry, the problem is not libtommath-dev. 

Problem is an file from libclamav-dev (libclamav.la) which has an dependency
on libtommath.la. If i remove libclamav.la all is fine and the system has an 
right dependency
against -lclamav.

Maybe we can reassign this bug to libclamav(-dev)?

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8


signature.asc
Description: Digital signature


Bug#612925: /usr/lib/libtommath.la removed from package (-dev)

2011-02-11 Thread Tim Weippert
Package: libtommath
Version: 0.42.0-1
Severity: normal

it seems that in the new Package the libtool archive has been removed:

/usr/lib/libtommath.la

This is stated within changelog of version 0.42.0-1.

My Package c-icap-modules requires these file and won't compile without this:

/bin/sed: can't read /usr/lib/libtommath.la: No such file or directory
libtool: link: `/usr/lib/libtommath.la' is not a valid libtool archive
make[4]: *** [srv_clamav.la] Error 1
make[4]: Leaving directory 
`/home/weiti/c-icap/modules/c-icap-modules-0.1.3/services/clamav'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/home/weiti/c-icap/modules/c-icap-modules-0.1.3/services'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/weiti/c-icap/modules/c-icap-modules-0.1.3'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/weiti/c-icap/modules/c-icap-modules-0.1.3'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


Can the file be added again in libtommath-dev?

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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



Bug#607836: Old version

2010-12-23 Thread Tim Weippert
Hi, 

On Thu, 2010-12-23 at 18:31 +0100, Jochen Friedrich wrote:
 Hi,
 
  please update to c_icap 0.1.4
 
  http://garr.dl.sourceforge.net/project/c-icap/c-icap/0.1.x/c_icap-0.1.4.tar.gz
 
  and add as extra package for modules this:
 
  http://mesh.dl.sourceforge.net/project/c-icap/c-icap-modules/0.1.x/c_icap_modules-0.1.2.tar.gz
 
 Mentors has both packages plus a third one for yet another c-icap module. 
 c-icap 0.1.3 has just been uploaded to unstable.

I just prepared new Packages and uploaded to mentors.debian.net with
Version 0.1.4 for c-icap and Version 0.1.3 for c-icap-modules. 

cheers, 
tim



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



Bug#604434: ITP: libc-icap-mod-squidclamav -- C-ICAP Service offer Antivirus via clamd

2010-11-21 Thread Tim Weippert
Package: wnpp
Owner: Tim Weippert we...@weiti.org
Severity: wishlist

*** Please type your report below this line ***

* Package name    : libc-icap-mod-squidclamav
  Version : 6.1
  Upstream Author : Gilles Darold
* URL : http://squidclamav.darold.net/
* License : GPL
  Programming Lang: C
  Description : C-ICAP Service offer Antivirus via clamd

 SquidClamav since version 6.x works as an ICAP service through the
 c-icap server. It is faster than previous v5.x releases and also
 remove old limitation on POST request, sites with sessions like
 webmail and audio/video streaming. The v6.x branch still allow
 chaining squidGuard with high performance.

This Service uses clamd and therefore can be dsitributed within main debian
archive.

As a prerequisit, c-icap =0.1.2 is needed. Currently i worked with the current
maintainer
on an up-to-date c-icap package.



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



Bug#561573: netcfg: Disable reverse-resolve via preseed

2009-12-18 Thread Tim Weippert
Package: netcfg
Version: 1.46
Severity: wishlist


Is it possible to set an flag within preseeding, to disable revese lookup
of the domain name from an ip. In some scenarios, i want to set an other
domain as in the reverse lookup.

For preseeding/automatic installation it would be nice to had an parameter for 
this.

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

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



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



Bug#477077: dansguardian: segmentation fault crash

2009-03-03 Thread Tim Weippert
Hi, 

i can confirm the bug too.

Running Debian Etch with an backported version of sid's dansguardian
2.9.9.7.

Can i do something to help by resolving this issue?

regards, 

tim




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



Bug#486076: /etc/init.d/clamav-daemon status is always 0

2008-06-13 Thread Tim Weippert
Package: clamav-daemon
Version: 0.93.1.dfsg-volatile1
Severity: minor

The init script returns always 0 when you ask for the current status of
the clamav-daemon. For automated status tests like in puppet or other
tools which know that there is an status commandline option this should
be in case of error an none 0 value.

I think the easiest way is just exit in the status case with:

exit $RUNNING

or similar.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-028stab051
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)

Versions of packages clamav-daemon depends on:
ii  clamav-base0.93.1.dfsg-volatile1 anti-virus utility for Unix - base
ii  clamav-freshclam [ 0.93.1.dfsg-volatile1 anti-virus utility for Unix - viru
ii  libc6  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  libclamav4 0.93.1.dfsg-volatile1 anti-virus utility for Unix - libr
ii  lsb-base   3.1-23.2etch1 Linux Standard Base 3.1 init scrip
ii  ucf2.0020Update Configuration File: preserv
ii  zlib1g 1:1.2.3-13compression library - runtime

clamav-daemon recommends no packages.

-- no debconf information



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



Bug#345119: Confirmation of Success :)

2006-10-12 Thread Tim Weippert
Hi there, 

i can confirm, that this patch is needed to get Jabber-yahoo Transports
working on an amd64 Machine.

Without the patch, the service runs, and you can register, but the logon
to the Yahoo Network fails with an Remote Server error failure.

Maybe this helps to include the patch in the Debian Package.


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



Bug#391154: Installation fails if files exist under /var/lib/mailman/qfiles/

2006-10-05 Thread Tim Weippert
Package: mailman
Version: 2.1.5-8sarge5
Severity: normal

I have difficulties to install the new update Mailman 2.1.5-8sarge5.

p15169043:~# apt-get install mailman
Reading Package Lists... Done
Building Dependency Tree... Done
Suggested packages:
  python2.3-korean-codecs python2.2-korean-codecs python-japanese-codecs
The following packages will be upgraded:
  mailman
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
18 not fully installed or removed.
Need to get 6607kB of archives.
After unpacking 623kB disk space will be freed.
Get:1 http://security.debian.org sarge/updates/main mailman
2.1.5-8sarge5 [6607kB]
Fetched 6607kB in 1s (4299kB/s)   
Preconfiguring packages ...
(Reading database ... 28501 files and directories currently installed.)
Preparing to replace mailman 2.1.5-8sarge2 (using
.../mailman_2.1.5-8sarge5_i386.deb) ...
Shutting down Mailman's master qrunner
dpkg: error processing
/var/cache/apt/archives/mailman_2.1.5-8sarge5_i386.deb (--unpack):
 subprocess pre-installation script returned error exit status 1
No updates are necessary.
Starting Mailman's master qrunner.
Errors were encountered while processing:
 /var/cache/apt/archives/mailman_2.1.5-8sarge5_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

After i have investigate a litte time in looking for the problem i see
that there are 2 shunt files within the /var/lib/mailman/qfiles/shunt
directory. 

p15169043:/var/lib/mailman/qfiles# find . -type f
./shunt/1145465662.2810569+61c49717358a01c964da7ae1b486f6e4604bebd8.pck
./shunt/1145466956.072372+84e55081a4239e44812e02da29eabe0cf8df2364.pck

I know that the preinst script looks for such files but it doesn't do
anything with them i think. After manually removal of these two files
the update goes like a charm.

Maybe it results from the empty debconf entry
mailman/queue_files_present:

then i suggest to ask for before the upgrade !?

HTH, 

tim

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages mailman depends on:
ii  apache-ssl [httpd]1.3.33-6sarge3 versatile, high-performance HTTP s
ii  apache2-mpm-prefork [ 2.0.54-5sarge1 traditional model for Apache2
ii  cron  3.0pl1-86  management of regular background p
ii  debconf   1.4.30.13  Debian configuration management sy
ii  libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an
ii  logrotate 3.7-5  Log rotation utility
ii  postfix [mail-transpo 2.1.5-9A high-performance mail transport 
ii  pwgen 2.03-1 Automatic Password generation
ii  python2.3.5-2An interactive high-level object-o
ii  ucf   1.17   Update Configuration File: preserv

-- debconf information:
* mailman/queue_files_present:
  mailman/default_server_language: en
  mailman/gate_news: false
  mailman/site_languages: de, en
* mailman/used_languages: de en
* mailman/create_site_list:



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



Bug#354685: php4: PHP4 in Sarge may be vulnerable to CVE-2005-3054

2006-05-10 Thread Tim Weippert
Package: php4
Version: 4:4.3.10-16
Followup-For: Bug #354685


Hi can this be confirmed, will be an update on security.debian.org, or
do we have to patch it on our own!?

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.14-skas3-v8.2
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages php4 depends on:
ii  libapache2-mod-php4  4:4.3.10-16 server-side, HTML-embedded scripti
ii  php4-common  4:4.3.10-16 Common files for packages built fr

-- no debconf information


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



Bug#345296: nemesis: tcp Mode fails on amd64 (x86_64)

2005-12-30 Thread Tim Weippert
Package: nemesis
Version: 1.32+1.4beta3-2
Severity: normal

On amd64 (x86_64) i have the following issue with the tcp Packet
injection:

spawn:~# nemesis tcp -v -y 1494 -S 1.1.1.1 -D 1.2.3.4  

TCP Packet Injection -=- The NEMESIS Project Version 1.4beta3 (Build 22)

[IP] 1.1.1.1  1.2.3.4
 [IP ID] 41209
  [IP Proto] TCP (6)
[IP TTL] 255
[IP TOS] 00
[IP Frag offset] 
 [IP Frag flags] 

 [TCP Ports] 24420  1494
 [TCP Flags] SYN 
[TCP Urgent Pointer] 0
   [TCP Window Size] 4096
[TCP Seq number] 706971441

Wrote 40 byte TCP packet.
*** glibc detected *** free(): invalid next size (fast):
0x0051b050 ***
Aborted

A packet gets injected, but it seems the header get scrambled ...

On an i386 Box this command works flawless. Think it is an x86_64 Arch
issue only!

I attach a file with an strace of the command (see above).

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-skas3-v8.2
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages nemesis depends on:
ii  libc6 2.3.5-9GNU C Library: Shared libraries an
ii  libnet0   1.0.2a-7   library for the construction and h

nemesis recommends no packages.

-- no debconf information
execve(/usr/bin/nemesis, [nemesis, tcp, -v, -y, 1494, -S, 
1.1.1.1, -D, 1.2.3.4], [/* 13 vars */]) = 0
uname({sys=Linux, node=spawn, ...}) = 0
brk(0)  = 0x51b000
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2aac2000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=75564, ...}) = 0
mmap(NULL, 75564, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2aac3000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/usr/lib/libnet.so.0, O_RDONLY)  = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\0$\0\0\0..., 640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=28048, ...}) = 0
mmap(NULL, 1076592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x2abc3000
mprotect(0x2abc9000, 1052016, PROT_NONE) = 0
mmap(0x2acc8000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0x2acc8000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/libm.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320=\0\0..., 640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=543920, ...}) = 0
mmap(NULL, 1589704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x2acca000
mprotect(0x2ad4e000, 1049032, PROT_NONE) = 0
mmap(0x2ae4d000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x83000) = 0x2ae4d000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/libresolv.so.2, O_RDONLY)   = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0[EMAIL PROTECTED]..., 640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=76600, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2ae4f000
mmap(NULL, 1133256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x2ae5
mprotect(0x2ae61000, 1063624, PROT_NONE) = 0
mmap(0x2af61000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x2af61000
mmap(0x2af63000, 6856, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2af63000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/libnsl.so.1, O_RDONLY)  = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0 I\0\0\0..., 640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=86272, ...}) = 0
mmap(NULL, 1141488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x2af65000
mprotect(0x2af79000, 1059568, PROT_NONE) = 0
mmap(0x2b078000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13000) = 0x2b078000
mmap(0x2b07a000, 6896, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b07a000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\200\305..., 640) = 640
lseek(3, 624, SEEK_SET) = 624
read(3, \4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0..., 32) = 32
fstat(3, {st_mode=S_IFREG|0755, 

Bug#321229: radiusclient1: fails to authenticate on 64bit Systems

2005-08-04 Thread Tim Weippert
Package: radiusclient1
Version: 0.3.2-8
Severity: normal
Tags: patch


On an amd64 (SUN V20z) Authentication against an  Radius Server fails, because
the Attribute Value Pairs sending to the Server are to big. This is due the
64bit System. 

With the attached Patch, UINT4 and INT4 (defined in radiusclient.h) is 
defined as int not as long, so the header AVP Fields are within
the specification.

I would like to see the attached patch included in the Debian Package, 
because we use some Servers which are 64bit aware.

HTH, 

tim


-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-10-amd64-k8
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages radiusclient1 depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libradius1  0.3.2-8  /bin/login replacement with RADIUS
ii  perl [perl5]5.8.4-8  Larry Wall's Practical Extraction 

-- no debconf information
--- include/radiusclient.h.orig	2005-08-04 10:50:19.636354682 +0200
+++ include/radiusclient.h	2005-08-04 10:48:47.955569910 +0200
@@ -38,8 +38,13 @@
 # define __P(protos) ()
 #endif
 
+#if !(defined(__x86_64__))
 typedef unsigned long UINT4;
 typedef long 	  INT4;
+#else
+typedef unsigned int UINT4;
+typedef int 	 INT4;
+#endif
 
 #define AUTH_VECTOR_LEN		16
 #define AUTH_PASS_LEN		(3 * 16) /* multiple of 16 */


Bug#307780: SMTP Auth fails with latest postfix-tls (sarge)

2005-05-05 Thread Tim Weippert
Package: postfix-tls
Version: 2.1.5-9
Severity: important


After upgrading to 2.1.5-9 my smtp auth fails between two postfix
mailservers. On the Client Side i have upgraded and now i get the
following errors (debugging peer, passwords and usernames cut off):

May  5 14:56:44 hebus postfix/qmgr[20403]: 7C8C81769B6:
from=[EMAIL PROTECTED], size=291, nrcpt=1 (queue active)
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: 220 mail.topf-sicret.org ESMTP
Postfix
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: EHLO hebus
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: 250-mail.topf-sicret.org
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: 250-PIPELINING
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: 250-SIZE 1024
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: 250-VRFY
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: 250-ETRN
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: 250-AUTH DIGEST-MD5 CRAM-MD5
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: 250-AUTH=DIGEST-MD5 CRAM-MD5
May  5 14:56:55 hebus postfix/smtp[20410]: 
mail.topf-sicret.org[217.160.140.89]: 250 8BITMIME
May  5 14:56:55 hebus postfix/smtp[20410]: server features: 0x2f size
1024
May  5 14:56:55 hebus postfix/smtp[20410]: maps_find: smtp_sasl_passwd:
hash:/etc/postfix/saslpass(0,100): mail.topf-sicret.org =
user:password
May  5 14:56:55 hebus postfix/smtp[20410]: smtp_sasl_passwd_lookup: host
`mail.topf-sicret.org' user `user' pass `password'
May  5 14:56:55 hebus postfix/smtp[20410]: starting new SASL client
May  5 14:56:55 hebus postfix/smtp[20410]: name_mask: noplaintext
May  5 14:56:55 hebus postfix/smtp[20410]: smtp_sasl_authenticate:
mail.topf-sicret.org[217.160.140.89]: SASL mechanisms DIGEST-MD5
CRAM-MD5
May  5 14:56:55 hebus postfix/master[20274]: warning: process
/usr/lib/postfix/smtp pid 20410 killed by signal 11
May  5 14:56:55 hebus postfix/master[20274]: warning:
/usr/lib/postfix/smtp: bad command startup -- throttling
May  5 14:56:55 hebus postfix/qmgr[20403]: warning: premature
end-of-input on private/smtp socket while reading input attribute name
May  5 14:56:55 hebus postfix/qmgr[20403]: warning: private/smtp socket:
malformed response
May  5 14:56:55 hebus postfix/qmgr[20403]: warning: transport smtp
failure -- see a previous warning/fatal/panic logfile record for the
problem description

Before the upgrade this environment runs over a year without problems.

With an other Client Postfix Server running unstable, the
authentication works fine. Maybe it is not a postfix-tls problem but an
sasl2 problem, but i can't verify this in deep.

I habe tried also with recompiled versions from postfix-tls and sasl2
from sarge, but that doesn't solve this issue. 

Without SMTP Auth, the system is able to communicate and deliver mails to 
the outside system.



-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.7-skas3-v8
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages postfix-tls depends on:
ii  libc6   2.3.2.ds1-21 GNU C Library: Shared libraries an
ii  libdb4.24.2.52-18Berkeley v4.2 Database Libraries [
ii  libgdbm31.8.3-2  GNU dbm database routines (runtime
ii  libsasl22.1.19-1.5   Authentication abstraction library
ii  libssl0.9.7 0.9.7e-3 SSL shared libraries
ii  postfix 2.1.5-9  A high-performance mail transport 

-- no debconf information


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



Bug#288545: mysql-query-browser: Killed on Query

2005-02-19 Thread Tim Weippert
On Sat, Jan 15, 2005 at 02:25:06PM -0600, Adam Majer wrote:
 Tim Weippert wrote:
 
 On Thu, 2005-01-13 at 12:43 -0600, Adam Majer wrote:
   
 
 Does it get killed on any query? For example, using the mysql schema,
 
 SELECT * FROM user
 
 will it get killed on this as well?
 
 
 
 Yes, it get killed on this as well. For a really short time i see the
 result in the window and then dies.
   
 
 
 Ok. So it seems to happen on a mac. (it works quite ok on a i386).
 
 I guess someone with a mac will have to debug the problem.

I have just run gdb on this, maybe it helps you or upstream to find out
what going on, i would look forward myself in the next few days:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 65539 (LWP 25210)]
0x0feeb6d8 in free_root () from /usr/lib/libmysqlclient.so.14
(gdb) thread apply all bt

Thread 6 (Thread 65539 (LWP 25210)):
#0  0x0feeb6d8 in free_root () from /usr/lib/libmysqlclient.so.14
#1  0x0ff0c908 in free_old_query () from /usr/lib/libmysqlclient.so.14
#2  0x0ff0eaa4 in mysql_close () from /usr/lib/libmysqlclient.so.14
#3  0x1011f2f4 in myx_mysql_close ()
#4  0x10064174 in MQQueryDispatcher::normal_thread ()
#5  0x10067428 in SigC::ClassSlot1_void, MQQueryDispatcher::Request*, 
MQQueryDispatcher::proxy ()
#6  0x1006747c in SigC::AdaptorBindSlot0_1_void, 
MQQueryDispatcher::Request*::proxy ()
#7  0x0ec264ec in (anonymous namespace)::call_thread_entry_slot () from 
/usr/lib/libglibmm-2.0.so.1
#8  0x0e8781fc in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#9  0x0e8781fc in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#10 0x0e8781fc in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#11 0x0e8781fc in g_static_private_free () from /usr/lib/libglib-2.0.so.0
Previous frame inner to this frame (corrupt stack?)
(gdb) 


I want to build the package with debugging symbols but haven't much time
yet ...

bye, 

tim

-- 

Every time I think I know where it's at, they move it.

Tim Weippert [EMAIL PROTECTED]
http://www.topf-sicret.org/


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



Bug#295847: gnome-icon-theme: almost all gnome icons missing or not found!?

2005-02-18 Thread Tim Weippert
Package: gnome-icon-theme
Version: 2.8.0-2
Severity: important

After upgrading the icon theme package i have lots of icons within
gnome-control-center or evolution ... some applications may not be
involved (like firefox).

I have tried to run gtk-update-icon-cache but without success (the tool
says that the cache is successfull created). Also i have tried to
reinstall the application which have the problems without success.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.11-rc4
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages gnome-icon-theme depends on:
ii  hicolor-icon-theme0.7-1  default fallback theme for FreeDes

-- no debconf information


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



Bug#295848: evolution: Patch to fix 'blank line after literal' on Exchange and Notes Imap Servers

2005-02-18 Thread Tim Weippert
Package: evolution
Version: 2.0.3-weiti.1
Severity: important
Tags: patch


With this patch they resolved some Problems on Exchange and Notes
Servers after the groupwise fix.

See here: http://bugzilla.ximian.com/show_bug.cgi?id=70556

HTH, 

tim

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.11-rc4
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages evolution depends on:
ii  evolution-data-server1.0.3-2 evolution database backend server
ii  gconf2   2.8.1-4 GNOME configuration database syste
ii  gnome-icon-theme 2.8.0-2 GNOME Desktop icon theme
ii  gtkhtml3.2   3.2.4-1 HTML rendering/editing library - b
ii  libart-2.0-2 2.3.17-1Library of functions for 2D graphi
ii  libasn1-6-heimdal0.6.3-7 Libraries for Heimdal Kerberos
ii  libatk1.0-0  1.8.0-4 The ATK accessibility toolkit
ii  libaudiofile00.2.6-5 Open-source version of SGI's audio
ii  libbonobo2-0 2.8.1-1 Bonobo CORBA interfaces library
ii  libbonoboui2-0   2.8.1-1 The Bonobo UI library
ii  libc62.3.2.ds1-20GNU C Library: Shared libraries an
ii  libcomerr2   1.36release-1   common error description library
ii  libcompfaceg11989.11.11-24   Compress/decompress images for mai
ii  libdb4.2 4.2.52-18   Berkeley v4.2 Database Libraries [
ii  libebook81.0.3-2 Client library for evolution addre
ii  libecal6 1.0.3-2 Client library for evolution calen
ii  libedataserver3  1.0.3-2 Utily library for evolution data s
ii  libegroupwise6   1.0.3-2 Client library for accessing group
ii  libesd0  0.2.35-2Enlightened Sound Daemon - Shared 
ii  libfontconfig1   2.2.3-4 generic font configuration library
ii  libfreetype6 2.1.7-2.3   FreeType 2 font engine, shared lib
ii  libgail-common   1.8.2-1 GNOME Accessibility Implementation
ii  libgail171.8.2-1 GNOME Accessibility Implementation
ii  libgal2.2-1  2.2.4-1 G App Libs (run time library)
ii  libgal2.2-common 2.2.4-1 G App Libs (common files)
ii  libgconf2-4  2.8.1-4 GNOME configuration database syste
ii  libgcrypt11  1.2.0-11LGPL Crypto library - runtime libr
ii  libglade2-0  1:2.4.2-1   library to load .glade files at ru
ii  libglib2.0-0 2.6.2-1 The GLib library of C routines
ii  libgnome-keyring00.4.1-1 GNOME keyring services library
ii  libgnome-pilot2  2.0.12-1.1  Support libraries for gnome-pilot
ii  libgnome2-0  2.8.0-6 The GNOME 2 library - runtime file
ii  libgnomecanvas2-02.8.0-1 A powerful object-oriented display
ii  libgnomeprint2.2-0   2.8.2-1 The GNOME 2.2 print architecture -
ii  libgnomeprintui2.2-0 2.8.2-2 GNOME 2.2 print architecture User 
ii  libgnomeui-0 2.8.0-3 The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0   2.8.3-11The GNOME virtual file-system libr
ii  libgnutls11  1.0.16-13   GNU TLS library - runtime library
ii  libgpg-error01.0-1   library for common error values an
ii  libgssapi1-heimdal   0.6.3-7 Libraries for Heimdal Kerberos
ii  libgtk2.0-0  2.6.2-3 The GTK+ graphical user interface 
ii  libgtkhtml3.2-11 3.2.4-1 HTML rendering/editing library - r
ii  libhowl0 0.9.8-2 Library for Zeroconf service disco
ii  libice6  4.3.0.dfsg.1-11 Inter-Client Exchange library
ii  libjpeg626b-9The Independent JPEG Group's JPEG 
ii  libkrb-1-kerberos4kth1.2.2-11.1  Kerberos Libraries for Kerberos4 F
ii  libkrb5-17-heimdal   0.6.3-7 Libraries for Heimdal Kerberos
ii  libldap2 2.1.30-3OpenLDAP libraries
ii  libnspr4 2:1.7.5-1   Netscape Portable Runtime Library
ii  libnss3  2:1.7.5-1   Network Security Service Libraries
ii  liborbit21:2.10.5-0.1libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-01.8.0-3 Layout and rendering of internatio
ii  libpisock8   0.11.8-10   Library for communicating with a P
ii  libpisync0   0.11.8-10   Synchronization library for PalmOS
ii  libpopt0 1.7-5   lib for parsing cmdline parameters
ii  libroken16-kerberos4kth  1.2.2-11.1  Roken Libraries for Kerberos4 From
ii  libsm6   4.3.0.dfsg.1-11 X Window System Session Management
ii  

Bug#295847: gnome-icon-theme: almost all gnome icons missing or not found!?

2005-02-18 Thread Tim Weippert
hi Loic, 

On Fri, 2005-02-18 at 16:30 +0100, Loïc Minier wrote:
 severity 295847 grave
 reassign 295847 libgtk2.0-bin
 merge 295815 295847
 thanks
 
 Hi,
 
 On ven, fév 18, 2005, Tim Weippert wrote:
  After upgrading the icon theme package i have lots of icons within
  gnome-control-center or evolution ... some applications may not be
  involved (like firefox).
 
  This has been reported against libgtk2.0-bin, we're working on it.
  Workaround: remove the caches.

Thanks for this, the workaround works, is there anything i can help
with?


-- 
Tim Weippert [EMAIL PROTECTED]
GnuPG Fingerprint 63E3 AA72 B3BC D0AB 583E  0382 AEA0 A1F9 AFF9 DC52
http://www.topf-sicret.org/ http://www.luug-hn.org/


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


Bug#295847: gnome-icon-theme: almost all gnome icons missing or not found!?

2005-02-18 Thread Tim Weippert
Hi, 

On Fri, 2005-02-18 at 17:05 +0100, Loïc Minier wrote:
 Hi,
 
 On Fri, Feb 18, 2005, Tim Weippert wrote:
  
  Thanks for this, the workaround works, is there anything i can help
  with?
 
  Thanks to offer your help, some people attempted to find out what is
  wrong, but the developers which were willing to track this down have
  higher priority tasks now and won't debug this further until tomorrow.

Ok, no harm with the workaround :)

  If you know how to debug this, feel free to join #gnome-debian on
  irc.gimp.org (gimpnet), I don't have a PPC Debian myself.

Ok, i think i can't debug this problem alone, but i will look at the
evening in #gnome-debian and offer my help to test or look forward.

bye, 

tim

-- 
Tim Weippert [EMAIL PROTECTED]
GnuPG Fingerprint 63E3 AA72 B3BC D0AB 583E  0382 AEA0 A1F9 AFF9 DC52
http://www.topf-sicret.org/ http://www.luug-hn.org/


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


Bug#288545: mysql-query-browser: Killed on Query

2005-01-14 Thread Tim Weippert
On Thu, 2005-01-13 at 12:43 -0600, Adam Majer wrote:
 Tim Weippert wrote:
 
 mysql-query-browser gets killed at execute an query.
   
 
 Can you reproduce this on i386?

Well, i hadn't tried it currently, but i hope that i can try it at the
weekend! I will inform you of the result.

 Does it get killed on any query? For example, using the mysql schema,
 
 SELECT * FROM user
 
 will it get killed on this as well?

Yes, it get killed on this as well. For a really short time i see the
result in the window and then dies.

HTH, 

tim

-- 
Tim Weippert [EMAIL PROTECTED]
GnuPG Fingerprint 63E3 AA72 B3BC D0AB 583E  0382 AEA0 A1F9 AFF9 DC52
http://www.topf-sicret.org/ http://www.luug-hn.org/


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