I look at scilab and it is not trivial to packaged it. I hope I’ll try at the end of this week. Meanwhile I encourage you to make some training with null package. 
Thanks for the encouragement. But, what makes packaging scilab not trivial? I have not passed yet from the “preparation” phase, did not go to the actual abf rpmbuiid. So far I hope the following steps will be my first attempt to package it:
From the analysis of OMA scilab 5.X spec, mageia scilab 6.0 spec and fedora scilab 6.0 spec, get an updated OMA 6.0 scilab spec, with proper dependencies inserted and unused ones removed. I guess this will take some time because package names differ from one distro to another, I probably will have to painstakingly verify “whatprovides”, “whatrequires”, and so on, to get the proper list for BuildRequires and Requires for the OMA scilab 6.0 spec. Then I simply will insert the sources, patches (got from mageia and fedora) into the SOURCE directory.
I guess having the spec, abf rpmbuild will perform the remaining steps.
It seem to be laborious but I hope not difficult if I’m not underestimating everything…
Also some other requires should be update (at least eigen3 but I haven’t finished to inspect all the other dependencies yet). Then, because it is a new major version, I’d like to try to compile it with clang because openmp support has been added (afaik other distros use gcc) and eventually to enable lto ad no-undefined, if they work. Finally it is not just a bugfix update, so the way it to build it in cooker first but actually it fails there due to some broken packages (especially lib64xml2-devel). At least this is what I’d try to do and well I agree all this is not difficult but imo may be not so trivial.
However I don’t want to discourage you in any way and all contribution are always welcome but I just warn you imho scilab is not the simplest package to start with. In case, here there are some useful infos in case.of some troubles.
btw for eigen3 you may use the spec at github or, for tests, the rpm ABF or my personal repo.
About some other packages you mention:
- kile: afaik _2.1.3_is the latest version. Just it may be recompiled using kde5 libraries.
- texstudio: 2.12.2 is in repo while 2.12.4 is the latest so it’s not so much outdate.
I’m really needing scilab 6.0. The 5.X version has known bugs and the binary downloaded from its home page for version 6.0 stopped working after some OMA updates (also in Arch linux and others). So, I’m limited to using scilab at RHEL (without updates) at work.
Unfortunately, as you said, building is depending on other broken packages. Other packages like texstudio and kile are working fine in their outdated versions.
Many thanks
@adelson.oliveira: please open a request on bugzilla about scilab.
@Cooker: until now I update some packages but it seems other need to be update. Some of this packages may require the update of some widely used java package (lucene, aqute-bnd, etc) which is not so easy because lots of java packages are quite outdated. So I can’t do it alone and for now I stopped my work. If you decide to upgrade java stack please let me know because I build lots of already updated java package in my personal repo so I think I could help.
Here is the actual situation for scilab.
updated packages:
eigen3-devel >= 3.3
xmlgraphics-commons
batik
fop
osgi-core (not on gituh yet)
osgi-compendium (not on gituh yet)
osgi-annotation (not on gituh yet)
ivy (not on gituh yet)
packages to be update:
lucene (may requires aqute-bnd update …)
vtk >= 7
Mandian,
I’ve already open a ticket on scilab a few months ago. This is 2116 bug. It was assigned to Crisb, before he left the distro.
By now, a close dead line of another work I have to do is consuming my time.
I have to say that I don’t even understand what it is meant by “to upgrade the java stack”!
I’ll be back to this question soon.
Thanks
I tried to build scilab on my machine using the standard method and according to my tests it requires a more update version of lucene but this requires a more update version of aqute-bnd. The update of aqute-bnd seems to be no compatible with some other packages and also some maven plugins which also need to be recompiled/updated. Unless the risk is to broke java stack in omdv. This is my own analysis of the problem and may be wrong also because I use my dirty box with lots of already update java packages.
Finally I’ll try! Following Mandian advices, I’ll begin with texstudio package (2.12.2 -> 2.12.4).
I’ve downloaded from GitHub Openmandriva the file texstudio-master.zip.
Unzipped in ~/rpmbuild/SPECS. It created directory
texstudio-master
Then I did,
$ cd texstudio-master
$ gvim texstudio.spec (to change 2.12.2 to 2.12.4)
$ abf rpmbuild
I got the following (error?) messages:
$ abf rpmbuild
Traceback (most recent call last):
File “/usr/bin/abf”, line 1748, in
command_line.func()
File “/usr/bin/abf”, line 621, in localbuild_rpmbuild
shutil.copytree(src, src_dir, symlinks=True)
File “/usr/lib64/python2.7/shutil.py”, line 171, in copytree
names = os.listdir(src)
TypeError: coercing to Unicode: need string or buffer, NoneType found
what should I do next?
1 Like
You may use git for this:
git clone https://github.com/OpenMandrivaAssociation/texstudio.git
or directly abf, as suggested by TPG:
abf get texstudio
In order to install all needed packages you may use:
sudo urpmi --buildrequires texstudio.spec
The directory should be named as the spec so rename the directory from texstudio-master to texstudio or use one of the above methods.
btw: I got a bit further with scilab. Now I fixed all required packages but I’ve still got a problemin building scilab itself with moelica. Someone more expert than me with ocaml is needed for a fast solution. In anyway I’ll put al on ABF asap so everyone can help. 
Ok. I did,
$ abf get texstudio
$ cd texstudio
$ gvim texstudio.spec (to change version to 2.12.4)
But when I do,
$ urpmi --buildrequires texstudio.spec
the package textudio-2.12.4.tar.gz is not among the developer packages downloaded.
and also, when I do,
$ abf rpmbuild (inside texstudio directory)
the old source texstudio-2.12.2 is downloaded instead of the new, desired one (I changed the spec!)
I guess I have to manually download the source, new patches, and so on, as I initially thought I need.
I noticed that at GitHub - OpenMandrivaAssociation/texstudio there is a
.abf.yml
where I can find the old source. Is it allowed to include the new source there? Would this solve the problem of
$ abf rpmbuild
downloading the old source?
Thanks
abf try to download the source from file-store according to the info in .abf.yml and rpmbuild try to download the source from the link into the .spec file. You you don’t like to manually download the source you may use abf get texstudio to download the content of the github repo (it acts in a similar way as git clone but it is simpler), make you changes and then use rpmbuild to make compilation. Finally before to push your project in the github repo you may upload the new source and update the .abf.yml file at once by using abf put.
Ok! I’m confused. I already have installed the devel packages in Buildrequires but it still complains about it:
I did,
$ rpmbuild texstudio/texstudio.spec
the proper source was downloaded at SOURCES/texstudio/ directory. Great!
Then I did,
$ rpmbuild --root ~/rpmbuild -ba texstudio/texstudio.spec
and I got:
error: Failed build dependencies:
qt5-devel is needed by texstudio-2.12.4-1.src
pkgconfig(poppler-qt5) is needed by texstudio-2.12.4-1.src
pkgconfig(Qt5Svg) is needed by texstudio-2.12.4-1.src
pkgconfig(Qt5Script) is needed by texstudio-2.12.4-1.src
pkgconfig(Qt5UiTools) is needed by texstudio-2.12.4-1.src
The point is that I’ve already done
$ urpmi --buildrequires texstudio.spec
That is, for qt5-devel (and also for pkgconfig)
$ rpm -qa|grep qt5-devel
lib64poppler-qt5-devel-0.43.0-2-omv2015.0.x86_64
qt5-devel-5.8.0-4-omv2015.0.x86_64
Try with:
cd ~/rpmbuild/SPECS/texstudio
sudo urpmi --buildrequires texstudio.spec
rpmbuild -ba texstudio.specSorry not have said everything on first time.
Mandian,
What I’ve done first was what you suggested. The process (rpmbuild) stops with errors in creating the directory texstudio2.12.4 for building purposes. I’ve concluded it was a permission issue. It could not create the directory because it was trying use a system area and I was doing everything as a common user.
I’ve reported my second attempt to use rpmbuild but changing the buildroot to point to an accessible area explicitly.
Now, I’m looking for answers to the following questions:
- Since I have the file .rpmmacros (its first line is %_topdir %(echo $HOME)/rpmbuild) that defines my user tree for building functions, why rpmbuild try to build the package elsewhere?
- Why rpmbuild does not recognizes the required (but installed) packages? Is it mislead by the definition of the building root and did not find the rpm database?
I think I could overcome this problems building the package as root but it was not what I use to do in the past.
Thanks
This is an example ~/.rpmmacros you may try:
# rpmbuil tree top dir
%_topdir %(echo $HOME)/rpmbuild
# Directory where to place building dir
#%_builddir %{_topdir}/BUILD/%{name}
# Directory where to place buildroot
#%_buildrootdir %{_topdir}/BUILDROOT/%{name}
# Directory where to place .rpm files
#%_rpmdir %{_topdir}/RPMS/%{name}
# Directory where to place soruce files
%_sourcedir %{_topdir}/SOURCES/%{name}
# Directory where to place patch files
%_patchdir %{_topdir}/SPECS/%{name}
# Directory where to place .spec files
%_specdir %{_topdir}/SPECS/%{name}
# Directory where to place .srpm files
#%_srcrpmdir %{_topdir}/SRPMS/%{name}
Then use the commands from the above post.
I can’t say without seeing at the error.
Are you launching rpmbuid as root? In the case you should never do this.
Thanks Mandian,
My .rpmmacros was different from yours. I’ve commented the lines in mine so as to be like yours and it worked.
However, I don’t understand why the process created, under my original rpmbuild another directory,
$HOME/rpmbuild/home/adelson/rpmbuild/BUILD/texstudio !!!
Why it was not able to use the very $HOME/rpmbuild/BUILD to do all the job?
Other preliminary comments,
It did not generated a i586 version for texstudio. If, after testing, I finally upload the package, It will lack such archtecture.
I’m attaching my original .rpmmacros (the one that did not worked) just in case someone else could give any hint on why it created only x86_64 packages, why it did not worked at first time,
Thanks a lot
The x86_64 rpm for texstudio 2.12.4 is working fine so far …
1 Like