[Pkg-kde-talk] KDE 3.4.2 Notes

Adeodato Simó asp16 at alu.ua.es
Tue Jul 26 07:44:12 UTC 2005


* 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.




More information about the Pkg-kde-talk mailing list