Given that we'd like more testers and most artists aren't going to bother learning to compile, and that getting obs set up once seems to give a fairly easy way of providing updated packages for most distro's it seems like an opportunity to me...

I seem to recall Lubos Lunak (sp?) put out a "simple" tutorial on using it for KDE based apps.

Pity the "simple" tutorial page makes my brain hurt...

I used to have one running for KOffice (synching from the OpenSuSE KDE team from time to time for update), but it was simply too much work for me to keep it uptodate. But it was at a time of many changes in KOffice, now that things have settled down, it could be worth trying again.

Would be *very cool* for getting users / testers / devs to be able to actually have packages for all the major distro's for download from Krita.org...

Krita? - what about things like Amarok dailys, there should be a serious look at using it for distributing anything on apps.kde.org

Obviously, having packages for everything on kde-apps.org would be even more awesome. As someone who primarily cares about Krita and has seen many doable goals fail by being turned into monster size goals, I'd be happy with "just" Krita. After that, everything else is a bonus in my book!

Maybe it's because for some bizarre reason I seem to get all the latest versions of Amarok from my distro's packages, and yet Krita always seems woefully out of date...

OK, I'm actually giving this a try myself (no laughing, please! ) This may be like trying to explain object oriented programming techniques to a caveman, but bear with me... it's for a good cause!

When giving OBS the whole koffice source as a tarball, OBS asks for about 30 dependencies it's confused by, which is to be expected, I guess. I'm trying to strip it down to just what's needed for Krita so I don't need to deal with masses of useless deps for other parts of Koffice (although I'm sure I'll need to figure out how to do this all again for Koffice-libs after,too).

Trouble is, with OBS there's no dcmake line entered that lets you define which parts of Koffice are built. It all seems down to whats in the tarball and I have no idea what specs define a normal functioning source tarball for an app. If you were releasing a tarball of Krita (sans koffice libs), would it be just a straight .tar.gz of Koffice-source/Krita? Should it have any special cmake folder/file stuff added? I'm also wondering if Koffice libs source is literally just the stuff in the Koffice source/libs folder?

Thanks everyone!

If you check any CMakeLists.txt file (one exist in practically every dir) you'll notice things like; macro_optional_add_subdirectory( foo )

What you can do is delete the subdir by that name 'foo' and it will not break the build in most cases.
Naturally its dangerous to delete too much functionality like this, so be careful with this.

Krita will not build without kofficelibs, things like pigment and flake are needed. Other libs like kopageapp/koproperty/koreport are not needed by krita.

Hope that helps a little

Thanks Thomas,

That helps a lot. I guess I need to get Koffice libs built first then so that Krita can then be built, which just means giving OBS a tarball of Koffice libs.

Would this just mean zipping up the Koffice-source/libs folder, or do tarball releases have to have any other special files that would only exist in the root Koffice-source folder?

Naturally its dangerous to delete too much functionality like this, so be careful with this.

Ha! What could possibly go wrong..?

Mhm, can't you put a cmake line in the spec file under %prep and %build just as you would put a configure line in the spec when building a autotools project?

Has anyone looked into PortableLinuxApps.org (self-contained Linux applications), primarily Gnome apps but there are some non-gtk apps like Arora, Opera, OpenOffice

how to: http://portablelinuxapps.org/forum/view ... p?f=11&t=5

Andre wrote:Mhm, can't you put a cmake line in the spec file under %prep and %build just as you would put a configure line in the spec when building a autotools project?

I read this, and it's pretty clear you know much more about this stuff than I do...Now if only I could understand what you just wrote...

Kubuntiac: The OBS uses specification files, just as other package formats (deb, rpm, pkg), which describe what the build system has to do to create the package (how to compile, etc.) and what information should be in the description of the package. To do that, OBS uses the RPM syntax of specification files. It's a simple language with embedded shell scripts. It consists of different sections for the different steps of the build process: get and unpack the sources, configure, compile, install the files, cleanup.

For a very simple package, it would look like this. There are some "macros" that help packagers reproduce common steps, but I'll omit them for now, for the sake of clarity.

Don't assume that these examples actually work, they're out of my head.

Code: Select all

Name: hello_world
Version: 1.0.0
Release: 1
License: GPL
Source: http://example.org/hello_world-1.0.0.tar.gz

%description
A hello world example.

%prep
tar xzf hello_world-1.0.0.tar.gz

%build
make

%install
cp hello_world /usr/local/bin/hello_world

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root)
/usr/local/bin/hello_world


Now, as you can guess, you can theoretically put everything in the command sections, like svn checkouts, cmake commands, etc. Just be sure to put every build-time dependency in the "BuildRequires" tag.

As these spec files are a lot of work, I'd suggest you look after an existing build file for a Krita package in any RPM based distribution (opensuse, fedora, RHEL, Mandriva, etc.).

Here is one for the whole of koffice:

https://build.opensuse.org/package/view ... 53774efc01

Everything that starts with a % is a section header (%prep, %build) or a macro. %setup if used in %prep for example unpacks the file that is given in the "Source" tag.

You can find more information about RPM in the fedora or red hat docs, e.g. here:

http://docs.fedoraproject.org/en-US/Fed ... index.html

Thanks Andre,

That looks very helpful. I'll look into it when I get a moment...

Have you tried "linking" a package from the unstable trunk repositories? In this way, their KOffice source packages would be built against the base repository. You can add additional linked packages to satisfy dependencies.

Edit: I've linked the package and overwritten the sources provided, so it should hopefully work, assuming the dependencies are in order

https://build.opensuse.org/package/show ... k2%3AKrita

error: no matching function for call to 'QByteArray::prepend(char*&, int)'

You seem to be compiling against Qt <= 4.5. prepend(char*, int) was introduced in Qt 4.6. You can use binary operators in RPM files (>,<,...)

But as we only want a Krita build, I'd suggest switching off kword, kspread, kpresenter, kivio, kexi, kplato, karbon, kformula and koreport first.

You should be able to add -DBUILD_{application}=off, just like the f-office param.

Perhaps the errors go away then (don't know the current build dependencies of Krita trunk).