[opensuse-buildservice] Building against SLE_10 repo
Hi, I'm trying to build updated Beagle packages for SLED 10, and the build against the SLE_10 platform is failing for me: buildinfo is borken... it says: expansion error: nothing provides epiphany, nothing provides epiphany-devel, nothing provides evolution-sharp, nothing provides gmime-devel, nothing provides gsf-sharp, nothing provides wv-devel Of these: * I don't think we shipped epiphany on SLED10, although it was available in autobuild and we shipped the plugin anyway. * We definitely shipped evolution-sharp and gsf-sharp on SLED10, as they're runtime deps of Beagle. * gmime-devel and wv-devel probably weren't shipped on the media, but they may have been in the SDK. Even if they're not, they are needed to build Beagle. So my question is: given that I can build this with autobuild, should the expectation that I can build this (or any other software, really) on SLE10? Or should I use the SL 10.1 target instead? Thanks, Joe --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
SLE_10 is just the intersection of SLED and SLES and is used to deploy packages against both systems, so it's missing a lot of things we need for SLED. Using the 10.1 target should bring in everything you need. It would be nice to have separate SLES and SLED targets that could contain proprietary packages (i.e. RealPlayer) and couple that with the ability to mark the output repository as private to avoid any distribution issues. --Aaron On Tue, 2006-12-19 at 13:06 -0500, Joe Shaw wrote:
Hi,
I'm trying to build updated Beagle packages for SLED 10, and the build against the SLE_10 platform is failing for me:
buildinfo is borken... it says: expansion error: nothing provides epiphany, nothing provides epiphany-devel, nothing provides evolution-sharp, nothing provides gmime-devel, nothing provides gsf-sharp, nothing provides wv-devel
Of these:
* I don't think we shipped epiphany on SLED10, although it was available in autobuild and we shipped the plugin anyway.
* We definitely shipped evolution-sharp and gsf-sharp on SLED10, as they're runtime deps of Beagle.
* gmime-devel and wv-devel probably weren't shipped on the media, but they may have been in the SDK. Even if they're not, they are needed to build Beagle.
So my question is: given that I can build this with autobuild, should the expectation that I can build this (or any other software, really) on SLE10? Or should I use the SL 10.1 target instead?
Thanks, Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Tuesday 19 December 2006 19:17 schrieb Aaron Bockover:
SLE_10 is just the intersection of SLED and SLES and is used to deploy packages against both systems, so it's missing a lot of things we need for SLED. Using the 10.1 target should bring in everything you need.
It would be nice to have separate SLES and SLED targets that could contain proprietary packages (i.e. RealPlayer) and couple that with the ability to mark the output repository as private to avoid any distribution issues.
This is still planned, but it makes the setup way more complex than the current one. So we have to spend some time on automaticing the setup and update of the repositories. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi all. I´m packing an application which has got some .sql to configure database. When you download the tar.gz you have to run the sql by hand, of course, and all tables, and databases are created. Well, I would like to make that process automatically when the rpm is being installed. As all of you could imagine to run the sql you must be root and know root password of the mysql server, so, I have no idea about how to ask for the root of the mysql when rpm -i foo.rpm is done. I mean, I would like to store the root password (I´ve been thinking that could be done with "expect") to use it with later, so then, the application will be installed and the databases will be set up correctly, cause I don´t want users to install the rpm and after that run by hand the sql file. The command I shoudl run is: cat pandoradb.sql | mysql -D pandora -u root -p cat pandoradb_data.sql | mysql -D pandora -u root -p Any ideas of what to do with the spec file? Thanks in advance. -- Manuel Arostegui Ramirez. Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi, Am Mittwoch, 20. Dezember 2006 16:23 schrieb Manuel Arostegui Ramirez:
I mean, I would like to store the root password (I´ve been thinking that could be done with "expect") to use it with later,
ah, and you know _my_ root-password for _my_ mysql-server?
so then, the application will be installed and the databases will be set up correctly, cause I don´t want users to install the rpm and after that run by hand the sql file.
The command I shoudl run is:
cat pandoradb.sql | mysql -D pandora -u root -p cat pandoradb_data.sql | mysql -D pandora -u root -p
Any ideas of what to do with the spec file?
hm, don't think about that, create a SUSE-readme in /usr/share/doc/packages/yourapp/, the user have to read this file. Detlef --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
El Miércoles, 20 de Diciembre de 2006 17:05, Detlef Reichelt escribió:
ah, and you know _my_ root-password for _my_ mysql-server?
That's exactly what I want and that's why I sent this email. I do not know if there's a way to ask for the password during the installation of the rpm package. -- Manuel Arostegui Ramirez. Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Wednesday 20 December 2006 17:20 schrieb Manuel Arostegui Ramirez:
El Miércoles, 20 de Diciembre de 2006 17:05, Detlef Reichelt escribió:
ah, and you know _my_ root-password for _my_ mysql-server?
That's exactly what I want and that's why I sent this email. I do not know if there's a way to ask for the password during the installation of the rpm package.
there is, but it is really evil to do this. Because this interrupts a maybe automated installation process. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
El Miércoles, 20 de Diciembre de 2006 17:41, Adrian Schröter escribió:
there is, but it is really evil to do this.
Because this interrupts a maybe automated installation process.
bye adrian
Yeah, but to be honest, I think it's more comfortable to do that rather than look for the sql file an run it manually. I would like to know how do you that :-) -- Manuel Arostegui Ramirez. Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello, Am Mittwoch, 20. Dezember 2006 17:51 schrieb Manuel Arostegui Ramirez:
El Miércoles, 20 de Diciembre de 2006 17:41, Adrian Schröter escribió:
there is, but it is really evil to do this.
Because this interrupts a maybe automated installation process.
Yeah, but to be honest, I think it's more comfortable to do that rather than look for the sql file an run it manually. I would like to know how do you that :-)
If you want to make it easy for your users, write a small script ("myapp_setup" or something like that) that creates the database. For extra bonus, add some echo commands in the postinstall script that point the user to your database creation script. Advantages: - some lines of text output won't hurt in automated installation - it's still easy for the user to create the database - no evil hacks needed - users cann install your package without being forced to create the database (might be a rare usecase, but there are people who want to read your scripts without using them for example). I can imagine some _really_ crazy ways to autoinstall your database, but they are that evil that I don't even want to mention them ;-) Regards, Christian Boltz --
*gruebel* Beenden sich Zombie-Prozesse nicht irgendwann mal von selbst? Ne, die sind ja schon beendet. Umpf. Jetzt wird's schwierig. Wie zum Henker tötet man tote Untote, die schon gestorben sind? [Eilert Brinkmann und Martin Leidig in suse-talk]
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, 2006-12-21 at 01:06 +0100, Christian Boltz wrote:
Hello,
Am Mittwoch, 20. Dezember 2006 17:51 schrieb Manuel Arostegui Ramirez:
El Miércoles, 20 de Diciembre de 2006 17:41, Adrian Schröter escribió:
there is, but it is really evil to do this.
Because this interrupts a maybe automated installation process.
Yeah, but to be honest, I think it's more comfortable to do that rather than look for the sql file an run it manually. I would like to know how do you that :-)
If you want to make it easy for your users, write a small script ("myapp_setup" or something like that) that creates the database.
For extra bonus, add some echo commands in the postinstall script that point the user to your database creation script.
Advantages: - some lines of text output won't hurt in automated installation - it's still easy for the user to create the database - no evil hacks needed - users cann install your package without being forced to create the database (might be a rare usecase, but there are people who want to read your scripts without using them for example).
I can imagine some _really_ crazy ways to autoinstall your database, but they are that evil that I don't even want to mention them ;-)
Regards,
Christian Boltz
I have a similar problem as one of my next steps to getting a package automated I'd like to enable apache2 and PHP and postgres. all in one script, i know the Moodle group can do it all from PHP , i'd like to fork that part of their code as a default PHP installation routine , would make a great template in the buildservice! I just googled "install.php" and got a few hits. we should share a script. James --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, December 21, 2006 01:06, Christian Boltz wrote:
If you want to make it easy for your users, write a small script ("myapp_setup" or something like that) that creates the database.
Yeah, actually we´ve got an .sql file which can be run by: cat pandoradb.sql | mysql -D pandora -u root -p
For extra bonus, add some echo commands in the postinstall script that point the user to your database creation script.
Advantages: - some lines of text output won't hurt in automated installation - it's still easy for the user to create the database - no evil hacks needed - users cann install your package without being forced to create the database (might be a rare usecase, but there are people who want to read your scripts without using them for example).
Yeah, I´ve already thought about some text, that´s an option, I agree.
I can imagine some _really_ crazy ways to autoinstall your database, but they are that evil that I don't even want to mention them ;-)
I would like to know it :-) If you prefer to contact me off the list, just do it. I will be pleased to hear that ideas. Thanks Manuel. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Mi 20.12.2006 16:23 schrieb Manuel Arostegui Ramirez
As all of you could imagine to run the sql you must be root and know root password of the mysql server, so, I have no idea about how to ask for the root of the mysql when rpm -i foo.rpm is done.
Remembering that storing a password in cleartext is not a good way... But here is some example - which works only if you have control over the installation of mysql resp. your user has done the steps below manualy: First: restrict access to mysql in /etc/my.cnf (always a good idea ;-) if not done already. Afterwards store the (in our way ramdomly created) password in /root/.my.cnf. Now you can use the entries in /root/.my.cnf during installation of your package. But you should test, if everything works as expected _after_ your sql-insert statement is executed. (And overwriting an existing database is perhaps nothing you want, too...) Greetings, Lars --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue 19 Dec 2006 20:06, Joe Shaw wrote:
Hi,
I'm trying to build updated Beagle packages for SLED 10, and the build against the SLE_10 platform is failing for me:
buildinfo is borken... it says: expansion error: nothing provides epiphany, nothing provides epiphany-devel, nothing provides evolution-sharp, nothing provides gmime-devel, nothing provides gsf-sharp, nothing provides wv-devel
Of these:
* I don't think we shipped epiphany on SLED10, although it was available in autobuild and we shipped the plugin anyway.
* We definitely shipped evolution-sharp and gsf-sharp on SLED10, as they're runtime deps of Beagle.
* gmime-devel and wv-devel probably weren't shipped on the media, but they may have been in the SDK. Even if they're not, they are needed to build Beagle.
So my question is: given that I can build this with autobuild, should the expectation that I can build this (or any other software, really) on SLE10? Or should I use the SL 10.1 target instead?
Building against the SL10.1 target is ONE way to solve the problem and one that I have been recommended more than one my SUSE people on the IRC channel. Consider the following target I have for the Server:Telephony project: <repository name="SLE_10"> <path repository="SuSE_Linux_10.1" project="ruby"/> <path repository="SLE_10" project="network:aaa"/> <path repository="SLE_10" project="SUSE:SLE-10:SDK:Extra"/> <path repository="Apache_SLE_10" project="Apache:Modules"/> <path repository="SLE_10" project="Java:addon"/> <arch>i586</arch> <arch>x86_64</arch> </repository> Now I just spent the last hour checking this list of targets and trust me they are ALL needed. You will notice that the one man out is the "ruby" project which doesn't have a SLE_10 target. Thats fine you say.. Just use the 10.1 target... HOWEVER this introduces a really subtle (actually not THAT subtle) problem! Several of my telephony packages use the speex compression codec, and it is happily listed as a BuildDependency. speex.rpm (and speex-devel) does not however ship with SLE_10, but my packages happily build without me being aware of that. (I just wanted ruby, but I got speex and god knows what else also!!) I only noticed this today* when I tried to install OpenPBX on a SLES10 server and rug complained that it couldn't satisfy the dependency and aborted install. (What the hell?? The whole reason we use "build" and the build service is to make sure we get _clean_ packages..) I am now in the position where I have to go through and test each and every package I have built on SLES10 (Which I have already previously tested fine on 10.1 and now 10.2 which I run on my notebook) just to see if they will actually work or not for my users (who I have been telling "just point to the repository and everything will work for you") So, I highly recommend that you do NOT point to a 10.1 target in absence of a SLE_10 target (or package) as while you may get a package _built_ your users will not be able to actually _install_ it. (Without resorting to manual shenanigans) * The reason that I was installing a PBX on Christmas Day can wait for another email. Merry Christmas Everyone -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (10)
-
Aaron Bockover -
Adrian Schröter -
Christian Boltz -
Detlef Reichelt -
James Tremblay -
Joe Shaw -
Lars Rupp -
Manuel Arostegui -
Manuel Arostegui Ramirez
-
Peter Nixon