The packaging/centos63/package.sh makes some assumptions about how it's being run that end up with some ugly results if it's not done exactly right. For example, I tried from the incubator-cloudstack directory: "sh ./packaging/centos63/package.sh", which seemed to copy /proc into my current directory and attemped to tar it up. Then I did "cd packaging/centos63; sh ./package.sh", which ended up with roughly the same result, although it died trying to run "Downloading: http://repo.maven..."; as a bash command.
Seems it didn't like being run as an 'sh' either way, even though it's not in the code as executable. After doing a chmod to make it executable, it seems to work but only if your cwd is incubator-cloudstack/packaging/centos63. Maybe we could change it to fail gracefully if your current path doesn't end in "packaging/centos63", and make it executable in git? On Sat, Feb 9, 2013 at 12:15 PM, Wido den Hollander <w...@widodh.nl> wrote: > > > On 02/08/2013 06:32 PM, Hugo Trippaers wrote: >> >> Hey guys, >> >> Just a quick note before the weekend with a status update on RPM. >> >> The management server package is pretty much done and installation on a >> clean system works like a charm. This is actually tested every few hours >> with a Jenkins setup a colleague and I built. We take the sources, compile >> and package. The packages are added to a repo and chef is used to deploy two >> new clean CentOS 6.3 boxes. One is configured as database server and another >> one as CloudStack management server by chef. After installation an ApiKey is >> created for the admin user. This proves that the package can be installed on >> a clean system and that the management server starts. >> >> With this testing we have found several issues of which a few haven't been >> resolved yet (hopefully this weekend): >> >> * 4.1-new-db-schema.sql is not loaded by cloudstack-setup-databases >> * userid is null in reponse to a login call with the admin user, expected >> 2 >> * Excryption initialization is now done in Transaction, this causes the >> mvn -Pdeveloper -pl developer -D deploydb to fail is db.properties is not in >> the classpath >> >> Next week: >> * we will continue with the setup and add some real tests to create >> zones and add hypervisors. >> *I will also start testing with the agent and usage package, they are >> created at the moment but not tested for functionality. >> * Deploy fedora 18 image and extend the test to that >> * Deploy Ubuntu 12.04 and add packaging scripts for that (check with >> wido/noa) >> > > We'll sync next week! A lot of the .deb work is already done, but we just > have to make sure the RPM and DEB packages contain the same files. > > Then it will just be tuning and some work in the pre and postinst files, but > that could be a pain, but we'll just see when we go along. > > Wido > > >> Cheers, >> >> Hugo >> >>> -----Original Message----- >>> From: Chip Childers [mailto:chip.child...@sungard.com] >>> Sent: Thursday, February 07, 2013 2:39 AM >>> To: David Nalley >>> Cc: Alex Huang; Pradeep Soundararajan; Wido den Hollander; cloudstack- >>> d...@incubator.apache.org >>> Subject: Re: [DISCUSS] Packaging in 4.1 >>> >>> On Wed, Feb 06, 2013 at 08:31:14PM -0500, David Nalley wrote: >>>> >>>> On Wed, Feb 6, 2013 at 8:24 PM, Alex Huang <alex.hu...@citrix.com> >>> >>> wrote: >>>>>> >>>>>> Well, first, Apache CloudStack only releases source code. >>>>>> >>>>>> But Wido is kind enough to also host RPM / DEB package repos for >>>>>> users to take advantage of. Our install guide explains how to >>>>>> build from source, as well as how to use Wido's repos. >>>>>> >>>>>> This was all true for 4.0.0-incubating, and I think it still holds >>>>>> true for all future releases. >>>>>> >>>>> Chip, >>>>> >>>>> Can you refresh my memory as to why this is? I look at something like >>>>> cxf >>> >>> or tomcat, they all have binary downloads available. >>>>> >>>>> >>>>> http://cxf.apache.org/download.html >>>>> >>>> >>>> Because providing 'binaries' isn't necessarily problematic, but making >>>> yum and apt repos work in the ASF mirror system seems a bit more of an >>>> issue. Plus, Wido stepped up to do the work, no one else has offered >>>> any other alternatives. >>>> >>>> --David >>>> >>> >>> Yup - exactly what David said. We had discussed trying to get ASF Infra >>> to >>> help us host package repos somewhere, but I don't think that went >>> anywhere. And since Wido's doing it, it avoided all sorts of questions >>> from >>> the infra team around mirrors, archiving, etc... >>> >>> -chip
