[opensuse-kde] Kalzium and avogadro
Avogadro allows kalzium to display and edit molecular models, a pretty useful tool especially for scientists. However, it is a build-time dependency, and it is not present in the KDE Distro repositories or the base openSUSE repositories, meaning openSUSE's version of Kalzium does not support it. This is understandable since avodgadro did not build for recent Qt versions, so it was not possible build it on more recent openSUSE releases. I have fixed this problem, so avogadro now builds successfully. Normally this would not be that big a deal, someone could just link avogadro from its current home in OBS Education and modify the spec file (I could even do that). The problem is that avogadro also has several build-time and run-time dependencies that are not found in KDE Distro or the base openSUSE repositories, they are only found in OBS education. So, if my understanding is correct, getting avogadro to build successfully would require adding those dependencies to KDE Distro as well. Is that acceptable? I could do this easily enough, but I don't want to unless I have some idea whether it would be accepted or not. I guess a more general question is: should we be trying to get as many of the optional features of the packages working as possible, she would only limit it to critical features or those that can be built from the default openSUSE repos, or should it be handled on a case-by-case basis? Another example is xplanet, which provides support for rendering the 7 other planets in kstars but is only found in the hamradio repo. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Saturday 11 September 2010 20:05:34 todd rme wrote:
Avogadro allows kalzium to display and edit molecular models, a pretty useful tool especially for scientists. However, it is a build-time dependency, and it is not present in the KDE Distro repositories or the base openSUSE repositories, meaning openSUSE's version of Kalzium does not support it. This is understandable since avodgadro did not build for recent Qt versions, so it was not possible build it on more recent openSUSE releases. I have fixed this problem, so avogadro now builds successfully.
Normally this would not be that big a deal, someone could just link avogadro from its current home in OBS Education and modify the spec file (I could even do that). The problem is that avogadro also has several build-time and run-time dependencies that are not found in KDE Distro or the base openSUSE repositories, they are only found in OBS education. So, if my understanding is correct, getting avogadro to build successfully would require adding those dependencies to KDE Distro as well. Is that acceptable? I could do this easily enough, but I don't want to unless I have some idea whether it would be accepted or not.
I guess a more general question is: should we be trying to get as many of the optional features of the packages working as possible, she would only limit it to critical features or those that can be built from the default openSUSE repos, or should it be handled on a case-by-case basis? Another example is xplanet, which provides support for rendering the 7 other planets in kstars but is only found in the hamradio repo.
Giving the general answer (which is also valid for the Avogadro case): Yes, we should be trying to build as much of our upstreams as possible, where not prohibited for other reasons (eg legal ones). The limiting factors are the presence of maintainers and the available space on the distribution media, so reduce the scope of dependencies and split packages where possible so that optional stuff can remain on the network repos only. Will -- Will Stephenson, KDE Developer, openSUSE Boosters Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Mon, Sep 13, 2010 at 9:53 AM, Will Stephenson
On Saturday 11 September 2010 20:05:34 todd rme wrote:
Avogadro allows kalzium to display and edit molecular models, a pretty useful tool especially for scientists. However, it is a build-time dependency, and it is not present in the KDE Distro repositories or the base openSUSE repositories, meaning openSUSE's version of Kalzium does not support it. This is understandable since avodgadro did not build for recent Qt versions, so it was not possible build it on more recent openSUSE releases. I have fixed this problem, so avogadro now builds successfully.
Normally this would not be that big a deal, someone could just link avogadro from its current home in OBS Education and modify the spec file (I could even do that). The problem is that avogadro also has several build-time and run-time dependencies that are not found in KDE Distro or the base openSUSE repositories, they are only found in OBS education. So, if my understanding is correct, getting avogadro to build successfully would require adding those dependencies to KDE Distro as well. Is that acceptable? I could do this easily enough, but I don't want to unless I have some idea whether it would be accepted or not.
I guess a more general question is: should we be trying to get as many of the optional features of the packages working as possible, she would only limit it to critical features or those that can be built from the default openSUSE repos, or should it be handled on a case-by-case basis? Another example is xplanet, which provides support for rendering the 7 other planets in kstars but is only found in the hamradio repo.
Giving the general answer (which is also valid for the Avogadro case): Yes, we should be trying to build as much of our upstreams as possible, where not prohibited for other reasons (eg legal ones). The limiting factors are the presence of maintainers and the available space on the distribution media, so reduce the scope of dependencies and split packages where possible so that optional stuff can remain on the network repos only.
If that is the case then why was the submission declined? -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Wednesday 15 September 2010 schrieb todd rme:
If that is the case then why was the submission declined?
You would know the reason if you had an email registered in the build service that allowed you to get mails. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Wed, Sep 15, 2010 at 11:13 AM, Stephan Kulow
Am Wednesday 15 September 2010 schrieb todd rme:
If that is the case then why was the submission declined?
You would know the reason if you had an email registered in the build service that allowed you to get mails.
Greetings, Stephan
My email in the buildservice can get emails, in fact it is the same as the one on this mailing list. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Am Wednesday 15 September 2010 schrieb todd rme:
On Wed, Sep 15, 2010 at 11:13 AM, Stephan Kulow
wrote: Am Wednesday 15 September 2010 schrieb todd rme:
If that is the case then why was the submission declined?
You would know the reason if you had an email registered in the build service that allowed you to get mails.
Greetings, Stephan
My email in the buildservice can get emails, in fact it is the same as the one on this mailing list.
Possibly now, but the system sends mail to toddrme13@gmail.com Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
On Wed, Sep 15, 2010 at 11:57 AM, Stephan Kulow
Am Wednesday 15 September 2010 schrieb todd rme:
On Wed, Sep 15, 2010 at 11:13 AM, Stephan Kulow
wrote: Am Wednesday 15 September 2010 schrieb todd rme:
If that is the case then why was the submission declined?
You would know the reason if you had an email registered in the build service that allowed you to get mails.
Greetings, Stephan
My email in the buildservice can get emails, in fact it is the same as the one on this mailing list.
Possibly now, but the system sends mail to toddrme13@gmail.com
Greetings, Stephan
While we are on the subject, building for openbabel is still disabled for most of the KDE:Distro:Factory repositories, which means most repositories are not getting the updated version of openbabel (2.2.3) that was accepted recently. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org
Dne So 11. září 2010 13:05:34 todd rme napsal(a):
Avogadro allows kalzium to display and edit molecular models, a pretty useful tool especially for scientists. However, it is a build-time dependency, and it is not present in the KDE Distro repositories or the base openSUSE repositories, meaning openSUSE's version of Kalzium does not support it. This is understandable since avodgadro did not build for recent Qt versions, so it was not possible build it on more recent openSUSE releases. I have fixed this problem, so avogadro now builds successfully.
Normally this would not be that big a deal, someone could just link avogadro from its current home in OBS Education and modify the spec file (I could even do that). The problem is that avogadro also has several build-time and run-time dependencies that are not found in KDE Distro or the base openSUSE repositories, they are only found in OBS education. So, if my understanding is correct, getting avogadro to build successfully would require adding those dependencies to KDE Distro as well. Is that acceptable? I could do this easily enough, but I don't want to unless I have some idea whether it would be accepted or not.
I guess a more general question is: should we be trying to get as many of the optional features of the packages working as possible, she would only limit it to critical features or those that can be built from the default openSUSE repos, or should it be handled on a case-by-case basis? Another example is xplanet, which provides support for rendering the 7 other planets in kstars but is only found in the hamradio repo.
-Todd
Hi, from point of view of user and researcher, I'd really appreciate to have as much (scientific) packages as possible (well, I can not build it myself, I'm not a programmer) - to allow me to center to my work and not playing with system... ;-) Thank You for any such package! Vojtěch -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://web.natur.cuni.cz/~zeisek/
participants (4)
-
Stephan Kulow
-
todd rme
-
Vojtěch Zeisek
-
Will Stephenson