Episode: 882
Title: HPR0882: RPM format
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0882/hpr0882.mp3
Transcribed: 2025-10-08 04:03:57

---

Thank you for listening to Acropolis Radio. This is Clat 2 with episode 2 of the How-To Package
for the new Linux mini-series. Today we're going to be doing RPMs. RPMs, of course, are,
I guess they were sort of like the big first famous packaging format for Linux. I've always
gotten the impression I could be mistaken, but I've always kind of gotten the impression
that they were the one that kind of set the stage for, oh, Linux, this is how Linux
application management is done. And from what I'm understanding, that's kind of, that
was the one that kind of established that you didn't have to compile everything from
source code anymore. You could grab these packages, run a command, rpm-uvhfood.rpm, and
it would do all of these magical things. And then I guess at some point, maybe at the
same time, you could also, you know, remove those packages. Now at that time, there was,
from, you know, what I've heard, no dependency resolution either. And so people would get
very frustrated because they'd be trying to install Audacity 1., or I guess, you know,
is probably like 0.1 back then. And then they would try to install, I don't know, let's
say lame or something that's kind of vaguely related to Audacity. And the version of lame
that they had downloaded would be something that's newer or older than the one that Audacity
was using. So then they couldn't install both at the same time and whatever. Dependency
hell is what they called it. And RPM has become sort of famous for the one that, you know,
oh, RPMs, that must mean that you're going to have trouble with dependencies. Funny enough,
I've never had any problems with dependencies on RPM, Slack builds. Really, the only one
I've had problems on is .deb. And wait, don't get all panicky because I don't like .debs
or something. I think that when people have dependency issues, it's largely because
they're not familiar with the way that that package manager works. And the one format,
the one package manager that I don't tend to use, well until very recently, I didn't
tend to use very often, as often as the others, was the .deb stuff because I just didn't
have that much debian going on lately because of the power PC computers that I've found
lying around at my new job. I've actually been doing a lot of .deb work. And when I first
started that, I would literally run into dependency problems. But now that I actually kind
of start to, you know, I've read up on apt-get and aptitude and stuff. And now I'm starting
to understand how it all works. And suddenly, those dependency problems have gone away. Coincidence,
I don't think so. So I don't know. I'm not saying that people never had dependency problems
because I'm sure they did. But I certainly have never had that issue with RPMs or Slack builds
myself. And now that I understand, for instance, .deb, I don't have any problems with that either.
Ports, I don't think I've even used enough to even fairly say. So dependencies, I don't know.
It could be an issue. It could not be. I guess it depends on your workflow. Point being,
RPMs came along. And then a little tool called Yum came along. Yum was apparently devised by
Yellow Dog Linux, which was the, I think, the PlayStation and power PC port of Fedora or something
like that, or a version of it. And I've run a little bit of Yellow Dog. But I think, right,
when I was getting into Linux, it was kind of getting out of being a very active force. If it was
ever an active force, I don't know. But Yum is really, it's the apt, it's the apt-get of RPMs.
So if Debian has DPKG and apt-get, and of course aptitude, then that in Red Hatland would be RPM
and Yum. You can use both, actually. And fairly recently, I've actually started using RPM more,
not really because I wanted to, but because there were some little tasks that I had to do that
when you're doing it with RPM. There are some very specific options that you can pass to do exactly
what you want. And suddenly I felt like I knew what I was doing. So once again, with packaging,
I'm doing this on actually a Red Hat system, Red Hat 6, or Rell 6. And when you're doing that,
you, and this is a fresh install, you want to either have a fresh install or you want to have a
VM running what will obviously be a fresh install because it's a virtual machine. You can
revert back to a snapshot or do a literal fresh install every time you build a package.
And that is very important. I also make a user, I tend to try to make that user fairly generic
just because I think, I think the goal behind that is so that you're not accidentally screwing up
your own system and you're not accidentally giving away a whole bunch of information about yourself
or whatever. Make an individual user for this process and then you need to install the things
that you're going to need in order to be a RPM builder. And unlike on the very fine slackware
distribution, not everything just comes included. You have to actually kind of hunt around,
well not hunt around, but you have to do a little bit of work. So the work that you have to do
is, well really in this case, what you should do is become root and then do a young group list
and then do a search or a grab, rather a search for, let's just do DeVel. And that will search
through the repositories that you've got and it will look for the groups that Fedora and I guess
Red Hat and Sindos and all those scientific Linux and all those that the ones group their
applications into. And these are, this is a really nice feature of young. I don't know if there's
an equivalent on aptitude or not, but on, I probably on aptitude it would be like a meta package
or something, but group installs are actually sort of, they're just someone at Fedora or sometimes
someone at Red Hat decided to group a whole bunch of applications together into a handy
mega download and install and you just have these groups that you can do a group install of.
I really like it actually and it's young group install. It's all one, it's young and then group
installs one word. In this case it would be development tools. So the full command after you find
that there is a development tools thing, it would be young group install space quote development tools
and you want to, I think it's a little bit forgiving in terms of the capitalization. I think if
I recall correctly, but you do have to quote it, you want to escape that space in the name of the
group you hit return and that's going to install a bunch of stuff like once that's finished
installing all those nice compiling tool applications and things you'll need to install one more tool
which is called young install space RPM dev tools and that is all one phrase RPM dev tools and that's
the stuff that you're going to need for this RPM development exercise. Now online if you look into
as you should look into tutorials on building RPM files you might see references
to RPM dev tools dash setup tree and this is supposed to be a command that will create the skeletal
structure of kind of an RPM development environment for you automatically and it does that but it
only does it to the slash root directory as I've discovered I cannot redirect it apparently.
I've tried doing RPM dev RPM build RPM dev dash setup tree to the directory that I wanted to
set up that tree into RPM dev dash setup tree redirecting to the current directory all kinds of
things I just can't get it to do that. I think it might be a legacy command assuming that still assumes
that you're building in your root directory but every piece of advice online that I have seen
urges you not to do that to not build your package as root user so I do not use the RPM dev
dash setup tree I simply make the directories myself and it's not hard so I make a folder in my
home directory and I call it RPM build pretty simple kind of obvious and then you simply have to
make six directories in in in the RPM build directories you've got until the slash RPM build
and then you can go into there CD RPM build and then simply make their build all capitals
space build root all capital RPMs so that's RPM s all capital space sources all capitals space
specs all capitals space s RPMs and that's it that's six directories that you can create and now
you've got your RPM build environment that is what all the RPM build tools are going to expect
and kind of want to see by default so if you don't have that environment setup your build will fail
all right so we're still working on the yes please application which is if you'll remember from
the last episode is sigflux little command line application that takes a screenshot and uploads
it to a to a site and the yes please program is really great for for this exercise like I said
last time because it is just a little bit complex it's just complex enough to cause us to actually
work at it and to give us a good taste of what a really really complex application might involve
on a larger scale but at the same time it's really really a small application there's not a whole lot
to it and it turns out to be a really short build script so the the center of the RPM world is the
spec file and that is a spec file is like a slack build that's how I would like a slack build file
that's how I would think of it and that is yes please in this case dot spec now you've got a
spec file that spec file goes guess where yes in the specs directory so if we're in CD or if we're
in rather till the slash RPM build slash specs all capitals and we touch yes please that's why
ESPLZ dot spec then we've got that file and if I do a less on the yes please spec that I actually have
which I'll have to link to this RPM in the show notes so that you can download it and follow along
the spec file is going to pass different variables and different options and different instructions
to the RPM or yum front end there are some things that are included in the RPM program that makes
a spec file fairly easy to write compared to all that code that we had in the slack build if you
remember your reaction or what your reaction might have been when you opened up the yes please
slack build and mind you that was a pretty simple slack build there's a lot of code there there's a
lot of detection going on there's a lot of stuff happening in that shell script RPM because it's
big hefty application all on its own it has a lot of that information that it can kind of figure
out and you don't have to write that into your into your application into your spec file for instance
there's no code blocking here trying to figure out if we're building on 32 or 64 bit RPM will
take care of that for us there's no variable that we have to assign for a libder suffix just in case
we're building on a 64 bit system and not a 32 bit system RPM will just kind of handle that for us
so a couple of like really nice conveniences it's just that you have to kind of get used to them
being there because at first glance this spec file especially it's going to look pretty sparse
so here we are spec file for yes please I'm not going to go line by line but you I think you'll
get the idea so the first line is a percent sign defined and and the percent sign is the RPM
notation for a macro as it were preset kind of thing that's going to get translated into a completely
different process once we start running RPM build on this so the percent define is obviously
defining a variable and in this case we're saying underscore top der is home slash home slash
clatu slash RPM build that is the top directory of our RPM building world that is that our RPM
doesn't need to know that anything outside of home slash clatu slash RPM build even exists
next line of course you see a percent define name this is exactly like the program name variable
in slack build and that is just yes please it's not the full string of all the versioning stuff
has nothing to do with that percent define release well this is release one this is the first
release of a yes please package RPM package that I've ever released so again this like like in
slack where this is the the build version sort of percent define version this is the versioning
number and again this is where sigflup kind of scorns the entire world in their petty conventions
and she boldly names her version AUG underscore four underscore twenty ten traditionally speaking
more often than not I think you're going to see things like zero dot eight one dot a one dot four two
dot three dot thirty three whatever it's going to be in a series of numbers and stuff unless
sigflup wrote it percent define space build route we are telling it that the build route is our top
directory the name of the the application the version of the application dash route this should
look really really familiar again from that slack build because if you would recall in the slack
build we said that we want to define a temp directory and then inside of that temp directory
we want it we want to define that there's a package and the version of that and that everything's
going to be sent there same thing is going on here next line says that the build route is slash
vars slash temp slash percent name dash build route so this is a very very temporary thing that's
why it's going into bar because it's a variable sized file that actually we're going to ditch after
we've built it but we want a working space and we throw that out to slash vars slash temp a summary
that's human information in this case I put one line yes please screen shot uploader for unix
porn dot com license gpl I don't know that that's true I'm assuming it's gpl I should probably ask
sigflup sometime about that name percent name we've already defined that for up in the script again
like I say this is all so similar slack build remember how I was like raving about how they
did all the variables at the top of the script well this is exactly what we've done here right we've
defined a number of variables now for everything underneath that we just keep referring back to
those variables so that if there is a big change sigflup suddenly changes it to yes please
properly spelled yes PL E SE all we have to do is change the word yes please once in the script
because everything else just refers back to that variable same for the release not necessarily
the same for the source the source is going to be the name dash version and then dot in this case
tgz now if your source code that you're compiling for or that you're building a package for
insin dot hard dot gz or tar dot bz 2 or dot zip or dot 7z or dot whatever then you're going to want
to change that extension so this is the line just like in the slack build script where you have to
kind of remember to actually change that appropriately or else when you run your build it's going to
say that no file existed and you'll probably spend like 10 minutes wondering what's going wrong
and you'll realize that you just forgot to give it the proper extension I speak from experience
next line defines our prefix which in this case is slash usr this again is going to be something
that you kind of have to watch keep an eye on I think normally it's going to be slash usr
but you might have to change it if you look through the source code and you see things happening
in the install script or whatever where you actually need to account for some kind of unique thing
in this case it's slash usr all that saying is that when we're doing our RPM build and we're
doing our little script and everything we're simply saying that it's a given that the prefix is
going to be slash usr now within usr there might be a bin an etsy a dock whatever a share
you know whatever other folders we are going to be dumping into our little build but the the
one that we can always account for is going to be slash usr the group I put it in development tools
which is completely wrong I have no idea what the group assignments are on fedora or red hat
I've never really bothered looking it up and then the requires now this is an interesting one
because if you if you do a really simple application that doesn't have any dependency at all and
they do exist then you won't have a requires line but in this case we have a requires line because
as you'll recall from last week this requires x11 libjpeg and actually p-threads well p-threads
is already in red hat and fedora and scientific linux and scintoss so we don't have to really
really worry about that one but lib x11 and libjpeg well actually they both are as well but see we're
on red hat now or fedora so it's not like slack where where all the header files come along with the
application that you've got so in this case we need to require that the user has lib x11 dash
devl and libjpeg dash devl so those are the development files that go along with for instance lib x11
and libjpeg and that's not installed by default on even a pretty robust install they're just not
going to have those files because they don't assume that everyone's going to need the development
versions of or the development files that go along with those those applications here case matters
very much so we're saying lib x11 dash devl and libjpeg dash devl the it's lib lowercase lib
capital x11 dash devl so that sort of thing really really matters because what you're going to find
is that if you were to run this rpm script like actually do an rpms install like rpm dash
capital u vh yes please blah blah blah rpm then it would stop and tell you this requires lib x11 dash
devl before it can build or or that and the libjpeg one so you'd have to go into root user and do a
yum search for lib x11 and libjpeg and find out the name of you know those what those libraries and
of course on fedora it's going to be one thing and then under debian it's going to be on it's
going to be another and i'm sure on some other uh distribution it's it's yet another fedora
usually has that dash devl at the end and i guess they often put live in the front i actually
haven't really noticed lately but but then debian will just say like jpeg lib's dash dev or
something like that and it's not devl so you kind of have to hunt around for these things but you
know i mean yum and aptitude both have really really fuzzy searches so you can you can find them
but you do have to be aware of what they're called how they're capitalized uh and the exact
you know naming scheme or else it it won't it won't realize that you're not you know you need to
be able to flag it you're flagging it for the user so that you're not trying to build something
against libraries and header files and stuff that don't actually exist so the requires line is
where you define that and then the next line is the description i put in a fairly long
description here simply because i could and then the next line is percent prep which is another one
of those little macros so that's doing a little preparation step and if you do an rpm build
that this you actually get to see what those little macros as it were um or placeholders or whatever
you want to call them what those actually do and the percent prep uh unzips or you know untars
the source directory and then i think and then the percent setup does something else so those
are presets that you almost don't even have to think about they're just they're two common steps
that almost every time you're doing an rpm you're gonna be doing that unless i don't know for some
reason you don't have to uncompile the source or something like that next step is percent build
and the build step that we want to define here normally would be dot slash configure and then make
in this case we do not do that because of that line in slack build in the slack build that i
wrote myself that i'd forgotten when i was doing the rpm that the install script that are that
that sigflup uses for a normal sort of command line e kind of install doesn't quite work the way
that rpm or slack build or port actually wanted it to work so you um would just do a dot slash
configure here and then under the install step we're going to remove the rpm build root and we do
that forcefully and recursively because we don't want any old versions of our build lying around
and then we'll make a directory in the rpm build root and the new one that we're going that we're
making right now slash usr slash bin so the rpm build root is a standard variable for slash
bar slash temp slash percent name dash build root and we define that up up at the top of the script
if you'll if you'll look up there right above the license in the summary you'll see the build
being defined so that's where the rpm build root is we've just made that and we've made two
directories inside of it a slash usr and a slash bin then we do a make install but we define the
prefix as being as as equaling the rpm build root slash usr and that ensures that the binary that
we're building is being sent to the prefix of the rpm build root slash usr and that that's a little
bit of a hack due to the the the the the the make file and the install script that sigflup wrote
into her program not a problem just something to be aware of and again it's kind of one of those
things that makes it fun if you go and do an rpm build for instance of w get or something like that
that's just really pretty straightforward then you might even have you might even find it even
more clear in a way because it's really just a replicate it's it's exact it's just like
compiling the thing from source except you're kind of outlining it a little bit more you know you're
you're telling another application to do those steps and you're just making sure that it's doing
those steps and sending the results into a certain directory in this case as I've said rpm build
root slash usr is our starting point so then we do a clean step and again on the slack build we
did the same thing if you remember at the very end of the script after we did the install we do a
little bit of clean up pretty common it's pretty pretty nice and the step that we actually do
is that we get rid of the rpm build root why would we do that well it's because the install step
includes grabbing everything from the rpm build root and dumping it into the appropriate files
here in our rpm build directory when I first saw that I was very very confused as to why we were
removing something so soon I I didn't have that line in there at all because I kept swearing that
surely would take everything that I've just created and delete it because I was still thinking
very much in slack build terms where you've just built this package in slash temp slash spo and so
we need to still go into that package and and do the make pkg step right we can't we can't remove
that yet well we can because you're not in this spec file you're not seeing everything that's
actually happening that'll become really clear in a minute once we once we run the actual rpm build
script so we just cleaned up after ourselves that's nice and then we'll do a percent files this
is actually really important this isn't just nice this is something that rpm needs in order to or
rpm build needs in order to make sure that everything you want in the package itself makes its way
into that package so it's percent files and then percent deaf ATTR so defining attributes as
a parentheses dash comma root comma root is closed parentheses so again just like in slack builds we
are taking everything that we've just built and we've choned it essentially to root root why well
because this is a package it belongs to root this is the root domain they take packages and they
install it under the system and they shouldn't be owned by other users by other random users that
might not even exist on that machine for instance so that's a good step to do and then the next
line is the first file that we want included in the rpm which is slash us slash bin slash yes please
and then we've got a percent dock and again that's another little macro see because it now it's
going to automatically make all the little document documentation directories in our package for us
so we don't have to worry about that so percent dock space read me space shouts because she has a
file in there called shouts where she shouts gives shout out shout outs to various people and that's
really it that's the spec file it's pretty much that simple so the only other thing that we need to do
which in real life I think we would have already done at this point but we need to go into the
sources directory and we need to double you get the source and the source of course lives somewhere
on a server which I will have to include in the show notes but you might already have it from the
last episode as well if you did if you followed along with the last episode at all you might still have
that dot tgz now the one thing that we have to do for the rpm that we didn't do for the slack build
but that I do have to do for the port file as well is change the name of her source directory
and change the name of what it untires to this is a little i mean like we can do this because this is
an example this is sigflup we know sigflup we all love sigflup we can change the pack the source
package name it's fine if this was something that was coming if some monolithic application coming
from some organization that you might not have complete say over how that package gets named we
might have to do that with some kind of extra script slack build has an allowance for that sort of
thing rpm has an allowance for that all the packaging formats will let you do that I I'm not doing
anything like that for yes please I've had to do it before for lives the the video editor for a
slack build I had to change the name that it because it unzipped to something other than what it
was zipped up as which wreaks havoc on your packaging script because you you're telling it okay the
name of this program is lives or yes please with a capital Y and a capital P but then once I unzip
it suddenly the name becomes different well that doesn't work because now the script doesn't recognize
it anymore so in this case we're going to just cheat and we're going to do a tar dash xf yes please
underscore aug underscore four twenty ten dot t gz and we see that it does indeed unzip two yes please
underscore aug four twenty ten but we're going to move yes please underscore aug two yes please
dash aug underscore four underscore twenty ten dot well not dot anything twenty ten so now we've
just made that directory have a dash after the name because remember last time I said that there
was that convention of the program archive being or the package being called the program name dash
the version number dot compression so in this case we're giving it a dash because that's what rpm
assumes your package is going to be named that's the scheme it is assuming so the yes please
becomes the name the aug four twenty ten becomes the version string and then dot t gz is the
compression so that that fits the convention now now let's zip it back up so word or tar back up
so we'll do a tar dash cf create file yes please dash aug underscore four underscore twenty ten so
we're keeping the dash dot t gz of course the file the folder that we're doing this to is yes please
dash aug underscore four underscore twenty ten that creates our tar and then we need to zip that up
so we'll just do a gzip yes please dash aug four twenty ten dot tar and that gives us a
tar dot gz and then let's just rename that to yes please dash aug underscore four underscore twenty
ten dot t gz so that we have exactly what sigflup gave us except one little dash is different but
I don't even think she's going to notice so now we've got our sources living in till the slash rpm
build slash sources and then slash yes please dash aug underscore four underscore twenty ten dot t gz
and we've got a spec file over in our specs folder in the same rpm build now that is all we need
that's that's the structure of your pre built rpm creation of course there are other files that
you can include if you need to lots of different options with this sort of thing but this is the
basic so now we need to issue a command the actually the command called rpm build and that's what we
um that's what we downloaded with those dev tools the rpm dev tools so we've got rpm build space
dash b a or dash b b and I'll tell you the difference in a moment space yes please dot spec
well actually we're not in spec so let's do dot slash specs slash yes please dot spec there
so we've just passed the rpm build command with the option of dash b a which means to build
all meaning build a binary distribution as well as a source distribution so we're going to have
two different rpm at the end of this process if we if we press return now and then of course the
space dot slash specs slash yes please dot spec is the path to the spec file because the spec file
is the thing that rpm build looks to on how it should be run now if you don't care about the
source package i don't know why you wouldn't for this particular program because it's so small
and it takes no time to compile it but if you are doing binary builds and you don't care about
the source rpm then you don't have to do a dash b a you can do a dash b b and that will build
only the binary rpm package so it's it's up to you and it kind of depends on what you're building
so anyway you press enter now on that and it goes through the spec file and you can as I say
now that we've no we know all the little macros that we put into our spec file we can actually see
what that's being translated into you might have to scroll up for it but you get the information
and you can see where we said percent prep it's untarring the thing and when we said
percent set up it's doing something else and when you said percent install it's actually
moving files around all over the place so there's there's a lot of other stuff going on that you
didn't actually write here and that threw me off a little bit too because again I was pretty
used to slack builds where the only thing that happened was exactly what I wrote with the exception
of that make pkg step at the very very end but then that's make pkg i mean who doesn't know that
so there's an rpm now but where is it well it could be of one one of two places one will be in
the slash for the if if you're in rpm build and dot slash rpm's all capital and then you'll see
in there there's an x86 underscore 64 or you might be on a different machine so it might be an i
486 or 586 rather whatever go into that folder and you'll see that sure enough there's your
nice new rpm along with a debug info version of it as well I don't need debug info there's no
bugs in sigflips applications so there we go if if we did right now we switched over to root
and we said rpm-u capital u vh dot slash rpm's x86 underscore 64 yes please dash august
asterisk rpm and did that then it installs it without any problems now of course if this is a
if this were a real fresh install which I admit for this episode I didn't actually set one up but
when I did set one up for the actual rpm it it erred out it said well you I can't do this
because you don't have lib x11 built and you don't have lib jpeg or the development files for those
so I had to go back through and do a young install of those development files now there's a way
that you can define you can differentiate between a library or an application that it needs to build
versus an application that it needs to run so that you know if the user has a library not installed
but it doesn't actually need that library to build itself then you could let it keep you could
let it do you could let it compile but it wouldn't run or you can say well look both of these are
the same are essentially the same we we need both you know you need all of these different libraries
or whatever in order to build and to run and I'm not going to let you do anything until you have
those it's all up to you and how you think this packaging thing is to be done okay so back to our
our our our little folder here so if I'm getting out of route now so now if I do an ls on dot slash
s rpm s then you see that there's a single rpm in there and that's a source rpm so it's yes please
dash org for twenty ten dash one dot src dot rpm meaning that when someone goes to build that
they're it's going to build the code it's going to build it from source the more common one is an
rpm binary you know I mean that's kind of what rpm's are are known for there that's a binary
distribution they they they give you the binary that just simply gets extracted from the rpm and
sprinkled across your file system and suddenly you're running the application and you know
honestly that's about it for rpm so I mean that's that's how they're made and that is how they are
actually constructed and that's where they get dumped too and what more can I say that's rpm
so rpm dash capital U underscore I mean lowercase v lowercase h space name of rpm dot rpm
that's the install command if you ever want to then remove that package then it would be rpm
space dash e for erase name of that package and then it will erase the really all traces of that
application from your system provided that other things haven't come along and started
depending on you know yes please if someone creates a file a new application called more more more
more and that requires yes please in order to run then okay you're going to need both of those
things on your your system of course there are a number of great great tutorials online there
there's I there's a an entire book on the subject I think it's called maximum rpm or something
like that and and there's just a lot of great info all the different kinds of things that you can
do that definitions for all those little shortcuts those macros that you're that you can use to
to simplify your spec file for yourself and of course I mean rpm's can call other rpm's via
yum so it can get pretty complex and pretty pretty cool rpm's are fairly common on the interwebs
finding an application that does not yet have an rpm associated to it might be a little bit
difficult heck there are even source code files sometimes that ship with a spec file included
and you can actually build the the rpm from the spec file that the that the developer wrote for
you you know I mean it's rpm's are pretty pretty popular I don't know how much in need they are
of of people to create new rpm's for applications that people are just dying to have however
I do think that finding something that may might be not quite up to date or something like that and
and offering to help maintain that package and keep it up to date that could be something you
might want to get into so the first step is obviously just to to build rpm's for yourself to
learn that and then once you've gotten pretty comfortable with it you can take on larger
applications and try to build applications that are a little bit more complex than for instance
yes please or w get I'll try to have some links in the show notes on different tutorials online
and have a good time with that and as always thank you very much for listening next episode we're
going to cover bsd port system and we'll build one for yes please
you have been listening to Hacker Public Radio or Hacker Public Radio does our
we are a community podcast network that releases shows every weekday Monday through Friday
today's show like all our shows was contributed by an hbr listener like yourself
if you ever consider recording a podcast then visit our website to find out how easy it really is
Hacker Public Radio was founded by the digital dog pound and the infonomicum computer club
hbr is funded by the binary revolution at binref.com all binref projects are proudly sponsored by
linear pages from shared hosting to custom private clouds go to lunar pages.com for all your hosting
needs on list otherwise stasis today's show is released on the creative commons attribution share
and I take those own license