[opensuse-edu] DIDASCA, LAZZARO PROJECT and openbabel 2.2.0
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Folks, openbabel 2.2.0 STABLE has been built. This mail is just to inform an important change, infact we have no more libopenbabel2 but now thereis libopenbabel3 that of course "obsoletes" and "provides" libopenbabel2. but the most important news is another one. I'm proud to annunce that DIDASCA ( http://www.didasca.it/ ) use on their "Progetto Lazzaro" ( http://www.progettolazzaro.it/ ) openSUSE and LTSP like instrumets to recovery obsoletes LANs and PCs Goals of prjects are to make Italian schools able to use LTSP on theier Education Enviroment with support of Italian "Education Ministry". I'm waiting for more and better infos but all the projects sound a greate way to improve Linux use on Education Enviroments and also to make our openSUSE better known. So... We must work hard to end openSUSE 11.0 EDU-CD on time. Andrea Florio -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkh2DSEACgkQyCZT87TFPuihgQCbBxwNFw8JCMviyHMBoh+lUX8+ WvQAoN+vcSShiaEW3CDLlJF3iEH5R9rd =+bz9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-edu+help@opensuse.org
Bravi! On Thu, 2008-07-10 at 15:22 +0200, Andrea Florio wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Folks, openbabel 2.2.0 STABLE has been built.
This mail is just to inform an important change, infact we have no more
libopenbabel2 but now thereis libopenbabel3 that of course "obsoletes" and "provides" libopenbabel2.
but the most important news is another one.
I'm proud to annunce that DIDASCA ( http://www.didasca.it/ ) use on their "Progetto Lazzaro" ( http://www.progettolazzaro.it/ ) openSUSE and LTSP like instrumets to recovery obsoletes LANs and PCs
Goals of prjects are to make Italian schools able to use LTSP on theier Education Enviroment with support of Italian "Education Ministry".
I'm waiting for more and better infos but all the projects sound a greate way to improve Linux use on Education Enviroments and also to make our openSUSE better known.
So... We must work hard to end openSUSE 11.0 EDU-CD on time.
Andrea Florio -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkh2DSEACgkQyCZT87TFPuihgQCbBxwNFw8JCMviyHMBoh+lUX8+ WvQAoN+vcSShiaEW3CDLlJF3iEH5R9rd =+bz9 -----END PGP SIGNATURE----- -- James Tremblay aka, SLEducator Director of Technology Newmarket School District Newmarket NH 03857 Founder http://en.opensuse.org/education "Let's make a difference!" Registered Linux user #440182 CNE 3,4,5 CLP 9 CLE in training ;)
-- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-edu+help@opensuse.org
Hi Andrea Thanks for all your hard work! On Do 10 Jul 2008 15:22:42 CEST Andrea Florio <andrea@opensuse.org> wrote:
Hi Folks, openbabel 2.2.0 STABLE has been built.
This mail is just to inform an important change, infact we have no more
libopenbabel2 but now thereis libopenbabel3 that of course "obsoletes" and "provides" libopenbabel2.
What about creating a "pseudo" package like the gcc people do? -------------- %package libopenbabel Requires: libopenbabel3 %files libopenbabel %defattr(-,root,root) %doc README.SuSE %package libopenbabel3 Provides: libopenbabel2 = %version Obsoletes: libopenbabel2 < %version -------------- Other packages just need to have Requires: libopenbabel in their dependencies - the pseudo package will then require the correct library version (so in the future, just change it to: %package libopenbabel Requires: libopenbabel4 for example - no other changes in other packages have to be done. What do you think about this?
I'm proud to annunce that DIDASCA ( http://www.didasca.it/ ) use on their "Progetto Lazzaro" ( http://www.progettolazzaro.it/ ) openSUSE and LTSP like instrumets to recovery obsoletes LANs and PCs
Goals of prjects are to make Italian schools able to use LTSP on theier Education Enviroment with support of Italian "Education Ministry".
I'm waiting for more and better infos but all the projects sound a greate way to improve Linux use on Education Enviroments and also to make our openSUSE better known.
Very cool!
So... We must work hard to end openSUSE 11.0 EDU-CD on time.
Yes. I'm creating Beta1 for openSUSE 11.0 right now. ;-) I've also added a new package called "opensuse-education-release" which is always installed now. This package comes with an own file: /etc/openSUSE-Education-release so anyone can know on which version he is just looking into this file. Another idea for this package can be found in /etc/zypp/* => a products definition for upcomming zypper and YaST features => a vendor file, so packages from openSUSE-Education will be handled as official openSUSE packages during an update => an online update repository (see below) Currently, the online update repository is empty (what a surprise ;-). I'm currently not shure if we want to go this way, but it looks to me like a good way as we can go the "official" way with a frozen main repository and just updates for packages with bugs - including an information file (Patchinfo) giving users a human readable information of what is fixed. Problem: Somebody has to write such a "Patchinfo" file - normally the packager who updates the package should do this as he's the one who should know all about the update. So this would be extra work for each packager: not only handling bugzilla entries and fixing packages: now even writing patchinfos and releasing updates. Currently, I like the Fedora way using a webfrontend for this: https://admin.fedoraproject.org/updates which is "bodhi" => https://fedorahosted.org/bodhi/wiki But again: this needs additional work for every packager who needs to release a fixed package - so I need your "GO" to implement this for openSUSE-Education. What's your opinion? With kind regards, Lars -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-edu+help@opensuse.org
Lars Vogdt ha scritto:
What about creating a "pseudo" package like the gcc people do? -------------- %package libopenbabel Requires: libopenbabel3
%files libopenbabel %defattr(-,root,root) %doc README.SuSE
%package libopenbabel3 Provides: libopenbabel2 = %version Obsoletes: libopenbabel2 < %version -------------- Other packages just need to have Requires: libopenbabel in their dependencies - the pseudo package will then require the correct library version (so in the future, just change it to: %package libopenbabel Requires: libopenbabel4 for example - no other changes in other packages have to be done.
What do you think about this?
and what's the problem?
Yes. I'm creating Beta1 for openSUSE 11.0 right now. ;-)
I've also added a new package called "opensuse-education-release" which is always installed now. This package comes with an own file: /etc/openSUSE-Education-release so anyone can know on which version he is just looking into this file. Another idea for this package can be found in /etc/zypp/* => a products definition for upcomming zypper and YaST features => a vendor file, so packages from openSUSE-Education will be handled as official openSUSE packages during an update => an online update repository (see below)
Currently, the online update repository is empty (what a surprise ;-). I'm currently not shure if we want to go this way, but it looks to me like a good way as we can go the "official" way with a frozen main repository and just updates for packages with bugs - including an information file (Patchinfo) giving users a human readable information of what is fixed.
Problem: Somebody has to write such a "Patchinfo" file - normally the packager who updates the package should do this as he's the one who should know all about the update. So this would be extra work for each packager: not only handling bugzilla entries and fixing packages: now even writing patchinfos and releasing updates.
Currently, I like the Fedora way using a webfrontend for this: https://admin.fedoraproject.org/updates which is "bodhi" => https://fedorahosted.org/bodhi/wiki
But again: this needs additional work for every packager who needs to release a fixed package - so I need your "GO" to implement this for openSUSE-Education. What's your opinion?
With kind regards, Lars
great! you are always the best!Lars Vogdt ha scritto:
Hi Andrea
Thanks for all your hard work!
On Do 10 Jul 2008 15:22:42 CEST Andrea Florio <andrea@opensuse.org> wrote:
Hi Folks, openbabel 2.2.0 STABLE has been built.
This mail is just to inform an important change, infact we have no more
libopenbabel2 but now thereis libopenbabel3 that of course "obsoletes" and "provides" libopenbabel2.
What about creating a "pseudo" package like the gcc people do? -------------- %package libopenbabel Requires: libopenbabel3
%files libopenbabel %defattr(-,root,root) %doc README.SuSE
%package libopenbabel3 Provides: libopenbabel2 = %version Obsoletes: libopenbabel2 < %version -------------- Other packages just need to have Requires: libopenbabel in their dependencies - the pseudo package will then require the correct library version (so in the future, just change it to: %package libopenbabel Requires: libopenbabel4 for example - no other changes in other packages have to be done.
What do you think about this?
I'm proud to annunce that DIDASCA ( http://www.didasca.it/ ) use on their "Progetto Lazzaro" ( http://www.progettolazzaro.it/ ) openSUSE and LTSP like instrumets to recovery obsoletes LANs and PCs
Goals of prjects are to make Italian schools able to use LTSP on theier Education Enviroment with support of Italian "Education Ministry".
I'm waiting for more and better infos but all the projects sound a greate way to improve Linux use on Education Enviroments and also to make our openSUSE better known.
Very cool!
So... We must work hard to end openSUSE 11.0 EDU-CD on time.
Yes. I'm creating Beta1 for openSUSE 11.0 right now. ;-)
I've also added a new package called "opensuse-education-release" which is always installed now. This package comes with an own file: /etc/openSUSE-Education-release so anyone can know on which version he is just looking into this file. Another idea for this package can be found in /etc/zypp/* => a products definition for upcomming zypper and YaST features => a vendor file, so packages from openSUSE-Education will be handled as official openSUSE packages during an update => an online update repository (see below)
Currently, the online update repository is empty (what a surprise ;-). I'm currently not shure if we want to go this way, but it looks to me like a good way as we can go the "official" way with a frozen main repository and just updates for packages with bugs - including an information file (Patchinfo) giving users a human readable information of what is fixed.
Problem: Somebody has to write such a "Patchinfo" file - normally the packager who updates the package should do this as he's the one who should know all about the update. So this would be extra work for each packager: not only handling bugzilla entries and fixing packages: now even writing patchinfos and releasing updates.
Currently, I like the Fedora way using a webfrontend for this: https://admin.fedoraproject.org/updates which is "bodhi" => https://fedorahosted.org/bodhi/wiki
But again: this needs additional work for every packager who needs to release a fixed package - so I need your "GO" to implement this for openSUSE-Education. What's your opinion?
With kind regards, Lars
-- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-edu+help@opensuse.org
On Fr 11 Jul 2008 20:56:58 CEST Andrea Florio <andrea@opensuse.org> wrote:
Lars Vogdt ha scritto:
What about creating a "pseudo" package like the gcc people do? -------------- %package libopenbabel Requires: libopenbabel3
%files libopenbabel %defattr(-,root,root) %doc README.SuSE
%package libopenbabel3 Provides: libopenbabel2 = %version Obsoletes: libopenbabel2 < %version -------------- Other packages just need to have Requires: libopenbabel in their dependencies - the pseudo package will then require the correct library version (so in the future, just change it to: %package libopenbabel Requires: libopenbabel4 for example - no other changes in other packages have to be done.
What do you think about this?
and what's the problem?
The "old" way, every other package has Requires: libopenbabel3 in his specfile - and must be adapted. With the new proposal, every other package except openbabel just has: Requires: libopenbabel and so only the openbabel package has to be adapted. So it should just be a problem if another package really needs a fixed version - but this is a problem of this single package, then. With kind regards, Lars -- To unsubscribe, e-mail: opensuse-edu+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-edu+help@opensuse.org
participants (3)
-
Andrea Florio -
James Tremblay -
Lars Vogdt