Simon McVittie | 1 Sep 16:32 2015
Picon

Bug#797678: dbus-user-session: should force dbus-x11 to upgrade

Package: dbus-user-session
Version: 1.10.0-1
Severity: serious
Justification: maintainer says so

mbiebl and buxy pointed out that installing dbus-user-session does not
force dbus-x11 to be upgraded in lockstep.

This is bad, because older dbus-x11 versions ship a 75dbus_dbus-launch
script that starts dbus-launch even if DBUS_SESSION_BUS_ADDRESS is already
set. That would cause two buses to be launched, and a nasty split-brain
situation.

It is not possible to make `dbus-launch --exit-with-session` not launch
if DBUS_SESSION_BUS_ADDRESS is set, because third party software relies
on being able to (ab)use dbus-launch to get a new bus for regression
tests and similar, because dbus-run-session(1) was only recently invented.

    S

Debian Bug Tracking System | 1 Sep 15:54 2015
Picon

Processed: your mail

Processing commands for control <at> bugs.debian.org:

> affects 777765 src:gdcm
Bug #777765 [src:activiz.net] activiz.net: ftbfs with GCC-5
Added indication that 777765 affects src:gdcm
>
End of message, stopping processing here.

Please contact me if you need assistance.
--

-- 
777765: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777765
Debian Bug Tracking System
Contact owner <at> bugs.debian.org with problems

Mathieu Malaterre | 1 Sep 15:51 2015
Picon

Bug#797673: Switch back to SWIB based C# layer in GDCM

Package: gdcm
Version: 2.4.4-4
Severity: grave
Tags: patch

Now that upstream has clarified the situation with Activiz.NET:


I suggest that:

1. We revert back (temporarily for stretch) to the GDCM C# SWIG layer (this is compatible with GDCM 2.2.x debian package),
2. Apply the attached patch,
3. Leave 777765 open,
4. Leave mummy and activiz.net in current state, so they will get auto-removed
5. once upstream (=kitware) updates Activiz.NET with a CastXML based build system, revert the operations !

(I am not sure about the status of cableswig, but as above, I would not touch it).

I've used the severity of grave, since otherwise GDCM will get removed simply because if Activiz.NET which would otherwise imapct lots of dependencies. Feel free to downgrade.

2cts
Attachment (gdcm_dotnet.patch): application/octet-stream, 4016 bytes
Michael Biebl | 1 Sep 14:46 2015
Picon

Bug#797661: Fails to upgrade, file conflict with x11-common

Package: xserver-xorg-core
Version: 2:1.17.2-2
Severity: serious

The xserver-xorg-core package fails to upgrade due to a file conflict
with x11-common:

Unpacking xserver-xorg-core (2:1.17.2-2) over (2:1.17.2-1.1) ...
dpkg: error processing archive
/var/cache/apt/archives/xserver-xorg-core_2%3a1.17.2-2_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man5/Xwrapper.config.5.gz', which is also in package x11-common 1:7.7+9
Errors were encountered while processing:
 /var/cache/apt/archives/xserver-xorg-core_2%3a1.17.2-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xserver-xorg-core depends on:
ii  keyboard-configuration    1.132
ii  libaudit1                 1:2.4.4-1
ii  libc6                     2.19-19
ii  libdrm2                   2.4.64-1
ii  libegl1-mesa              10.6.4-1
ii  libepoxy0                 1.2-1
ii  libgbm1                   10.6.4-1
ii  libgcrypt20               1.6.3-2
ii  libgl1-mesa-glx [libgl1]  10.6.4-1
ii  libpciaccess0             0.13.4-1
ii  libpixman-1-0             0.32.6-3
ii  libselinux1               2.3-2+b1
ii  libudev1                  225-1
ii  libxau6                   1:1.0.8-1
ii  libxdmcp6                 1:1.1.2-1
ii  libxfont1                 1:1.5.1-1
ii  libxshmfence1             1.2-1
ii  udev                      225-1
iu  xserver-common            2:1.17.2-2

Versions of packages xserver-xorg-core recommends:
ii  libgl1-mesa-dri  10.6.4-1

Versions of packages xserver-xorg-core suggests:
ii  xfonts-100dpi    1:1.0.4+nmu1
ii  xfonts-75dpi     1:1.0.4+nmu1
ii  xfonts-scalable  1:1.0.3-1.1

-- no debconf information

Steven Chamberlain | 1 Sep 14:26 2015

Bug#797656: kglobalaccel: out-of-date Build-Depends on (>= 5.12.0~)

Package: kglobalaccel
Version: 5.13.0-1
Severity: serious

Hi,

kglobalaccel/5.13.0-1 FTBFS on a few architectures:
kfreebsd-i386, ppc64, and x32 for example:
|   The following configuration files were considered but not accepted:
|    /usr/lib/i386-kfreebsd-gnu/cmake/KF5Crash/KF5CrashConfig.cmake, version: 5.12.0
https://buildd.debian.org/status/fetch.php?pkg=kglobalaccel&arch=kfreebsd-i386&ver=5.13.0-1&stamp=1440971005

This is because kglobalaccess had many versioned Build-Depends on
(>= 5.12.0~), and these were not bumped when the new upstream
version was packaged.

At least the libkf5crash-dev package must be (>= 5.13.0~) now;  I'm
not sure if the other Build-Depends should be (>= 5.13.0~) now also.

Thanks!

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

Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Mathieu Malaterre | 1 Sep 12:04 2015
Picon

Bug#797651: mummy fails to build (libgccxml-dev vs GCC-5)

Source: mummy
Version: 1.0.3-2
Severity: grave


mummy FTBFS in sid:

/usr/bin/cmake -E cmake_link_script CMakeFiles/mummy.dir/link.txt --verbose=1
/usr/bin/c++   -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2  -O2 -g -DNDEBUG   -Wl,-z,relro CMakeFiles/mummy.dir/MummyMain.cxx.o  -o bin/mummy -rdynamic bin/libmummyLib.a -lCableGenerators -lCableParsers -lexpat -lCxxTypes -lgxsys 
bin/libmummyLib.a(MummyCsharpGenerator.cxx.o): In function `ExtractTypeAndCountFromHintLine(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)':
/home/mathieu/tmp/mummy-1.0.3/MummyCsharpGenerator.cxx:437: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
bin/libmummyLib.a(MummyCsharpGenerator.cxx.o): In function `ReturnTypeMatchesHintType(cable::Type*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
/home/mathieu/tmp/mummy-1.0.3/MummyCsharpGenerator.cxx:456: undefined reference to `gxsys::SystemTools::UpperCase(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
bin/libmummyLib.a(MummyCsharpGenerator.cxx.o): In function `ExtractCountFromMethodDeclarationLine(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)':
/home/mathieu/tmp/mummy-1.0.3/MummyCsharpGenerator.cxx:500: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/mathieu/tmp/mummy-1.0.3/MummyCsharpGenerator.cxx:507: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/mathieu/tmp/mummy-1.0.3/MummyCsharpGenerator.cxx:514: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/mathieu/tmp/mummy-1.0.3/MummyCsharpGenerator.cxx:521: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
bin/libmummyLib.a(MummyCsharpGenerator.cxx.o): In function `MummyCsharpGenerator::CacheExternalHints(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
/home/mathieu/tmp/mummy-1.0.3/MummyCsharpGenerator.cxx:138: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
bin/libmummyLib.a(MummyLineOrientedTextFileReader.cxx.o):/home/mathieu/tmp/mummy-1.0.3/MummyLineOrientedTextFileReader.cxx:368: more undefined references to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' follow
bin/libmummyLib.a(MummySettings.cxx.o): In function `MummySettings::AddArgumentHandlers(gxsys::CommandLineArguments&)':
/home/mathieu/tmp/mummy-1.0.3/MummySettings.cxx:115: undefined reference to `gxsys::CommandLineArguments::AddArgument(char const*, gxsys::CommandLineArguments::ArgumentTypeEnum, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, char const*)'
/home/mathieu/tmp/mummy-1.0.3/MummySettings.cxx:122: undefined reference to `gxsys::CommandLineArguments::AddArgument(char const*, gxsys::CommandLineArguments::ArgumentTypeEnum, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, char const*)'
/home/mathieu/tmp/mummy-1.0.3/MummySettings.cxx:129: undefined reference to `gxsys::CommandLineArguments::AddArgument(char const*, gxsys::CommandLineArguments::ArgumentTypeEnum, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, char const*)'
/home/mathieu/tmp/mummy-1.0.3/MummySettings.cxx:136: undefined reference to `gxsys::CommandLineArguments::AddArgument(char const*, gxsys::CommandLineArguments::ArgumentTypeEnum, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, char const*)'
/home/mathieu/tmp/mummy-1.0.3/MummySettings.cxx:143: undefined reference to `gxsys::CommandLineArguments::AddArgument(char const*, gxsys::CommandLineArguments::ArgumentTypeEnum, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, char const*)'
bin/libmummyLib.a(MummyUtilities.cxx.o): In function `EmitDocumentationBlock(std::ostream&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, unsigned int, bool)':
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:963: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:965: undefined reference to `gxsys::SystemTools::ReplaceString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, char const*)'
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:1015: undefined reference to `gxsys::SystemTools::ReplaceString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, char const*)'
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:1016: undefined reference to `gxsys::SystemTools::ReplaceString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, char const*)'
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:969: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:971: undefined reference to `gxsys::SystemTools::ReplaceString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, char const*)'
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:975: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:977: undefined reference to `gxsys::SystemTools::ReplaceString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, char const*)'
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:981: undefined reference to `gxsys::RegularExpression::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/home/mathieu/tmp/mummy-1.0.3/MummyUtilities.cxx:983: undefined reference to `gxsys::SystemTools::ReplaceString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, char const*)'
collect2: error: ld returned 1 exit status

Simon McVittie | 1 Sep 11:19 2015
Picon

Bug#797649: dxflib: transition needed for g++-5 ABIs

Source: dxflib
Version: 2.5.0.0-3
Severity: serious
Justification: potentially breaks reverse-dependencies

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of dxflib, std::string appears in header files that
get installed, so it seems very likely that a transition is needed.
The transition consists of renaming the affected library packages, adding a
v5 suffix (libdxflib-2.5.0.0v5). The SONAME should not be changed.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

In the case of dxflib, there do not seem to be any C++ build-dependencies,
so I think this transition is ready to start.

The package is likely to be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

    S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg00000.html

Simon McVittie | 1 Sep 10:32 2015
Picon

Bug#797646: xmms2: transition needed for g++-5 ABIs

Source: xmms2
Version: 0.8+dfsg-13
Severity: serious
Justification: breaks reverse-dependencies

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of xmms2, std::string appears in header files that
get installed, so it seems very likely that a transition is needed.
The transition consists of renaming the affected library packages, adding a
v5 suffix.

In the case of xmms2, libxmmsclient++4 and libxmmsclient++-glib1 appear
to be affected. A couple of packages build-depend on libxmmsclient++-dev,
so libxmmsclient++4 needs renaming to libxmmsclient++4v5. Nothing actually
seems to build-depend on libxmmsclient++-glib-dev, but if you're going
through the NEW queue to rename libxmmsclient++4 anyway, it seens sensible
to rename libxmmsclient++-glib1 to libxmmsclient++-glib1v5 in the
same upload.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

In the case of xmms2:

* boost already started its transition with version 1.58
* the other library dependencies appear to have C APIs

so I think this transition is ready to start.

The package is likely to be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

    S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg00000.html

Debian Bug Tracking System | 1 Sep 10:30 2015
Picon

Processed: Re: [Pkg-fglrx-devel] Bug#796074: Bug#796074: fglrx-driver: vterms broken when fglrx in use

Processing commands for control <at> bugs.debian.org:

> severity #796074 normal
Bug #796074 [fglrx-driver] fglrx-driver: vterms broken when fglrx in use
Severity set to 'normal' from 'grave'
> thanks
Stopping processing here.

Please contact me if you need assistance.
--

-- 
796074: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796074
Debian Bug Tracking System
Contact owner <at> bugs.debian.org with problems

Simon McVittie | 1 Sep 10:20 2015
Picon

Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'

Package: kdelibs5-dev
Version: 4:4.14.10-3
Severity: serious
Justification: kopete fails to build from source (but built successfully in the past)
Control: affects -1 kopete

X-Debbugs-Cc set to kopete <at> packages.debian.org since it is known to be
affected.

While building kopete to verify that a proposed upload for libmsn
successfully carries out the libstdc++ transition, I encountered this
build error:

cd kopete && /usr/bin/c++   -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=24 -DKDE_DEPRECATED_WARNINGS
-DQT_NO_CAST_TO_ASCII -DQT_NO_STL -DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS
-D_BSD_SOURCE -D_DEFAULT_SOURCE -D_REENTRANT -D_XOPEN_SOURCE=500 -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
-D_FORTIFY_SOURCE=2  -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts
-Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new
-fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden
-Werror=return-type -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG -I. -I../../kopete
-I../../libkopete -I../libkopete -I../../libkopete/ui -I../../libkopete/private
-I../../libkopete/contactlist -I../../libkopete/tasks -I../../kopete/addaccountwizard
-Iaddaccountwizard -I../../kopete/statusmenu -Istatusmenu -I../../kopete/identity -Iidentity
-I../../kopete/contactlist -Icontactlist -I../../kopete/config/plugins -I/usr/include/KDE
-I/usr/include/qt4/KDE -I/usr/include/qt4 -I/usr/include/qt4/phonon
-I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtUiTools
-I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtSql
-I/usr/include/qt4/QtScriptTools -I/usr/include/qt4/QtScript -I/usr/include/qt4/QtNetwork
-I/usr/include/qt4/QtHelp -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtDeclarative
-I/usr/include/qt4/QtDBus -I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt -I/usr/share/qt4/mkspecs/default
-I/usr/include/qimageblitz    -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -o
CMakeFiles/kopete_bin.dir/kopeteadaptor.o -c kopeteadaptor.cpp
make[4]: *** No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'.  Stop.

This appears to be because KDeclarative's CMake glue mentions that library:

% ack libsoprano /usr/lib
/usr/lib/cmake/KDeclarative/KDeclarativeLibraryTargets-debian.cmake
12:  IMPORTED_LINK_INTERFACE_LIBRARIES_DEBIAN "kdeui;/usr/lib/libsoprano.so"

If a particular -dev package requires linking with some other library,
it should depend on that library's -dev package (the same principle
as depending on the -dev packages of the libraries mentioned in a
pkg-config .pc file).

There is an additional, more minor bug here, which could perhaps be fixed
at the same time: that cmake file mentions libsoprano by its fully qualified
path, so kopete would also FTBFS in a similar way if libsoprano was moved
from /usr/lib to /usr/lib/${DEB_HOST_MULTIARCH}. If I'm understanding
correctly, the CMake glue should ideally list system libraries by the
name that would follow the "-l" linker argument, for example "kdeui;soprano",
in the same way that pkg-config would normally result in
"-lkdeui -lsoprano". Please clone a separate bug for this if it is
confirmed but not trivial to fix.

Regards,
    S

Simon McVittie | 1 Sep 09:49 2015
Picon

Bug#791140: closed by Pau Garcia i Quiles <pgquiles <at> elpauer.org> ()

Control: reopen 791140

On Mon, 31 Aug 2015 at 08:39:10 +0000, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:libmsn package:
> 
> #791140: libmsn: library transition may be needed when GCC 5 is the default
...
> Done in 4.2.1+dfsg1

A bug should not be closed until the version fixing it has reached the
archive. I assume you are referring to
<http://mentors.debian.net/package/libmsn> here. I'll look at that
version next.

For bugs with a wider impact than their own package, such as RC
bugs, transitions and release goals, please try to keep all available
information available in the bug log. The number of packages involved
in the libstdc++ transition is huge (around 3000 packages to be rebuilt
and up to 300 sourceful uploads), and a small number of developers are
trying to make it happen; the more information we have immediately
available, the sooner we can complete this transition and make unstable
usable for development again.

    S


Gmane