Regarding updates, I regard Fedora as a living on the edge distribution, where experimentations are done and new software is built. The new startup daemon being ported to Fedora 14 is a primary sample of this. And this is the advantage of Fedora over, say, Ubuntu. Ubuntu has the momentum, the buzz, a company beyond – all of this, but has also critical issues in upstream contribution (Gnome comes to mind), innovation, and also patching.

What can be done? Innovation is the holy grail of Fedora, and that should stay. Perhaps, instead of following a 6 months release cycle, we could take a more progressive approach – an 8 month release cycle? Some LTS releases? Open to suggestions.

Looking carefully, the first one is named django_extensions, but really the name should be “django-extensions”, and you can find the project with the not intuitive name of “django-commandline-extensions” here at googlecode.

Ok, let’s see the spec file:

%{!?python_sitelib: %define python_sitelib %(%{__python} -c “from distutils.sysconfig import get_python_lib; print get_python_lib()”)}

Name:           django-extensions
Version:        0.4.1
Release:        1%{?dist}
Summary:        Django command line extensions

Up to this point, standard stuff. The {?dist} should stand for “current distribution”, so it will end in a “fc11″ package.

Group:          Development/Languages
License:        BSD
URL:            http://code.google.com/p/django-command-extensions/
Source0:        %{name}-%{version}.tar.gz
Source1:        %{name}-docs-%{version}.tar.gz

The Group is standard for Python / Django libraries. License is taken from the project’s homepage, source is the standard .tar.gz file which is downloaded from the front page of the project. Source1 is extracted from the github 0.4.1 tag of the project and contains just the documentation to be built.

BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildArch:      noarch
BuildRequires:  python-devel python-sphinx
Requires:       Django

%description
This is a repository for collecting global custom management extensions
for the Django Framework

The buildroot path is standard, arch is noarch (just python code…), the build requires gets the addition of python-sphinx (python documentation generator) which, at buildtime, generates html documentation from .rst files. Obviously runtime requirements are Django, while the description is a copy and paste from the project home page.

%package doc
Summary:        Documentation for django-extensions
Group:          Documentation
Requires:       %{name} = %{version}-%{release}
Provides:       %{name}-docs = %{version}-%{release}
Obsoletes:      %{name}-docs < %{version}-%{release}

%description doc
This package contains the documentation for the django-extension library

Wait a minute, what is this? Exactly, we are building not one but two packages. One for code, one for doc.

%prep
%setup -q -n %{name}-%{version}
%setup -a 1

Ok, now things become interesting. According to both the Fedora Project RPM Guide and the Maximum RPM book on rpm.org, the above section reads as: prepare environment; extract first source file silently in a directory named $name-$version (e.g. django-extension-0.4.1), then extract the second source file after changing directory to the newly created directory. This is necessary because I compressed just the docs directory level in the git-donwloaded file.

%build
%{__python} setup.py build

%install
rm -rf $RPM_BUILD_ROOT
%{__python} setup.py install -O1 –skip-build –root $RPM_BUILD_ROOT

(cd docs && make html)

All this stuff comes standard creating an empty python spec file, apart from the last line, which builds the html documentation. This is suggested also by Django spec file (go get it with a yumdownloader –source Django and rpm -ivh the src.rpm).

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%{python_sitelib}/*

Standard stuff again.

%files doc
%doc docs

doc packages files

%changelog
* Sun Aug 23 2009 Luca Botti <lucabotti…fedoraproject.org>
- Initial RPM Release

changelog description.

This file is uploaded at my fedorapeople.org‘s address and is submitted in bugzilla for review here. I am waiting for sponsorship. Thanks.

More packages will follow. Stay tuned.

On the link above you will find all the info for the project, so let’s start. We will build the release version of Pinax (for development versions I have a side project, which I will show you at right time). Please note – all the release used are current for the day this entry has been written.

Download pinax version 0.5.1 from here and put it in rpmbuild/SOURCES. After that:

cd ~/rpmbuild/SPECS

rpmdev-newspec -t python pinax

Rpmdev-newspec creates the skeleton for a new spec file named pinax. The -t python option tells to create a skeleton with some python definitions in it (python definitions are laid out according to this wiki entry on the Fedora Project Wiki); you can see which skeletons are available looking in ‘\etc\rpmdevtools’.

Why Python? Well, my guess is that being DJango a Python framework, you know….

Let’s look at the spec file and put some info into that. You can use any editor for the file (I use geany, fast and lightweight).

# sitelib for noarch packages, sitearch for others (remove the unneeded one)
%{!?python_sitelib: %global python_sitelib %(%{__python} -c “from distutils.sysconfig import get_python_lib; print get_python_lib()”)}
%{!?python_sitearch: %global python_sitearch %(%{__python} -c “from distutils.sysconfig import get_python_lib; print get_python_lib(1)”)}

Name: pinax
Version:
Release: 1%{?dist}
Summary:

Group: Development/Languages
License:
URL:
Source0:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildArch:
BuildRequires: python-devel

I am assuming that Pinax is a pure python package, so we use the sitelib for noarch packages (first line of the two provided). After that we have to insert some descriptive info of the Pinax project.

But, of course, before going ahead we must check some of the Pinax dependencies.

Continuing tomorrow…

Just in case, the older spec file can be found here .

A sidenote – the behaviour here is that fixes of major version will update the base package. So 1.6u15 will just upgrade 1.6u14. If you wish something different, let me know. But this is JPackage standard.

Update – please remove previous version of packages. I am studying the update path + alternatives issues which emerged.

For Java on Fedora, I rely on Paul Howarth excellent wiki entry regarding rebuild of Sun Java Package on Fedora Linux.
As a side note, OpenJDK is possibly the best thing that could happen to Java, but:

• as a developer, I need the target vm on my development environment
• as a user, a lot of applets have issues with the OpenJDK plugin

Unfortunately, Paul’s entry refers to version 7 of Java 6, while, at the time of this writing, Java has been updated to version 14. Furthermore, since release 12 of Java 6, a 64 bit version of the java plugin exists (which follows new plugin apis available from mozilla version 3 forward, by the way), so Paul’s notes regarding 64 bit plugin are not valid anymore.

Well, enough said. I just put up a new spec file to help any of you out there setting up the correct java version for your fedora. The thing is set for Fedora 11, but should work for version 10, too.

You can donwload the spec file here . Also download this xsl file and this one .

If you need to startup with rpm packaging (easier than what you would expect) see my previous post regarding packaging setup. You can skip the installation of development-tools, anyway.

After completing the initial steps, put the spec file above in the SPECS directory under rpmbuild in your home directory, and the xsl files in the SOURCES directory (still under rpmbuild).

Download Java (as of today, spec file is for version 6 update 14) 64 or 32 bit as needed. As I was saying, from version 12 forward there is the 64 bit plugin and Java Web Start. Choose the bin file, and download it in ~/rpmbuild/SOURCES.

In case you are wondering, the ~ symbol in Linux stands for “the user’s home directory“, so, if the username you adopted on Linux is “jsmith”, your user home directory will be “/home/jsmith“, and the above directory will be”/home/jsmith/rpmbuild/SOURCES” and the previous one will be “/home/jsmith/rpmbuild/SPECS“

Now insert the following commands:

cd rpmbuild/SPECS
rpmbuild -ba java-1.6.0-sun.spec

Take your time here (it takes a bit to unpack and repackage all). After a while, if all is OK, the command prompt will be back and you will find some files in the RPMS and SRPMS directories.

Depending on your architecture, you will find a i586 (for Fedora 11) or X86_64 directory with rpms in it. To have the Java runtime environment, just do:

sudo yum localinstall java-1.6.0-sun{,-alsa,-fonts,-plugin}-1.6.0*.rpm –nogpgcheck

answer y(es) and go ahead. But now the default Java will still be set to OpenJDK (if installed) the gcj. Just do

sudo alternatives –config java

There are 3 programs which provide ‘java’.

Selection Command

———————————————–

* 1 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java

2 /usr/lib/jvm/jre-1.4.2-gcj/bin/java

+ 3 /usr/lib/jvm/jre-1.6.0-sun/bin/java

Enter to keep the current selection[+], or type selection number:

In this case, selecting 3 you would select the sun java runtime we just installed.
As an additional benefit, an entry in the administration menu of Gnome (do not know about KDE) will be present to set all things related to Java. Also the Java Web Start should work. You can try with (ex)TrollTech’s Qt Jambi Demo Page or at Sun’s Java Web Start Demo Page.

I hope all this becomes obsolete quickly – it looks like in b16 of the OpenJDK the plugin source code is included, so we should see it appear in the Fedora infrastructure for F12.

Update Fabio comments that KDE menu entries work correctly, too. Also, to have the development environment you have to:

sudo yum localinstall java-1.6.0-sun{,-demo,-devel,-src,-jdbc}-1.6.0*.rpm –nogpgcheck

to install compilers, profiler, and all of the JDK elements.

But if you try sudo at the command line, you are met with some error regarding sudo configuration: Fedora does not sudo-enable your account to during system installation, so you are stuck.

What to do is simple:

su -
(insert your root password)
visudo <em> (as per kagesenshi comment #1)</em>

root    ALL=(ALL)       ALL

$username ALL=(ALL)     ALL

$username ALL=(ALL)      NOPASSWD: ALL

EDIT – Brian correctly suggests to uncomment the wheel group in /etc/sudoers and add the users to said group; while correct from a sysadmin point of view, I believe we should keep it simple for users that use Fedora “on the Desktop”. I strongly believe Using Fedora and Administering Fedora should be kept as separate activities as possible. Anyway, for more technically oriented users, you can find this way at the fedorasolved.org site.

• An internal subversion repository for spec files (before posting them on fedora)
• Mock (also look here) to build in a chrooted environment

The subversion repository will be hosted on my soho server at home with dynamic ip (obviously in a ssh setting), which runs on CentOS. The mock environment is just a sudo yum install mock on my machines.

I was also toying with the idea of installing Koji and run a build server on my little atom 330, but perhaps that is overkill.

In the previous weekend, I already had installed the preview release on my notebook, as a clean install. It all worked perfectly, marking this version of Fedora the most interesting Linux Distribution release I ever tried.

Fast, beautiful (thanks to Byte-Code colleague Samuele Storari and his Solar theme), this version, while looking similar to older 9 release, feels definitely more polished and performing.

After the release, I yum-upgraded my home server (the Atom 330 I mentioned in the past), and it worked out really fine, with no issues at all. It’s a simpler environment (no gnome, and a initlevel at 3), but everything (iscsi, samba, DNS, DHCP) continued working as before.

On a side note, my iscsi disk is one of two USB disks attached to the server, so I was wondering how to ensure the block device naming and availability. After contemplating custom udev rules, all that was necessary was a look at /dev/disk. I discovered I can access block devices (like disks) through the /dev/disk/by-id, for example.

Really interesting.