[KDE/Mac] State of the KDE/Mac address

[Big O]

I realize I had this draft in my mailbox which wasn't sent so...

On Jan 20, 2009, at 7:03 PM, Jonas Bähr wrote:

> Hi,
>
> Am 20.01.2009 um 18:58 schrieb O:
>> [...]
>> TOPIC NUMBER THE SECOND
>> Currently we pull stuff from macports when we need things installed
>> and ports are always a moving target. I think it makes sense to set  
>> up
>> a kde rsync server that has portfiles we need in the versions we know
>> work (well). Comments?
>
> In my eyes the primary goal should be that kde4 works out of the box
> with macports. Unfortunately macports isn't very powerfull, at least
> for someone who knows i.e. gentoo's portage. The main problems are
> that it can only manage *one* version of a port and that you can't
> test for variants in the dependencies.
Frankly, macports is a means to an end, and that end is semi-automated  
end user packages.
The limitation of being able to manage one version of a port and an  
inability to test for dependencies in variants don't hinder that  
terribly. Also port maintainers are quite accommodating at adding  
default variants once given an explanation - and trac ticket.  
Something which is harder to do is revert a version bump once it  
happens.

>
> I think we got now all default variants in a state that kde4 works.
> The dbus x11 problem is gone since some hours, the default dbus is now
> completely launchd based. :-) http://trac.macports.org/ticket/17950#comment
> :53
Awesome :-)
Well up to kdebase at least :-)
kdegraphics/okular needs poppler built w/ +quartz and +qt4 which also  
brings in a gtk2 dependency :-/. For the time being I think this is  
fine, the most important thing for me is that we don't pull in x11 by  
default.
kdepim still has some weird problem with macports pulling in  
libJPEG.dylib. I'm going to delete the kdepim4 portfile until that's  
fixed.

Generally we need the ports to provide variants for individual apps so  
that users can disable them whether they break occassionally.
Also the po/ directories of external apps (amarok, ktorrent, etc.)  
currently need to be patched because of a (now fixed) bug with the  
findgettext cmake modules. After this is fixed I think adding i10n to  
portfiles becomes a viable (default?) option.
*Deep Breath*

>
>
> An other issue are different versions of dependencies, where boost
> come in mind. But if we run into troubles here, it's either a kde
> regression or a bug in the dependency. Both can be fixed.
>
> So, generally I'm against a second macports universe for kde
> dependencies, but it may be a good idea to have backups around of
> versions we now to work. What exactly is your idea with "a kde rsync
> server"?
We have our own rsync server with the portfiles of dependencies at the  
versions we know work.

>
>
>
>> TOPIC NUMBER THE THIRD
>> I don't have a ppc machine and making packages for 10.4 intel, 10.5
>> intel, 10.4 ppc and 10.5 ppc takes a lot of time. In the future (next
>> set of packages) I'm only creating 10.5 packages to upload. Then I'll
>> _attempt_ 10.4 packages.
>> Short version: I'll prioritize work with what I've got. And ppc get
>> the short end of the pkg-ing stick (unless someone steps up).
>
> I still got a G4 PowerBook with Tiger laying around. Maybe I'll find
> the time to set it up for packaging. One condition though: You have to
> write a good howto on techbase ;-)
Unfortunately still haven't found time to do this yet. I'll try to set  
aside some time this weekend.

>
>
>
>> TOPIC NUMBER THE FOURTH
>> Packaging Team: Having macports in a pretty much OK state for "normal
>> folk" to contribute, and having spoken to folks like Bill Hoffman
>> about using CPack at Camp KDE, after 4.2.0 is release I'm shifting
>> gears and working on getting CPack support integrated into KDE.
>> This effectively means no more packages from me for anything and I
>> will merely stay on in an advisory position :-) Hopefully this'll  
>> mean
>> that six months from now Mac and Windows will have CPack installers.
>> Oh, and we're working with the windows guys on this.
>
> That sounds excellent!
>
>> I'll try to get this announced on the dot too but things are at the
>> point where packaging is pretty simple and we're ready for
>> contributors. And if there's no interest well, why bother do it
>> anyways. If you'd like to see support for your platform faster (even
>> if it's 10.5) it would behoove you to contribute. :-D
>>
>> Amarokers, Marblites, Digikamies on the mac this is your chance to
>> shine and help out your favorite application and KDE at the same  
>> time.
>
> I'll though Krusader in the ring ;-) Basically the Portfile is ready,
> and in the mean time I got macports commit rights too.
And the kde4 portgroup is ready for you. Have a look at any of the kde  
portfiles to see how to use it. Just add the line right under  
PortSystem. The portgroup files (one for cmake and one for kde4 are in  
${repo_root}/_resources/port1.0/group

>
>
>> Let's make kde-mac rawk boyz n gurlz!
>>
>> -- 
>> Rita Rudner  - "When I eventually met Mr. Right I had no idea that  
>> his
>> first name was Always."
>> _______________________________________________
>> kde-mac at kde.org
>> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
>> KDE/Mac Information: http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X
>
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X