Alien Pastures

My thoughts on Slackware, life and everything

Category: Me (Page 24 of 27)

Using git for version control

February 26, 2010 / / 13 Comments

I have always really hated the Git Version Control System (or VCS).

I am pretty comfortable working with other products like RCS, CVS and Subversion (SVN). I am not a developer, so my main use for a VCS is a to allow me to keep track of the changes in my SlackBuild scripts or my server’s log book. I use RCS for this, it is simple but effective.

Of course, in order to compile software it is often required to check out the source code for the program. This is how I got familiar with CVS, SVN, mercurial and git. Way back when I was “build manager” for a software company, I have used PVCS, Clearcase and Visual SourceSafe which are all commercial programs. So, I have been around.

Still, git still confused me after all that time as a end-user. Git uses some alien (to me) concepts which I did not grasp because I never took the trouble to dive into its documentation – I knew just enough to checkout source code from a git repository and did not need – did not want to – know more.

This changed recently. Because two of the projects I am involved with are preparing to use git as their Version Control System, I was forced to start learning how to approach the tool as a developer.

I quickly decided it was worth the while to run two parallel tracks: start reading documentation, and at the same time actually using git by setting up a server for hosting git repositories.

I found some places which host very good reading material.

  • The Pro Git book at http://progit.org/ . This book is hosted itself in a git repository and the language translations are coordinated using git. Well-written with lots of visual examples.
  • The Git Community Book at http://book.git-scm.com/ .

I’m halfway through the “Pro Git” book, retracing my steps a few times after the new concepts found a place in my brain. Indeed, git is starting to make sense now. Surely it has some very strong points which make it interesting not only for large projects with lots of developers who are scattered all over the place (like the Linux kernel developers) but also for small projects like those I am participating in.

Perhaps I will document more about my git activities in a future Wiki article – for instance how I am setting up an online git repository.

This made me think of something else: could it be beneficial to dump the history of my SlackBuild script repository (past and future) into a git repository? What do you think – will it help you if you are able to look at older revisions of my SlackBuild scripts? Some time ago I started copying the SlackBuild script into the documentation directory of every Slackware package I create, but I realize that once I release a newer package, the older scripts disappear from public view.

Leave your opinions in the comments section below please.

Eric

KDE3, KDE4 and Slackware 13.0

January 26, 2010 / / 28 Comments

A bit of history… I realized that just a year ago, KDE 4.2.rc1 got added to Slackware’s “/testing” area.

With all the recent posts on this blog about KDE4 and me telling people how nice I think this version of KDE is, I realize that “liking” is a very personal expression of feelings. A feeling shared by many, fortunately, but there are still people who rather have the old KDE3 back, and the perceived stability that comes with it.

Those people should not read the next few paragraphs… instead do a fast-forward to the bottom half of this post 🙂

One of the reasons for the switch to KDE4 in Slackware 13.0 was that I did not want to build KDE3 packages for slackware64 during the time that I was “secretly” building the package set for it. I had been running KDE4 on my Slackware laptop for more than half a year when I kickstarted the 64-bit port in september 2008. Looking at my options for completing slackware64, I decided that I should jump straight to KDE4. It would probably take until somewhere in 2009 before the 64-bit port would be released to the general public. By that time, KDE 4.2 would be available which I thought would be the right time to replace KDE3 in Slackware.

In january 2009, Pat added KDE 4.2.0 to “/testing“, which was essentially a 32-bit “rebuild” of the KDE 4.2.0 packages the Slackware team members were already running on slackware64. Close inspection of the 32-bit KDE SlackBuild scripts would have revealed that something was cooking. The build scripts contained numerous hints to the non-public 64-bit port. By that time I think most of us were running slackware64 on a daily basis and were used to working with KDE4 (well perhaps this is not tru for Robby, our avid XFCE user ;-). The goal for going public with slackware64-current was set for may 2009. This meant that the package sets for 32-bit and 64-bit had to be synchronized before that time. The SlackBuild scripts for slackware64 were written with the philosophy that they should compile 32-bit packages just as easily, so this synchronization effort was not particularly hard, technically speaking… just a tedious administrative job (Pat might disagree here 🙂 The only big change of course, was that KDE4 had to move from “/testing” into the core “/slackware/kde” package directory.

KDE 4.2.1 was the actual version to finally replace KDE3 in Slackware. This was in march 2009, and got big publicity, because it was a revolutionary upgrade and therefore not welcomed by all Slackware users (but what major change is, really). The KDE team on the other hand, was quite pleased about this 😉

Note that I really like KDE4 – it has become so much more powerful a desktop than KDE3 ever was to me. There was just no way that we could keep everybody happy with the switch to KDE4. If Slackware 13.0 had shipped with KDE3, lots of people would have complained about “stale software”, since KDE3 was no longer maintained at that time (3.5.10 was the final release in the series). KDE 4.2.4 which did ship with Slackware 13.0, was good, with rough edges, but the best choice at that time. Since then, Vincent Batts has released a KDE 4.3.1 package set for Slackware 13.0: http://cardinal.lizella.net/~vbatts/kde/kde4-packages/4.3.1/ , slackware-current has moved to KDE 4.3.4 (stable and a joy to use) and my own packages for play-testing the KDE 4.4 prereleases (to be installed on slackware64-current) are mentioned in other blog posts of mine. KDE 4.4 is surrounded by some “political” issues involving the influence of certain big distros, which keep it from being included into Slackware in the near future. Perhaps I should talk about that in more detail, but I will spend another blog post on that.

However, many people have overlooked the fact that Pat actually did create a KDE 3.5.10 package set to accompany the Slackware 13.0 release. Its location is somewhat hidden and there was no publicity on the slackware.com web site. Mainly because KDE 3.5.10 for Slackware was released with status “unsupported“. It was meant as a service to the Slackware users who required more time to make the switch to KDE4.

You can find KDE 3.5.10 for Slackware 13.0 (32-bit as well as 64-bit packages are available) here: http://slackware.osuosl.org/unsupported/kde-3.5.10-for-slack13.0/

Cheers, Eric

Bleeding at the edges again?

January 5, 2010 / / 4 Comments

… Ok, ok, it is not so bad actually! Au contraire!

Slackware Linux development made a big leap today, when Pat Volkerding updated the distro’s “vital organs” of kernel, glibc and gcc. The “dull” phase of the slackware-current development cycle is over hopefully, and it’s back to the bleeding edge.

To be fair, gcc 4.4.2 has been sitting in “testing” area for quite a while now, and we think it is time to promote it into the core. With glibc 2.11.1 we are pushing it, as this is the most recent stable release, and the 2.6.32.2 kernel was much-anticipated by those who run -current on their computers.

Note that the new kernel has full support for EFI (the Extensible Firmware Interface which is going to be the replacement for the ageing BIOS on modern computers). This means that there is also support for GPT partitions. GUID Partition Table is a standard for the layout of the partition table on a physical hard disk (part of the EFI specification and meant to overcome the 2 TB size limitation of MBR partitions). We still have to look into updating the Slackware installer for automatic GPT partition recognition, but you will be able to use GPT partitions if you do some footwork yourself before running “setup”.

With this update to Slackware’s vitals, the stage is set for further tweaks of the core, but I think that for now, you will have plenty to play with.

And as promised to those running the 64-bit version of Slackware-current, I have made available multilib versions of the new gcc and glibc packages! Thanks to Pat Volkerding who allowed me sufficient time to build and rebuild these packages on my old computer until they were just perfect (I hope) and could be released along with the Slackware originals.

You can get them here: http://slackware.com/~alien/multilib/13.1/ (I took the liberty of assuming that 13.1 will be the version of the next Slackware release, mainly because I needed to give that directory a name).

For detailed instructions about what multilib means to the 64-bit Slackware and how you can add it, read this wiki article: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib

Have fun! Eric

Installing Slackware using USB thumb drive

December 2, 2009 / / 87 Comments

There are several ways to install Slackware to your computer. You have network installation options available (where the packages are on a remote NFS/FTP/HTTP/Samba server) and local options (where the packages are on a DVD/CDROM or a local directory).

In all these cases you need to boot your computer with Slackware’s installer. Traditionally you can boot from a DVD or CDROM of course, or even from a floppy if you are creative. If your computer does not have a DVD/CD drive then there is still the network boot (aka PXE boot) or using a USB thumb drive to boot from.

It is the USB thumb drive I want to talk about in this blog post.

Slackware ships with a USB image file “usbboot.img” since the 12.0 release (see http://slackware.osuosl.org/slackware-13.0/usb-and-pxe-installers/usbboot.img for instance). Using “dd” this image can be transfered to a USB thumb drive which transforms the USB drive to a bootable Slackware installer. The packages will still have to be available on a local or network medium, because the “usbboot.img” image only contains kernels and setup files… no packages.

If you do not want to “sacrifice” a USB thumb drive for this (note that dumping the image file on the USB stick will destroy all data already present on the stick), there is a solution: Slackware also ships with a script “usbimg2disk.sh” since the 13.0 release (see http://slackware.osuosl.org/slackware-13.0/usb-and-pxe-installers/usbimg2disk.sh for instance). This script extracts the content from the “usbboot.img” image file and uses this to transform a regular USB thumb drive into a bootable Slackware installer  non-destructively (i.e. any existing files on the stick will not be touched), as long as there is some 30 MB of available free space on the stick.

The “usbimg2disk.sh” script is also convenient if your computer refuses to boot from a USB stick loaded with the “usbboot.img” file. The BIOS of some computers will not understand the format of the default Slackware USB image. Using the “usbimg2disk.sh” script, you create an alternative bootable USB stick that will be recognized by your computer’s BIOS.

All nice, but there is still a problem that remains to be solved.

If you have a netbook for instance.

The average netbook computer (like my own Asus EeePC 1000H) comes without DVD drive. If you are mobile and without access to wired network, it will not be easy to install Slackware packages after booting from the USB stick.

In such circumstances you need to copy the complete Slackware package tree to a disk partition of your netbook before you start the Slackware installation. This is not always efficient, or even feasible.

Now, I have been creating “multi-partition USB images” for several Slackware releases in the past (more accurately, I have written the scripts that let you create the image and then transfer it to a big enough USB stick using the ” dd” command). You can find those scripts here: http://slackware.com/~alien/tools/usbinstall/ . This is an elegant way to create a USB Slackware installer that has all packages “on board” but I wanted something that was more basic, and thus potentially easier to use for a Slackware newbie.

The “old” scripts at http://slackware.com/~alien/tools/usbinstall/ create a secoind, EXT2-formatted partition to store the Slackware packages. This makes it harder to add more files if you are on a Windows computer for instance. I wanted to have a USB stick with a single large FAT partition – and fortunately the bootloader I am using (syslinux) allows this.

So I took Slackware’s “usbimg2disk.sh” script (which I incidentally wrote too) and expanded its functionality. What is new? The script can now copy the Slackware setup files, kernels and packages all to a regular USB thumb drive, if that has a minimum of 2GB free space available.And it still retains its original functionality (to create a bootable installer as long as there is 30 MB of available free space on the stick).

The USB stick does not even have to be formatted! So, if you already have data on the stick, it will not be destroyed.

There is one advantage to formatting though: if you allow the script to format the USB stick, it will make your future Slackware installation easier. The formatting step assigns a label “USBSLACKINS” to the fat partition. This enables Slackware’s setup to recognize and mount the USB partition automatically after boot, and pre-fill the SOURCE setup dialog “Install from a pre-mounted directory” with the correct directory path. Just hit ENTER a few times to start the installation!

If you did not format the USB stick but used an existing VFAT-formatted stick, you have two options:

  1. either you assign  the label “USBSLACKINS” to the stick’s fat partition manually,
  2. or else you do the following after booting from the USB stick but before running setup: mount the USB partition yourself using the following commands (for this eaxmple I am assuming that the installer recognized the drive as “/dev/sdX“):
mkdir /usbinstall

mount -t vfat -o ro,shortname=mixed /dev/sdX /usbinstall/

And then after you’ve started “setup” and have come to the “SOURCE selection” dialog, you use the directory “/usbinstall/slackware-<version>/slackware” as the source location where setup should look for Slackware packages.

This is how the help text for the script looks:

./usbimg2disk.sh -h
#
# Purpose #1: to use the content of Slackware's usbboot.img and
#   transform a standard USB thumb drive with a single vfat partition
#   into a bootable medium containing the Slackware Linux installer.
#
# Purpose #2: to use the contents of a Slackware directory tree
#   and transform a standard USB thumb drive with
#   a single vfat partition and 2GB of free space into
#   a self-contained USB installation medium for Slackware Linux.
#
#
# Your USB thumb drive may contain data!
# This data will *not* be overwritten, unless you have
#   explicitly chosen to format the drive by using the '-f' parameter.
#
# usbimg2disk.sh accepts the following parameters:
#   -h|--help                  This help
#   -f|--format                Format the USB drive before use
#   -i|--infile <filename>     Full path to the usbboot.img file
#   -l|--logfile <filename>    Optional logfile to catch fdisk output
#   -o|--outdev <filename>     The device name of your USB drive
#   -s|--slackdir <dir>        Use 'dir' as the root of Slackware tree
#   -u|--unattended            Do not ask any questions
#
# Examples:
#
# usbimg2disk.sh -i ~/download/usbboot.img -o /dev/sdX
# usbimg2disk.sh -f -s /home/ftp/pub/slackware-13.0 -o /dev/sdX
#
# The second example shows how to create a fully functional Slackware
# installer on a USB stick (it needs a Slackware tree as the source).

The enhanced script is here: http://connie.slackware.com/~alien/tools/usbimg2disk.sh …get itwhile it’s hot!

I hope it will get added to the Slackware tree soon. Tell me if you liked it! Any questions or remarks, you can leave them below this post.

Cheers, Eric

No mouse in X after installing multilib?

September 14, 2009 / / 2 Comments

Perhaps you run the 64-bit Slackware 13.0. If so, did you by any chance install my 32bit multilib packages on top, and then ran the slackpkg command after that?

There was a bug in my multilib conversion script convertpkg-compat32 (all versions before “10alien“). The compat32-tools package which I have uploaded today contains a fixed version (11alien).

If you have run slackpkg after installing my set of multilib packages and then instructed slackpkg to install the *.new files that it finds, you would end up with empty /etc/rc.d/rc.hald , /etc/rc.d/rc.messagebus and /etc/rc.d/rc.mysqld scripts thanks to this bug.

These empty startup scripts cause hal and dbus not to start when the computer boots (and neither does mysql, but that is not relevant to this little mouse tale). This will perhaps not have an immediately obvious effect, but if you start X, you will have no mouse and no keyboard because X.Org uses hal to probe for and configure your hardware peripherals.

The fix is to upgrade to my latest compat32-tools package, and then reinstall the original Slackware64 hal, dbus and mysqld packages:

upgradepkg --reinstall a/dbus-1.2.14-x86_64-1.txz
upgradepkg --reinstall l/hal-0.5.11-x86_64-6.txz
upgradepkg --reinstall ap/mysql-5.0.84-x86_64-1.txz

Make sure you install the *.new files  which you will find in /etc/rc.d/ , thereby overwriting the empty files !!!

Apologies for the inconvenience this may have caused. Apart from a new compat32-tools package I have also uploaded clean, re-created *-compat32 packages (created by the massconvert32.sh script, using the original 32-bit Slackware packages).

Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑