KDE Windows/Meetings/Berlin Meeting September 2007

During the last weekend, the KDE on Windows developers conducted their second real life meeting in the Trolltech offices in Berlin Adlershof, incorporating new developers and improving infrastructure. Read the dot story for details.

Started: jstaniek 11:40, 15 September 2007 (CEST)

Topics

• mirror related

1. having two or more main directories on the server: one for current stable release, one for 'unstable/testing' one
   • we need unstable releases to get people test software early and often and on Windows -> there are snapshots available
   • 'unstable' is the term for base system (kdewin32, kdelibs, kdebase); note that in turn, unstable _applications_ could be installed in a stable base system as it's the case on Linux

• installer related

1. development installation requires tools having own installers -> rhabacker: The installer is able to handle different installation roots, so one install root can be used for development and one for end-user. There is no need for additional installers.
   • ideally this should not be the case for end-user installation, otherwise updating would be hard (user would be forced to uninstall prev. version of an external app and install a new one in the same place...)
2. define directory format of the kde mirrors --> rhabacker: there is a directory structure available on the currently used mirrors, which is usable by the installer.
3. USB memory sticks/CDs: it would be possible to run kde apps/infrastructure installed on the stick/CD in two ways:
   1. If the user's machine already contains KDE 4 runtime installed, it could be reused to run apps from the stick, and settings placed on the host computer could be reused
   2. If the user's computer contains no KDE-related stuff at all, default settings and .kde directory is used
   • In either case the default user expectation is that after plugging off the stick, no settings or files remain on the machine's filesystem <-really like that???
4. extend the installer with the following features:
   • • integrity checks (md5 package and file checks) --> rhabacker: not started yet
     • install from cd/dvd --> rhabacker: kde can run directly from a cd or dvd by installing KDE on a harddisc or usb stick and then burning the installation directory complety to a cd/dvd
     • usb stick installation --> rhabacker: fixed

• package related

1. Insert compiler name into package and manifest file name (msvc, gcc) --> chehrlic: Should be fixed now

• dbus related

1. dbus for win32 is working mostly for recent kde applications, although there are some issues:
   • A service registered in dbus is not removed in case the related application crashes. This was detected with klauncher on msvc.
   • if dbus-daemon is killed, the related tcp port is blocked for reusage for some time and prevents that the dbus-daemon can be started again. The solution is documented in http://support.microsoft.com/?scid=kb%3Ben-us%3B177074&x=7&y=11
   • Efforts to implement win32 named pipe transport protocol were canceled because its need refactoring of the internal dbus api which was to much work yet.
   • There is a bug in dbus which prevents to list anonymous connections. This behavior can be verified with qdbusviewer.
   • There are some efforts required to merge the windows port into the dbus cvs, especialy refactoring the internal api. TODO: more details

• build system related

1. KDELibsDependencies.cmake contains absolute file pathes. They have to be variabled to be evaluated on configure time using kdelibs installation. The same belongs to KDEPimLibsDependencies.cmake

saroengels: possibly fixed

• source code related

1. missing or not working parts in kdelibs
   • phonon needs a win32 implementation maybe using directx with uses a COM interface

saroengels: hopefully within qt 4.4

1. • kioslaves are only working partially --> chehrlic: file, http and ftp are working better now, maybe we still have some unicode problems there.
2. kde application state
   • kate - '@' could not be typed in --> chehrlic: fixed for msvc (don't know why it does not work with mingw)
   • konqueror - crashes --> chehrlic: fixed some of them recently
   • dolphin - error messages with could not display root and home dir, problems to contact nepomukdaemon
   • umbrello - writing and printing does not work --> rhabacker: fixed

• compiler tools chain issues

1. loading kde applications into gdb needs a long time to load and start when libraries are compiled with debug symbols. This makes it hard to debug.
2. There are problems mixing msvc debug and release libraries resulting in runtime errors. One problem seems to be that the FILE structure differs between debug and release libraries. It has to be checked if there are workarounds for all developers.
3. The update-mime-database step was taken out for make install DESTDIR builds according to pino toscano; there are two possibilities: try to convince the people to revert the changes or add a post-install script to the packages (I would append the informations into the emerge scripts myself).

FAQ

1. Question: snapshot releases with debugging information - New developers may want to get the core libraries without a need for compilation from scratch, while still being able to step deeply into the its source code while debugging. This helps to enter into the project faster by fixing bugs, discovering structure of a given source code or extending features
   • Answer rhabacker: saroengels has provided mingw snapshot releases with debug informations on http://www.saroengels.net/kde-windows/. Msvc snapshots are probably not possible because the debug msvc runtime isn't distributable.
2. Question: Could we have release versions with debug information? On msvc, this could help to achieve the goal mentioned in the above point while it is still possible to link release binaries with and without debug information.
   • Answer chehrlic: the official releases are now build in Release mode with debug informations
3. Question: Should not the distribution of the file be reduced by keeping a snapshot of all required files on our server(s) - this would make mirroring possible
   • Answer rhabacker: mirroring is possible already now because the installer is able to fetch package online from external sites. If those external packages would not be available in the future it could be easily added to the mirrors.
4. Question: is there a central list of mirrors available ?
   • Answer rhabacker: Yes a list of all available mirrors is located on the main kde on windows mirror http://www.winkde.org/pub/kde/ports/win32/mirrors.lst. This file is used by the installer to let the user choosing a mirror.
5. Question: We need someone using Vista on daily basis to test kdeinstaller. Until then Vista is not supported?
   • Answer chehrlic: I got a vista license from Adriaan de Groot and after a system upgrade vista will be supported. Until now we should deny any vista support
   • Answer saroengels: we have several users on vista, probably shakes was one of them, I cannot remember though.