Bug#805157: virtuoso-opensource: FTBFS on s390x: conflicting types for 'saddr_t'
tags 805157 patch
user ubuntu-de...@lists.ubuntu.com
usertags 805157 ubuntu-patch xenial
thanks
On Sun, Nov 15, 2015 at 01:33:25PM +0100, Kurt Roeckx wrote:
> Your package is failing to build on s390x with the following
> error:
> In file included from Dksestcp.c:32:0:
> Dksestcpint.h:45:25: error: conflicting types for 'saddr_t'
> typedef struct sockaddr saddr_t;
> ^
> In file included from /usr/include/linux/types.h:4:0,
> from /usr/include/s390x-linux-gnu/asm/sigcontext.h:10,
> from /usr/include/s390x-linux-gnu/bits/sigcontext.h:27,
> from /usr/include/signal.h:332,
> from ../../libsrc/Dk/Dksystem.h:62,
> from ../../libsrc/Dk.h:40,
> from Dksestcp.c:30:
> /usr/include/s390x-linux-gnu/asm/types.h:18:25: note: previous declaration of
> 'saddr_t' was here
> typedef __signed__ long saddr_t;
> ^
This should do the trick.
* Remove the saddr_t typedef, which clashes with system headers on s390x
(closes: #805157).
diff -Nru
virtuoso-opensource-6.1.6+dfsg2/debian/patches/remove-saddr_t-typedef.patch
virtuoso-opensource-6.1.6+dfsg2/debian/patches/remove-saddr_t-typedef.patch
--- virtuoso-opensource-6.1.6+dfsg2/debian/patches/remove-saddr_t-typedef.patch
1970-01-01 01:00:00.0 +0100
+++ virtuoso-opensource-6.1.6+dfsg2/debian/patches/remove-saddr_t-typedef.patch
2015-12-24 17:39:52.0 +
@@ -0,0 +1,50 @@
+Description: Remove the saddr_t typedef
+ This clashes with system headers on s390x.
+Author: Colin Watson
+Bug-Debian: https://bugs.debian.org/805157
+Forwarded: no
+Last-Update: 2015-12-24
+
+Index: b/libsrc/Dk/Dksestcp.c
+===
+--- a/libsrc/Dk/Dksestcp.c
b/libsrc/Dk/Dksestcp.c
+@@ -587,7 +587,7 @@
+ {
+ int rc;
+ int new_socket;
+- socklen_t addrlen = sizeof (saddr_t);
++ socklen_t addrlen = sizeof (struct sockaddr);
+
+ dbg_printf_1 (("tcpses_accept."));
+
+@@ -2481,7 +2481,7 @@
+ return (SER_CNTRL);
+ }
+
+- if ((rc = bind (s, (saddr_t *) p_addr, sizeof (saddrun_t))) < 0)
++ if ((rc = bind (s, (struct sockaddr *) p_addr, sizeof (saddrun_t))) < 0)
+ {
+
+ test_eintr (ses, rc, errno);
+Index: b/libsrc/Dk/Dksestcpint.h
+===
+--- a/libsrc/Dk/Dksestcpint.h
b/libsrc/Dk/Dksestcpint.h
+@@ -42,7 +42,6 @@
+
+
+ typedef struct sockaddr_in saddrin_t;
+-typedef struct sockaddr saddr_t;
+ #ifdef COM_UNIXSOCK
+ typedef struct sockaddr_un saddrun_t;
+ #endif
+@@ -53,7 +52,7 @@
+ #ifdef COM_UNIXSOCK
+ saddrun_t u;
+ #endif
+- saddr_t a;
++ struct sockaddr a;
+ } usaddr_t;
+ #define TCP_HOSTNAMELEN 100 /* Something
*/
+
diff -Nru virtuoso-opensource-6.1.6+dfsg2/debian/patches/series
virtuoso-opensource-6.1.6+dfsg2/debian/patches/series
--- virtuoso-opensource-6.1.6+dfsg2/debian/patches/series 2014-09-15
17:34:46.0 +0100
+++ virtuoso-opensource-6.1.6+dfsg2/debian/patches/series 2015-12-24
17:40:01.0 +
@@ -15,3 +15,4 @@
safer-timeout.patch
17-fix-imagemagick-detection.patch
remove_ckeditor_mini
+remove-saddr_t-typedef.patch
--
Colin Watson [cjwat...@debian.org]
Re: KDE 3.1.4 Status Update - 20031020
On Mon, Oct 20, 2003 at 05:10:14PM -0500, Chris Cheney wrote: > The current[1] status of KDE in sid is below. Hopefully the buildds will > catch up soon then I can upload a new kdelibs. I am not sure if mips is > ever going to be in good shape since it appears the buildd admin doesn't > care to maintain it... I'm not sure that waiting for buildds before uploading new packages is really good at this stage. If you're waiting for a particular version of kdelibs to upload kdebase, for example, then it would be better just to add a versioned build-dep to kdebase. Those can be ignored pretty efficiently by the buildds until a new version is available, and in the meantime testing can proceed by users and by other buildds. kdebase is really getting urgent. :( Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: KDE 3.1.4 Status Update - 20031020
On Wed, Oct 22, 2003 at 08:05:06PM +0300, Riku Voipio wrote: > On Wed, Oct 22, 2003 at 06:11:31AM -0500, Colin Watson wrote: > > On Mon, Oct 20, 2003 at 05:10:14PM -0500, Chris Cheney wrote: > > > The current[1] status of KDE in sid is below. Hopefully the > > > buildds will catch up soon then I can upload a new kdelibs. I am > > > not sure if mips is ever going to be in good shape since it > > > appears the buildd admin doesn't care to maintain it... > > > > I'm not sure that waiting for buildds before uploading new packages > > is really good at this stage. If you're waiting for a particular > > version of kdelibs to upload kdebase, for example, then it would be > > better just to add a versioned build-dep to kdebase. > > That's not the problem. the problem is that kdelibs-dev package > depends on exact kdelibs4 version, and the new kdelibs-dev is > binary-all and thus gets into the archive before kdelibs is compiled > on that specific platform. Oh, that should be equally not a problem. If kdelibs-dev can't be installed then the buildds will just defer the build for a while; that's perfectly normal and not something that should delay maintenance work. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Orphaning packages
On Thu, Oct 23, 2003 at 01:22:47PM -0400, Nathanael Nerode wrote: > I believe that the kdelibs upload to fix RC bugs is very high > priority. It also should be pretty easy! > > 1. kdelibs-data requires a > Conflicts: k3b (<= 0.9-3), arson (<= 0.9.7-1) > line (see #214534, #214535). This is a job for versioned Replaces:, not versioned Conflicts:. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: ETA on kdebase 3.1.4?
On Thu, Nov 13, 2003 at 02:22:43AM -0600, Chris Cheney wrote: > On Thu, Nov 13, 2003 at 12:23:30AM -0500, Nathanael Nerode wrote: > > Several estimates have come and gone, but could we have a new estimate > > anyway? ;-) > > After looking at kdebase closer I determined it will take a bit longer > than expected to fix it. There are roughly 55-60 Debian specific bugs on > kdebase which I am currently working on. If an initial upload of kdebase 3.1.4 could be made before all of the work necessary for a final release has been done, that would be very much appreciated. You'll be able to start finding out whether there are unexpected build problems that way, and you'll give the release team a better idea of how long we should expect to wait before it's in a releasable state. While it makes sense not to upload kdebase willy-nilly because of its size and the length of time it takes to build, it really doesn't make sense to be too conservative either. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#631769: [Debconf-devel] Bug#631769: New Kde frontend based on debconf-kde-helper
On Thu, Jun 30, 2011 at 02:03:56AM +0300, Modestas Vainius wrote: > I pushed my changes to the debconf.git close on wagner [1], branch debconf- > kde. Could you review and merge changes? Sorry for dropping this on the floor for so long! I've reviewed this and tested it on a Debian KDE stretch system, and I see no major problems, so I've rebased and merged it. The only substantive changes I made were to silence the rather noisy debugging output from debconf-kde-helper (using QT_LOGGING_RULES) unless DEBCONF_DEBUG=kde is set, and to make the Kde frontend fall back to the Qt frontend. > Notably, I renamed old Kde frontend to Qt (3ae06bf). Sune asked me to keep > old > frontend for now as he might try to keep qt4-perl alive. However, I think > there is a consensus that debconf-kde-helper based one is the future so maybe > we will get rid of that old frontend regardless in the end. That's still to > be > decided. It seems likely that we'll need to get rid of it relatively soon, but I'd first like to make sure that the new one works properly in more than trivial test situations. I've CCed the maintainers of debconf-kde and the debian-qt-kde list - is that something you could test, please? Use debconf 1.5.68 once it hits unstable shortly, and also make sure that you aren't seeing warnings about falling back to the Qt frontend. > Regarding the last commit (0a4843c - NEWS entry), Kde frontend will stop > working for its users unless they install debconf-kde-helper. I don't see how > we can avoid this breakage via dependencies thus I added a NEWS entry. > Surprisingly, there was no NEWS file before so I don't know if you want to > add > it. So feel free to ignore that commit. Nowadays, task-kde-desktop happens to pull debconf-kde-helper in via apper, so most people probably have it; but we should probably explicitly add it to the task. -- Colin Watson [cjwat...@debian.org]
Re: Bug#631769: [Debconf-devel] Bug#631769: New Kde frontend based on debconf-kde-helper
On Thu, Jul 19, 2018 at 01:43:09PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > El jueves, 19 de julio de 2018 07:08:43 -03 Colin Watson escribió: > > Sorry for dropping this on the floor for so long! I've reviewed this > > and tested it on a Debian KDE stretch system, and I see no major > > problems, so I've rebased and merged it. > > > > The only substantive changes I made were to silence the rather noisy > > debugging output from debconf-kde-helper (using QT_LOGGING_RULES) unless > > DEBCONF_DEBUG=kde is set, and to make the Kde frontend fall back to the > > Qt frontend. > > That sounds good, and a post-patch related change if I'm not mistaken (the > logging rules where added after Modestas did the patch, again if I'm not > mistaken). Quite possibly. > > It seems likely that we'll need to get rid of it relatively soon, but > > I'd first like to make sure that the new one works properly in more than > > trivial test situations. I've CCed the maintainers of debconf-kde and > > the debian-qt-kde list - is that something you could test, please? Use > > debconf 1.5.68 once it hits unstable shortly, and also make sure that > > you aren't seeing warnings about falling back to the Qt frontend. > > Now the bad news: we haven't (or at very least I haven't) heard of Modestas > in > a long time now. Ah, that's a shame, but the debconf side of the new frontend is simple enough that I should have no trouble maintaining it from here on in anyway. (I don't know much about the debconf-kde side, but that's had a respectable amount of activity lately so I'm not too concerned about it.) > For what I've gathered from the last queries I made to the team due to qt4- > perl and the debconf frontend no one is really using/interested in it. Of > course if someone reading me thinks I'm wrong please jump in right now! > > At this point getting rid of the qt4 fromtend will surely help us reduce the > Qt4 footprint in the archive. > > > What I can do is ask users to try it. I would need to know first how to use > it, because I see the KDE fromtend installed in my system but I've never seen > a KDE-based debconf dialog. Yes, I might be missing something very silly > here... Simple enough: once you've installed the new version, "dpkg-reconfigure debconf" and select the "Kde" frontend. You can then install/remove packages that do debconf interaction, using apt or aptitude or a graphical frontend or whatever, and see if you get reasonable prompts. If you'd prefer to configure the frontend temporarily, then you can also export DEBIAN_FRONTEND=kde in the environment (but make sure that this makes it all the way through whatever layers of package management you're using). Thanks, -- Colin Watson [cjwat...@debian.org]
Re: Bug#631769: [Debconf-devel] Bug#631769: New Kde frontend based on debconf-kde-helper
On Wed, Jul 25, 2018 at 10:23:49AM +0800, Matthias Klumpp wrote: > 2018-07-25 5:51 GMT+08:00 Lisandro Damián Nicanor Pérez Meyer > : > > On Thu, 19 Jul 2018 at 14:04, Colin Watson wrote: > >> Simple enough: once you've installed the new version, "dpkg-reconfigure > >> debconf" and select the "Kde" frontend. You can then install/remove > >> packages that do debconf interaction, using apt or aptitude or a > >> graphical frontend or whatever, and see if you get reasonable prompts. > > > > Works like a charm. I will keep testing it, but I think we can > > deprecate the Qt4 version right now. > > This is really cool, thank you a lot for working on it! The KDE > frontend will also be much easier to maintain with debconf-kde-helper, > porting it to Qt 6 when it arrives should be very easy. > This change may also help with a current effort to improve the way > debconf is handled when packages are installed via PackageKit (by > potentially making it possible to get rid of KDE special-casing). Great, thanks a lot to you both. I've uploaded debconf 1.5.69 now to remove the old Qt frontend. -- Colin Watson [cjwat...@debian.org]
Re: [Debconf-devel] Bug#887687: libsmokeqt4-dev: broken symlinks and causes qt4-perl FTBFS
On Fri, Jun 29, 2018 at 10:22:50AM +0300, Niko Tyni wrote:
> On Fri, Jun 29, 2018 at 12:55:50AM +, Scott Kitterman wrote:
> > I had hoped to work on this this week. It hasn't happened and it's not
> > going to.
> >
> > In the end, I the Qt4 stuff has to go, so I wouldn't wait on this for the
> > transition.
>
> Okay, thanks. The problem is that we can't really get Perl 5.28 into
> testing if that makes debconf fail to build. So something needs to
> be done.
>
> I think I'll try to push debconf #629405 ("libqtgui4-perl based frontend
> might need to be removed") then.
That's now fixed, so as far as debconf is concerned you can remove
qt4-perl.
--
Colin Watson [cjwat...@debian.org]
Bug#449554: konqueror: Recode manual pages to UTF-8
tags 449554 patch
user [EMAIL PROTECTED]
usertags 449554 origin-ubuntu ubuntu-patch hardy
thanks
The attached patch uses a new facility provided by man-db 2.5.1 to
recode manual pages to UTF-8 while reading them. This allows the man kio
slave's rendering code to work regardless of the source encoding of the
manual page, without it having to have lots of logic duplicated from
man-db to figure this out.
This facility is specific to man-db, and so at present not suitable for
upstream (without some kind of run-time logic to figure out whether the
facility is available).
See also:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440420
https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/44548
Thanks,
--
Colin Watson [EMAIL PROTECTED]
diff -Nru kdebase-3.5.8.dfsg.1.orig/debian/control.in kdebase-3.5.8.dfsg.1/debian/control.in
--- kdebase-3.5.8.dfsg.1.orig/debian/control.in 2008-02-11 10:45:39.0 +
+++ kdebase-3.5.8.dfsg.1/debian/control.in 2008-02-11 10:52:06.0 +
@@ -174,7 +174,7 @@
Package: kdebase-kio-plugins
Section: kde
Architecture: any
-Depends: ${shlibs:Depends}, libsasl2-modules, psmisc, kdeeject
+Depends: ${shlibs:Depends}, libsasl2-modules, psmisc, kdeeject, man-db (>= 2.5.1-1)
Recommends: hal, pmount, kamera, kdemultimedia-kio-plugins
Suggests: khelpcenter, mtools
Conflicts: kdebase-libs (<< 4:3.0.0)
diff -Nru kdebase-3.5.8.dfsg.1.orig/debian/patches/71_kio_man_utf8.diff kdebase-3.5.8.dfsg.1/debian/patches/71_kio_man_utf8.diff
--- kdebase-3.5.8.dfsg.1.orig/debian/patches/71_kio_man_utf8.diff 1970-01-01 01:00:00.0 +0100
+++ kdebase-3.5.8.dfsg.1/debian/patches/71_kio_man_utf8.diff 2008-02-11 10:44:54.0 +
@@ -0,0 +1,64 @@
+diff -Nur -x '*.orig' -x '*~' kdebase-3.5.8/kioslave/man/kio_man.cpp kdebase-3.5.8.new/kioslave/man/kio_man.cpp
+--- kdebase-3.5.8/kioslave/man/kio_man.cpp 2007-10-08 10:51:22.0 +0100
kdebase-3.5.8.new/kioslave/man/kio_man.cpp 2008-01-31 09:04:58.0 +
+@@ -517,6 +517,11 @@
+ myStdStream += QString::fromLocal8Bit(s, len);
+ }
+
++void MANProtocol::slotGetStdOutputUtf8(KProcess* /* p */, char *s, int len)
++{
++ myStdStream += QString::fromUtf8(s, len);
++}
++
+ char *MANProtocol::readManPage(const char *_filename)
+ {
+ QCString filename = _filename;
+@@ -564,24 +569,20 @@
+ }
+ lastdir = filename.left(filename.findRev('/'));
+
+-QIODevice *fd= KFilterDev::deviceForFile(filename);
+-
+-if ( !fd || !fd->open(IO_ReadOnly))
+-{
+- delete fd;
+- return 0;
+-}
+-QByteArray array(fd->readAll());
+-kdDebug(7107) << "read " << array.size() << endl;
+-fd->close();
+-delete fd;
+-
+-if (array.isEmpty())
+-return 0;
+-
+-const int len = array.size();
++myStdStream = QString::null;
++KProcess proc;
++/* TODO: detect availability of 'man --recode' so that this can go
++ * upstream */
++proc << "man" << "--recode" << "UTF-8" << filename;
++
++QApplication::connect(&proc, SIGNAL(receivedStdout (KProcess *, char *, int)),
++ this, SLOT(slotGetStdOutputUtf8(KProcess *, char *, int)));
++proc.start(KProcess::Block, KProcess::All);
++
++const QCString cstr=myStdStream.utf8();
++const int len = cstr.size()-1;
+ buf = new char[len + 4];
+-qmemmove(buf + 1, array.data(), len);
++qmemmove(buf + 1, cstr.data(), len);
+ buf[0]=buf[len]='\n'; // Start and end with a end of line
+ buf[len+1]=buf[len+2]='\0'; // Two NUL characters at end
+ }
+diff -Nur -x '*.orig' -x '*~' kdebase-3.5.8/kioslave/man/kio_man.h kdebase-3.5.8.new/kioslave/man/kio_man.h
+--- kdebase-3.5.8/kioslave/man/kio_man.h 2005-10-10 16:04:01.0 +0100
kdebase-3.5.8.new/kioslave/man/kio_man.h 2008-01-31 12:44:49.0 +
+@@ -61,6 +61,7 @@
+
+ private slots:
+ void slotGetStdOutput(KProcess*, char*, int);
++ void slotGetStdOutputUtf8(KProcess*, char*, int);
+
+ private:
+ void checkManPaths();
Bug#672552: kdelibs5-dev: PythonMacros.cmake breaks with Python 3
Package: kdelibs5-dev Version: 4:4.7.4-4 Severity: normal User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu quantal PythonMacros.cmake assumes that byte-compiling any .py file will result in a .pyc file in the current directory. This breaks with Python 3, which creates it in a __pycache__ subdirectory instead. Gentoo carries a patch to allow suppressing this with an environment variable: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-base/kdelibs/files/kdelibs-4.6.3-bytecode.patch?view=markup https://bugs.gentoo.org/show_bug.cgi?id=372407 This would make a degree of sense for Debian as well since dh_python2 removes .pyc files anyway, so it's just a waste of time to byte-compile them during package builds. However, it would be nice if this macro were smart enough to handle __pycache__ in the Python 3 case as well. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120512014244.ga6...@riva.dynamic.greenend.org.uk
Bug#672553: pykde4: Add Python 3 support
Package: pykde4
Version: 4:4.7.4-2
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch quantal
pykde4 already supports Python 3 in the upstream code. Making this
available would be a simple matter of packaging.
Well ... almost. There are a couple of things that complicate it.
Firstly, there's a patch from newer upstream releases to fix building
with >= 3.2. Secondly, a bug in kdelibs5-dev (which I've filed
separately as #672552) causes a build failure; I worked around that by
shipping a local cut-down copy of PythonMacros.cmake, which I reckoned
would be temporarily acceptable because the resulting file is so short.
I've tested this by running a Python 3 port of the Ubuntu installer's
KDE frontend with it, and everything appears to be working fine. I
built my test packages on Ubuntu rather than Debian because I ran into
#671893 and couldn't readily fix that, but I hope it will still be OK
once that's fixed.
* Add Python 3 support.
diff --git a/debian/control b/debian/control
index 51ac67f..d634f34 100644
--- a/debian/control
+++ b/debian/control
@@ -8,8 +8,9 @@ Build-Depends: kde-sc-dev-latest (>= 4:4.7.4),
libphonon-dev (>= 4:4.6.0really4.4.4), libsoprano-dev (>= 2.7.0),
libqt4-dev (>= 4:4.7.1), libqt4-opengl-dev (>= 4:4.7.1), libqtwebkit-dev,
libboost-dev, shared-desktop-ontologies (>= 0.8),
- python, python-all-dev, python-sip-dev (>= 4.12.0),
- python-qt4 (>= 4.8.3-3~), python-qt4-dev (>= 4.8.3-3~)
+ python, python-all-dev, python3-all-dev,
+ python-sip-dev (>= 4.12.0), python3-sip-dev,
+ python-qt4 (>= 4.8.3-3~), python3-pyqt4, python-qt4-dev (>= 4.8.3-3~)
Uploaders: Sune Vuorela , Modestas Vainius
, Michael Meskes
Standards-Version: 3.9.2
X-Python-Version: >= 2.5
@@ -89,3 +90,50 @@ Description: debugging symbols for the PyKDE bindings
are experiencing crashes of the PyKDE application and wish to report a problem
to the developers.
+Package: python3-kde4
+Architecture: any
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends},
+ python3-pyqt4, ${sip:Depends}, python3-sip
+Provides: ${python3:Provides}
+Description: Python 3 bindings for the KDE Development Platform
+ This package contains PyKDE, the Python 3 bindings for the KDE
+ libraries, that allow you to write KDE programs using Python 3 instead of
+ C++. It contains at least the following modules under the
+ PyKDE namespace:
+ .
+ * dnssd
+ * kdecore
+ * kdeui
+ * khtml
+ * kio
+ * knewstuff
+ * kparts
+ * kterminal
+ * ktexteditor
+ * kutils
+ * nepomuk
+ * plasma
+ * solid
+ .
+ And a few KDE related technologies like:
+ .
+ * akonadi
+ * phonon
+ * soprano
+ .
+ This package provides modules for all supported Python 3 versions.
+
+Package: python3-kde4-dbg
+Section: debug
+Architecture: any
+Priority: extra
+Depends: ${misc:Depends}, kdelibs5-dbg, python3-kde4 (= ${binary:Version})
+Recommends: python3-pyqt4-dbg
+Breaks: kdebindings-dbg
+Replaces: kdebindings-dbg
+Description: debugging symbols for the PyKDE bindings
+ This package contains debugging files used to investigate problems with
+ Python 3 bindings for the KDE Development Platform. Install this package if
+ you are experiencing crashes of the PyKDE application and wish to report a
+ problem to the developers.
+
diff --git a/debian/patches/cmake_no_bytecode.diff
b/debian/patches/cmake_no_bytecode.diff
new file mode 100644
index 000..ab90706
--- /dev/null
+++ b/debian/patches/cmake_no_bytecode.diff
@@ -0,0 +1,31 @@
+Index: b/cmake/modules/PythonMacros.cmake
+===
+--- /dev/null
b/cmake/modules/PythonMacros.cmake
+@@ -0,0 +1,26 @@
++# Python macros
++# ~~~~~
++# Copyright (c) 2007, Simon Edwards
++# Cloned-and-hacked by Colin Watson , removing bytecode
++# support.
++#
++# Redistribution and use is allowed according to the terms of the BSD license.
++# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
++#
++# This file defines the following macros:
++#
++# PYTHON_INSTALL (SOURCE_FILE DESINATION_DIR)
++# Install the SOURCE_FILE, which is a Python .py file, into the
++# destination directory during install.
++
++GET_FILENAME_COMPONENT(PYTHON_MACROS_MODULE_PATH ${CMAKE_CURRENT_LIST_FILE}
PATH)
++
++MACRO(PYTHON_INSTALL SOURCE_FILE DESINATION_DIR)
++
++ FIND_FILE(_python_compile_py PythonCompile.py PATHS ${CMAKE_MODULE_PATH})
++
++ ADD_CUSTOM_TARGET(compile_python_files ALL)
++
++ # Install the source file.
++ INSTALL(FILES ${SOURCE_FILE} DESTINATION ${DESINATION_DIR})
++ENDMACRO(PYTHON_INSTALL)
diff --git a/debian/patches/python32_compile_fix.diff
b/debian/patches/python32_compile_fix.diff
new file mode 100644
index 000..5440477
--- /dev/null
+++ b/debian/patches/python32_compile_fix.diff
@@ -0,0 +1,21 @@
+Description: Compile fix for Python 3.2 and higher
+Author: Simon Edwards
+Origin: upstre
Re: bugs requiring a new kdebase upload.
On Wed, Dec 10, 2003 at 09:43:45PM -0600, Chris Cheney wrote: > Yea, I am working through my list of packages needing updates and will > be uploading kdebase soon. By the way most of the buildds are still not > online so it won't be building and migrating to testing anytime soon. If > I remember correctly testing migration is still disabled anyway. As Rene says, testing is running. Also I think it's better to forget about the fact that some buildds aren't running; there may be bugs that require a new kdebase upload anyway, and you won't find out about those until it's uploaded. This is *really urgent*. It's been urgent for the last couple of months. Please, we cannot release in this condition and KDE is not something we can rush in at the last minute. Buildd status, testing status, all such external factors can be sorted out later. If you yourself have no time, then perhaps one of the other people forming the maintenance group can do it? -- Colin Watson [EMAIL PROTECTED]
Bug#215946: /etc/kde3/magic/*.magic
On Fri, Dec 12, 2003 at 06:21:09PM -0600, Chris Cheney wrote: > On Wed, Dec 10, 2003 at 10:01:29PM +0100, Bill Allombert wrote: > > On Sat, Dec 06, 2003 at 03:18:16PM -0600, Chris Cheney wrote: > > > What /etc/mime-magic file, you mean the one that gnome > > > provides?[1] Why doesn't gnome use the KDE one? :P All I see that > > > is standard is a /etc/magic file which does not include anything > > > that was directly built into the file(1) utility, which happens to > > > mean /etc/magic is empty. > > > > Then why not add mime-magic support to mime-types and share that > > between all the program that need it instead of replicating the > > feature all along ? > > It would probably make more sense to have file ship its magic file > (the one with the actual data in it). If file provided its magic file > then both Gnome and KDE could send their changes to upstream and > everyone benefit from it, instead of just forking it. Isn't this what's in the /usr/share/misc/file directory? -- Colin Watson [EMAIL PROTECTED]
Re: kdebase, kdemultimedia ETAs?
On Mon, Jan 05, 2004 at 03:26:27PM -0600, Chris Cheney wrote: > On Mon, Jan 05, 2004 at 09:55:49PM +0100, Dominique Devriese wrote: > > I think we all would very much like KDE 3.2 in sarge. I have a newly > > added application in there e.g., that deserves more attention. > > However, we have to make a concession at some point, and we have to > > keep Debian's interests in mind. If other Debian devs see that KDE > > gets to upload a brand new version, they'll want to do the same, and > > we can write off all chances to a quick Debian release. I fully agree with Nathanael's position here. Uploading KDE 3.2 at this point will probably kill your chances of getting a working KDE in sarge, or else delay sarge radically, since the version of KDE in testing is not currently releaseable. (An installable kdemultimedia would have got into testing tonight if it weren't for the recent upload; fortunately it narrowly escaped screwing over newer versions of jack-audio-connection-kit and alsa-lib, which are needed for GNOME. There are a lot of interdependencies which still need to be resolved.) I'd suggest that KDE ought to be in mini-freeze (bug fixes, no new major upstreams) until no KDE packages are listed in http://ftp-master.debian.org/testing/testing_probs.html and in particular until a modern version of meta-kde is in testing. I'm giving the GNOME people essentially the same advice. We *really* need to have stable, working, installable (!) versions of the desktop environments in testing, and we need them there as soon as possible. The way to do that is to fix, stabilize, and freeze, not introduce lots of new code. > Another thing to note was that the toolchain was supposed to have been > frozen in September but there was a new gcc upload just last week on > 29 Dec 2003... As long as even the toolchain isn't frozen freezing > other things aren't going to work very well either, for example see the > kdebase breakage wrt SYS_sysinfo. AFAICT that was broken by new glibc > with 2.6 headers. Yes, using syscalls the way KDE did was not a good > idea, but if the toolchain is going to continue to rev exposing more > bugs in applications what is the point in the freeze? I don't know if > anyone with power is reading this, but freezing the toolchain at some > point would be a good idea. I don't think there are going to be any more major toolchain changes from now until release. However there does still have to be *some* work done on gcc to fix compiler bugs exposed by builds. As far as I know, this has been the driver for virtually all Debian gcc package work over the last few months. There don't have to be no changes at all to the toolchain: common sense applies, and "no major destabilizing changes, but bug-fixes allowed" is the sense we're looking for. The linux-kernel-headers change was *months* ago, hitting unstable at the end of October; I think, frankly, that now is long past the time when it's legitimate to still be worrying about that. No offence intended, but how long did it take to get kdebase fixed for that change? A month and a half or so? > > Therefore, I would argue that at the time of the KDE 3.2 upstream > > release, we evaluate sarge's progress, and if it seems likely that it > > would make a release within, say, a month, then I think we should give > > the Debian guys that chance. > > KDE 3.2's upstream release is less than 2 weeks away... but yes I will > get kdebase/kdemultimedia fixed and uploaded before then. However, I > don't promise to wait until they filter into sarge before uploading KDE > 3.2, since (afaik) currently nothing is filtering into sarge.[0] This isn't true; we've had a fair amount of activity in sarge. You can see the last day's activity for yourself at http://ftp-master.debian.org/testing/update_output.txt.gz, rather than guessing. > [0] I suppose arch all packages can filter into sarge but since several > buildds are very behind and/or not working at all arch any are taking > a very prolonged time to even get built. And if packages aren't built on > all archs then they obviously can't migrate to sarge. Anthony explicitly allowed arm, s390, and sparc to slip while their build daemons were behind. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: kdebase, kdemultimedia ETAs?
On Fri, Jan 09, 2004 at 04:14:27PM -0600, Chris Cheney wrote: > On Fri, Jan 09, 2004 at 11:27:44AM -0600, Colin Watson wrote: > > I fully agree with Nathanael's position here. Uploading KDE 3.2 at this > > point will probably kill your chances of getting a working KDE in sarge, > > or else delay sarge radically, since the version of KDE in testing is > > not currently releaseable. (An installable kdemultimedia would have got > > into testing tonight if it weren't for the recent upload; fortunately it > > narrowly escaped screwing over newer versions of > > jack-audio-connection-kit and alsa-lib, which are needed for GNOME. > > There are a lot of interdependencies which still need to be resolved.) > > By the way do you know when people are going to stop breaking KDE? Just > today or yesterday(?) Graham Wilson uploaded a new libxslt1 that broke > around 47 packages including kdelibs, koffice, kopete, and various gnome > and xml libs... You might have noticed that I filed a bug about libxslt very shortly after it was uploaded, and it's going to be unbroken fairly soon. This doesn't look like a big problem. > Yea, I'll believe sarge is close to release when I see it. As long as people keep espousing this attitude it won't be ... Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: KDE 3.1.5 Status Update - 20040119
On Mon, Jan 19, 2004 at 10:19:04PM -0600, Chris Cheney wrote: > qt-x11-free > --- > finished ... but has an RC bug due apparently to breakage in libxrender-dev. I've suggested a binary-only NMU workaround, since the bug appears to have manifested only on the maintainer's build machine and not on any buildds. -- Colin Watson [EMAIL PROTECTED]
Consider building ksysguardd without libsensors support for now?
Hi, Probably the biggest task remaining for sarge as I see it is getting meta-kde and all its dependencies ready. Now, I know there are various build issues and things, most of which seem to be finally crawling towards resolution, but one thing that currently looks like a showstopper is that ksysguardd (and indirectly ksysguard) depend on libsensors2, and lm-sensors is having major problems getting itself ready for sarge which have been discussed quite extensively on debian-devel without resolution, and which seem to be fairly intractable at the moment. I notice that the lm-sensors dependency is i386-specific, so presumably it's just an optional feature. I'd really like to remove this roadblock so that we can get on with other things, and maybe put it back later if and when lm-sensors gets sorted out. Would you consider building ksysguardd without lm-sensors support for now? Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Consider building ksysguardd without libsensors support for now?
On Mon, Jan 26, 2004 at 02:42:26PM -0600, Chris Cheney wrote: > On Mon, Jan 26, 2004 at 05:43:07PM +0000, Colin Watson wrote: > > Probably the biggest task remaining for sarge as I see it is getting > > meta-kde and all its dependencies ready. Now, I know there are various > > build issues and things, most of which seem to be finally crawling > > towards resolution, but one thing that currently looks like a > > showstopper is that ksysguardd (and indirectly ksysguard) depend on > > libsensors2, and lm-sensors is having major problems getting itself > > ready for sarge which have been discussed quite extensively on > > debian-devel without resolution, and which seem to be fairly intractable > > at the moment. > > The various build issues are not coming any closer to being resolved. Or > at least don't look that way to me. The incompetent buildd admins are > still around and still have not retried builds they should never have > failed in the first place (all the g++ related ones). If I were you, in future, I'd use a versioned Build-Depends: to make sbuild automatically upgrade g++, or at the very least a Build-Conflicts: on the problematic versions. Looking through the wanna-build states, every build that's maybe-failed for this reason is in state Building, not Failed. The builds may not actually have happened yet, but the buildd maintenance looks reasonable to me. > > I notice that the lm-sensors dependency is i386-specific, so presumably > > it's just an optional feature. I'd really like to remove this roadblock > > so that we can get on with other things, and maybe put it back later if > > and when lm-sensors gets sorted out. Would you consider building > > ksysguardd without lm-sensors support for now? > > The lm-sensors problem with kdebase is minor compared to all the other > problems KDE has currently, but yes once the other problems are resolved > if lm-sensors is still an issue I will upload a version of kdebase with > no dependency on lm-sensors. I think it's fairly clear that it will still be an issue, and the reason I brought it up now is that there's no point waiting for builds of kdebase when the current version clearly isn't going to get into testing any time soon ... I'm trying to get problems resolved in parallel rather than in series. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: KDE 3.1.5 Status Update - 20040209
On Mon, Feb 09, 2004 at 12:55:55PM -0600, Chris Cheney wrote: > Some of the packages were changed to Needs-Build so hopefully they will > be built soon. Maybe I will be able to upload KDE 3.2.0 by the end of > the week. :) [...] > kdebase 3.1.5-2 > --- > mipsel- failed - needs retry with unbuilt qt-x11-free (see below) > (Feb 4) > s390 - failed - bad kernel headers? (Feb 6) > > kdegames 3.1.5-1 > > arm - Needs-Build (Feb 9) > mips - Needs-Build (Feb 9) There's going to be one problem with these two, namely that they both need newer alsa-lib which needs newer jack-audio-connection-kit than what's in testing, and some things still need to be rebuilt for that. I'm inclined to remove some packages from testing to speed the way, but one of the affected packages is gst-plugins and that's a dependency of meta-gnome2, so that can't be so easily swept aside ... Fun for all the family. -- Colin Watson [EMAIL PROTECTED]
Re: KDE 3.1.5 Status Update - 20040217
On Tue, Feb 17, 2004 at 08:47:22AM -0500, Josh Metzler wrote: > (Cross posted to debian-kde, as many there are wondering why KDE 3.2 > isn't in unstable yet.) Here's a follow-up, as some slightly strange things happened in testing last night which bear explaining. > Chris hasn't done a status update for a while, so I'll try to make do. > But, first some exciting news - arts 1.2.0 (the version that was > released with KDE 3.2) is going into experimental today. I expect that > means KDE 3.2 will follow it in the near future. Thank you, Chris. > > Some more good news - only two packages still need to build - kdebase > and kdegraphics. And, two of the three builds should succeed when retried. > > * Packages that still need to build: > > kdebase 3.1.5-2 > --- > s390 - failed? Feb 5 due to buggy (#231972) kernel headers (not yet fixed) [...] > kdepim (3.1.4-1) - waits for libmal (5 of 10 days old) > kdebase (3.1.3-1) > kdegames (3.1.4-1) > both wait for alsa-lib which waits for jack-audio-connection-kit > kdegraphics (3.1.4-1) - waits for libusb (5 of 10 days old) > kdeaddons (2.2.2-4 !) - waits for kdegames and kdebase > > -- > > So, the main bottle-necks are linux-kernel-headers on s390 and > jack-audio-connection-kit moving into testing. kdebase/s390 was built - somehow, and I think by hand - so last night the testing scripts considered meta-kde, kdeaddons, kdebase, and kdegames as "valid candidates". (This means that they don't have obvious problems that bar them from testing, but they may still fail if promoting the new packages results in more uninstallable packages than beforehand.) While kdeaddons, kdebase, and kdegames are still waiting for other things to happen, meta-kde was upgraded in testing. The reason for this was that it was actually already uninstallable there, so upgrading it didn't make the situation any worse. You can see at http://ftp-master.debian.org/testing/testing_probs.html that it's still uninstallable. As for the remaining things to happen before jack-audio-connection-kit and alsa-lib can be promoted, which will include kdeaddons, kdebase, and kdegames: ardour needs to be built on arm gst-plugins needs to be built on mipsel gst-plugins is 2 days old; needs 10 libjackasyn has just had bug #232605 fixed, which needs to be built redland is waiting for perl perl needs to be built on m68k, but has problems (#233175) spiralsynthmodular is 7 days old; needs 10 So, getting there ... -- Colin Watson [EMAIL PROTECTED]
Re: Please build KDE on other arches and upload to experimental
On Wed, Feb 25, 2004 at 03:30:42AM -0600, Chris Cheney wrote: > If you happen to have a non i386 arch system please try building kde on > it and if you are a debian developer upload the result to experimental. > If you see any problems please report them to this list. I'm building these (by hand; must get round to setting up sbuild or pbuilder) on powerpc, and have uploaded arts to experimental. I notice that kdelibs build-depends on libdb4.1-dev, while kdebase build-depends on libdb4.0-dev. Was this a mistake, or is it deliberate for some reason? -- Colin Watson [EMAIL PROTECTED]
Re: Please build KDE on other arches and upload to experimental
On Wed, Feb 25, 2004 at 11:26:25AM -0600, Colin Watson wrote: > On Wed, Feb 25, 2004 at 03:30:42AM -0600, Chris Cheney wrote: > > If you happen to have a non i386 arch system please try building kde on > > it and if you are a debian developer upload the result to experimental. > > If you see any problems please report them to this list. > > I'm building these (by hand; must get round to setting up sbuild or > pbuilder) on powerpc, and have uploaded arts to experimental. After kdeutils or so I got bored and set up sbuild, which helped a lot. I've uploaded all of KDE 3.2 I could find for powerpc to incoming, except for kdemultimedia since that build-depends on libtag1-dev which is still in the NEW queue (so arts, kdeadmin, kdeartwork, kdebase, kdegames, kdegraphics, kdelibs, kdenetwork, kdepim, kdetoys, kdeutils). No problems beyond that reported in my previous mail. At least the basic parts appear to work, although I don't actually use KDE except for the odd demonstration. :-) -- Colin Watson [EMAIL PROTECTED]
Re: ro svn checkout of svn.debian.org/svn/pkg-kde/
On Mon, Mar 01, 2004 at 12:36:14PM -0800, Jeremy Shaw wrote: > I just tried to do a check out for the first time, but I got this error: > > $ svn co svn://svn.debian.org/pkg-kde/trunk > svn: Can't connect to host 'svn.debian.org': Connection refused See: http://lists.debian.org/debian-devel-announce/2004/debian-devel-announce-200402/msg00015.html -- Colin Watson [EMAIL PROTECTED]
Bug#239753: Autobuilder error message
On Fri, Mar 26, 2004 at 04:35:32PM +0100, Dominique Devriese wrote: > Andreas Metzler writes: > > On Fri, Mar 26, 2004 at 02:41:37PM +0100, Andreas Metzler wrote: > >> The hppa autobuildder tried three times (last on Mon 15 Mar 2004 > >> 20:54) but sarti is suposed to have had problems. > > > It has been built and uploaded manually on 24-Mar. - How about > > closing the bug and letting kdelibs propagate to testing? > > Good idea ! This means that kdelibs 3.2 will probably propagate to testing tonight, *without* kdebase 3.2. Will this break KDE in testing? -- Colin Watson [EMAIL PROTECTED]
Bug#239753: Autobuilder error message
On Fri, Mar 26, 2004 at 05:14:56PM +0100, Dominique Devriese wrote: > Colin Watson writes: > > On Fri, Mar 26, 2004 at 04:35:32PM +0100, Dominique Devriese wrote: > >> Good idea ! > > > This means that kdelibs 3.2 will probably propagate to testing > > tonight, *without* kdebase 3.2. Will this break KDE in testing? > > It shouldn't, but I have still filed a fake critical bug report on > kdelibs to keep it in sid. Can you check if I have done so correctly, > cause I have to go now ? That should be fine, although I'd suggest adding the reason. -- Colin Watson [EMAIL PROTECTED]
Bug#240188: Package dependencies violate policy
severity 240188 important thanks On Thu, Mar 25, 2004 at 06:53:50PM -0800, Stephen Zander wrote: > Package: libarts1-dev > Version: 1.2.1-2 > Severity: serious > > Section 2.5 says: > > Packages must not depend on packages with lower priority values > (excluding build-time dependencies). > > libarts1-dev violates this by being Priority: optional and depending on > xlibs-stat-pic, which is Priority: extra Per http://release.debian.org/sarge_rc_policy.txt, this is not release-critical for sarge. Also, priorities are controlled by the ftpmasters, so bugs against individual packages for priority problems often confuse people (i.e. they try to change the priority in the package and get confused when this doesn't work straight off because the override file still has the old value ...). Cheers, -- Colin Watson [EMAIL PROTECTED]
Please do not upload kdelibs today
This is just a note, for safety ... kdelibs should make it into testing tonight, along with the whole enormous cupsys transition which has been blocking a lot of packages. If you guys have any kdelibs uploads planned, please, please defer them until this transition is complete. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Please do not upload kdelibs today
On Thu, Jul 08, 2004 at 09:08:47PM -0400, Christopher Martin wrote: > On July 8, 2004 07:18, Colin Watson wrote: > > kdelibs should make it into testing tonight, along with the whole > > enormous cupsys transition which has been blocking a lot of packages. > > If you guys have any kdelibs uploads planned, please, please defer them > > until this transition is complete. > > Any idea as to what went wrong? According to bjorn.haxx.se, there are a > lot of packages, themselves not ready for Sarge, that would break in > Sarge if libgnomeprint moved in, but I might be misinterpreting the > situation. Some bright spark uploaded gimp-print ... we get to wait five days. Sorry. :-( Annoyed, -- Colin Watson [EMAIL PROTECTED]
