Hi,
I have installed the kubuntu 10.04 / kde3 64-bit distro and am trying to install that require the two libraries above and am getting the errors below.
Thanks
Murray
root@kubuntu10:/usr/local/share/icons# apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following extra packages will be installed: kdelibs-data kdelibs4c2a The following NEW packages will be installed: kdelibs-data kdelibs4c2a 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. 8 not fully installed or removed. Need to get 0B/17.9MB of archives. After this operation, 62.3MB of additional disk space will be used. Do you want to continue [Y/n]? Y (Reading database ... 146714 files and directories currently installed.) Unpacking kdelibs-data (from .../kdelibs-data_4%3a3.5.10.dfsg.1-3ubuntu2_all.deb) ... dpkg: error processing /var/cache/apt/archives/kdelibs-data_4%3a3.5.10.dfsg.1-3ubuntu2_all.deb (--unpack): trying to overwrite '/etc/kde3/colors/40.colors', which is also in package kdelibs-data-kde3 4:3.5.12-0ubuntu6+r1152788 dpkg-deb: subprocess paste killed by signal (Broken pipe) Unpacking kdelibs4c2a (from .../kdelibs4c2a_4%3a3.5.10.dfsg.1-3ubuntu2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/kdelibs4c2a_4%3a3.5.10.dfsg.1-3ubuntu2_amd64.deb (--unpack): trying to overwrite '/etc/kde3/khotnewstuffrc', which is also in package kdelibs-data-kde3 4:3.5.12-0ubuntu6+r1152788 Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/kdelibs-data_4%3a3.5.10.dfsg.1-3ubuntu2_all.deb /var/cache/apt/archives/kdelibs4c2a_4%3a3.5.10.dfsg.1-3ubuntu2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
Murray Trainer wrote:
Hi,
I have installed the kubuntu 10.04 / kde3 64-bit distro and am trying to install that require the two libraries above and am getting the errors below.
Thanks
Murray
root@kubuntu10:/usr/local/share/icons# apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following extra packages will be installed: kdelibs-data kdelibs4c2a The following NEW packages will be installed: kdelibs-data kdelibs4c2a 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. 8 not fully installed or removed. Need to get 0B/17.9MB of archives. After this operation, 62.3MB of additional disk space will be used. Do you want to continue [Y/n]? Y (Reading database ... 146714 files and directories currently installed.) Unpacking kdelibs-data (from .../kdelibs-data_4%3a3.5.10.dfsg.1-3ubuntu2_all.deb) ... dpkg: error processing /var/cache/apt/archives/kdelibs-data_4%3a3.5.10.dfsg.1-3ubuntu2_all.deb (--unpack): trying to overwrite '/etc/kde3/colors/40.colors', which is also in package kdelibs-data-kde3 4:3.5.12-0ubuntu6+r1152788 dpkg-deb: subprocess paste killed by signal (Broken pipe) Unpacking kdelibs4c2a (from .../kdelibs4c2a_4%3a3.5.10.dfsg.1-3ubuntu2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/kdelibs4c2a_4%3a3.5.10.dfsg.1-3ubuntu2_amd64.deb (--unpack): trying to overwrite '/etc/kde3/khotnewstuffrc', which is also in package kdelibs-data-kde3 4:3.5.12-0ubuntu6+r1152788 Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/kdelibs-data_4%3a3.5.10.dfsg.1-3ubuntu2_all.deb /var/cache/apt/archives/kdelibs4c2a_4%3a3.5.10.dfsg.1-3ubuntu2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
For trinity you are installing the wrong packages, you should be installing 'kdelibs-data-kde3' and 'kdelibs4c2a-kde3'.
Please pay attention that you are installing the 'kde3' packages and you will have the best kde 3.5 desktop ever. :-)
Hi Murray,
The outdated 3.5.10 version of kdelibs in the Ubuntu archives (including kdelibs-data) is not compatible with the new KDE3/Trinity version of kdelibs (which includes kdelibs-data-kde3). Please remove kdelibs-data, and note which programs will be removed with it. Then try reinstalling those programs, but with a -kde3 suffix appended. For example, kolourpaint becomes kolourpaint-kde3.
Hope this helps!
Tim
Hi,
I have installed the kubuntu 10.04 / kde3 64-bit distro and am trying to install that require the two libraries above and am getting the errors below.
Thanks
Murray
root@kubuntu10:/usr/local/share/icons# apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following extra packages will be installed: kdelibs-data kdelibs4c2a The following NEW packages will be installed: kdelibs-data kdelibs4c2a 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. 8 not fully installed or removed. Need to get 0B/17.9MB of archives. After this operation, 62.3MB of additional disk space will be used. Do you want to continue [Y/n]? Y (Reading database ... 146714 files and directories currently installed.) Unpacking kdelibs-data (from .../kdelibs-data_4%3a3.5.10.dfsg.1-3ubuntu2_all.deb) ... dpkg: error processing /var/cache/apt/archives/kdelibs-data_4%3a3.5.10.dfsg.1-3ubuntu2_all.deb (--unpack): trying to overwrite '/etc/kde3/colors/40.colors', which is also in package kdelibs-data-kde3 4:3.5.12-0ubuntu6+r1152788 dpkg-deb: subprocess paste killed by signal (Broken pipe) Unpacking kdelibs4c2a (from .../kdelibs4c2a_4%3a3.5.10.dfsg.1-3ubuntu2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/kdelibs4c2a_4%3a3.5.10.dfsg.1-3ubuntu2_amd64.deb (--unpack): trying to overwrite '/etc/kde3/khotnewstuffrc', which is also in package kdelibs-data-kde3 4:3.5.12-0ubuntu6+r1152788 Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/kdelibs-data_4%3a3.5.10.dfsg.1-3ubuntu2_all.deb /var/cache/apt/archives/kdelibs4c2a_4%3a3.5.10.dfsg.1-3ubuntu2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
On Wednesday 01 September 2010 19:43:54 Timothy Pearson wrote:
The outdated 3.5.10 version of kdelibs in the Ubuntu archives (including kdelibs-data) is not compatible with the new KDE3/Trinity version of kdelibs (which includes kdelibs-data-kde3). Please remove kdelibs-data, and note which programs will be removed with it. Then try reinstalling those programs, but with a -kde3 suffix appended. For example, kolourpaint becomes kolourpaint-kde3.
We on OpenSUSe have no such problems and kdebase3 in the official OpenSUSE repository is in fact the same as that in our KDE3 repo (it is maintained in KDE3 repo and linked to it from Factory).
On Wednesday 01 September 2010 19:43:54 Timothy Pearson wrote:
The outdated 3.5.10 version of kdelibs in the Ubuntu archives (including kdelibs-data) is not compatible with the new KDE3/Trinity version of kdelibs (which includes kdelibs-data-kde3). Please remove kdelibs-data, and note which programs will be removed with it. Then try reinstalling those programs, but with a -kde3 suffix appended. For example, kolourpaint becomes kolourpaint-kde3.
We on OpenSUSe have no such problems and kdebase3 in the official OpenSUSE repository is in fact the same as that in our KDE3 repo (it is maintained in KDE3 repo and linked to it from Factory).
That its because your official archive maintainers were kind enough to remove the offending packages from the main archive, and transfer complete control of the KDE3 system to the KDE3 repository maintainers. Ubuntu was not so kind. It is a very simple fix; just remove the old, outdated package and only install the new packages from the KDE3/Trinity repository.
Also, I'd would like to point out that Trinity contains features that OpenSUSE does not. OpenSUSE uses a patched version of the original 3.5.10 release, and while they have added features over time their added feature set is quite different that Trinity's. For example, OpenSUSE users cannot resize the panel or system tray icons independently of the panel height. Trinity users can.
Tim.
On Wednesday 01 September 2010 20:11:33 Timothy Pearson wrote:
On Wednesday 01 September 2010 19:43:54 Timothy Pearson wrote:
The outdated 3.5.10 version of kdelibs in the Ubuntu archives (including kdelibs-data) is not compatible with the new KDE3/Trinity version of kdelibs (which includes kdelibs-data-kde3). Please remove kdelibs-data, and note which programs will be removed with it. Then try reinstalling those programs, but with a -kde3 suffix appended. For example, kolourpaint becomes kolourpaint-kde3.
We on OpenSUSe have no such problems and kdebase3 in the official OpenSUSE repository is in fact the same as that in our KDE3 repo (it is maintained in KDE3 repo and linked to it from Factory).
That its because your official archive maintainers were kind enough to remove the offending packages from the main archive,
They did not remove any offending packages. There is simply no offending packages. What is in KDE:KDE3 is the same as what was in OpenSUSE when it included KDE3 (11.0). And it always was maintained in KDE:KDE3, just the most stable packages were included in the official repo.
and transfer complete control of the KDE3 system to the KDE3 repository maintainers. Ubuntu was not so kind. It is a very simple fix; just remove the old, outdated package and only install the new packages from the KDE3/Trinity repository.
Also, I'd would like to point out that Trinity contains features that OpenSUSE does not. OpenSUSE uses a patched version of the original 3.5.10 release, and while they have added features over time their added feature set is quite different that Trinity's. For example, OpenSUSE users cannot resize the panel or system tray icons independently of the panel height.
Do you use Dolpin instead of Konq as some people say?
Trinity users can.
On the other hand we made many patches. Recently we fixed handling encrypted rar archives and Yahoo login, today we ported Qt3 to libpng4 etc.
On Wednesday 01 September 2010 20:11:33 Timothy Pearson wrote:
On Wednesday 01 September 2010 19:43:54 Timothy Pearson wrote:
The outdated 3.5.10 version of kdelibs in the Ubuntu archives
(including
kdelibs-data) is not compatible with the new KDE3/Trinity version of kdelibs (which includes kdelibs-data-kde3). Please remove
kdelibs-data,
and note which programs will be removed with it. Then try
reinstalling
those programs, but with a -kde3 suffix appended. For example, kolourpaint becomes kolourpaint-kde3.
We on OpenSUSe have no such problems and kdebase3 in the official OpenSUSE repository is in fact the same as that in our KDE3 repo (it is maintained in KDE3 repo and linked to it from Factory).
That its because your official archive maintainers were kind enough to remove the offending packages from the main archive,
They did not remove any offending packages. There is simply no offending packages.
Which is because they do not exist in the primary archive. The simple fact is Ubuntu quite suddenly dropped KDE3 in favor of KDE4, but left several badly outdated packages in the main repository. I have no control over that repository or their decision, and it has been causing headaches for new Trinity users since the days of Ubuntu Intrepid.
What is in KDE:KDE3 is the same as what was in OpenSUSE when it included KDE3 (11.0). And it always was maintained in KDE:KDE3, just the most stable packages were included in the official repo.
And are they in the official repository now? If so then OpenSUSE has a more open mind than Ubuntu. If not, at least they were polite enough to remove them so as to avoid conflicts with the KDE3 repository.
and transfer complete control of the KDE3 system to the KDE3 repository maintainers. Ubuntu was not so kind. It is a very simple fix; just remove the old, outdated package and only install the new packages from the KDE3/Trinity repository.
Also, I'd would like to point out that Trinity contains features that OpenSUSE does not. OpenSUSE uses a patched version of the original 3.5.10 release, and while they have added features over time their added feature set is quite different that Trinity's. For example, OpenSUSE users cannot resize the panel or system tray icons independently of the panel height.
Do you use Dolpin instead of Konq as some people say?
No. The Trinity project utilizes Konqueror by default, although the user can install Dolphin later if he or she wishes.
Trinity users can.
On the other hand we made many patches. Recently we fixed handling encrypted rar archives and Yahoo login, today we ported Qt3 to libpng4 etc.
Some of those patches have been in Trinity for over four months now. I try to keep Trinity up to date by pulling patches from anyone still working on a KDE3 variant; this keeps all the code available in one location and (hopefully) creates a system that has the best of all worlds so to speak.
Tim
On Wednesday 01 September 2010 21:39:53 Timothy Pearson wrote:
What is in KDE:KDE3 is the same as what was in OpenSUSE when it included KDE3 (11.0). And it always was maintained in KDE:KDE3, just the most stable packages were included in the official repo.
And are they in the official repository now?
Some packages (kdebase3-runtime, kdelibs3 etc) are still in the official repo they are in fact copyed from KDE:KDE3 repository. When KDE3 was the official part of OpenSUSE the KDE3 packages were also copied from the KDE:KDE3 repo which existed always and included slightly more packages than the official OpenSUSE repo. So OpenSUSE always included a subset of KDE:KDE3.
If so then OpenSUSE has a more open mind than Ubuntu. If not, at least they were polite enough to remove them so as to avoid conflicts with the KDE3 repository.
There are no conflicts. The packages in OpenSUSE=the packages in KDE:KDE3 by the date of OpenSUSE feature freeze.
and transfer complete control of the KDE3 system to the KDE3 repository maintainers.
It always was there. And I am now one of those maintainers, I do with KDE3 repository whatever I want and this goes directly to OpenSUSE main repo in the case the packages in question were not yet dropped from OpenSUSE.
Do you use Dolpin instead of Konq as some people say?
But some people say you broke the file manager so it is not as good as Konq in KDE3 was.
<snip>
and transfer complete control of the KDE3 system to the KDE3 repository maintainers.
It always was there. And I am now one of those maintainers, I do with KDE3 repository whatever I want and this goes directly to OpenSUSE main repo in the case the packages in question were not yet dropped from OpenSUSE.
That is what Ubuntu is unwilling to do. They do not want anything to do with KDE3 at this point.
Do you use Dolpin instead of Konq as some people say?
But some people say you broke the file manager so it is not as good as Konq in KDE3 was.
Who? And what its their specific complaint? If something was broken then it was most likely accidental and it needs to be fixed. ;-) I will say that I have had no other complaints about Konqueror, so it is quite possible that a specific feature used by that individual was overlooked somehow.
Thanks!
Tim
Timothy Pearson wrote:
Which is because they do not exist in the primary archive. The simple fact is Ubuntu quite suddenly dropped KDE3 in favor of KDE4, but left several badly outdated packages in the main repository. I have no control over that repository or their decision, and it has been causing headaches for new Trinity users since the days of Ubuntu Intrepid.
Just some questions out of interest.
Why isn't it possible to let the Trinity repository contain updated versions of those offending packages? When the Trinity versions have a higher version number, I would expect they would automatically be used over the standard Ubuntu ones.
And does anyone know if it would be possible to take over maintenance upstream, either at Debian or with Ubuntu? What is their stance about providing the KDE 3 libs based on Trinity sources?
Thanks, Julius
Timothy Pearson wrote:
Which is because they do not exist in the primary archive. The simple fact is Ubuntu quite suddenly dropped KDE3 in favor of KDE4, but left several badly outdated packages in the main repository. I have no control over that repository or their decision, and it has been causing headaches for new Trinity users since the days of Ubuntu Intrepid.
Just some questions out of interest.
Why isn't it possible to let the Trinity repository contain updated versions of those offending packages? When the Trinity versions have a higher version number, I would expect they would automatically be used over the standard Ubuntu ones.
This is due to the fact that they have a different name, e.g. kdelibs-kde3 instead of kdelibs. I could make kdelibs-kde3 conflict with kdelibs, but I seem to remember that a peculiar side effect crept in when I did that in the past. I can re-enable the conflict statement and see if any problems occur...thoughts anyone?
And does anyone know if it would be possible to take over maintenance upstream, either at Debian or with Ubuntu? What is their stance about providing the KDE 3 libs based on Trinity sources?
I don't know. Now that there is an upstream again in the form of Trinity they may be more receptive to the idea. The process should start with Debian, as Ubuntu mirrors Debian's package offerings for the most part. The only issue is that Debian wants an on-call package maintainer, and I am too swamped with the Trinity project itself to properly fill that role.
Any volunteers? ;-)
Tim
On Wednesday 01 September 2010 22:59:01 Timothy Pearson wrote:
Which is because they do not exist in the primary archive. The simple fact is Ubuntu quite suddenly dropped KDE3 in favor of KDE4, but left several badly outdated packages in the main repository. I have no control over that repository or their decision, and it has been causing headaches for new Trinity users since the days of Ubuntu Intrepid.
Just some questions out of interest.
Why isn't it possible to let the Trinity repository contain updated versions of those offending packages? When the Trinity versions have a higher version number, I would expect they would automatically be used over the standard Ubuntu ones.
This is due to the fact that they have a different name, e.g. kdelibs-kde3 instead of kdelibs.
This is due to use of deb package format. In rpm world the package name does not matter for dependency resolution.
We in particular have the nave kdelibs3, and I think it did not change when KDE4 was introduced (they have name kdelibs4).
I could make kdelibs-kde3 conflict with kdelibs, but I seem to remember that a peculiar side effect crept in when I did that in the past. I can re-enable the conflict statement and see if any problems occur...thoughts anyone?
Why you cannot use name kdelibs for your package?
And does anyone know if it would be possible to take over maintenance upstream, either at Debian or with Ubuntu? What is their stance about providing the KDE 3 libs based on Trinity sources?
I don't know. Now that there is an upstream again in the form of Trinity they may be more receptive to the idea. The process should start with Debian, as Ubuntu mirrors Debian's package offerings for the most part. The only issue is that Debian wants an on-call package maintainer, and I am too swamped with the Trinity project itself to properly fill that role.
Why you cannot use name kdelibs for your package?
The official version in the archive of all KDE modules, e.g. kdelibs, is the KDE4 version. As Debian does not allow overrides by version numbers, there was no choice but to change the package names so as not to conflict. Unlike SuSE, all official packages are in a single primary archive, so the user cannot just deselect the KDE4 repository. Besides, this method allows KDE3 and KDE4 to live together should the user want to use both.
Tim
On Thursday 02 September 2010 02:04:05 Timothy Pearson wrote:
Why you cannot use name kdelibs for your package?
The official version in the archive of all KDE modules, e.g. kdelibs, is the KDE4 version.
And how they call the kde3 version which you called 'outdated'?
On Thursday 02 September 2010 02:04:05 Timothy Pearson wrote:
Why you cannot use name kdelibs for your package?
The official version in the archive of all KDE modules, e.g. kdelibs, is the KDE4 version. As Debian does not allow overrides by version numbers, there was no choice but to change the package names so as not to conflict. Unlike SuSE, all official packages are in a single primary archive, so the user cannot just deselect the KDE4 repository
In SUSE also official packages are in the official repo. You cannot disable KDE4 repository without disabling the main release repo.
. Besides, this method allows KDE3 and KDE4 to live together should the user want to use both.
We also have KDE3 and KDE4 excellently living together.
On Thursday 02 September 2010 02:04:05 Timothy Pearson wrote:
Why you cannot use name kdelibs for your package?
The official version in the archive of all KDE modules, e.g. kdelibs, is the KDE4 version. As Debian does not allow overrides by version numbers, there was no choice but to change the package names so as not to conflict. Unlike SuSE, all official packages are in a single primary archive, so the user cannot just deselect the KDE4 repository
In SUSE also official packages are in the official repo. You cannot disable KDE4 repository without disabling the main release repo.
. Besides, this method allows KDE3 and KDE4 to live together should the user want to use both.
We also have KDE3 and KDE4 excellently living together.
Then I may not understand enough about the RPM packaging system in use under SuSE. I can explain the technical details behind what is required to have KDE3 and KDE4 work together, but it seems the main thrust of what you are trying to do here is to promote OpenSUSE's KDE3 version over the Trinity project. Am I understanding you correctly?
I don't have time to argue over which implementation is better; there are limitations in what I can do that are out of my control due to the Debian package format and also the cooperativeness of the distribution maintainers. OpenSUSE has always been more supportive of KDE since the beginning, however I am doing my best under Ubuntu and Debian within the limits that I have. The features that have been added from OpenSUSE are not as numerous as those in the Trinity project (yes I did look at the patch list), and they are generally built only for OpenSUSE. Trinity instead aims to provide packages for all distributions, as the old KDE project once did.
Tim
I don't have time to argue over which implementation is better; there are limitations in what I can do that are out of my control due to the Debian package format and also the cooperativeness of the distribution maintainers. OpenSUSE has always been more supportive of KDE since the beginning, however I am doing my best under Ubuntu and Debian within the limits that I have. The features that have been added from OpenSUSE are not as numerous as those in the Trinity project (yes I did look at the patch list),
I suggest you also look through the list of the packages. We also plan to expand the list greatly in the coming future.
I don't have time to argue over which implementation is better; there are limitations in what I can do that are out of my control due to the Debian package format and also the cooperativeness of the distribution maintainers. OpenSUSE has always been more supportive of KDE since the beginning, however I am doing my best under Ubuntu and Debian within the limits that I have. The features that have been added from OpenSUSE are not as numerous as those in the Trinity project (yes I did look at the patch list),
I suggest you also look through the list of the packages. We also plan to expand the list greatly in the coming future.
In my opinion it would have been better for KDE3 as a whole if we could have worked off the same codebase, but it seems that OpenSUSE has always shipped a heavily modified version of KDE. Not all users want those changes, so it is probably better to have the two separate versions. Trinity is the equivalent of the old vanilla KDE, and has pulled in many of the the non-SuSE specific patches from the SuSE RPMs, as well as other sources. SuSE is what it always was, and I can respect that.
I politely ask that this list remain focused for discussion about the Trinity project itself, and that other projects that wish to remain completely isolated from Trinity only be brought up on the trinity-devel list in the context of GPL-released patches that can be applied to the Trinity codebase. If you or others would like to discuss OpenSUSE, please do it on their dedicated list(s).
Thank you,
Timothy Pearson Trinity Desktop Project
On Thursday 02 September 2010 21:12:47 Timothy Pearson wrote:
In my opinion it would have been better for KDE3 as a whole if we could have worked off the same codebase, but it seems that OpenSUSE has always shipped a heavily modified version of KDE. Not all users want those changes, so it is probably better to have the two separate versions. Trinity is the equivalent of the old vanilla KDE, and has pulled in many of the the non-SuSE specific patches from the SuSE RPMs, as well as other sources. SuSE is what it always was, and I can respect that.
I politely ask that this list remain focused for discussion about the Trinity project itself, and that other projects that wish to remain completely isolated from Trinity only be brought up on the trinity-devel list in the context of GPL-released patches that can be applied to the Trinity codebase. If you or others would like to discuss OpenSUSE, please do it on their dedicated list(s).
Seems you did not understand me. I am talking not about patches, but about applications. I suggested you to browse the OpenSUSE KDE3 repo to see if there are any apps you did not include in Trinity. Say, KBibTex, kde3-texmaker, schafkopf etc. I also plan to include other software such as KDE3-based version of VirtualBox, Firefox etc.
By the way, does aLinux use Trinity or they use the vanilla KDE3 branch?
Timothy Pearson wrote:
Why isn't it possible to let the Trinity repository contain updated versions of those offending packages? When the Trinity versions have a higher version number, I would expect they would automatically be used over the standard Ubuntu ones.
This is due to the fact that they have a different name, e.g. kdelibs-kde3 instead of kdelibs. I could make kdelibs-kde3 conflict with kdelibs, but I seem to remember that a peculiar side effect crept in when I did that in the past. I can re-enable the conflict statement and see if any problems occur...thoughts anyone?
I understand that it's not trivial to have a package without the -kde3 suffix?
If you enable the conflict statement, then you should also enable the provides statement. I opened a bug that some packages miss it. It will allow kdbg from the normal Ubuntu repository to work against the Trinity libraries for example.
And does anyone know if it would be possible to take over maintenance upstream, either at Debian or with Ubuntu? What is their stance about providing the KDE 3 libs based on Trinity sources?
I don't know. Now that there is an upstream again in the form of Trinity they may be more receptive to the idea. The process should start with Debian, as Ubuntu mirrors Debian's package offerings for the most part. The only issue is that Debian wants an on-call package maintainer, and I am too swamped with the Trinity project itself to properly fill that role.
Any volunteers? ;-)
Does anyone know what the duties and requirements of an on-call package manager would be? :)
Best regards, Julius
Timothy Pearson wrote:
Why isn't it possible to let the Trinity repository contain updated versions of those offending packages? When the Trinity versions have a higher version number, I would expect they would automatically be used over the standard Ubuntu ones.
This is due to the fact that they have a different name, e.g. kdelibs-kde3 instead of kdelibs. I could make kdelibs-kde3 conflict with kdelibs, but I seem to remember that a peculiar side effect crept in when I did that in the past. I can re-enable the conflict statement and see if any problems occur...thoughts anyone?
I understand that it's not trivial to have a package without the -kde3 suffix?
Yes, for a number of reasons.
If you enable the conflict statement, then you should also enable the provides statement. I opened a bug that some packages miss it. It will allow kdbg from the normal Ubuntu repository to work against the Trinity libraries for example.
Not really; that is only true while the ABI does not change. It has changed significantly in Trinity, which will cause all kinds of symbol not found runtime errors when attempting to run binaries from the old official package.
And does anyone know if it would be possible to take over maintenance upstream, either at Debian or with Ubuntu? What is their stance about providing the KDE 3 libs based on Trinity sources?
I don't know. Now that there is an upstream again in the form of Trinity they may be more receptive to the idea. The process should start with Debian, as Ubuntu mirrors Debian's package offerings for the most part. The only issue is that Debian wants an on-call package maintainer, and I am too swamped with the Trinity project itself to properly fill that role.
Any volunteers? ;-)
Does anyone know what the duties and requirements of an on-call package manager would be? :)
It is a somewhat convoluted process, with useful information somewhat hard to come by (I have very little knowledge in this particular area myself.)
Some information is available here: http://www.debian.org/doc/maint-guide/ http://wiki.debian.org/DebianMaintainer http://www.debian.org/devel/join/newmaint
Honestly I would join a Debian developer's list and ask what would be involved in packaging and maintaining Trinity for Debian. Much of the packaging can be cloned from the Debian packages on the QuickBuild system, but there are other responsibilities that you would need to agree to IIRC, including prompt security patch application and a few other things.
Hope this helps!
Tim
Timothy Pearson wrote:
If you enable the conflict statement, then you should also enable the provides statement. I opened a bug that some packages miss it. It will allow kdbg from the normal Ubuntu repository to work against the Trinity libraries for example.
Not really; that is only true while the ABI does not change. It has changed significantly in Trinity, which will cause all kinds of symbol not found runtime errors when attempting to run binaries from the old official package.
Ok, I see. I still have one question though if you don't mind :)
I understood that binaries of all 3.5.x releases of KDE were backwards compatible. Also in my experience, I could always run older KDE3 apps against newer libraries. (Which means that the ABI would be backwards compatible I understand?) I also understood that the current Trinity would basically be KDE 3.5.12, but it is not compatible anymore with applications compiled against older KDE 3.5.x versions? (In my own experience it is though, but maybe my testing was too limited.) What is the reason this compatibility wasn't kept? I guess staying compatible with applications compiled against previous versions is the most important thing when trying to get them into Debian & Ubuntu.
Does anyone know what the duties and requirements of an on-call package manager would be? :)
It is a somewhat convoluted process, with useful information somewhat hard to come by (I have very little knowledge in this particular area myself.)
Some information is available here: http://www.debian.org/doc/maint-guide/ http://wiki.debian.org/DebianMaintainer http://www.debian.org/devel/join/newmaint
Honestly I would join a Debian developer's list and ask what would be involved in packaging and maintaining Trinity for Debian. Much of the packaging can be cloned from the Debian packages on the QuickBuild system, but there are other responsibilities that you would need to agree to IIRC, including prompt security patch application and a few other things.
I will read these pages when I have some spare time. I cannot promise more yet right now unfortunately, but it seems good to discuss all the steps needed for this here. I still use KDE3 on many systems, so I'm quite motivated to look into this though. Thanks a lot for the information!
Best regards, Julius
-
Ilya Chernykh -
Jimmy Johnson -
Julius Schwartzenberg -
Murray Trainer -
Timothy Pearson