KDE Commit-Digest
This Week...
khtml fixes include table layout, background-position, min max-height and mangled html fixes. New KControl for Logitech mouse features. Kicker and taskbar optimizations and improvements. Xpdf security fixes. Also coverage of the Subversion discussions on kde-core-devel.
Kde has been around for 8 years. Numerous developers, translators, documentation writers have felt welcome contributing to this project. The center of the project is the source code management system, cvs.
Cvs has been a reliable workhorse, an indispensible part of the Kde development infrastructure. Many of the characteristics of the Kde development environment stem from cvs and the added features (or some would say hacks) that the maintainers have written. For example, each time a change is made, all those on the kde-cvs mailing list see the changes. If the code contains a possible insecure system call or isn't licensed clearly, the commit is flagged. There are many eyes watching, so it is remarkably easy to get write permission to the repository. The policies and controls are quite relaxed. The whole system works well while being open to contributions.
All the code that has been written is in the cvs repository. It is a valuable history and resource. The repository is over 12gb in size, around half of that consisting of the i18n module. Cvs imposes a centralized repository model which works well for this project.
However cvs has some serious deficiencies.
What are they and how do they affect the Kde development effort? Cvs doesn't support moving file and directories. Well, not entirely true. Files and directories can be moved using shell commands, since the cvs repository is made up of files. So you can email one of the maintainers, who will move the file for you. Or if you want to do it yourself, you can remove the file and recommit elsewhere, losing the commit history. We don't see much moving for this reason.
A second limitation of cvs is illustrated when you commit changes in two files, say a source file and its header file. When you commit the changes, cvs views it as two commits, with the commit log duplicated in both file histories.
A third limitation is poor merging support. Remember when KMail had three development branches? There was HEAD, what became the Kolab client, and a rewrite that was tagged make_it_cool. When it came time to merge the three branches, well suffice to say it was ugly.
Kde and other projects have continued using cvs simply because there hasn't been a viable free alternative available. That has changed with the advent of SubVersion and other source code control systems. Should Kde change to Subversion or Arch? If you are curious, this Subversion FAQ answers some common questions. There is an article at LinuxJournal: http://www.linuxjournal.com/article.php?sid=7671 that discusses Arch.
Cvs has been a reliable workhorse, an indispensible part of the Kde development infrastructure. Many of the characteristics of the Kde development environment stem from cvs and the added features (or some would say hacks) that the maintainers have written. For example, each time a change is made, all those on the kde-cvs mailing list see the changes. If the code contains a possible insecure system call or isn't licensed clearly, the commit is flagged. There are many eyes watching, so it is remarkably easy to get write permission to the repository. The policies and controls are quite relaxed. The whole system works well while being open to contributions.
All the code that has been written is in the cvs repository. It is a valuable history and resource. The repository is over 12gb in size, around half of that consisting of the i18n module. Cvs imposes a centralized repository model which works well for this project.
However cvs has some serious deficiencies.
What are they and how do they affect the Kde development effort? Cvs doesn't support moving file and directories. Well, not entirely true. Files and directories can be moved using shell commands, since the cvs repository is made up of files. So you can email one of the maintainers, who will move the file for you. Or if you want to do it yourself, you can remove the file and recommit elsewhere, losing the commit history. We don't see much moving for this reason.
A second limitation of cvs is illustrated when you commit changes in two files, say a source file and its header file. When you commit the changes, cvs views it as two commits, with the commit log duplicated in both file histories.
A third limitation is poor merging support. Remember when KMail had three development branches? There was HEAD, what became the Kolab client, and a rewrite that was tagged make_it_cool. When it came time to merge the three branches, well suffice to say it was ugly.
Kde and other projects have continued using cvs simply because there hasn't been a viable free alternative available. That has changed with the advent of SubVersion and other source code control systems. Should Kde change to Subversion or Arch? If you are curious, this Subversion FAQ answers some common questions. There is an article at LinuxJournal: http://www.linuxjournal.com/article.php?sid=7671 that discusses Arch.
I know we had this topic some times ago, but we came to no conclusion. So I want to ask again, when do we move the KDE repository to subversion? The guys on #svn told me the csv2svn script, which converts the repository works quite well now and handles branches and tags smoothly. IMHO doing the change before 3.4 would be the best solution, so we can concentrate on the new Qt version for 4.0 and have the possebility to rename and move files which is really important for the library cleanup.
This started an interesting thread, with an abundance of opinions. Here are some snippets, with links to respective messages.
I have the opinion that subversion may not be the best solution. Now, obviously, cvs isn't the best solution either, but I think the cost of switching to subversion from cvs may not be worth the return, at least immediately.
http://lists.kde.org/?l=kde-core-devel&m=109726321828634&w=2
http://lists.kde.org/?l=kde-core-devel&m=109726321828634&w=2
We want to have a versioning system that is familiar to all developers, and since svn has nearly the same commands like cvs, that's the perfect solution for us.
http://lists.kde.org/?l=kde-core-devel&m=109726732209162&w=2
http://lists.kde.org/?l=kde-core-devel&m=109726732209162&w=2
Having used the cvs2svn script, I can tell you that it will take much longer than one hour to complete the conversion of KDE's CVS repository over to Subversion. I'd suspect you're talking on the order of *days* rather than hours.
http://lists.kde.org/?l=kde-core-devel&m=109726827904972&w=2
http://lists.kde.org/?l=kde-core-devel&m=109726827904972&w=2
we should also coordinate with the admins of our anon CVS mirrors as well so they can get anonymous SVN (or whatever) up as well.
http://lists.kde.org/?l=kde-core-devel&m=109727027627464&w=2
http://lists.kde.org/?l=kde-core-devel&m=109727027627464&w=2
last time we tried to convert to SVN for testing purposes the conversion script ran a week and then aborted with an out-of-memory condition (with 2GB RAM).
http://lists.kde.org/?l=kde-core-devel&m=109727383325635&w=2
http://lists.kde.org/?l=kde-core-devel&m=109727383325635&w=2
All I'm saying is that we should try out more than one option before switching. If we find problems in SVN, they're likely to not be significant enough to make us change again, so we'll have to put up with them. Therefore it's better to find and avoid them now.
If someone has a good argument for or against SVN, Arch or something else, please speak up.
http://lists.kde.org/?l=kde-core-devel&m=109727853228490&w=2
If someone has a good argument for or against SVN, Arch or something else, please speak up.
http://lists.kde.org/?l=kde-core-devel&m=109727853228490&w=2
Familiarity with the command syntax / workflow should be though. We have a lot of people who don't know much version control (perhaps just cvs checkout, cvs up, cvs diff, cvs commit) - especially in doco and translation teams. It would be handy if the same basic commands "just worked".
I have three issues:
I have three issues:
- What specific problems with our current version control system are we trying to solve?
- Who is going to do the evaluation work to tell which of the options best solves those problems?
- Who is going to do the migration task, including providing support and documentation for everyone involved in KDE development
No, it's the only criterion. We're here to develop KDE not to play with repository systems. The only reason we're switching at all is the lack of features in cvs, not because we need something completely different.
http://lists.kde.org/?l=kde-core-devel&m=109730738118934&w=2
http://lists.kde.org/?l=kde-core-devel&m=109730738118934&w=2
When we start library cleanup after the release of KDE 3.4, we'll have to move and rename a lot of files and that's a PITA with CVS. Furthermore SVN supports nice features like a hidden repository on your hd, so you don't have to connect to the server everytime just to see which files have been changed, that's a huge advantage when you're travelling (e.g. by train) without an internet connection.
IMHO the biggest advantage of SVN is that the command syntax is nearly the same like in CVS and the developers of CVS have enough expiriences with version control systems from their former projects.
http://lists.kde.org/?l=kde-core-devel&m=109730797015713&w=2
IMHO the biggest advantage of SVN is that the command syntax is nearly the same like in CVS and the developers of CVS have enough expiriences with version control systems from their former projects.
http://lists.kde.org/?l=kde-core-devel&m=109730797015713&w=2
Converting kde-i18n will take easily some days and will get us towards a couple of millions in revision number (we plan on cleaning up it's history before though) - but I see no problem it shouldn't work.
http://lists.kde.org/?l=kde-core-devel&m=109733638428989&w=2
- who is going to rewrite the docu that is currently talking about CVS?
- who is going to write the docu how to do things with subversion that are known how they work with CVS?
- who is going to rewrite admin/cvs-clean.pl?
- who is going to rewrite the translation parts that heavily rely on cvs behaviour?
- who has a plan for migrating the pserver accounts?
- who is going to fix the things I forgot to list here?
http://lists.kde.org/?l=kde-core-devel&m=109733638428989&w=2
Last time I checked I wasn't able to create a diff for a specific file between svn revisions before and after the file being moved. Does this work now? How do I do it?
http://lists.kde.org/?l=kde-core-devel&m=109735937709628&w=2
http://lists.kde.org/?l=kde-core-devel&m=109735937709628&w=2
Hmm. You need to remind svn from what it moved? Where is the advantage then?
http://lists.kde.org/?l=kde-core-devel&m=109739364821675&w=2
http://lists.kde.org/?l=kde-core-devel&m=109739364821675&w=2
That means there is no way without knowing the old file name? This would be a significant loss of functionality to our current way with CVS and moving files on the server, especially if people begin moving file around a lot "because subversion can do it".
http://lists.kde.org/?l=kde-core-devel&m=109739364821675&w=2
http://lists.kde.org/?l=kde-core-devel&m=109739364821675&w=2
I still haven't figured out how to revert a move, though. There doesn't seem to be an equivalent of "cvs up -j" taking into account file moves. All these things I actually took for granted ;(
http://lists.kde.org/?l=kde-core-devel&m=109739856418087&w=2
http://lists.kde.org/?l=kde-core-devel&m=109739856418087&w=2
CVS is simply mature, does not undergo significant changes, and can simply be relied upon. SVN is still in flux and will change frequently. Oh, I already anticipate recurring statements like, "KDE rep doesnt work with svn 1.x anymore, use 1.x+10 instead". So you will be forced to update svn *often*, much more often than once in a decade.
Why dont we wait until SVN reaches a mature state like cvs, and switch then?
http://lists.kde.org/?l=kde-core-devel&m=109741879204840&w=2
Why dont we wait until SVN reaches a mature state like cvs, and switch then?
http://lists.kde.org/?l=kde-core-devel&m=109741879204840&w=2
We're talking about kdenonbeta and kdeextreager (not even that part is sure yet). And as long we're not testing SVN for real, we won't know it's mature or not.
http://lists.kde.org/?l=kde-core-devel&m=109742079929822&w=2
http://lists.kde.org/?l=kde-core-devel&m=109742079929822&w=2
A 12 Gb database, 4 distro releases with more then 5000 packages was enough stability for us at Conectiva. And yes, we had update a lot of times in the past, since we are one of the oldest beta testers of subversion, but we run out of problems for a long time. Just FYI, see how we can handle out things with subversion:
https://moin.conectiva.com.br/RepositorySystem
http://lists.kde.org/?l=kde-core-devel&m=109742737324737&w=2
https://moin.conectiva.com.br/RepositorySystem
http://lists.kde.org/?l=kde-core-devel&m=109742737324737&w=2
Can you identify all commands that are not easily revertable? For example I notice that it is possible to change existing log entries, so if a SVN account of a developer gets hacked by a bad guy he could potentially wipe out all commit logs. Do such changes trigger notifications? Is it possible to disable features like that?
http://lists.kde.org/?l=kde-core-devel&m=109757879124144&w=2
http://lists.kde.org/?l=kde-core-devel&m=109757879124144&w=2
apropos...
this is certainly getting boring/annoying, because i point it out every time someone brings up the svn idea, but...
implement cvs2svn issue #1 first: auto-detect cvs "moves" while importing the repo. some months ago i reconstructed the kdm add/rm/move history by hand - and even though kdm is a really small project, it was sufficient to confirm my view on the issue for all times.
http://lists.kde.org/?l=kde-core-devel&m=109778938415501&w=2
this is certainly getting boring/annoying, because i point it out every time someone brings up the svn idea, but...
implement cvs2svn issue #1 first: auto-detect cvs "moves" while importing the repo. some months ago i reconstructed the kdm add/rm/move history by hand - and even though kdm is a really small project, it was sufficient to confirm my view on the issue for all times.
http://lists.kde.org/?l=kde-core-devel&m=109778938415501&w=2
Well, for one: we're planing on cleaning out kde-i18n's history before going anywhere. this alone will reduce our current repository from 12 to ~6. And from my experiments I would say the SVN repository would be around 10 (haven't read clee's comments so far).
http://lists.kde.org/?l=kde-core-devel&m=109782557030897&w=2
http://lists.kde.org/?l=kde-core-devel&m=109782557030897&w=2
The amount of data downloaded or uploaded should be roughly the same, I'd venture. The protocol is different, for sure, but the database itself isn't transferred. The protocol is completely agnostic to that.
However, your checkouts will increase in size. The current Subversion working dir module saves a copy of every file inside .svn dirs, which means your srcdirs double in size.
If you use svk, it has it's own WC implementation (called XD, as the next letters in the alphabet) that doesn't save the file twice. But you lose disconnected diffs.
http://lists.kde.org/?l=kde-core-devel&m=109783775412978&w=2
However, your checkouts will increase in size. The current Subversion working dir module saves a copy of every file inside .svn dirs, which means your srcdirs double in size.
If you use svk, it has it's own WC implementation (called XD, as the next letters in the alphabet) that doesn't save the file twice. But you lose disconnected diffs.
http://lists.kde.org/?l=kde-core-devel&m=109783775412978&w=2
KDE Security Advisory: kpdf integer overflows. For the full announcement see http://www.kde.org/info/security/advisory-20041021-1.txt. Here is an overview of the problem:
Chris Evans notified the KDE security team about multiple integer overflow and integer arithmetic flaws in xpdf 3.0.
These flaws, if exploited, can cause xpdf (and therefore kpdf) to hang using 100% CPU, crash the viewer or corrupt the program heap. It might be possible to execute arbitrary code. The Common Vulnerabilities and Exposures project assigned CAN-2004-0889 to this issue.
kpdf, the KDE pdf viewer, shares code with xpdf 2.02. This code is significantly different from the xpdf 3.0 codebase, but is also affected by similiar issues. Sebastian Krahmer from the SUSE security team developed a patch that corrects integer overflows in the XRef code. This patch is made available below for kpdf as shipped in the KDE 3.2.x releases. The Common Vulnerabilities and Exposures project assigned CAN-2004-0888 to this issue.
KDE 3.3.1 contains a kpdf based on xpdf 3.0. We're providing a patch to fix the remaining integer overflows in this code base.
These flaws, if exploited, can cause xpdf (and therefore kpdf) to hang using 100% CPU, crash the viewer or corrupt the program heap. It might be possible to execute arbitrary code. The Common Vulnerabilities and Exposures project assigned CAN-2004-0889 to this issue.
kpdf, the KDE pdf viewer, shares code with xpdf 2.02. This code is significantly different from the xpdf 3.0 codebase, but is also affected by similiar issues. Sebastian Krahmer from the SUSE security team developed a patch that corrects integer overflows in the XRef code. This patch is made available below for kpdf as shipped in the KDE 3.2.x releases. The Common Vulnerabilities and Exposures project assigned CAN-2004-0888 to this issue.
KDE 3.3.1 contains a kpdf based on xpdf 3.0. We're providing a patch to fix the remaining integer overflows in this code base.
digiKam is a digital photo management application for KDE, which makes importing and organizing digital photos a "snap". The photos can be organized in albums which can be sorted chronologically, by directory layout or by custom collections. An easy to use interface is provided that enables you to connect to your camera and preview, download and/or delete your images.
The tarballs can be downloaded from http://sourceforge.net/projects/digikam
Key New features:
The tarballs can be downloaded from http://sourceforge.net/projects/digikam
Key New features:
- Reliable and fast database (sqlite) backend for saving metadata
- Tagging support for photos.
- Tags are grouped together as virtual folders shown similar to albums.
- Extensive drag and drop support for tagging and moving/copying photos
- Enhanced camera interface with support for automatic photo rotation and renaming of photos while downloading.
- EXIF support with optional oriented display of thumbnails and photos using camera provided information
- Customizable thumbnails for albums and tags
- Support for nested albums
- Tooltips providing detailed photo information
- Themeing support for digiKam
- KIPI support for enhanced plugin support. KIPI is an initiative between various KDE image management applications to provide a common architecture for implementing image based plugins. Currently implemented plugins and other details can be found at: http://extragear.kde.org/apps/kipi.php
- New fast image viewer and editor which uses its own plugin architecture to provide various additional functionalities in addition to the usual gamma/contrast/brightness adjustments, rotation, resize functions. Some of the plugins supplied with digiKam are: - Histogram Viewer - Red Eye correction - Black & White and Sepia conversion - Blurring and sharpening - RGB color correction - Hue/Saturation/Lightness correction - Normalize and Equalize
- Highly improved thumbnail loading speed.
- Lots more ... visit this link to see a more detailed list of changes http://digikam.sourceforge.net/Digikam-SPIP/rubrique.php3?id_rubrique=12
The DigikamImagePlugins team is pleased to announce the first beta release for digiKam Image Editor Plugins 0.7.0.
DigikamImagePlugins are a collection of plugins for Digikam 0.7.0 Image Editor. These plugins add new image treatment options like color management, filters, or special effects.
Currently implemented plugins are listed below:
http://extragear.kde.org/apps/digikamimageplugins.php
Currently implemented plugins are listed below:
- Adjust levels : a plugin to adjust the image histogram levels manually.
- Despeckle : A noise reduction filter (using on Gimp 2.0 algorithm).
- Unsharp : An unsharped mask image filter (using on Gimp 2.0 algorithm).
- SolarizeImage : a plugin to solarize an image.
- OilPaint : an oil painting effect filter (using Pieter Voloshyn algorithm).
- Emboss : an embossed image effect filter (using Pieter Voloshyn algorithm).
- Raindrops : adding the visual effect of raindrops to an image (using Pieter Voloshyn algorithm).
- Charcoal : a charcoal drawing image effect filter.
- FilmGrain : simulate film grain to an image.
http://extragear.kde.org/apps/digikamimageplugins.php
As of now the Kile version 1.7, an Integrated LaTeX Environment for KDE, is available for download (for instructions use this link): http://kile.sourceforge.net/download.php or directly: http://prdownloads.sourceforge.net/kile/kile-1.7.tar.bz2?download
Kile-1.7 requires KDE 3.2 or newer.
This test release offers many new features, in particular the following should be tested (full Changelog can be found below):
Kile-1.7 requires KDE 3.2 or newer.
This test release offers many new features, in particular the following should be tested (full Changelog can be found below):
- new tool system, QuickBuild tool can be configured completely
- it is possible to switch to other TeX systems besides LaTeX
- autocompletion of (La)TeX commands, configurable (Settings->Configure Kile->Complete)
- System Check (Settings->System Check), checks if all (La)TeX tools are available and if Kile is configured correctly. This needs to be checked since people have reported problems with this feature.
- Detailed clickable error summary.
Statistics
| Commits | 3183 by 216 developers, 816067 lines modified, 1178 new files |
| Open Bugs | 7452 |
| Open Wishes | 6965 |
| Bugs Opened | 328 in the last 7 days |
| Bugs Closed | 212 in the last 7 days |
Commit Summary
| Module | Commits |
| kde-i18n |
1006
|
| khtmltests |
398
|
| kdenonbeta |
219
|
| kdepim |
190
|
| kdebase |
148
|
| kdelibs |
121
|
| kdeextragear-2 |
107
|
| kdenetwork |
98
|
| koffice |
94
|
| kdeedu |
88
|
| Lines | Developer | Commits |
|
583681
|
Stephan Kulow |
428
|
|
8278
|
Thierry Vignaud |
387
|
|
926
|
Benjamin Meyer |
169
|
|
490
|
Laurent Montel |
92
|
|
6368
|
Stefan Asserhäll |
72
|
|
1940
|
David Faure |
69
|
|
1023
|
Nicholas Nethercote |
68
|
|
2236
|
benb |
57
|
|
518
|
Anne-Marie Mahfouf |
57
|
|
1475
|
Pedro Morais |
52
|
Internationalization (i18n) Status
| Language | Percentage Complete |
| British English (en_GB) |
99.92%
|
| Swedish (sv) |
98.92%
|
| Portuguese (pt) |
96.61%
|
| Danish (da) |
94.8%
|
| Spanish (es) |
91.91%
|
| Dutch (nl) |
91.69%
|
| Serbian (sr) |
91.4%
|
| Italian (it) |
90.94%
|
| Estonian (et) |
90.67%
|
| French (fr) |
90.06%
|
Bug Killers
| Person | Bugs Closed |
| Stephan Kulow |
46
|
| Aaron J. Seigo |
38
|
| Tommi Tervo |
32
|
| Till Adam |
25
|
| Matt Rogers |
18
|
| Scott Wheeler |
18
|
| metz |
17
|
| Renchi Raju |
16
|
| Luboš Luňák |
15
|
| Anders Lund |
13
|
No commits found