Hello, Since KDE 3.4.2 is about to be released, I think it would be nice to upload it, rather than 3.4.1, for the upcoming transition. Thoughts? Now that we''re using gcc 4.0, the new symbol visibility feature is available. It requires a patched Qt, but even then, it seems to cause problems. Indeed, lintian started reporting a lot of non-PIC code in a number of binaries, though I didn''t investigate this. Nevertheless, I think it would be prudent not to attempt to use this feature until KDE 3.5.0. The KDE build system checks if Qt contains the visibility patch (from http://bugs.kde.org/show_bug.cgi?id=109386, FYI) and if it is detected, and gcc 4.0 is the compiler, it sets -fvisibility=hidden, etc. automatically. Since we''re not patching Qt, this shouldn''t be a problem. However, it seems that the checks for arts and kdelibs are broken, meaning that these packages will be build with -fvisibility=hidden, etc. no matter what we do. I propose a trivial patch, for debian/patches/common, to disable fvisibility for all modules, regardless of whether Qt is patched, for the time being. Also, libarts1 and kdelibs4 need to be renamed (c2) as part of the transition. The library packages in other modules (kdebase, kdemultimedia, etc.) weren''t renamed by Ubuntu, and I guess we should follow that example, though I''d be interested in hearing why things were done this way. On my system I''ve made the necessary changes to arts and kdelibs, and if no one objects, will commit (though if others have also done this work and want to commit, just go for it). Notably, to get kdebase 3.4.2 to build, I had to upgrade to glibc 2.3.5. See bug #317363 for details. We can probably hack around this problem, but if glibc 2.3.5 is planned for Sid soon (anyone know?), then perhaps we won''t have to. Cheers, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 252 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20050725/c901d700/attachment.pgp
On Mon, Jul 25, 2005 at 11:30:50PM +0000, Christopher Martin wrote:> Now that we''re using gcc 4.0, the new symbol visibility feature is > available. It requires a patched Qt, but even then, it seems to cause > problems. Indeed, lintian started reporting a lot of non-PIC code in a > number of binaries, though I didn''t investigate this. Nevertheless, I think > it would be prudent not to attempt to use this feature until KDE 3.5.0.There will be a Qt 3 bugfix release shortly after Qt 4.0.1 which is expected to include visibility fixes. It might be that visibility is more practical with that new Qt. Jonathan Riddell
On Mon, Jul 25, 2005 at 11:30:50PM +0000, Christopher Martin wrote:> The library packages in other modules (kdebase, kdemultimedia, > etc.) weren''t renamed by Ubuntu, and I guess we should follow that example, > though I''d be interested in hearing why things were done this way.This was at Matthias Klose''s suggestion and is because there''s no need. Renaming libraries causes hassle to packagers and users and since all KDE stuff depends on kdelibs, qt and/or arts renaming those is sufficient to ensure all KDE libraries are updated to new g++ versions as required. Jonathan
Le Mar 26 Juillet 2005 01:30, Christopher Martin a ?crit :> Hello, > > Since KDE 3.4.2 is about to be released, I think it would be nice to > upload it, rather than 3.4.1, for the upcoming transition. Thoughts? > > Now that we''re using gcc 4.0, the new symbol visibility feature is > available. It requires a patched Qt, but even then, it seems to cause > problems. Indeed, lintian started reporting a lot of non-PIC code in > a number of binaries, though I didn''t investigate this. Nevertheless, > I think it would be prudent not to attempt to use this feature until > KDE 3.5.0.ACK here. let''s do so big changes one step after another. -- ?O? Pierre Habouzit ??O madcoder@debian.org OOO http://www.madism.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20050726/cab987c7/attachment.pgp
* Christopher Martin [Mon, 25 Jul 2005 23:30:50 +0000]:> Since KDE 3.4.2 is about to be released, I think it would be nice to upload > it, rather than 3.4.1, for the upcoming transition. Thoughts?Sounds reasonable.> Now that we''re using gcc 4.0, the new symbol visibility feature is > available. It requires a patched Qt, but even then, it seems to cause > problems. Indeed, lintian started reporting a lot of non-PIC code in a > number of binaries, though I didn''t investigate this. Nevertheless, I think > it would be prudent not to attempt to use this feature until KDE 3.5.0.ACK.> The KDE build system checks if Qt contains the visibility patch (from > http://bugs.kde.org/show_bug.cgi?id=109386, FYI) and if it is detected, and > gcc 4.0 is the compiler, it sets -fvisibility=hidden, etc. automatically. > Since we''re not patching Qt, this shouldn''t be a problem. However, it seems > that the checks for arts and kdelibs are broken, meaning that these > packages will be build with -fvisibility=hidden, etc. no matter what we do. > I propose a trivial patch, for debian/patches/common, to disable > fvisibility for all modules, regardless of whether Qt is patched, for the > time being.http://dev.kubuntu.org.uk/~jr/kubuntu/ADMIN.diff> Also, libarts1 and kdelibs4 need to be renamed (c2) as part of the > transition. The library packages in other modules (kdebase, kdemultimedia, > etc.) weren''t renamed by Ubuntu, and I guess we should follow that example, > though I''d be interested in hearing why things were done this way.What Jonathan said.> On my system I''ve made the necessary changes to arts and kdelibs, and > if no one objects, will commit (though if others have also done this > work and want to commit, just go for it).Sure, go ahead. Please remember to commit different things separately, and to be a bit more verbose in the changelog when appropriate (ok, I probably exceed myself some times, so only "a bit more"). :) Also, can we loose this from arts?:> * Bump build-depends on libmad-dev, to ensure that we build against a version > that sets shlibs. Once this package is uploaded to unstable, this will be > sufficient to ensure that all of KDE depends on a fixed libmad0, as arts > is at the bottom of KDE''s dependency chain.I was going to argue that we should remove it because it makes the work of backporters harder (*waves to Ervin*). But seeing that the fixed version is even in stable, we should remove it then because it really makes no sense now. =)> Notably, to get kdebase 3.4.2 to build, I had to upgrade to glibc 2.3.5. See > bug #317363 for details. We can probably hack around this problem, but if > glibc 2.3.5 is planned for Sid soon (anyone know?), then perhaps we won''t > have to.Well, glibc 2.3.5 is planned for Sid, but not RSN AFAIK. OTOH, I''ve heard about the possibility of glibc in sid getting some fixes to make other important packages (util-linux, db4.3) not FTBFS with gcc4. I will stay tuned to see if this finally happens, and if it does and we can provide such fix, sneak it in. Cheers, -- Adeodato Sim? EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The easy way is the wrong way, and the hard way is the stupid way. Pick one.
On July 25, 2005 23:41, Jonathan Riddell wrote:> On Mon, Jul 25, 2005 at 11:30:50PM +0000, Christopher Martin wrote: > > The library packages in other modules (kdebase, kdemultimedia, > > etc.) weren''t renamed by Ubuntu, and I guess we should follow that > > example, though I''d be interested in hearing why things were done this > > way. > > This was at Matthias Klose''s suggestion and is because there''s no > need. Renaming libraries causes hassle to packagers and users and > since all KDE stuff depends on kdelibs, qt and/or arts renaming those > is sufficient to ensure all KDE libraries are updated to new g++ > versions as required.Makes sense, and is less work, so that''s fine with me...> There will be a Qt 3 bugfix release shortly after Qt 4.0.1 which is > expected to include visibility fixes. ?It might be that visibility is > more practical with that new Qt.I see; let''s hope it is. I also borrowed and adapted your visibility-disabling patch. Thanks for the all the information and help. Cheers, Christopher Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 252 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20050726/f181e601/attachment.pgp
On July 26, 2005 07:44, Adeodato Sim? wrote:> http://dev.kubuntu.org.uk/~jr/kubuntu/ADMIN.diffThanks. I''ve committed a version of this patch updated to work with 3.4.2''s admin dir.> Sure, go ahead. Please remember to commit different things separately, > and to be a bit more verbose in the changelog when appropriate (ok, I > probably exceed myself some times, so only "a bit more"). :)OK, I''ve broken the commits into manageable chunks. As for more verbose, I''ll have another look and add more details.> Also, can we loose this from arts?: > > * Bump build-depends on libmad-dev, to ensure that we build against a > > version that sets shlibs. Once this package is uploaded to unstable, > > this will be sufficient to ensure that all of KDE depends on a fixed > > libmad0, as arts is at the bottom of KDE''s dependency chain. > > I was going to argue that we should remove it because it makes the > work of backporters harder (*waves to Ervin*). But seeing that the > fixed version is even in stable, we should remove it then because it > really makes no sense now. =)Good point; done.> > Notably, to get kdebase 3.4.2 to build, I had to upgrade to glibc > > 2.3.5. See bug #317363 for details. We can probably hack around this > > problem, but if glibc 2.3.5 is planned for Sid soon (anyone know?), > > then perhaps we won''t have to. > > Well, glibc 2.3.5 is planned for Sid, but not RSN AFAIK. OTOH, I''ve > heard about the possibility of glibc in sid getting some fixes to make > other important packages (util-linux, db4.3) not FTBFS with gcc4. I > will stay tuned to see if this finally happens, and if it does and we > can provide such fix, sneak it in.Since uploading kdebase is still some time away, probably, I guess we can just watch the situation for now. Cheers, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 252 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20050726/95aaff7e/attachment.pgp
* Christopher Martin [Tue, 26 Jul 2005 20:43:02 +0000]:> As for more verbose, I''ll have another look and add more details.It''s ok.> > Well, glibc 2.3.5 is planned for Sid, but not RSN AFAIK. OTOH, I''ve > > heard about the possibility of glibc in sid getting some fixes to make > > other important packages (util-linux, db4.3) not FTBFS with gcc4. I > > will stay tuned to see if this finally happens, and if it does and we > > can provide such fix, sneak it in.> Since uploading kdebase is still some time away, probably, I guess we can > just watch the situation for now.Heh, just after sending out my mail I learnt that glibc 2.3.5 was closer than I expected. -- Adeodato Sim? EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Matt Bianco f. Basia - La Luna An economist is an expert who will know tomorrow why the things he predicted yesterday didn''t happen today. -- Laurence J. Peter