[ovirt-users] Compiling oVirt for Debian.

Fri Apr 21 19:00:09 UTC 2017

Also I noticed when running `make` and `make install` for otopi after
running ./configure with the --enable-java-sdk and --with-maven
options that in both instances, code (for lack of a better word) gets
downloaded from https://repo.maven.apache.org/. I was wondering if
there was a way instead to check if the latest jar and pom modules
have been downloaded and then continue with the build using what is
already there. For a user like myself who's on a capped connection,
that would helpful since it would trim the amount of data used. Of
course, it is possible that it is minimal, but I also thought it would
be handy to avoid the duplication of effort so to speak.

As an aside, at what time is the community online in IRC? I ask
because I have had difficulty working this out from the documentation
which says 07:00 UMT to 11:00 UMT (09:00 IST to 17:00 PST). I haven't
been able to work out what timezone UMT is (all I got was Universal
Military Time and a successor standard to GMT, which I was unable to
make sense of unfortunately) and all I got for IST was Indian Standard
Time which would be okay, only that PST stands for Pacific Standard
Time (PDT in the summer) and that wouldn't add up :)

However if the mailing list is the preferred option, then I shall be
more than happy to stick to that :D

On 4/21/17, Leni Kadali Mutungi <lenikmutungi at gmail.com> wrote:
> Have run into difficulties building ovirt-host-deploy. I tried to
> build otopi using the commands given in the INSTALL file and made sure
> to run `./configure` with the options --enable-java-sdk and
> --with-maven. Unfortunately, when I restarted the building of
> ovirt-host-deploy, I failed to make it past ./configure with the
> resulting error below:
>
> user at localhost:~/ovirt-host-deploy$ ./configure --enable-java-sdk
> --with-maven
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking for a sed that does not truncate output... /bin/sed
> checking whether NLS is requested... yes
> checking for msgfmt... /usr/bin/msgfmt
> checking for gmsgfmt... /usr/bin/msgfmt
> checking for xgettext... /usr/bin/xgettext
> checking for msgmerge... /usr/bin/msgmerge
> checking for a sed that does not truncate output... (cached) /bin/sed
> checking whether make sets $(MAKE)... (cached) yes
> checking whether ln -s works... yes
> checking if 'ln -sr' supported... yes
> checking for pyflakes... pyflakes
> checking for pep8... no
> checking for mvn... mvn
> checking for javac... javac
> checking for jar... jar
> checking for otopi-bundle... no
> checking for a Python interpreter with version >= 2.6... python
> checking for python... /usr/bin/python
> checking for python version... 2.7
> checking for python platform... linux2
> checking for python script directory...
> ${prefix}/lib/python2.7/dist-packages
> checking for python extension module directory...
> ${exec_prefix}/lib/python2.7/dist-packages
> checking python module: otopi... yes
> configure: error: otopi-devtools required but missing
>
> I've run ./configure with the options and without it, and I've got the
> same error. Sandro in IRC had suggested that I adapt the full options
> for ./configure in Fedora and use them in Debian. Those are as
> follows:
>
>  ./configure --build=x86_64-redhat-linux-gnu
> --host=x86_64-redhat-linux-gnu --program-prefix=
> --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
> --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
> --libexecdir=/usr/libexec --localstatedir=/var
> --sharedstatedir=/var/lib --mandir=/usr/share/man --info
> --docdir=/usr/share/doc/otopi-1.6.3 --disable-python-syntax-check
> --enable-java-sdk --with-local-version=otopi-1.6.3-0.0.master.fc26
> COMMONS_LOGGING_JAR=/usr/share/java/commons-logging.jar
> JUNIT_JAR=/usr/share/java/junit.jar
>
> I got stuck at `--build=x86_64-redhat-linux-gnu` since `uname -a`
> gives: Linux localhost 4.6.0-1-amd64 #1 SMP Debian 4.6.2-2
> (2016-06-25) x86_64 GNU/Linux
> I wasn't sure if I should substitute `x86_64-redhat-linux-gnu` with
> `x86_64-gnu-linux`. Also the ./configure script downloaded
> otopi-1.7.0.master so that I would need to change that as well as the
> reference to Fedora in
> `--with-local-version=otopi-1.6.3-0.0.master.fc26`. I went onto the
> #debian-next channel and was advised to spare myself future pain by
> looking into packaging the necessary stuff for Debian instead of
> trying to hack out a build that will be painful to maintain in future.
>
> Pointers, docs, advice are all welcome.
>
> On 4/20/17, Yedidyah Bar David <didi at redhat.com> wrote:
>> On Thu, Apr 20, 2017 at 3:45 PM, Leni Kadali Mutungi
>> <lenikmutungi at gmail.com> wrote:
>>> On 4/18/17, Yedidyah Bar David <didi at redhat.com> wrote:
>>>> On Sun, Apr 16, 2017 at 6:54 AM, Leni Kadali Mutungi
>>>> <lenikmutungi at gmail.com> wrote:
>>>>>>> I think that all of them are maintained on gerrit.ovirt.org, and
>>>>>>> most
>>>>>>> have
>>>>>>> mirrors on github.com/ovirt.
>>>>>>>
>>>>> Found all the source code on gerrit.ovirt.org; not all of it is
>>>>> mirrored to github.com/ovirt
>>>>>
>>>>>>> If you haven't yet, you might want to check also:
>>>>>>>
>>>>>>> http://www.ovirt.org/develop/developer-guide/engine/engine-development-environment/
>>>>>>> Adding to otopi support for apt/dpkg is indeed interesting and
>>>>>>> useful,
>>>>>>> but
>>>>>>> imo isn't mandatory for a first milestone. Not having an apt
>>>>>>> packager
>>>>>>> will
>>>>>>> simply mean you can't install/update packages using otopi, but other
>>>>>>> things
>>>>>>> should work. Notably, you won't be able to use engine-setup for
>>>>>>> upgrades,
>>>>>>> at least not the way it's done with yum and versionlock.
>>>>>
>>>>> So does this mean I shouldn't bother with installing otopi, because
>>>>> according to the development guide for RPM-based systems, it seems
>>>>> only the ovirt-host-deploy, ovirt-setup-lib, and ovirt-js-dependencies
>>>>> are the packages required.
>>>>
>>>> ovirt-host-deploy requires otopi, and also engine-setup (from the
>>>> engine
>>>> git repo) does. So unless you want to start manually imitating what
>>>> these
>>>> do (which might not be a terrible idea, if you want to understand more
>>>> deeply how things work, but will take more time), you do need otopi.
>>>>
>>>> Also please note that the above developer guide is probably not
>>>> complete
>>>> or up-to-date - please check also README.adoc from the engine sources.
>>>>
>>>>> The guide for Debian is blank and marked as
>>>>> TODO.
>>>>
>>>> Indeed, patches are welcome :-)
>>>>
>>>> I expect at least some packages to be missing there, didn't check
>>>> personally.
>>>>
>>>>> Another query I had was that should I make the config files
>>>>> myself as referenced by the README or can I expect that it will be
>>>>> done during make install?
>>>>
>>>> which ones? postgresql's? It's automatically done when you install
>>>> from RPMs, but not in dev-env mode. So you'll have to do that
>>>> manually for now.
>>>
>>> I was referring to the configuration files referenced in the README
>>> docs for otopi, ovirt-host-deploy, ovirt-setup-lib, and
>>> ovirt-js-dependencies.
>>
>> otopi and ovirt-host-deploy do not need configuration files.
>> ovirt-setup-lib does not have any (and does not mention any).
>> No idea about ovirt-js-dependencies.
>>
>>> I'm not sure that running the make install will
>>> put the required configuration files in the directories that the
>>> programs will expect to find them.
>>
>> Not sure either.
>>
>> I suggest to check the spec file in the source to see what rpm
>> installation does, and the gentoo stuff I mentioned earlier.
>>
>>> If it turns out that that is the
>>> case, then I think I am all set.
>>
>> And if you are not, please post specific errors/problems :-)
>>
>>> I installed postgresql from the
>>> Debian repositories.
>>
>> Obviously. When I said "from RPMs", I referred the oVirt and the
>> provided spec files, not to postgresql. IIRC I already used oVirt
>> with a postgresql db on a remote Debian machine without problems.
>>
>> Best,
>> --
>> Didi
>>
>
>
> --
> - Warm regards
> Leni Kadali Mutungi
>

-- 
- Warm regards
Leni Kadali Mutungi