Bug#662966: Uneeded conflict between openswan and raccon
On 07.03.2012 17:42, Erik Esterer wrote: the conflict were added 2 years ago because of bug #583334 (the file /usr/share/man/man3/ipsec_set_policy.3.gz was available in both packages). But openswan doesn't contain that file anymore. Therefor I don't see a reason for the conflict anymore. Can you remove it? There is also a conflict in terms of port usage - both packages will use UDP port 500 (and optionally 4500) and therefore conflict when running at the same time. best regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646775: strongswan: Allow Strongswan uses NAT Traversal
On Monday 31 October 2011 05:55:21 T Z wrote: I've tested the version from backport and indeed it works. Please ignore my previous message. Just another question, is there any possibility to move it back to the mainstream stable repo at all? (i.e., get it from stable rather than backports) I have discussed an update enabling the NAT-T code in stongswan with the security team for Debian stable, but did not get agreement to push it into stable. Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646775: strongswan: Allow Strongswan uses NAT Traversal
On Thursday 27 October 2011 04:42:06 you wrote: By default Strongswan does not allow NAT Traversal due to its potential security risks. However this feature is very necessary for most L2TP/IPSec clients since a good number of them would be NATed and Strongswan from the Debian binary repository simply cannot handle them, for the option '--enable-nat-transport' is not included when compiling the source code. If possible could the maintainer enable NAT Traversal so it could work with NATed networks? Thanks so much. This is already being done for the packages in unstable/testing. Please try to recompile the newer versions and see if that works for you. best regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571133: openswan: pluto seems to ignore rightid if rightcert is set to missing file
On Monday 28 June 2010 07:51:07 Harald Jenny wrote: Sorry Paul but I don't think the currect behaviour is correct - there is no indication for the user why *id is ignored and this is not good :-(. I would tend to agree with that... best regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569299: Fwd: Bug#569299: Please update configure check to use new nm-glib pkgconfig file names
On Saturday 19 June 2010 18:09:40 Michael Biebl wrote: just wanted to know if there was any progress getting this new version of strongswan uploaded. I'd really appreciate if I could get rid of the symlink. I'll probably upload this week. best regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583334: racoon and openswan: error when trying to install together
On 05/27/2010 11:12 AM, Stefan Bauer wrote: Am 27.05.2010 11:05, Rene Mayrhofer schrieb: We could also simply add a mutual Conflicts, as there seems to be no reason to have both racoon and openswan installed. Actually, quite a few years ago (back in freeswan days...) it was decided between all IPsec-ish package maintainers to Provide and Conflict with a virtual ike-server package. For some reason, this seems to have been dropped. How about reviving this idea? openswan and strongswan-ikev[12] still provide ike-server, but don't conflict with it at the moment. Shall we just change that (I would need to figure out how to do this with two strongswan binary packages that actually don't conflict with each other, though)? I like it to give users the chance to decide if they want to have different software installed even if they serve the same purpose. So a conflict is not the best solution from my point of view. It might be handy to have both deamons installed alongside eachother for testing and stuff. Even tough this case is not happening quite often, it happens to the bug reporter. What is your opinion about that? I'm not sure if anybody would want both daemons installed at the same time - the bug report was created based on an automated installation test, AFAIK. Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583334: racoon and openswan: error when trying to install together
On Thursday 27 May 2010 10:24:54 Stefan Bauer wrote: thank you for your report. Do you really think, removing the manpage in one package might be clever? As both packages are using the same function under the hood, both packages need to have an appropriate manpage for this. Both packages manpages include almost the same informations in their manpage. I only see some FIXME-tags in the openswan manpages. Agreed. I would like to either rename the manpages shipped with racoon or let openswan-maintainers do that. I'm looking forward to get some response from the openswan-guys. We could also simply add a mutual Conflicts, as there seems to be no reason to have both racoon and openswan installed. Actually, quite a few years ago (back in freeswan days...) it was decided between all IPsec-ish package maintainers to Provide and Conflict with a virtual ike-server package. For some reason, this seems to have been dropped. How about reviving this idea? openswan and strongswan-ikev[12] still provide ike-server, but don't conflict with it at the moment. Shall we just change that (I would need to figure out how to do this with two strongswan binary packages that actually don't conflict with each other, though)? best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#578036: Does not work anymore, linked against libclamav5 (0.94)
On Friday 16 April 2010 10:56:44 you wrote: # /etc/init.d/havp start Cleaning up /var/spool/havp... done Starting havp: Starting HAVP Version: 0.89 LibClamAV Warning: *** LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq *** LibClamAV Warning: *** LibClamAV Error: cli_hex2str(): Malformed hexstring: This ClamAV version has reached End of Life! Please upgrade to version 0.95 or later. For more information see www.clamav.net/eol-clamav-094 and www.clamav.net/download (length: 169) LibClamAV Error: Problem parsing database at line 742 LibClamAV Error: Can't load /var/spool/havp/clamav-0daed075948713baa2faa8666de360d6/daily.ndb: Malformed database LibClamAV Error: Can't load /var/lib/clamav//daily.cvd: Malformed database One or more scanners failed to initialize! Check errorlog for errors. Exiting.. Since this morning, as planned by the clamav team. :-( Recompiled packages are available in the lenny volatile repository. You can add it as deb http://volatile.debian.org/debian-volatile lenny/volatile main best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#524045: havp: the daemon doesn't release/reopens the logfiles on reload
On Friday 16 April 2010 15:46:09 Christoph Berg wrote: Re: Heiko Schlittermann 2009-04-14 20090414122258.ga7...@jumper.schlittermann.de The postrotate script (using /etc/init.d/havp reload) does not trigger havp to release and reopen the log (access/error). Doing a ``killall -HUP havp'' seems(!) to trigger one(!) process to reopen the access/error.log. A workaround for the problem is to use copytruncate in the logrotate config. (And then possibly remove delaycompress.) Heiko, could you please test if this works for you? best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#569299: Fwd: Bug#569299: Please update configure check to use new nm-glib pkgconfig file names
Hi Martin and Andreas, Could you please update configure.in due to the libnm_glib name update? Thanks, Rene -- - Gibraltar firewall http://www.gibraltar.at/ ---BeginMessage--- Package: strongswan Severity: wishlist Tags: patch Hi, since network-manager 0.7.999-1, libnm_glib and libnm_glib_vpn have been renamed to libnm-glib and libnm-glib-vpn along with its pkgconfig files. For now, I ship compat symlinks in libnm-glib-dev and libnm-glib-vpn-dev so packages like yours don't ftbfs. As I want to get rid of those symlinks eventually, please consider updating the configure check in your package. Attached is a patch for that and I would appreciate if you forward that also to upstream. You will also need to regenerate ./configure, either by shipping a separate patch for that or running autoreconf during build time. You probably also want to bump the build-dependency on libnm-glib-vpn-dev to = 0.7.999. Thanks for considering, Michael -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.33-rc7 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- configure.in.orig 2010-02-11 11:44:50.392808082 +0100 +++ configure.in2010-02-11 11:45:12.240095694 +0100 @@ -1024,7 +1024,7 @@ fi if test x$nm = xtrue; then - PKG_CHECK_MODULES(nm, [NetworkManager libnm_glib_vpn gthread-2.0]) + PKG_CHECK_MODULES(nm, [NetworkManager libnm-glib-vpn gthread-2.0]) AC_SUBST(nm_CFLAGS) AC_SUBST(nm_LIBS) fi ---End Message--- signature.asc Description: This is a digitally signed message part.
Bug#569299: Fwd: Bug#569299: Please update configure check to use new nm-glib pkgconfig file names
On Monday 19 April 2010 12:13:29 Martin Willi wrote: Hi Rene, Could you please update configure.in due to the libnm_glib name update? strongSwan 4.3.6 already supports _ and - libnm packages, see changeset [1]. Ah, just saw it - perfect, we can close the bug report with the next upload. best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#567823: Please include late translation for strongswan if possible
On Sunday 07 February 2010 19:12:48 Helge Kreutzmann wrote: On Sun, Feb 07, 2010 at 06:51:28PM +0100, Christian PERRIER wrote: Quoting Helge Kreutzmann (deb...@helgefjell.de): due to a communication problem (sorry) within the German team the deadline for the i18n update was missed and apparently an old German translation was used. It would be great if you could include it for Squeeze, still. If you need help doing so (I can't NMU, though, as I'm only a Maintainer) don't hesitate to ping me. It means NMUing the package again, or have the maintainer upload. I need at least an ACK from him for doing so. Yes, I know. If there is anything I can do to facilitate the process, I'll gladly do so (as long as possible). Thanks for you quick response. Feel free to NMU strongswan, I'll add the patch to my repository. best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#540776: RM: freeswan -- ROM; Transition package now obsolete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: ftp.debian.org Severity: normal Please remove freeswan, freeswan-modules-source, and kernel-patch-freeswan. For lenny, these were transitional packages, but they should no longer be necessary in sid/testing and currently break installation of openswan. Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp/+IMACgkQq7SPDcPCS94lEgCfXKUKEqxmgbTFAu+gVgPp/XTU +tYAoKnrVmw2uFfK46dR5xl8HTOG8MyW =dqe2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537335: openswan: Typo in init.d LSB header make it fail to work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petter Reinholdtsen schrieb: Are you OK with me NMUing to fix this issue, or do you plan to work on it in the next few days? No problem from my side - please feel free to NMU in unstable (openswan updates will soon happen in stable and oldstable). best regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkptVpcACgkQq7SPDcPCS94KFgCgm9MKfAd+GZjImND2yGC4rxW8 a0MAnRx5cajY5ENsAZ+XP7Z/RL374FOF =2JmH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528073: strongswan: General update after the debconf review process
On Saturday, 23. May 2009 22:37:37 Jonathan Wiltshire wrote: Please notify me of your intents with regards to this. In case you are short of time, I can either prepare and upload a non-maintainer upload or prepare an upload for you. I intend to do the upload myself, but it may take a few days (and I will wait for the announced second tarball before applying). best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#528073: strongswan: General update after the debconf review process
On Monday, 25. May 2009 17:32:30 Jonathan Wiltshire wrote: On Sun, May 24, 2009 at 08:05:48AM +0200, Christian Perrier wrote: Also, your patch still contains the trailing spaces I mentioned in a previous answer: Yep, I spotted that too. I've corrected all the spacing problems in the translations received so far, and unfuzzied them (in fact, in all cases the translator had already anticipated this). The problem with ja.po seems to be that the translation was made before the Smith review was complete, and I carelessly didn't spot this. I've emailed Hideki with an up-to-date po file; in the meantime, Rene: do you want to wait for this or proceed with an upload of the translations as they stand at the moment? I'll wait for that update. best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#528073: strongswan: [debconf_rewrite] Debconf templates review
On Sunday 10 May 2009 18:50:23 Jonathan Wiltshire wrote: Please review the suggested changes are suggested, and if you have any objections, let me know in the next 3 days. No objections from my side. best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#521949: CVE-2009-0790: DoS
On Tuesday 31 March 2009 01:55:46 Steffen Joeris wrote: I've attached the patch from stable-security, please consider including it for unstable/testing. Unfortunately, this doesn't apply as dpd code seems to have moved out of demux.c (I didn't find any of the patch context). Have you had contact with openswan upstream concerning this bug? best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#520671: Fwd: Bug#520671: openswan: Unable to specify a specific MTU on a vpn tunnel
Hi Openswan and strongSwan teams, I recently received a wishlist item in the Debian BTS and fully agree that it would make sense to support setting the MTU on a per-tunnel basis. What do you think? best regards, Rene ---BeginMessage--- Package: openswan Severity: wishlist Hi, It sould really be a nice feature to be able to specify lock the mtu for a specific tunnel when having issues at some ISPs. For the time being I had to override the mtu in /usr/lib/ipsec/_updown parms3=$parms3 mtu lock 1412 Thanks Laurent -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.27.7-icc-20081122 (SMP w/4 CPU cores) Locale: lang=fr...@euro, lc_ctype=fr...@euro (charmap=ISO-8859-1) (ignored: LC_ALL set to fr_FR) Shell: /bin/sh linked to /bin/bash ---End Message---
Bug#516914: live-initramfs: should check if /var/log is writable before copying
Package: live-initramfs
Severity: wishlist
Tags: patch
Justification: cosmetical
The attached patch just adds a check before trying to copy live.log to the
newly mounted root filesystem. When using the exposedroot skipunion options,
then /var/log may not be writable at this time, resulting in an error message
during bootup. The patch fixed this.
-- System Information:
Debian Release: 5.0
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500,
'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.27-12-generic (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 live-initramfs depends on:
ii busybox 1:1.10.2-2 Tiny utilities for small and
embed
ii file 4.26-2 Determines file type using magic
pn initramfs-tools none (no description available)
ii sudo 1.6.9p17-2 Provide limited super user
privile
pn udev none (no description available)
pn user-setupnone (no description available)
Versions of packages live-initramfs recommends:
pn eject none (no description available)
ii uuid-runtime 1.41.3-1 universally unique id library
ii wget 1.11.4-2 retrieves files from the web
Versions of packages live-initramfs suggests:
pn curlftpfs none (no description available)
pn genext2fs none (no description available)
pn httpfs2 none (no description available)
pn loop-aes-utilsnone (no description available)
pn mtd-tools none (no description available)
ii squashfs-tools1:3.3-7Tool to create and append to
squas
--- usr/share/initramfs-tools/scripts/live~ 2009-02-08 15:09:09.0 +0100
+++ usr/share/initramfs-tools/scripts/live 2009-02-24 10:41:29.0 +0100
@@ -1585,5 +1585,5 @@
exec 16 6-
exec 27 7-
kill ${tailpid}
- cp live.log ${rootmnt}/var/log/
+ [ -w ${rootmnt}/var/log/ ] cp live.log ${rootmnt}/var/log/ 2/dev/null
}
signature.asc
Description: This is a digitally signed message part.
Bug#509446: live-initramfs: Support further checks on loopback image and support skipping union mounts
Package: live-initramfs
Version: 1.154.3-1
Severity: wishlist
Tags: patch
To use live-initramfs for the Gibraltar firewall distribution, I ported two
missing features from my own mkinitrd-cd package to work as scripts/hooks
within the initramfs-tools framework and plug into live-initramfs. Although
most can be implemented this way, a minor patch is required for the live
script to:
- Call another set of scripts after finding the loopback image that is about to
be mounted but just before actually mounting it. This allows to perform
further checks at this stage.
- Completely bypass the unionfs mounts so that this can be handled by custom
distribution scripts during bootup. The reason is that even larger parts of
the filesystem should remain read-only for security reasons.
The attached patch is quite minor and non-intrusive and will not change any
current functionality when the added options are not used. Please consider
applying it so that the Debian package can be used without further changes.
Thanks,
Rene
-- Package-specific info:
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.27-11-generic (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages live-initramfs depends on:
ii busybox 1:1.10.2-2 Tiny utilities for small and
embed
ii file 4.26-2 Determines file type using magic
ii initramfs-tools 0.92n tools for generating an initramfs
ii sudo 1.6.9p17-1 Provide limited super user
privile
ii udev 0.125-7/dev/ and hotplug management
daemo
ii user-setup1.23 Set up initial user and password
Versions of packages live-initramfs recommends:
pn eject none (no description available)
ii uuid-runtime 1.41.3-1 universally unique id library
ii wget 1.11.4-2 retrieves files from the web
Versions of packages live-initramfs suggests:
pn curlftpfs none (no description available)
pn genext2fs none (no description available)
pn httpfs2 none (no description available)
pn loop-aes-utilsnone (no description available)
pn mtd-tools none (no description available)
ii squashfs-tools1:3.3-7Tool to create and append to
squas
-- no debconf information
diff -r 6619a22cc6aa usr/share/initramfs-tools/scripts/live
--- a/usr/share/initramfs-tools/scripts/live Sun Dec 21 21:14:42 2008 +0100
+++ b/usr/share/initramfs-tools/scripts/live Mon Dec 22 14:25:13 2008 +0100
@@ -427,6 +427,11 @@
export PLAIN_ROOT
;;
+ skipunion)
+SKIP_UNION_MOUNTS=Yes
+export SKIP_UNION_MOUNTS
+;;
+
root=*)
ROOT=${ARGUMENT#root=}
export ROOT
@@ -1085,6 +1090,12 @@
do
imagename=$(basename ${image})
+export image devname
+maybe_break live-realpremount
+log_begin_msg Running /scripts/live-realpremount
+run_scripts /scripts/live-realpremount
+log_end_msg
+
if [ -d ${image} ]
then
# it is a plain directory: do nothing
@@ -1242,8 +1253,12 @@
mount --bind ${exposedrootfs} ${rootmnt} || \
panic bind mount of ${exposedrootfs} failed
- cow_dirs='/var/tmp /var/lock /var/run /var/log /var/spool
- /home /var/lib/live'
+if [ -z ${SKIP_UNION_MOUNTS} ]; then
+cow_dirs='/var/tmp /var/lock /var/run /var/log /var/spool
+/home /var/lib/live'
+else
+cow_dirs=''
+fi
for dir in ${cow_dirs}; do
mkdir -p /cow${dir}
signature.asc
Description: This is a digitally signed message part.
Bug#502048: havp: Havp init fails after reboot if /var/run is tempfs
On Monday 13 October 2008, Scott Kitterman wrote: since /var/run/havp no longer exists. I'll add a patch in a moment. Thanks, applied! best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#507542: strongswan: endless loop
On Dienstag, 2. Dezember 2008, Vladimir Stavrinov wrote: The similar configuration is on the other side. There are no problem when connection initiating from one side of tunnel and VPN are working fine. But if it is originated from other side, the following scenario are rolling up. At the first time ipsec started, the tunnel is build and working as should. It is successfully rekeying few times with keylife period. But when ikelifetime expired, the tunnel destroyed and rebuild again repeatedly in the endless loop. Analyzing the syslog I have found the only difference between two side in the strange message: charon: 08[IKE] reauthenticating IKE_SA due address change That's the first time I am reading this message. Hmm... If this means ip address then it is not true: no address changed. I have tried to reproduce this situation on the virtual machines with most close network configuration without success. Changing interfaces and firewall and default route has no effect. Adding mobike = no to config cause this endless loop immediately after ipsec starting up. I can't find the source of problem. Can you reproduce this problem on another set of machines as well? best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#507542: strongswan: endless loop
On Dienstag, 2. Dezember 2008, Vladimir Stavrinov wrote: If this means ip address then it is not true: no address changed. I have tried to reproduce this situation on the virtual machines with most close network configuration without success. Changing interfaces and firewall and Can you reproduce this problem on another set of machines as well? Do You read this few lines above? I can not. I have tried to do so on virtual (kvm) machines with network configuration as close as possible to real situation including ppp as default route. But there are no such problem: vpn work in any configurations. I actually meant if you could reproduce it using another set of Debian installs in _exactly the same positions_ instead of being close to the network configuration. Rene signature.asc Description: This is a digitally signed message part.
Bug#497213: [SPAM] Re: Bug#497213: libmono-system-web2.0-cil: Please include System.Web.Extensions.dll, for example in non-free
On Sunday 31 August 2008, Jo Shields wrote: The problem code has actually been released under a new (DFSG-friendly) license in the development version of Mono, so if you were to prepare a dpatch file against 1.9.1+dfsg-3 containing System.Web.Extensions from Mono SVN, we would be open to including it. However, with Lenny frozen, we can't make any promises. Unfortunately, I'm not sure I can afford the time right now, considering that it'll be uncertain to make it into Lenny. Would somebody else who is already familiar with the code in question be able to prepare the patch more quickly? Post-Lenny, (i.e. once Mono 2.0 is in Debian), the problem will go away. Are there any preliminary 2.0 packages available that I could test? I need a solution pretty soon, and installing the upstream binary distribution is not my favourite option. I'd rather install experimental packages (and maybe upgrade others) if available. best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#497213: libmono-system-web2.0-cil: Please include System.Web.Extensions.dll, for example in non-free
Package: libmono-system-web2.0-cil Version: 1.9.1+dfsg-3 Severity: important Justification: Non-obvious and non-documented failure by differing from upstream distribution The problem with the current packaging is that System.Web.Extensions.dll is missing without this being obvious. Yes, it's documented in changelog.Debian.gz (who reads this file upon installation???), but doesn't seem to be hinted anywhere else. When trying web applications (specifically, Mojoportal), then it is non-obvious why it fails when all documentation says it should work. Please re-include System.Web.Extension.dll, either by removing or replacing the non-DFSG code or, as a quick solution, a separate package in non-free. This will allow standard web applications to work in Debian (when they work perfectly with the official mono distributions). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libmono-system-web2.0-cil depends on: ii libgdiplus 1.9-1interface library for Mono class S ii libmono-corlib2.0-cil 1.9.1+dfsg-3 Mono core library (2.0) ii libmono-sqlite2.0-cil 1.9.1+dfsg-3 Mono Sqlite library ii libmono-system-data2.0-cil 1.9.1+dfsg-3 Mono System.Data Library ii libmono-system2.0-cil 1.9.1+dfsg-3 Mono System libraries (2.0) ii libmono2.0-cil 1.9.1+dfsg-3 Mono libraries (2.0) ii mono-jit1.9.1+dfsg-3 fast CLI JIT/AOT compiler for Mono libmono-system-web2.0-cil recommends no packages. Versions of packages libmono-system-web2.0-cil suggests: ii libmono-winforms2.0-cil 1.9.1+dfsg-3 Mono System.Windows.Forms library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489721: RM: gibraltar-bootcd -- ROM;
Package: ftp.debian.org Severity: normal The package has been mostly obsoleted by initramfs-tools. A future version will be integrated with initramfs-tools and be re-uploaded with just the added functionality. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-19-generic (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash signature.asc Description: This is a digitally signed message part.
Bug#479891: Bug#479885: php-clamavlib: FTBFS: clamav.c:164: error: 'struct cl_limits' has no member named 'maxratio'
On Mittwoch, 7. Mai 2008, Stephen Gran wrote: I tried to warn all of you ahead of time, but I didn't hear anything back. If you need help porting your application to work with the new API, let me know and I'll see what I can do. A patch would certainly be appreciated :) best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#461841: Announce of the upcoming NMU for the openswan package
On Sonntag, 6. April 2008, Christian Perrier wrote: Among these, the following translations are incomplete: cs es nl pt pt_BR sv vi I plan to do a new upload within the next few days and will include all updates that are currently in BTS. best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#474062: gibraltar-bootcd: should this package be removed?
On Donnerstag, 3. April 2008, Barry deFreese wrote: If you disagree and want to continue to maintain this package, please just close this bug and do an upload also fixing the other issues. A redesign of the whole package to make use of initramfs-tools is currently pending, but will take a few more weeks at least. I would like to leave the package as it is right now and do a single upload to get it into shape again with a new base system. best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#453785: gibraltar-bootcd: FTBFS: dpkg-shlibdeps: failure: couldn't find library libc.so.0 needed by debian/mkinitrd-cd/usr/lib/mkinitrd-cd/paste (its RPATH is '').
On Montag, 31. März 2008, Petter Reinholdtsen wrote: I was planning to NMU this package to solve bugs #459872 and #431703, but am unable to do so because the source fail to build due to this bug. According to popcon.debian.org, there are no installations using this package, which might be explained by bug #431703 making the gibraltar-bootsupport package impossible to install. Because of this, I suggest this issue is fixed quickly, or the package is removed from the archive to avoid confusing users with an unusable package. I am in the process of reworking the whole gibraltar-bootcd source package, and one of the issues is to fix gibraltar-bootsupport (the other is to port mkinitrd-cd to turn into hooks for initramfs-tools instead of a completely stand-alone initrd creation tool). I expect this conversion to take a few more weeks at least, but after that both issues should be solved. The package description should make it fairly clear to most users that, in the mean time, this package should not be installed unless they have very specific needs. best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#439977: Will OpenSwan 2.5.x be packaged?
On Freitag 28 März 2008, Vincent Bernat wrote: Will OpenSwan 2.5.x be packaged to solve this bug? Is any help needed? I'm in the process of updating openswan to the latest 2.4.x now (2.4.12 is supposed to work with kernels 2.6.22 according to the changelog) - 2.5 seems to be unstable at the moment. However, I could need testers, as I only use openswan KLIPS support on 2.4 kernels myself and use strongswan for 2.6sec support. Would you be able to thoroughly test KLIPS on 2.6.23/24 if I sent you test packages of openswan 2.4.12? best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#472317: ITP: placelab-linux -- Estimate location based on WLAN, Bluetooth, or GSM
Package: wnpp Severity: wishlist Owner: Rene Mayrhofer [EMAIL PROTECTED] * Package name: placelab-linux Version : 2.1 Upstream Author : Intel research labs * URL : http://www.placelab.org/ * License : GPL Programming Lang: Java with some native code Description : Estimate location based on WLAN, Bluetooth, or GSM Place Lab is software providing low-cost, easy-to-use device positioning for location-enhanced computing applications. Place Lab tries to provide positioning which works worldwide, both indoors and out (unlike GPS which only works well outside). Place Lab clients can determine their location privately without constant interaction with a central service (unlike badge tracking or mobile phone location services where the service owns your location information). The Place Lab approach is to allow devices like notebooks, PDAs and cell phones to locate themselves by listening for radio beacons such as 802.11 access points, GSM cell phone towers, and fixed Bluetooth devices that already exist in large numbers around us in the environment. These beacons all have unique or semi-unique IDs, for example, a MAC address. Clients compute their own location by hearing one or more IDs, looking up the associated beacons’ positions in a locally cached map, and estimating their own position referenced to the beacons’ positions. Note that Place Lab will work best if you have (or create) an account on wigle.net to access WLAN beacon databases. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-12-generic (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash signature.asc Description: This is a digitally signed message part.
Bug#449512: Please include Patch in Debian-Package
On Mittwoch 16 Januar 2008, Horst Vissel wrote: Bug ist fixed in upstream till 08-25-07. Any chance that the patch will be included in the debian package soon? I'll try to do an upload as soon as possible. best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#458646: ppp: Please support arbitrary interface names [patch]
Subject: ppp: Please support arbitrary interface names
Package: ppp
Version: 2.4.4rel-9
Severity: normal
Justification (for not being wishlist): because selectable interface names are
becoming necessary on today's increasingly complex ADSL, UMTS; etc.
configrations
Tags: patch, upstream
*** Please type your report below this line ***
Use of arbitrary and freely selectable network interface names both improves
manageability of systems with multiple interfaces (e.g. two outgoing ADSL
lines for upstream connection and multiple incoming L2TP/IPSec tunnels with
obviously very different settings/requirements) and makes firewalling much
easier. Although pppX interface names can be changed with
ip link set pppX name , e.g. in ip-up.d/ scripts, this solution is far
from optimal because ppp itself gets confused when the current interface name
does not correspond to its internal unit name. The most obvious breakage is
that statistics no longer get printed (e.g. to syslog) when terminating a
connection and that the CONNECT_TIME, BYTES_RCVD, and BYTES_SENT variables
are not set for ip-down scripts. This makes accurate accounting and keeping
track of quota a lot harder.
I found the attached patch on the ppp mailing list archives from quite a while
ago and forward-ported it to ppp 2.4.4 with Debian specific patches taken into
consideration. It should apply cleanly when dropping the attached file into
debian/patches. When applied, the new option ifname can be used e.g. in
/etc/ppp/peers/YYY to set which interface name should be used for the specific
connection. This is complementary to the existing linkname option, which is
not sufficient for clean interaction with firewalling, NAT, policy routing,
IPSec, etc.
I have tested it on multiple systems with and without this option being used
and found no issues at all (elthough I have not tried multilink, which the
patch also seems to take care of). It will be used for all ppp versions in
future Gibraltar releases.
Please consider applying it to future ppp packages.
best regards,
Rene
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (800, 'testing'), (300, 'unstable'), (100, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages ppp depends on:
ii libc6 2.7-5 GNU C Library: Shared libraries
ii libpam-modules0.99.7.1-5 Pluggable Authentication Modules
f
ii libpam-runtime0.99.7.1-5 Runtime support for the PAM
librar
ii libpam0g 0.99.7.1-5 Pluggable Authentication Modules
l
ii libpcap0.80.9.8-2System interface for user-level
pa
ii netbase 4.30 Basic TCP/IP networking system
ii procps1:3.2.7-5 /proc file system utilities
ppp recommends no packages.
-- no debconf information
diff -urN ppp-2.4.4.orig/pppd/auth.c ppp-2.4.4/pppd/auth.c
--- ppp-2.4.4.orig/pppd/auth.c Tue Jan 1 14:44:37 2008
+++ ppp-2.4.4/pppd/auth.c Tue Jan 1 14:45:12 2008
@@ -647,8 +647,10 @@
}
if (!hungup)
lcp_lowerdown(0);
-if (!doing_multilink !demand)
+if (!doing_multilink !demand) {
script_unsetenv(IFNAME);
+script_unsetenv(IFUNIT);
+}
/*
* Run disconnector script, if requested.
diff -urN ppp-2.4.4.orig/pppd/main.c ppp-2.4.4/pppd/main.c
--- ppp-2.4.4.orig/pppd/main.c Tue Jan 1 14:44:37 2008
+++ ppp-2.4.4/pppd/main.c Tue Jan 1 14:45:12 2008
@@ -739,9 +739,14 @@
set_ifunit(iskey)
int iskey;
{
-info(Using interface %s%d, PPP_DRV_NAME, ifunit);
slprintf(ifname, sizeof(ifname), %s%d, PPP_DRV_NAME, ifunit);
-script_setenv(IFNAME, ifname, iskey);
+info(Using interface %s, ifname);
+script_setenv(IFUNIT, ifname, iskey);
+if (req_ifname[0] sys_change_ifname(ifname, req_ifname)) {
+ slprintf(ifname, sizeof(ifname), %s, req_ifname);
+info(Changing interface to %s, ifname);
+}
+script_setenv(IFNAME, ifname, 0);
if (iskey) {
create_pidfile(getpid()); /* write pid to file */
create_linkpidfile(getpid());
diff -urN ppp-2.4.4.orig/pppd/multilink.c ppp-2.4.4/pppd/multilink.c
--- ppp-2.4.4.orig/pppd/multilink.c Tue Jan 1 14:44:37 2008
+++ ppp-2.4.4/pppd/multilink.c Tue Jan 1 14:45:12 2008
@@ -204,7 +204,7 @@
/* make sure the string is null-terminated */
rec.dptr[rec.dsize-1] = 0;
/* parse the interface number */
- parse_num(rec.dptr, IFNAME=ppp, unit);
+ parse_num(rec.dptr, IFUNIT=ppp, unit);
/* check the pid value */
if (!parse_num(rec.dptr, PPPD_PID=, pppd_pid)
|| !process_exists(pppd_pid)
@@ -417,7 +417,7 @@
TDB_DATA kd, vd;
int ret = 0;
- slprintf(ifkey, sizeof(ifkey), IFNAME=ppp%d, unit);
+ slprintf(ifkey, sizeof(ifkey), IFUNIT=ppp%d, unit);
kd.dptr = ifkey;
kd.dsize = strlen(ifkey);
vd =
Bug#456309: vlan: [patch] support arbitrary interface names
On Freitag 14 Dezember 2007, you wrote: Looking at what it does, I think it doesn't need to be specific to vlan. Couldn't you as well rename any interface with a name parameter? Yes, very true. But renaming vlan interfaces is a special case, not only because they are removed again by ifdown (and for that, keeping the number makes it easier). For renaming all other kinds of interfaces (physical ones, to be precise), ifrename is currently the preferred solution. However, as vlan interfaces don't exist before ifup is called for them, ifrename can't be used for this case and we consequently need special handling. The combination of the current ifupdown, ifrename, and vlan packages work flawlessly with this small patch applied. best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#456309: vlan: [patch] support arbitrary interface names
Package: vlan Version: 1.9-3 Severity: wishlist I have been using a small extension for the if-pre-up.d/vlan script for quite some time for Gibraltar firewall. This patch allows to use arbitrary interface names for the VLAN interfaces such as dmz.0 and external.1 as long as the .number extension is used (mostly so that the if-post-down.d/vlan script can remove it again). There are no problems whatsoever in practice, and we have been using a script like that on many in-production boxes so far. Please consider applying this for the next release. --- /etc/network/if-pre-up.d/vlan~ 2007-09-30 18:16:10.0 +0200 +++ /etc/network/if-pre-up.d/vlan 2007-12-14 15:16:16.0 +0100 @@ -30,12 +30,14 @@ [ -z $IF_VLAN_RAW_DEVICE ] exit 0 vconfig set_name_type DEV_PLUS_VID VLANID=`echo $IFACE|sed s/[^.]*\.0*//g` +VLANBASE=echo $IFACE|sed s/\..*//g ;; *.*) # Silently ignore interfaces which we do not (know how to) support [ -z $IF_VLAN_RAW_DEVICE ] exit 0 vconfig set_name_type DEV_PLUS_VID_NO_PAD VLANID=`echo $IFACE|sed s/[^.]*\.0*//g` +VLANBASE=echo $IFACE|sed s/\..*//g ;; *) @@ -55,6 +57,12 @@ vconfig add $IF_VLAN_RAW_DEVICE $VLANID fi +# addition to allow for arbitrary names, Rene Mayrhofer, 2006-03-30 +# if the name doesn't fit in one of the standard schemes, rename now before activating +if [ -n $VLANBASE -a $VLANBASE != $IF_VLAN_RAW_DEVICE ]; then + ip link set $IF_VLAN_RAW_DEVICE.$VLANID name $IFACE +fi + # This is not vlan specific, and should actually go somewhere else. if [ -n $IF_HW_MAC_ADDRESS ]; then ip link set $IFACE address $IF_HW_MAC_ADDRESS -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (800, 'testing'), (300, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vlan depends on: ii iproute 20070313-1 Professional tools to control the ii libc6 2.7-3 GNU C Library: Shared libraries vlan recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455468: linux-image-2.6.18-5-xen-686: kernel BUG on drbd disconnect
Subject: linux-image-2.6.18-5-xen-686: kernel BUG on drbd disconnect
Package: linux-image-2.6.18-5-xen-686
Version: 2.6.18.dfsg.1-13etch4
Severity: important
My cluster of 2 Debian etch boxes (on Intel CPUs with vmx support) running
drbd8 on Linux kernel packages linux-image-2.6.18-4-xen-686
(2.6.18.dfsg.1-12etch2) or linux-image-2.6.18-5-xen-686
(2.6.18.dfsg.1-13etch4), the latter sometimes exposing a Xen networking bug
similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451297 on one of
the systems (but I haven't started debugging this one). I have compiled my
own drbd8 kernel modules, so that Debian package version is 8.0.7-1 for both
drbd8-utils and drbd8-2.6.18-*-xen-686. Xen packages are from Debian etch,
i.e. xen-utils-3.0.3-1, xen-hypervisor-3.0.3-1-i386-pae, etc. version
3.0.3-0-4. domU instances are also Debian etch using
linux-image-2.6.18-4-xen-686 to start from dom0 and
linux-modules-2.6.18-4-xen-686 installed in the domUs.
Both boxes have a ca. 60GB LVM2 VG with 20 LVs of equal size and name on
both. There is one drbd resource for each LV (currently up to drbd28, but
using only every second one for now), which are used as backend devices for
the Xen domUs. At any time, only one node switches the respective drbd
resource to primary and then starts the domU (live migration is not yet
used, so primary-primary does not happen right now). The drbd resources all
have a similar configuration:
resource xen-xxx {
protocol C;
startup {
wfc-timeout 120; ## 2 minutes.
degr-wfc-timeout 120; ## 2 minutes.
}
disk {
on-io-error detach;
}
net {
max-buffers 128;
allow-two-primaries;
cram-hmac-alg sha256;
shared-secret ;
after-sb-0pri disconnect;
after-sb-1pri disconnect;
after-sb-2pri disconnect;
rr-conflict disconnect;
}
syncer {
rate 50M;
after xen-yyy;
}
on {
device /dev/drbd26;
disk/dev/mapper/xendomains-xxx;
address 192.168.255.30:7814;
meta-disk internal;
}
on {
device /dev/drbd26;
disk/dev/mapper/xendomains-xxx;
address192.168.255.29:7814;
meta-disk internal;
}
}
That is, syncer rate is moderate (1Gbps connection), max-buffers low so as not
to run into out-of-memory issues (this used to be a problem), and the syncer
is serialized.
Sometimes, when rebooting one of the nodes, it will crash the respective
other. This is reproducible, but not ever time. Just an hour ago, it happened
again and we were able to capture the kernel output on the serial console
after reboot was started on the other node (so to be clear: this is the one
that wasn't touched by any manual intervention):
drbd0: meta connection shut down by peer.
drbd26: meta connection shut down by peer.
drbd0: tl_clear()
drbd26: tl_clear()
drbd28: meta connection shut down by peer.
drbd28: tl_clear()
drbd24: PingAck did not arrive in time.
drbd24: short read expecting header on sock: r=-512
drbd24: tl_clear()
drbd20: PingAck did not arrive in time.
drbd20: short read expecting header on sock: r=-512
drbd20: tl_clear()
drbd14: PingAck did not arrive in time.
drbd14: short read expecting header on sock: r=-512
drbd14: tl_clear()
drbd4: PingAck did not arrive in time.
drbd4: short read expecting header on sock: r=-512
drbd4: tl_clear()
drbd10: PingAck did not arrive in time.
drbd10: short read expecting header on sock: r=-512
drbd10: tl_clear()
drbd6: PingAck did not arrive in time.
drbd6: short read expecting header on sock: r=-512
drbd6: tl_clear()
drbd22: PingAck did not arrive in time.
drbd22: short read expecting header on sock: r=-512
drbd22: tl_clear()
BUG: unable to handle kernel paging request at virtual address c081e000
printing eip:
c01bb090
19529000 - *pde = 0001:19f48001
27948000 - *pme = :07099067
01099000 - *pte = :
Oops: [#1]
SMP
Modules linked in: sha256 drbd cn xt_physdev button ac battery ocfs2_dlmfs
ocfs2_dlm ocfs2_nodemanager configfs bridge ip6t_LOG ipt_LOG xt_state
ipt_REJECT xt_tcpudp ip6table_filter ip6_tables ipv6 iptable_mangle
iptable_nat ip_nat ip_conntrack nfnetlink iptable_filter ip_tables x_tables
xfs dm_crypt loop serio_raw serial_core psmouse rtc pcspkr shpchp pci_hotplug
tsdev evdev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod raid1 md_mod
ide_generic ide_cd cdrom sd_mod generic usbhid tg3 skge ahci libata piix
scsi_mod ide_core ehci_hcd uhci_hcd usbcore thermal processor fan
CPU:0
EIP:0061:[c01bb090]Not tainted VLI
EFLAGS: 00010202 (2.6.18-5-xen-686 #1)
EIP is at csum_partial+0x88/0x120
eax: ebx: c01bb0f0 ecx: 0007 edx: 0400
esi: c081e080 edi: 0408 ebp: 0064 esp: c031fd54
ds: 007b es: 007b ss: 0069
Process swapper (pid: 0, ti=c031e000 task=c02cf660 task.ti=c031e000)
Stack: c081e000 0064 c022d626 c081e000 0400 0010 e4f00d2c
0050 0464 c911cef4 c022e532
Bug#449365: strongswan: [INTL:fr] French debconf templates translation update
On Samstag 10 November 2007, Christian Perrier wrote: Quoting Rene Mayrhofer ([EMAIL PROTECTED]): On Montag 05 November 2007, Christian Perrier wrote: Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. The templates file is no longer called strongswan.templates.master, but strongswan.templates - which is why I changed the fr.po file accordingly in the last upload. Is there a specific reason for changing it back in this version? Hmmm, anyway, the original file name is not really important in PO files. But something in the build process broke when it was not corrected, so there seems to be an importance to the debhelper tools. So, you can safely put the file I sent in #449365 in debian/po, run debconf-updatepo and voilà. As far as I can see, this file name change is the only change from my current fr.po to the one you attached to this bug report. If you can't find any other difference, could you please close the bug report? best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#449365: strongswan: [INTL:fr] French debconf templates translation update
On Montag 05 November 2007, Christian Perrier wrote: Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. The templates file is no longer called strongswan.templates.master, but strongswan.templates - which is why I changed the fr.po file accordingly in the last upload. Is there a specific reason for changing it back in this version? best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#406029: openswan: Template patch
On Samstag 27 Oktober 2007, Matthias Julius wrote: You seem to agree with me that there should be no space before a question mark. And this is exactly what the patch does. It removes all the spaces that currently are in front of question marks. Sorry, you're right (seems I read the patch the wrong way around...). I'm correcting that now. Rene signature.asc Description: This is a digitally signed message part.
Bug#446556: openswan installation takes a very long time without any warning
On Samstag 13 Oktober 2007, Uwe Storbeck wrote: The key generation during the openswan installation took more than 40 minutes on my system without any warning. The installation hung between the following two lines: Setting up openswan (2.4.6+dfsg.2-1.1) ... Successfully created a plain openswan RSA keypair. This seems like your system did not have any entropy. Is it diskless? Rene -- - Gibraltar firewall http://www.gibraltar.at/ signature.asc Description: This is a digitally signed message part.
Bug#438738: RM: uclibc -- RoQA; RC-buggy; unmaintained
On Sonntag 26 August 2007, Luk Claes wrote: On Sun, Aug 26, 2007 at 12:20:46PM +0200, Joerg Jaspert wrote: tags 438738 moreinfo thanks Hi Hi Rene uclibc is about to be removed, though one of your packages depends on it. Can you please adopt uclibc, ask for removal of gibraltar-bootcd or don't depend on uclibc anymore? A new version of gibraltar-bootcd is now being worked on that will no longer depend on uclibc. However, this is going to be a major new version, and I expect it to take at least 2 more months to get into an uploadable state... with best regards, Rene Not until someone dealt with: Checking reverse dependencies... ** mkinitrd-cd has an unsatisfied dependency on i386: uclibc-toolchain (= 0.9.26-1) ** mkinitrd-cd has an unsatisfied dependency on i386: libuclibc-dev (= 0.9.26-1) ** gibraltar-bootcd has an unsatisfied build-dependency: uclibc-toolchain (= 0.9.26-1) ** ** gibraltar-bootcd has an unsatisfied build-dependency: libuclibc-dev (= 0.9.26-1) Dependency problem found. Continue (y/N)? -- bye Joerg DarkRider also dies ist so ziemlich der einzige chanel wo ich meist 0 peile DarkRider ich schreibe etwas dann rennen se alle gegen die wand und schreien aua signature.asc Description: This is a digitally signed message part.
Bug#390913: xserver-xorg-video-i810: blank screen after suspend
On Samstag, 23. Juni 2007, Brice Goglin wrote: I am contacting all of you again since everybody does not agree whether this bug is fixed or not. It could be related to which chipset you have. It would be good if all of you could try with the latest xserver-xorg-video-intel driver (2:2.0.0-5 currently in experimental). It is supposed to resume well. -5 is certainly an improvement for me, as now the resume seems to be really stable (it wasn't completely stable with -4, making X crash upon resume about 1/3 of the time). From my side, the bug can be closed. with best regards, Rene signature.asc Description: This is a digitally signed message part.
Bug#390913: xserver-xorg-video-i810: blank screen after suspend
On Donnerstag, 24. Mai 2007 15:18, Roberto Lumbreras wrote: : What is the status of this bug now that xserver-xorg-core 1.3 and : xserver-xorg-video-intel 2.0 are in unstable? : : Did you guys see Brandon Philips' comment: : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390913;msg=38 As mentioned earlier, it partially works for me now. Suspend-to-RAM is not as stable as it was with 1.5.1 (the X server crashes roughly every fourth time I wake it up), but no hard hangs so far. Rene pgpYysnoDojEv.pgp Description: PGP signature
Bug#390913: xserver-xorg-video-i810: blank screen after suspend
On Samstag, 21. April 2007 13:24, you wrote: What is the status of this bug now that xserver-xorg-core 1.3 and xserver-xorg-video-intel 2.0 are in unstable? I'll try to test it today. Rene pgpG0NvuZSzrn.pgp Description: PGP signature
Bug#390913: xserver-xorg-video-i810: blank screen after suspend
On Samstag, 21. April 2007 19:09, Rene Mayrhofer wrote: On Samstag, 21. April 2007 13:24, you wrote: What is the status of this bug now that xserver-xorg-core 1.3 and xserver-xorg-video-intel 2.0 are in unstable? I'll try to test it today. Solved for me with xserver-xorg 7.2-2 xserver-xorg-core1.3.0.0.dfsg-1 xserver-xorg-video-intel 2.0.0-1 This bug can be closed as far as I am concerned, now I have DRI and suspend-to-RAM working, very nice. Rene pgpPfQEg4qgKm.pgp Description: PGP signature
Bug#418414: havp fails to stop.
Am Samstag, 14. April 2007 21:27 schrieb Björn Heide: Because there was already an user havp on my machine (left behind from an old havp install) the chown commands never got executed. Thanks for the quick analysis - I have an idea on how to solve the problem, but I will probably need some time to change it. with best regards, Rene pgpayqTNHtDnJ.pgp Description: PGP signature
Bug#412748: Patch works nicely
And just for completeness, I want to add that the patch works nicely. drbd8 and ocfs2 can be used together with no visible side-effects. If anybody of the kernel team has time to add this, it would help admins trying to create highly available file systems. Rene pgpomzOYfHHCp.pgp Description: PGP signature
Bug#412748: Actually attach the patch
This patch has been fetched from
http://gateway.total-knowledge.com/cgi-bin/gitweb.cgi?p=linux-mips.git;a=commitdiff;h=b559292e066f6d570cd5aa5dbd41de61dd04bdce;hp=925037bcba7691db2403684141a276930ad184f3
and is already in upstream 2.6.20, so should be OK to apply even for etch.
Rene
From: Philipp Reisner [EMAIL PROTECTED]
Date: Thu, 11 Jan 2007 09:58:10 + (+0100)
Subject: [PATCH] ocfs2 heartbeat: clean up bio submission code
X-Git-Url: http://gateway.total-knowledge.com/cgi-bin/gitweb.cgi?p=linux-mips.git;a=commitdiff;h=b559292e066f6d570cd5aa5dbd41de61dd04bdce
[PATCH] ocfs2 heartbeat: clean up bio submission code
As was already pointed out Mathieu Avila on Thu, 07 Sep 2006 03:15:25 -0700
that OCFS2 is expecting bio_add_page() to add pages to BIOs in an easily
predictable manner.
That is not true, especially for devices with own merge_bvec_fn().
Therefore OCFS2's heartbeat code is very likely to fail on such devices.
Move the bio_put() call into the bio's bi_end_io() function. This makes the
whole idea of trying to predict the behaviour of bio_add_page() unnecessary.
Removed compute_max_sectors() and o2hb_compute_request_limits().
Signed-off-by: Philipp Reisner [EMAIL PROTECTED]
Signed-off-by: Mark Fasheh [EMAIL PROTECTED]
---
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -184,10 +184,9 @@ static void o2hb_disarm_write_timeout(st
flush_scheduled_work();
}
-static inline void o2hb_bio_wait_init(struct o2hb_bio_wait_ctxt *wc,
- unsigned int num_ios)
+static inline void o2hb_bio_wait_init(struct o2hb_bio_wait_ctxt *wc)
{
- atomic_set(wc-wc_num_reqs, num_ios);
+ atomic_set(wc-wc_num_reqs, 1);
init_completion(wc-wc_io_complete);
wc-wc_error = 0;
}
@@ -212,6 +211,7 @@ static void o2hb_wait_on_io(struct o2hb_
struct address_space *mapping = reg-hr_bdev-bd_inode-i_mapping;
blk_run_address_space(mapping);
+ o2hb_bio_wait_dec(wc, 1);
wait_for_completion(wc-wc_io_complete);
}
@@ -231,6 +231,7 @@ static int o2hb_bio_end_io(struct bio *b
return 1;
o2hb_bio_wait_dec(wc, 1);
+ bio_put(bio);
return 0;
}
@@ -238,23 +239,22 @@ static int o2hb_bio_end_io(struct bio *b
* start_slot. */
static struct bio *o2hb_setup_one_bio(struct o2hb_region *reg,
struct o2hb_bio_wait_ctxt *wc,
- unsigned int start_slot,
- unsigned int num_slots)
+ unsigned int *current_slot,
+ unsigned int max_slots)
{
- int i, nr_vecs, len, first_page, last_page;
+ int len, current_page;
unsigned int vec_len, vec_start;
unsigned int bits = reg-hr_block_bits;
unsigned int spp = reg-hr_slots_per_page;
+ unsigned int cs = *current_slot;
struct bio *bio;
struct page *page;
- nr_vecs = (num_slots + spp - 1) / spp;
-
/* Testing has shown this allocation to take long enough under
* GFP_KERNEL that the local node can get fenced. It would be
* nicest if we could pre-allocate these bios and avoid this
* all together. */
- bio = bio_alloc(GFP_ATOMIC, nr_vecs);
+ bio = bio_alloc(GFP_ATOMIC, 16);
if (!bio) {
mlog(ML_ERROR, Could not alloc slots BIO!\n);
bio = ERR_PTR(-ENOMEM);
@@ -262,137 +262,53 @@ static struct bio *o2hb_setup_one_bio(st
}
/* Must put everything in 512 byte sectors for the bio... */
- bio-bi_sector = (reg-hr_start_block + start_slot) (bits - 9);
+ bio-bi_sector = (reg-hr_start_block + cs) (bits - 9);
bio-bi_bdev = reg-hr_bdev;
bio-bi_private = wc;
bio-bi_end_io = o2hb_bio_end_io;
- first_page = start_slot / spp;
- last_page = first_page + nr_vecs;
- vec_start = (start_slot bits) % PAGE_CACHE_SIZE;
- for(i = first_page; i last_page; i++) {
- page = reg-hr_slot_data[i];
-
- vec_len = PAGE_CACHE_SIZE;
- /* last page might be short */
- if (((i + 1) * spp) (start_slot + num_slots))
- vec_len = ((num_slots + start_slot) % spp) bits;
- vec_len -= vec_start;
+ vec_start = (cs bits) % PAGE_CACHE_SIZE;
+ while(cs max_slots) {
+ current_page = cs / spp;
+ page = reg-hr_slot_data[current_page];
+
+ vec_len = min(PAGE_CACHE_SIZE,
+ (max_slots-cs) * (PAGE_CACHE_SIZE/spp) );
mlog(ML_HB_BIO, page %d, vec_len = %u, vec_start = %u\n,
- i, vec_len, vec_start);
+ current_page, vec_len, vec_start);
len = bio_add_page(bio, page, vec_len, vec_start);
- if (len != vec_len) {
- bio_put(bio);
- bio = ERR_PTR(-EIO);
-
- mlog(ML_ERROR, Error adding page to bio i = %d,
- vec_len = %u, len = %d\n, start = %u\n,
- i, vec_len, len, vec_start);
- goto bail;
- }
+ if (len != vec_len) break;
+ cs += vec_len / (PAGE_CACHE_SIZE/spp);
vec_start = 0;
}
bail:
+ *current_slot = cs;
return bio;
}
-/*
- * Compute the maximum number of sectors the bdev can handle in one bio,
- * as a power of two.
- *
- * Stolen from oracleasm, thanks Joel!
- */
-static int compute_max_sectors(struct block_device *bdev)
-{
- int max_pages, max_sectors, pow_two_sectors;
-
- struct request_queue *q;
-
- q = bdev_get_queue(bdev);
- max_pages =
Bug#409690: havp: diff for NMU version 0.82-1.1
Am Mittwoch, 28. Februar 2007 13:59 schrieb Stephen Gran: tags 409690 + patch thanks Hi, Attached is the diff for my havp 0.82-1.1 NMU. I plan to upload in the next day or two, unless you have any objections. Please wait for a few more days, I'm in the process of preparing a new upload that should solve the mand-option RC bug as well. Rene pgpHbXXFnFH7z.pgp Description: PGP signature
Bug#390913: Problem still present in 1.7.2-3
After reading the last entry in this bug report, I tried 1.7.2-3. The changelog of 1.7.2-2 indicates that the issue may have been solved by an upstream patch, but unfortunately it is not. Suspending to RAM leaves the X server failing after resume. That is, the X server still crashes over and over again (being restarted by kdm). Rene pgpD6C5nFrH3c.pgp Description: PGP signature
Bug#400218: More info
Am Sonntag, 3. Dezember 2006 00:46 schrieb Martín Ferrari: This package seems to be unmaintained. As is also uninstallable on default setups (it requires a special mount option on /var!!), wouldn't it be reasonable to remove it from testing? (popcon reports only 15 installs) Not unmaintained, but poorly maintained - with me to blame. Feel free to remove from testing, because there's currently nothing that can be done about the requirement for the mandatory locks in the file system. Rene pgpCPurIRk6Gz.pgp Description: PGP signature
Bug#395905: openswan: ppp should be listed as dependency
Am Samstag, 28. Oktober 2006 15:54 schrieb Chris Purves: I just got openswan working using preshared keys. I couldn't get it to work until I installed the ppp package, but it's not listed as a dependency or recommended package. Do you use Xauth? Else pppd should not be needed, and it's not a dependency for normal use. Rene -- - Gibraltar firewall http://www.gibraltar.at/ pgpVe9FmWwV0s.pgp Description: PGP signature
Bug#360735: [Openswan Users] openswan + l2tpd + iptables problem
Am Wednesday 04 October 2006 18:37 schrieb Paul Wouters: openswan series 2.4 is our stable tree. Development is happening in 2.5.x (git #public) and 2.6.x (git #ocf). Debian stable should upgrade their openswan to 2.4.x I talked to the release manager. This won't happen. But the next Debian stable release will have openswan 2.4.6. Rene -- - Gibraltar firewall http://www.gibraltar.at/ pgpHHiUubHUrv.pgp Description: PGP signature
Bug#360735: [Openswan Users] openswan + l2tpd + iptables problem
Am Wednesday 04 October 2006 20:43 schrieb Michael Richardson: Should we go to dated releases? openswan-2006q4.tar.gz or something. and then in hindsight, give them version #s that indicate stability? Would that make it easier for the release manager to understand that we do not generally get less stable. Yes, that might help. Although they would still prefer the least possible changes to the source code, i.e. only patches for specific issues. Minor releases within the same major branch might work. Rene -- - Gibraltar firewall http://www.gibraltar.at/ pgprboeV32I5K.pgp Description: PGP signature
Bug#386987: kmail: Displays warning messages for cachedimap since last update lose emails
Package: kmail
Version: 4:3.5.4-1
Severity: grave
Justification: make package nearly unusable with cachedimap and can
Since a recent update (I think it was from 3.5.3-something to
3.5.4-1), KMail now displays very annoying warning messages in the
style of
Warning - Kontact:
Mails on the server in folder whatever folder I moved a message into
were deleted. Do you want to delete them locally?
UIDs: some number,some other number,...
after I move messages around. Most commonly, I move messages from my
Inbox to some other folder on the IMAP server (cachedimap for KMail), and
upon the next periodical check, this message will appear. It also
happens for automatic folders like Sent and Trash, where KMail
itself copies messages into.
Answering Yes will delete the messages to the effect of removing it
both from the local IMAP cache _and_ from the IMAP server. But the
messages were in fact _not_ deleted on the server by another process,
and only one IMAP client is active at a time. That is, answering Yes
means losing emails (as has happened to me)!
My interpretation is that KMail does not move the message into the
other folder immediately (I think older versions behaved the same), but
only at the next sync period, i.e. when it checks this folder for
changes. However, it checks the folder, notices that the messages is
not there, fails to notice that it should copy it over so that it will
be there, and asks to delete it locally instead. Not good.
Anwering No produces, as far as I can see, the same behaviour as
previous KMail versions, which is the intended behaviour of not losing
all emails that have been moved to another IMAP box.
Search for this message string gets me to a patch to KMail, which
introduces
if( !msgsForDeletion.isEmpty() ) {
-removeMsg( msgsForDeletion );
+#ifdef MAIL_LOSS_DEBUGGING
+ if ( KMessageBox::warningYesNo(
+ 0, i18n( qtpMails on the server in folder
b%1/b were deleted.
+ Do you want to delete them locally?brUIDs:
%2/p/qt )
+ .arg( folder()-prettyURL() ).arg( uids.join(,)
) ) == KMessageBox::Yes )
+#endif
+removeMsg( msgsForDeletion );
}
So it seems that this is a debugging code?
Please revert the change so that it behaves like KMail 3.5.3, not
deleting all moved emails.
with best regards,
Rene
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (800, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.11
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages kmail depends on:
ii kdebase-kio-plugins 4:3.5.4-2core I/O slaves for KDE
ii kdelibs4c2a 4:3.5.4-3core libraries and binaries for
al
ii kdepim-kio-plugins 4:3.5.4-1KDE pim I/O Slaves
ii libart-2.0-22.3.17-1 Library of functions for 2D
graphi
ii libaudio2 1.8-2The Network Audio System (NAS).
(s
ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries
ii libfontconfig1 2.3.2-7 generic font configuration
library
ii libfreetype62.2.1-4 FreeType 2 font engine, shared
lib
ii libgcc1 1:4.1.1-13 GCC support library
ii libice6 2:1.0.0-0ubuntu2 X11 Inter-Client Exchange library
ii libidn110.6.5-1 GNU libidn library,
implementation
ii libjpeg62 6b-13The Independent JPEG Group's JPEG
ii libkcal2b 4:3.5.4-1KDE calendaring library
ii libkdepim1a 4:3.5.4-1KDE PIM library
ii libkleopatra1 4:3.5.4-1KDE GnuPG interface libraries
ii libkmime2 4:3.5.4-1KDE MIME interface library
ii libkpimidentities1 4:3.5.4-1KDE PIM user identity information
ii libksieve0 4:3.5.4-1KDE mail/news message filtering
li
ii libmimelib1c2a 4:3.5.4-1KDE mime library
ii libpng12-0 1.2.8rel-5.2 PNG library - runtime
ii libqt3-mt 3:3.3.6-4Qt GUI Library (Threaded runtime
v
ii libsm6 2:1.0.0-0ubuntu2 X11 Session Management library
ii libstdc++6 4.1.1-13 The GNU Standard C++ Library v3
ii libx11-62:1.0.0-8X11 client-side library
ii libxcursor1 1.1.7-4 X cursor management library
ii libxext62:1.0.0-0ubuntu4 X11 miscellaneous extension
librar
ii libxft2 2.1.8.2-8FreeType-based font drawing
librar
ii libxi6 2:1.0.0-0ubuntu3 X11 Input extension library
ii libxinerama12:1.0.1-0ubuntu2 X11 Xinerama extension library
ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library
ii libxrender1 1:0.9.1-3X Rendering
Bug#368723: openswan: Cleanup of dependencies (fileutils)
Am Wednesday 24 May 2006 13:26 schrieb Stefan Huehner: your package depends on 'coreutils | fileutils'. The latter has been replaced by coreutils a long time ago (before sarge). Please consider changing the dependency to coreutils. The dependency is still in there to support backporting to woody in a very simple manner. Some people (including myself) are still using it, so this will probably need to stay in the package until etch releases and woody can safely be assumed to be unsupported. Rene -- - Gibraltar firewall http://www.gibraltar.at/ pgp78SbmuKdCr.pgp Description: PGP signature
Bug#384100: kscreensaver-xsavers: please add webcollage
Package: kscreensaver-xsavers Version: 4:3.5.4-1 Severity: wishlist The xscreensavers package has one nice screen saver that is not added to KDE by: the WebCollage screen saver. Without any translations, this webcollage.desktop file seems to work for me: --- [Desktop Entry] Encoding=UTF-8 Exec=webcollage Icon=kscreensaver Type=Application TryExec=xscreensaver Actions=InWindow;Root;Setup; X-KDE-Category=Banners Pictures Name=WebCollage [Desktop Action Setup] Exec=kxsconfig webcollage Name=Setup... Icon=kscreensaver [Desktop Action InWindow] Exec=kxsrun webcollage -- -window-id %w Name=Display in Specified Window NoDisplay=true [Desktop Action Root] Exec=kxsrun webcollage -- -root Name=Display in Root Window NoDisplay=true -- -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (800, 'testing'), (300, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages kscreensaver-xsavers depends on: ii kdebase-bin 4:3.5.4-2 core binaries for the KDE base mod ii kdelibs4c2a 4:3.5.4-3 core libraries and binaries for al ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-5 GCC support library ii libqt3-mt 3:3.3.6-2 Qt GUI Library (Threaded runtime v ii libstdc++64.1.1-5The GNU Standard C++ Library v3 ii libx11-6 2:1.0.0-8 X11 client-side library ii libxt61:1.0.0-5 X11 toolkit intrinsics library ii xscreensaver 4.24-5 Automatic screensaver for X Versions of packages kscreensaver-xsavers recommends: ii kscreensaver 4:3.5.4-1 additional screen savers released ii kwin 4:3.5.4-2 the KDE window manager pn xscreensaver-gl none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372267: ITP: strongswan -- second fork of freeswan.
Package: wnpp Severity: wishlist Owner: Rene Mayrhofer [EMAIL PROTECTED] strongswan is the second fork of the freeswan code basis besided the openswan package. It has diverged far enough to warrant its own package. * Package name : strongswan Version : 2.7.1 Upstream Author : Andreas Steffen [EMAIL PROTECTED] * URL : http://www.strongsec.org/ * License : GPL 2 Programming Lang: C Description : strongswan is the second fork of the freeswan package and seems to have diverged far enough from openswan to warrant its own package. Basically like the openswan package, but with different feature set. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (900, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16.14 Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8) pgpGZYhNFkBbu.pgp Description: PGP signature
Bug#363375: Bug#370752: diff for 1:2.4.5+dfsg-0.1 NMU
Am Friday 09 June 2006 18:28 schrieb Steinar H. Gunderson: Aha, you are using CONFIG_HIPPI -- that's marked as experimental and is rather obscure. (It seems to be some kind of supercomputer networking standard.) The offending lines are: #ifdef CONFIG_HIPPI n-private.ifield=skb-private.ifield; #endif /* CONFIG_HIPPI */ (I can reproduce this with your .config, even though I had to run it through make oldconfig first.) Given http://lkml.org/lkml/2005/9/13/274 I believe that the line can simply be dropped. Let me know if you need an NMU :-) If you could, then please yes. Thanks for your help, Rene pgpuWyYpDOBYq.pgp Description: PGP signature
Bug#363375: Bug#370752: diff for 1:2.4.5+dfsg-0.1 NMU
Am Tuesday 06 June 2006 19:15 schrieb Steinar H. Gunderson: You mean #363375? I could have a look at it, but I doubt I could be of too much use. Yes, the compilation problem - it would be also helpful if you can reproduce it. Thanks for the NMU, Rene pgpqdtKgDrJje.pgp Description: PGP signature
Bug#370752: diff for 1:2.4.5+dfsg-0.1 NMU
Am Tuesday 06 June 2006 18:03 schrieb Steinar H. Gunderson: Attached is the diff for my openswan 1:2.4.5+dfsg-0.1 NMU. (Note that all the changes, except for the one to debian/changelog, are done in the upstream tarball.) Thanks, I will apply it as soon as possible (but am currently _very_ busy with another project, so please feel free to NMU the other RC bug if you feel like it). Rene pgpsVShqjdJVl.pgp Description: PGP signature
Bug#321070: acknowledged by developer (Closing because of no response from submitter)
Am Sunday 16 April 2006 00:31 schrieb Pieter Jansen: Does not compute.. I never saw anything apart from this message.. I've got no clue as to the current status of this bugreport :) Hmm, then my last message does not seem to have come through. Strange... The IKE server packages in Debian now all provide ike-server, but don't conflict with it anymore. with best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ pgpSVX4995sby.pgp Description: PGP signature
Bug#361800: Does not compile now
Am Tuesday 11 April 2006 14:02 schrieb Lupe Christoph: I should have checked before using so much time on trying to get the 2.4.4 version going. The OpenSWAN project released 2.4.5 a few days ago. That version is supposed to work with the 2.6.15 kernel. I don't think I can close this bug as a non-DD. Rene, please do that. I hope you find time soon to package 2.4.5... I'll try to find time for that within the next few days, but I can't promise - very busy right now with other projects -- - Gibraltar firewall http://www.gibraltar.at/ pgp4pHEu5zCNA.pgp Description: PGP signature
Bug#361850: Syncml plugin for opensync needs another patch to libwbxml2
Package: libwbxml2 Version: 0.9.0-3 Severity: wishlist The syncml plugin for opensync needs a patch to be applied to libxml2. I applied it here locally to the debian package, and besides two files which have already been patched, it applies cleanly. Details on the patch can be found at http://www.opensync.org/wiki/syncml-guide. In short, the patch is in (anonymously accessible) SVN at http://svn.opensync.org/libsyncml/trunk as misc/wbxml2-0.9.0.patch. Thanks for considering, Rene -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (800, 'testing'), (300, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.6 Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Versions of packages libwbxml2 depends on: ii libc6 2.3.6-3GNU C Library: Shared libraries an ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libpopt0 1.7-5 lib for parsing cmdline parameters ii zlib1g1:1.2.3-11 compression library - runtime libwbxml2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360735: openswan 2.4 peer crashes openswan 2.2 peer
This bug has been fixed in newer upstream versions, see #292132. Rene pgpL2taEf5tjT.pgp Description: PGP signature
Bug#360735: openswan 2.4 peer crashes openswan 2.2 peer
Am Tuesday 04 April 2006 14:25 schrieb Rene Mayrhofer: This bug has been fixed in newer upstream versions, see #292132. But you are right, it should be fixed for sarge too. I just don't know if it can be fixed without updating to the new upstream version... Rene -- - Gibraltar firewall http://www.gibraltar.at/ pgpBNI5cUMkH0.pgp Description: PGP signature
Bug#352050: Fix this (trivial?) issue?
Am Thursday 16 March 2006 08:06 schrieb Christian Perrier: Attached is the patch for the NMU I just uploaded in the DELAYED/2-day queue (to give you some opportunity to block it in case you disagree with a part of it). Thanks - the diff is against another version you did to enable XAUTH support, but I think I'll manage to apply it ;-) Hope that all this will help your maintenance work. Thanks a lot. Rene pgpi4QdohhS7k.pgp Description: PGP signature
Bug#352050: Fix this (trivial?) issue?
Am Monday 13 March 2006 11:08 schrieb Christian Perrier: I fail to understand why this issue, which seems trivial, is not yet fixed. Honestly, lack of time I went on it while trying to build a custom openswan on my system and I hereby propose to quickly build a NMU to fix this FTBFS. Please go forward with it! I will try to get up to speed as soon as possible again. However, as openswan seems quite actively maintained, there may be good reasons for not fixing the issue and I'd like to get the maintainer's input before NMU'ing. Thanks for asking, I really appreciate it. You are right, I try to keep openswan in good shape - just right now is a bad time. best regards, Rene pgpquk14c2FDo.pgp Description: PGP signature
Bug#352050: Fix this (trivial?) issue?
Am Monday 13 March 2006 17:05 schrieb Christian Perrier: OK, I'll try to do this NMU. If you're OK, I can also try to deal with the pending bug (from Clytie) mentioning typos/errors in the debconf templates and handle this without breaking existing translations. And, while I'm at it, I can also add the pending debconf translation(s). I am certainly OK with it - I will just review it as soon as I find time and ack the NMU. with best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ pgpvdV6M0TaJr.pgp Description: PGP signature
Bug#338212: Please move the libpcsclite.so symlink from libpcsclite-dev to libpcsclite1
Package: libpcsclite1 Severity: normal Please move the symbolic link libpcsclite.so to the main library package so hat the library can be found under that name. At least one application that I use needs that symlink (a Java applet). [For details please see the bottom of http://www.mayrhofer.eu.org/Default.aspx?pageindex=7pageid=30 . It's better viewed in that context than repeated here.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329095: openswan_1:2.2.0-11(m68k/unstable/thing2): FTBFS on m68k
Am Montag 19 September 2005 22:40 schrieb Steve Langasek: FWIW, Wouter Verhelst has made progress on identifying the gcc bug causing these problems, so I'm not sure how much good it does to file per-package bugs about this issue now. I agree that automatically filing bugs with severity serious to packages that only trigger a toolchain bug but are not buggy by themselves is not the best way to deal with it. best regards, Rene pgpEm3PumY5kN.pgp Description: PGP signature
Bug#329095: openswan_1:2.2.0-11(m68k/unstable/thing2): FTBFS on m68k
Am Dienstag 20 September 2005 10:31 schrieb Steve Langasek: You seem to be agreeing with something I didn't say. :) I only pointed out that progress is being made on fixing the toolchain; when this was not the case, I certainly encouraged maintainers to lower the optimization level they were using on m68k. Sorry, didn't mean to ;-) But shouldn't the toolchain actually take care of lower the optimization level when - for this platform - it is known that higher levels can cause bugs? It would just be more pragmatic to do the change at one place instead of for every package. best regards, Rene pgpiD5F37bGmW.pgp Description: PGP signature
Bug#329095: openswan_1:2.2.0-11(m68k/unstable/thing2): FTBFS on m68k
Am Montag 19 September 2005 15:06 schrieb Stephen R Marenka: Package: openswan Version: 1:2.2.0-11 Severity: serious Justification: fails to build on release candidate arch. Tags: sid openswan fails to build from source on m68k. This is likely due to bug #317475 on gcc-4.0. As a workaround, you might try compiling with less optimization (-O2 usually works) or gcc-3.3/gcc-3.4. I don't think that this is an openswan bug: A full buildd log is available at http://buildd.debian.org/build.php?pkg=openswanver=1:2.2.0-11arch=m68k optionsfrom.c:68: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.0/README.Bugs. Whoops Can I close that bug report for openswan? with best regards, Rene pgpNfXOuQBiAx.pgp Description: PGP signature
Bug#321070: openswan debian package does not conflict with racoon
On Wednesday 03 August 2005 11:19, Pieter Jansen wrote: had to manually (apt-get remove) racoon before installation of openswan would continue But this is intended, since only one IKE daemon can be active at a time. For this reason, it has been agreed between the IPSec package maintainers that the virtual package ike-server should be provided by all packages and that they should conflict with it to prevent multiple installation. Can I close this bug? with best regards, Rene pgp9fHQFwbjW8.pgp Description: PGP signature
Bug#298468: Is this actually fixed in sarge?
Am Thursday 26 May 2005 19:48 schrieb Len Sorensen: I don't see 2.2.0-7 in sarge yet (at least proposed updates on ftp.debian.org when I connect still says 2.2.0-6) so I don't think this bug should be closed until it actually makes it into the archive. I hope that 2.2.0-8 should hit testing really soon, so the bug will probably be fixed tomorrow. with best regards, Rene pgplzVNlFV7Lj.pgp Description: PGP signature
Bug#291274: openswan in sarge
Am Samstag, 21. Mai 2005 15:59 schrieb Steve Langasek: The only sane way to get 2.2.0-5 back into testing now would be with an epoched upload to unstable. I'd still be happy to let it into sarge if you wanted to do this, as I agree with those who say it's an important piece of software; even so, bringing the package back any other way than through unstable just has too much risk. I have now put some packages together, which are based on 2.2.0-5, include the latest security fix and now have an epoch. Besides that, only minor changes (e.g. in debian/control) to fix some bugs (e.g. libcurl2-dev build dependeny, ike-server conflict). They are now at http://www.gibraltar.at/~rene/openswan/ If anybody wants to give them a try, it would be much appreciated. I have tested them with a 2.6.11 kernel without problems and verified that openswan-modules-source and kernel-patch-openswan at least build cleanly with the current 2.4.27-2 kernel source from testing. I have not yet tried those kernels due to missing test environment right now, but I expect them to work (since I do use 2.2.0-X on production boxes with custom 2.4.X kernels). with best regards, Rene pgppK87N5iWYy.pgp Description: PGP signature
Bug#291274: openswan in sarge
Hi all, Does anybody want to test the current openswan 1:2.2.0-7 packages at http://www.gibraltar.at/~rene/openswan/ or should I upload to unstable? If nobody can give it a try, I intent to upload tomorrow morning (GMT+2). with best regards, Rene pgpzY0AcGY7xT.pgp Description: PGP signature
Bug#291274: openswan in sarge
Am Freitag, 20. Mai 2005 07:10 schrieb Steve Langasek: I'm happy to let openswan 2.3.0-2 in now if the maintainer thinks it's ready, but IIRC he had some other concerns about 2.3 that were unrelated to this bug. Rene? Yes, a pluto (IKE daemon) crash that is triggered by openswan 2.3.(0|1). People tell me that it's rare, but at least in my setup it's reproducable. I would indeed feel more comfortable with 2.2.0-5 (which works perfectly well on all of my production boxes, with kernels 2.4.X with the openswan stack and with Debian default kernels with 26sec). Is there anything that I can do to revive that version (which got removed from testing due to my failure to mark the RC bug sid I am very sorry about that). with best regards, Rene pgpR9wExHEclW.pgp Description: PGP signature
Bug#291274: openswan in sarge
Hi Bdale, Am Donnerstag, 19. Mai 2005 00:25 schrieb Bdale Garbee: Release team, please allow openswan back into sarge. We had freeswan in woody, and it's still in sarge. Unfortunately, freeswan is no longer maintained upstream, openswan is where development continues. See www.freeswan.org for confirmation of this. Thanks for your mail - your words have a lot more weight than mine, so openswan might now get back into sarge. with best regards, Rene pgpxqVhtHqbmm.pgp Description: PGP signature
Bug#307578: freeswan doesn't create ipsec0
Carl T. Miller schrieb: Can you tell me what I need to do to support the ipsec* interfaces? The ipsec* interfaces are only provided by the KLIPS IPSec stack. Freeswan does not support 2.6 kernels, only openswan = 2.3.0 properly supports them. Also, can the package description and documentation be updated? It says that it works with the standard kernels. Or, better yet, can the kernel maintainers include support for them in the 2.6 series? It will work, but without the virtual ipsec* interfaces. The native IPSec stack is just a different means of integration. with best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307578: freeswan doesn't create ipsec0
Carl T. Miller schrieb: This explains what I'm seeing now. Both sides of the tunnel show that the tunnel is up. A route is added for each remote lan using the default gateway. If I try to ping a host on the remote lan (it's an unrouteable address) I get an error from the gateway saying that the host cannot be reached. Strange - you might want to look at auth.log for any error messages. However, I can recommend to use openswan instead - freeswan is unmaintained. with best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307578: freeswan doesn't create ipsec0
Carl T. Miller schrieb: I'm running the standard kernel that installs with Sarge on the i386. I've installed ipsec-tools. Am I just missing something? The native IPSec stack in kernel 2.6 does not have the virtual ipsec* interfaces, the support is different. with best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297508: pptpd: The same problem on my system
Am Freitag, 1. April 2005 13:33 schrieb bear: I have the same problem with ppp-2.4.3 and pptpd-1.2.1-2. The ppp-2.4.2 is OK. Please help! I don't use that plugin on my systems, so I can't easily try it out. However, I have investigated the issue and would propose the following fix: $ apt-get source pptpd $ apt-get source ppp $ tar xvfz ppp-2.4.3/upstream/tarballs/ppp-2.4.3.tar.gz $ cp ppp-2.4.3/pppd/patchlevel.h pptpd-1.2.1/plugins/ $ cp ppp-2.4.3/pppd/pppd.h pptpd-1.2.1/plugins/ $ cd pptpd-1.2.1 $ dpkg-buildpackage -rfakeroot which compiles successfully. Could you please try if that fixes it for you? If yes, I'll prepare a new upload. with best regards, Rene pgpSWSm1y6H94.pgp Description: PGP signature
Bug#301342: (no subject)
Hi Thomas, Am Freitag, 25. März 2005 10:15 schrieb Thomas Lange: the new mkinitrd-cd version is fantastic, but it does not work at all for a 2.6 kernel, since it does not find all .ko kernel modules needed. The patch is attached. Thank you very much for the patch! I am still using it with 2.4 kernels, so testing with 2.6 has indeed been minimal. I will interate this patch as soon as possible and make a new upload. Thanks again, Rene pgpwMuyeovIAV.pgp Description: PGP signature
Bug#292458: CVE Id
Hi Joey, On Friday 28 January 2005 07:28, Martin Schulze wrote: Stack-based buffer overflow in the get_internal_addresses function in the pluto application for Openswan 1.x before 1.0.9, and Openswan 2.x before 2.3.0, when compiled XAUTH and PAM enabled, allows remote authenticated attackers to execute arbitrary code. I still think that the bug is present in 2.3.0 too. At least I applied the patch also to this release - which has the same (flawed) definition of the src variable. Please mention this id in the changelog (could be done with the next upload if you've already uploaded the fixed package. Ok, I will do that with the next upload - both testing and unstable versions got uploaded yesterday to fix the security issue. best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292458: Openswan XAUTH/PAM Buffer Overflow Vulnerability
Hi Joey, Am Donnerstag, 27. Januar 2005 07:34 schrieb Martin Schulze: Package: openswan Severity: grave Tags: security sarge sid patch Please see the advisory and patch here: http://www.idefense.com/application/poi/display?id=190type=vulnerabilities flashstatus=false Even though iDEFENSE wrote: iDEFENSE has confirmed that Openswan 2.2.0 is vulnerable. All previous versions of Openswan also contain the vulnerable code. it seems that 2.3.0 in sid is vulnerable as well. Many thanks for informing me about this - I have somehow missed the announcement (it does not seem to have been communicated over the openswan announce mailing list either). I now have two packages ready, one 2.2.0 based for testing (IMHO 2.3.0 should not enter testing in its current state - it is broken upstream) and one 2.3.0 based for unstable which both fix the mentioned security issue. How should I proceed? Upload one to unstable, the other to testing as soon as you are prepared to release the DSA? best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292132: openswan: OpenSwan 2.2.0 crashes when a road-warrior comes in using 2.3.0
Dear Joerg, On Tuesday 25 January 2005 11:23, Joerg Morbitzer wrote: I am running Debian testing on my main vpn gateway using openswan 2.2.0, the same setup is on all of my road-warriors. Yesterday one road-warrior was upgraded to Debian unstable with openswan 2.3.0, since then the openswan on my main vpn gateway crashes when this road-warrior is trying to establish the connection showing these lines in /var/log/syslog: Jan 25 10:52:57 darkstar ipsec__plutorun: /usr/lib/ipsec/_plutorun: line 1: 4974 Segmentation fault /usr/lib/ipsec/pluto --nofork --secretsfile /etc/ipsec.secrets --ipsecdir /etc /ipsec.d --debug-none --uniqueids Jan 25 10:52:57 darkstar ipsec__plutorun: !pluto failure!: exited with error status 139 (signal 11) I couldn't find a core file unfortunately. We manually downgraded to openswan 2.2.0 and everything is ok again. I have also encountered this issue and am trying to track it down. with best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291600: FTBFS: Attempts to use 'apt-get source'
On Friday 21 January 2005 19:37, Stephen Quinney wrote: Upon investigation I found that debian/rules is calling two scripts: build-discover (which attempts to download the source for curl, expat and discover) and build-paste (which attempts to grab the source for coreutils). This is total and utter madness, I've never come across anything so odd before in my experience of Debian packaging. There is absolutely _no_ reason to be rude about this. If you think that it is odd, then ok. But insulting me personally is unprofessional and certainly counterproductive. Just because it doesn't work like you would've done it is no indicator for total and utter madness. rant It might have helped if you had asked for the reasons for this special construction, which I have not done just for the fun of it But I understand that flaming is easier, takes less of your seemingly valuable time and maybe gets you a few additional ego points then thinking about the issue and writing a constructive email with real suggestions for improving it. /rant Btw, this is already documented in the changelog. You must not assume even the existence of a network connection from a buildd never mind the ability to run apt-get. It must be possible to build a package inside a self-contained chroot. You should also note that there is a high chance that the apt source urls will not be listed in typical chroots. In all of the build environments that I have access to, they are. I agree that some might not have this possibility, but then you could work with a local package mirror. I am absolutely certain that you really do not need to download the source code for each of these packages and then build them. There must be a better way to achieve what you are trying to do here. OK, send me patches if you have a better solution. I will look at them and decide if they have other problems. In case you care about the reasoning for my decisions: it is all about maintainability and size: I do not want to: a) duplicate the complete sources in my package, because it would simply be a waste of space and bandwidth. b) extract only those source files that are really necessary and create a new build system for them, because that would mean a lot of effort for tracking upstream changes for no benefit (and for building the uclibc-linked discover binary, nearly all of the source files are necessary anyways). c) ship pre-compiled binaries in the source package, like it was done in the version before this odd construction. If you have a solution that does not need to download the source packages at build time (which is no problem for reasonable development environments) and does not have the problems listed above, then you are welcome to send me patches. I am not completely happy with the current solution and would like to do something about it. And since you are absolutely certain that there is such a solution, I am already delighted to get the chance to improve my package. PS: A second outright insulting email (aka. flame) will simply be ignored, because my time is also valuable. If you would like to resolve this in a constructive manner, then I am, as always, open to any suggestion. Rene pgpDxWhMsu12I.pgp Description: PGP signature
Bug#276521: This is a release critical bug.
On Monday 17 January 2005 19:24, Markus Kolb wrote: This is a release critical bug. I don't think it is release critical - it works with modules, just the additional ciphers are not available. And they are not mandatory by the IPSec RFCs. When there will be a new revision of this package? When I (or someone else) has figured out how to solve this properly. In the next week, I will probably not have time to look closely at this issue, but any help is welcome. Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
