Processed: Re: Bug#1100599: transition: courier-unicode
Processing control commands: > tags -1 confirmed Bug #1100599 [release.debian.org] transition: courier-unicode Added tag(s) confirmed. -- 1100599: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100599 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1100599: transition: courier-unicode
Control: tags -1 confirmed On 15/03/2025 22:03, Soren Stoutner wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: courier-unic...@packages.debian.org Control: affects -1 + src:courier-unicode User: release.debian@packages.debian.org Usertags: transition src:courier-unicode is transitioning from libcourier-unicode4 to libcourier-unicode8. https://release.debian.org/transitions/html/auto-courier-unicode.html The only reverse dependencies of libcourier-unicode are courier and maildrop. I am the maintainer of both packages. Since this was requested before the transition freeze, let's go ahead. Please upload the package as soon as possible, so that we can schedule the appropriate binNMUs and get this done. Cheers, Emilio
Processed: Re: Bug#1100416: transition: coq-elpi, coq-quickchick, coq-simple-io and coqeal
Processing control commands: > tags -1 confirmed Bug #1100416 [release.debian.org] transition: coq-elpi, coq-quickchick, coq-simple-io and coqeal Added tag(s) confirmed. -- 1100416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100416 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1100599: transition: courier-unicode
On Tuesday, March 18, 2025 5:07:18 AM Mountain Standard Time Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 15/03/2025 22:03, Soren Stoutner wrote: > > Package: release.debian.org > > Severity: normal > > X-Debbugs-Cc: courier-unic...@packages.debian.org > > Control: affects -1 + src:courier-unicode > > User: release.debian@packages.debian.org > > Usertags: transition > > > > src:courier-unicode is transitioning from libcourier-unicode4 to > > libcourier-unicode8. > > > > https://release.debian.org/transitions/html/auto-courier-unicode.h > > tml > > > > The only reverse dependencies of libcourier-unicode are courier > > and maildrop. I am the maintainer of both packages. > > Since this was requested before the transition freeze, let's go > ahead. Please upload the package as soon as possible, so that we > can schedule the appropriate binNMUs and get this done. I have made the upload to unstable. Thank you for squeezing this in. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Uploading linux (6.12.19-1)
Hi Emilio, On Tue, Mar 18, 2025 at 04:18:32PM +0100, Emilio Pozuelo Monfort wrote: > On 15/03/2025 07:27, Salvatore Bonaccorso wrote: > > Hi > > > > I would like to upload linuxversion 6.12.19-1 to unstable (with the > > aim that this should migrate to testing for trixie). > > > > It imports 6.12.18 and 6.12.19 on top of the current packaging. There > > are some packaging changes to improve (hardware) support: > > > > * Compress kernel with zstd where supported. (Closes: #1099722) > > > > This was asked primarily from the loong64 porters to unblock their > > FTBFS. > > > > * [amd64] sound/soc/amd/acp: Enable SND_AMD_ASOC_ACP70, > > SND_SOC_AMD_ACP_PCI > > and SND_SOC_AMD_LEGACY_MACH as modules (Closes: #1096006) > > * Enable IIO HRTIMER and SYSFS trigger. These are useful to do > > high-speed > > continuous and manual (or scripted) sensor reading respectively. > > * sound/pci/hda: Enable SND_HDA_SCODEC_CS35L56_I2C, > > SND_HDA_SCODEC_CS35L56_SPI, SND_SOC_CS35L56_I2C, SND_SOC_CS35L56_SPI, > > SND_SOC_CS35L56_SDW as modules > > > > The upload does not contain yet the fixes posted upstream for the > > netfs issues (#1099591, #1098698) for which I have raised the > > severity, I think it should be considered RC. > > > > For the release team, as my question in my last mail might have got > > lost: What are you expecting from the kernel-team in these stages of > > the freeze towards the trixie release from us? As for stable we > > usually try to keep the pace with new stable upstream series versions. > > Can you confirm this is still okay from you with the current approach > > or let us know where you want us to adjust? Is this simple heads-up > > advance notification still enough or do you need more time? > > I think this is fine at this stage, but please add a cc to debian-boot as > kernel updates affect d-i. I'll check with them and see if we need more > advance notice, but for now this should suffice. Thanks a lot for your feedback. Yes will add in future debian-boot as well. FWIW, requests for adding hardware support are flowing in at this stage more in my gut feeling as people start more to test trixie. Regards, Salvatore
Re: trixie toolchain freeze - util-linux
Hi,
* Chris Hofstaedtler [250221 11:57]:
Do you have some estimates from last releases of util-linux how many
changes go into a release after rc1? Do you expect a big diff between
rc1 and the final release?
Attached are two filtered debdiffs. The first one is from rc1 to
final - util-linux_2.41-1-from-rc1.debdiff.filtered.gz
The second one is from rc2 to final -
util-linux_2.41-1-from-rc2.debdiff.filtered.
The filtered diffs were produced using the following command.
Currently we do not use meson to build, and the translation and
manpage updates are filtered out.
debdiff util-linux_2.41~rc2-1.dsc util-linux_2.41-1.dsc | filterdiff -x
'*/po*/*.po' -x '*/po*/*.pot' -x '*/*.[1358]' -x '*.adoc' -x '*/meson.build'
rc2 was in experimental since 2025-03-06. I've now uploaded the
final release to experimental.
Chris
util-linux_2.41-1-from-rc1.debdiff.filtered.gz
Description: application/gunzip
diff -Nru util-linux-2.41~rc2/ChangeLog util-linux-2.41/ChangeLog
--- util-linux-2.41~rc2/ChangeLog 2025-03-06 12:25:41.215978531 +0100
+++ util-linux-2.41/ChangeLog 2025-03-18 13:56:05.331195955 +0100
@@ -1,3 +1,3 @@
See version control history.
-https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/log?h=v2.41-rc2
+https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/log?h=v2.41
diff -Nru util-linux-2.41~rc2/config.h.in util-linux-2.41/config.h.in
--- util-linux-2.41~rc2/config.h.in 2025-03-06 12:20:59.472105026 +0100
+++ util-linux-2.41/config.h.in 2025-03-18 13:52:33.260910749 +0100
@@ -381,6 +381,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_LINUX_RAW_H
+/* Define to 1 if you have the header file. */
+#undef HAVE_LINUX_SECCOMP_H
+
/* Define to 1 if you have the header file. */
#undef HAVE_LINUX_SECUREBITS_H
diff -Nru util-linux-2.41~rc2/configure util-linux-2.41/configure
--- util-linux-2.41~rc2/configure 2025-03-06 12:20:58.808107899 +0100
+++ util-linux-2.41/configure 2025-03-18 13:52:32.593913806 +0100
@@ -1,6 +1,6 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.72 for util-linux 2.41-rc2.
+# Generated by GNU Autoconf 2.72 for util-linux 2.41.
#
# Report bugs to .
#
@@ -614,8 +614,8 @@
# Identity of this package.
PACKAGE_NAME='util-linux'
PACKAGE_TARNAME='util-linux'
-PACKAGE_VERSION='2.41-rc2'
-PACKAGE_STRING='util-linux 2.41-rc2'
+PACKAGE_VERSION='2.41'
+PACKAGE_STRING='util-linux 2.41'
PACKAGE_BUGREPORT='k...@redhat.com'
PACKAGE_URL='https://www.kernel.org/pub/linux/utils/util-linux/'
@@ -2131,7 +2131,7 @@
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat <<_ACEOF
-'configure' configures util-linux 2.41-rc2 to adapt to many kinds of systems.
+'configure' configures util-linux 2.41 to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@@ -2202,7 +2202,7 @@
if test -n "$ac_init_help"; then
case $ac_init_help in
- short | recursive ) echo "Configuration of util-linux 2.41-rc2:";;
+ short | recursive ) echo "Configuration of util-linux 2.41:";;
esac
cat <<\_ACEOF
@@ -2595,7 +2595,7 @@
test -n "$ac_init_help" && exit $ac_status
if $ac_init_version; then
cat <<\_ACEOF
-util-linux configure 2.41-rc2
+util-linux configure 2.41
generated by GNU Autoconf 2.72
Copyright (C) 2023 Free Software Foundation, Inc.
@@ -3205,7 +3205,7 @@
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
-It was created by util-linux $as_me 2.41-rc2, which was
+It was created by util-linux $as_me 2.41, which was
generated by GNU Autoconf 2.72. Invocation command line was
$ $0$ac_configure_args_raw
@@ -6051,7 +6051,7 @@
# Define the identity of the package.
PACKAGE='util-linux'
- VERSION='2.41-rc2'
+ VERSION='2.41'
printf "%s\n" "#define PACKAGE \"$PACKAGE\"" >>confdefs.h
@@ -6612,7 +6612,7 @@
sub("-.*","",$3); print $3 ~ /^[0-9]+$/ ? $3 : 0}')
LIBBLKID_VERSION="$PACKAGE_VERSION_MAJOR.$PACKAGE_VERSION_MINOR.$PACKAGE_VERSION_RELEASE"
-LIBBLKID_DATE="06-Mar-2025"
+LIBBLKID_DATE="18-Mar-2025"
LIBBLKID_LT_MAJOR=1
LIBBLKID_LT_MINOR=1
LIBBLKID_LT_MICRO=0
@@ -25934,6 +25934,12 @@
printf "%s\n" "#define HAVE_LINUX_RAW_H 1" >>confdefs.h
fi
+ac_fn_c_check_header_compile "$LINENO" "linux/seccomp.h"
"ac_cv_header_linux_seccomp_h" "$ac_includes_default"
+if test "x$ac_cv_header_linux_seccomp_h" = xyes
+then :
+ printf "%s\n" "#define HAVE_LINUX_SECCOMP_H 1" >>confdefs.h
+
+fi
ac_fn_c_check_header_compile "$LINENO" "linux/securebits.h"
"ac_cv_header_linux_securebits_h" "$ac_includes_default"
if test "x$ac_cv_header_linux_securebits_h" = xyes
then :
@@ -26506,6 +26512,7 @@
have_linux_mount_h=$ac_cv_header_linux_mount_h
have_linux_pr_h=$ac_cv_header_linux_pr_h
have_linux_raw_h=$ac_cv_header_linux_raw_h
+hav
Re: Uploading linux (6.12.19-1)
On 15/03/2025 07:27, Salvatore Bonaccorso wrote: Hi I would like to upload linuxversion 6.12.19-1 to unstable (with the aim that this should migrate to testing for trixie). It imports 6.12.18 and 6.12.19 on top of the current packaging. There are some packaging changes to improve (hardware) support: * Compress kernel with zstd where supported. (Closes: #1099722) This was asked primarily from the loong64 porters to unblock their FTBFS. * [amd64] sound/soc/amd/acp: Enable SND_AMD_ASOC_ACP70, SND_SOC_AMD_ACP_PCI and SND_SOC_AMD_LEGACY_MACH as modules (Closes: #1096006) * Enable IIO HRTIMER and SYSFS trigger. These are useful to do high-speed continuous and manual (or scripted) sensor reading respectively. * sound/pci/hda: Enable SND_HDA_SCODEC_CS35L56_I2C, SND_HDA_SCODEC_CS35L56_SPI, SND_SOC_CS35L56_I2C, SND_SOC_CS35L56_SPI, SND_SOC_CS35L56_SDW as modules The upload does not contain yet the fixes posted upstream for the netfs issues (#1099591, #1098698) for which I have raised the severity, I think it should be considered RC. For the release team, as my question in my last mail might have got lost: What are you expecting from the kernel-team in these stages of the freeze towards the trixie release from us? As for stable we usually try to keep the pace with new stable upstream series versions. Can you confirm this is still okay from you with the current approach or let us know where you want us to adjust? Is this simple heads-up advance notification still enough or do you need more time? I think this is fine at this stage, but please add a cc to debian-boot as kernel updates affect d-i. I'll check with them and see if we need more advance notice, but for now this should suffice. Cheers, Emilio
Processed: Re: Bug#1100607: bookworm-pu: package libtheora
Processing commands for cont...@bugs.debian.org: > affects 1100607 src:libtheora Bug #1100607 [release.debian.org] bookworm-pu: package libtheora Added indication that 1100607 affects src:libtheora > thanks Stopping processing here. Please contact me if you need assistance. -- 1100607: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100607 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1094736: transition: libcdio
* Gabriel F. T. Gomes:
>
> Alternatively, we could make libiso9660 (and libiso9660++) explicitly
> depend on the newer version of libcdio.
This did not help the test. :/
libdevice-cdio-perl in testing (i.e.: libdevice-cdio-perl i386
2.0.0-2+b4) owns /usr/lib/i386-linux-gnu/perl5/5.40/perliso9660.so,
which is linked against the older libiso9660.so file, as can be seen
below:
$ ltrace -s128 perl t/07.iso2.t 2>&1 | grep -E "^dlopen.*iso9660"
dlopen("/usr/lib/i386-linux-gnu/perl5/5.40/perliso9660.so", 1) = 0x57582f10
$ readelf --dynamic /usr/lib/i386-linux-gnu/perl5/5.40/perliso9660.so | grep
NEEDED | grep libiso9660
0x0001 (NEEDED) Shared library: [libiso9660.so.11]
I don't think that there's anything I can do, from libcdio, to fix this.
Bug#1099081: marked as done (transition: gnustep-base, gnustep-gui, gworkspace)
Your message dated Wed, 19 Mar 2025 07:36:40 +0100 with message-id and subject line Re: Bug#1099081: transition: gnustep-base, gnustep-gui, gworkspace has caused the Debian Bug report #1099081, regarding transition: gnustep-base, gnustep-gui, gworkspace to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1099081: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099081 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:gnustep-base src:gnustep-gui src:gworkspace We at the GNUstep team would like to request a transition slot for a simultaneous (combined) transition of three libraries: libgnustep-base1.30 -> 1.31 libgnustep-gui0.31 -> 0.32 libinspector0 -> 1 The only reverse-dependency that FTBFS is gnustep-dl2 (#1096111) but the fixed package is already in testing. As always during GNUstep library transitions, gnustep-back will require a sourceful upload. The ben file for gnustep-base will need a little correction to take into account universal-detector: is_affected = .depends ~ /\b(libgnustep\-base1\.31|libgnustep\-base1\.30)\b/ | .source ~ /universal-detector/; is_good = .depends ~ /\b(libgnustep\-base1\.31|gnustep\-base\-abi\-1\.31)\b/; is_bad = .depends ~ /\b(libgnustep\-base1\.30|gnustep\-base\-abi\-1\.30)\b/; Both bookworm and bullseye shipped with outdated GNUstep core libraries so we would very much like to avoid that in trixie. Thanks for considering. --- End Message --- --- Begin Message --- On 2025-03-03 11:09:19 +0200, Yavor Doganov wrote: > В 09:32 +0100 на 03.03.2025 (пн), Emilio Pozuelo Monfort написа: > > gnustep-gui is failing its own autopkgtests. Can you take a look? > > Yes, I noticed and it's been fixed in Git already. Unfortunately I > couldn't test these in advance as autopkgtest-schroot does not allow me > to install extra packages. > > I hope it will be uploaded today and I guess it won't delay the > transition because gworkspace needs 2 more days to age. The old binaries got removed from testing. Closing. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1098765: marked as done (transition: pcl)
Your message dated Wed, 19 Mar 2025 07:37:25 +0100 with message-id and subject line Re: Bug#1098765: transition: pcl has caused the Debian Bug report #1098765, regarding transition: pcl to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1098765: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098765 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal X-Debbugs-Cc: p...@packages.debian.org Control: affects -1 + src:pcl User: release.debian@packages.debian.org Usertags: transition Hi release team, I would like to transition the pcl package to the new version. The only reverse dependency is probably ros-perception-pcl (maintained by me), or whatever ben comes up with, once it is there ;). Cheers Jochen --- End Message --- --- Begin Message --- On 2025-02-24 09:01:59 +0100, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 23/02/2025 21:15, Jochen Sprickerhof wrote: > > Package: release.debian.org > > Severity: normal > > X-Debbugs-Cc: p...@packages.debian.org > > Control: affects -1 + src:pcl > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hi release team, > > > > I would like to transition the pcl package to the new version. The only > > reverse dependency is probably ros-perception-pcl (maintained by me), or > > whatever ben comes up with, once it is there ;). > > Indeed. Does it build fine against the new pcl? If so, go ahead. The old binaries got removed from testing. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1094897: marked as done (transition: insighttoolkit5)
Your message dated Wed, 19 Mar 2025 07:38:27 +0100 with message-id and subject line Re: Bug#1094897: transition: insighttoolkit5 has caused the Debian Bug report #1094897, regarding transition: insighttoolkit5 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1094897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094897 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal X-Debbugs-Cc: insighttoolk...@packages.debian.org Control: affects -1 + src:insighttoolkit5 User: release.debian@packages.debian.org Usertags: transition I've uploaded insighttoolkit5 (ITK) v5.4 to experimental and it has cleared NEW. The disposition of ITK's five reverse dependencies is listed below. ants: fails to build, but upstream github sources DO build - filed bug #1094896 camitk: one test failed during my rebuild - filed bug #1094895 elastix: have uploaded new version to experimental, which builds OK plastimatch: builds OK with no source changes sight: fails to build - filed bug #1094894 Ben file: title = "insighttoolkit5"; is_affected = .depends ~ "libinsighttoolkit5.3" | .depends ~ "libinsighttoolkit5.4"; is_good = .depends ~ "libinsighttoolkit5.4"; is_bad = .depends ~ "libinsighttoolkit5.3"; --- End Message --- --- Begin Message --- On 2025-02-11 15:59:00 +0100, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 01/02/2025 05:35, Steve M. Robbins wrote: > > Package: release.debian.org > > Severity: normal > > X-Debbugs-Cc: insighttoolk...@packages.debian.org > > Control: affects -1 + src:insighttoolkit5 > > User: release.debian@packages.debian.org > > Usertags: transition > > > > I've uploaded insighttoolkit5 (ITK) v5.4 to experimental and it has cleared > > NEW. > > The disposition of ITK's five reverse dependencies is listed below. > > > > > > ants: fails to build, but upstream github sources DO build > > - filed bug #1094896 > > > > camitk: one test failed during my rebuild > > - filed bug #1094895 > > > > elastix: have uploaded new version to experimental, which builds OK > > > > plastimatch: builds OK with no source changes > > > > sight: fails to build > > - filed bug #1094894 > > Go ahead. This transition is complete. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1099894: marked as done (transition: addresses-for-gnustep/gnustep-addresses)
Your message dated Wed, 19 Mar 2025 07:25:58 +0100 with message-id and subject line Re: Bug#1099894: transition: addresses-for-gnustep/gnustep-addresses has caused the Debian Bug report #1099894, regarding transition: addresses-for-gnustep/gnustep-addresses to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1099894: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099894 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal X-Debbugs-Cc: addresses-for-gnus...@packages.debian.org Control: affects -1 + src:addresses-for-gnustep + src:gnustep-addresses User: release.debian@packages.debian.org Usertags: transition Our intention was to do this transition together with the rest of the GNUstep libraries (RT #1099081) but the package has been in NEW until today. This is a bugfix release following a full audit of the code inspired by #1087735. To cite the upstream announcement [1]: , | AddressManager and Addresses Frameworks got a major maintenance | release, 0.5.0. Highly recommended: code modernisation, highly | improved encoding detection and RFC compliance for UTF-8, display | fixes, memory and initialization handling, crash fixers ` Both rdeps agenda.app and gnumail build fine against the new version. There is no auto tracker because the source package was renamed from addresses-for-gnustep to gnustep-addresses to match the naming convention that was proposed to the FTP masters [2] and the rest of the GNUstep libraries/frameworks in the archive. Here is a ben file constructed by reportbug: title = "addresses-for-gnustep/gnustep-addresses"; is_affected = .depends ~ "libaddresses0" | .depends ~ "libaddressview0" | .depends ~ "libaddresses0.5.0" | .depends ~ "libaddressview0.5.0"; is_good = .depends ~ "libaddresses0.5.0" | .depends ~ "libaddressview0.5.0"; is_bad = .depends ~ "libaddresses0" | .depends ~ "libaddressview0"; [1] https://savannah.nongnu.org/news/?id=10726 [2] https://alioth-lists.debian.net/pipermail/pkg-gnustep-maintainers/2025-January/006272.html --- End Message --- --- Begin Message --- On 2025-03-14 08:16:32 +0200, Yavor Doganov wrote: > Sebastian Ramacher wrote: > > On 2025-03-09 17:28:26 +0100, Sebastian Ramacher wrote: > > > Control: tags -1 confirmed > > > On 2025-03-09 14:41:21 +0200, Yavor Doganov wrote: > > > > > > > > Both rdeps agenda.app and gnumail build fine against the new > > > > version. > > > > > > Please go ahead. > > > > binNMUs scheduled. > > Thanks. > > > Please also file a RM bug to remove addresses-for-gnustep from > > unstable. > > Done; #1100457. addresses-for-gnustep got removed from testing. Cheers -- Sebastian Ramacher--- End Message ---
