bitmath is a Python module I wrote for working with file size units (ex: 12GiB
, 64kB
) as objects. You can use them just like you would use regular numbers in python. It’s full of other functionality as well. Objects have native ‘convert to $unit‘ methods, support native arithmetic, are sortable, and include a ‘best human readable prefix’ method.
Since March 2014, bitmath had only been available via PyPi and Fedora/EPEL repositories. Now, as of July 2nd 2016, bitmath is natively available to Ubuntu users by means of a new Personal Package Archive (PPA) hosting bitmath builds for Xenial, Wily, Vivid, Trusty, and Precise.
Ubuntu users can install bitmath in the following way:
Ubuntu support wouldn’t have happened if GitHub user hkraal hadn’t submitted an issue. Thanks Henk for getting the fire lit!
In my experience, the best way to learn about how to package RPMs is to look at how other people package RPMs. That means looking at lots of spec files. Sure fedpkg
will let you clone lots of package repos, but what if you only have the SRPM? You can get the spec file out of a SRPM, but it takes a little work with cpio
, a tool with so many options that I can never remember the exact invocation. So I wrote a quick two-liner to save me some aggravation:
#! /bin/sh
spec=$(rpm -qlp $1 | grep -E '\.spec$')
rpm2cpio $1 | cpio -i --to-stdout $spec
And how can you get the SRPM? Simple, install yum-utils
then run
$ yumdownloader --source --downloadonly PACKAGE_NAME
I use mock frequently when I am building packages for Fedora. Koji is great, but mock really shines when you are rapidly iterating over spec file changes. The --no-clean
option keeps the chroot around so you don’t have to download packages repeatedly and you can actually look around inside the chroot to see where a build is going wrong if you need to.
I also use repoquery a lot to see what a package requires or provides. Knowing what a package requires or provides is especially helpful when you’re doing builds. By default repoquery runs against the repos in /etc/yum.repos.d
. Wouldn’t it be nice if we could run repoquery against the repos set up in our mock configs?
It turns out that you can. Repoquery takes a --repofrompath
argument that can be used to create an ad hoc repo to query. The only missing piece is reading the mock config, grabbing the repo URL, and formatting it.
I wrote a little Zsh function to do just that.
#! /bin/zsh
mock-repoquery() {
local profile="$1"
[ -f "$profile" ] || profile="/etc/mock/${1}.cfg"
# Take all baseurls in a file and make them into an array
# See Parameter Expansion Flags section of the zshexpn man page and
# http://unix.stackexchange.com/a/29748
local repo_urls
repo_urls=("${(@f)$(sed -n -r 's/.*baseurl=(.*)(\\n|$)/\1/p' $profile | cut -d'\' -f1)}")
local repo_args
repo_args=()
for ((i=1; i <= ${#repo_urls}; i++)); do
repo_args+="--repofrompath=r${i},$repo_urls[i]"
repo_args+="--repoid=r${i}"
done
repoquery "${repo_args[@]}" "$@[2,-1]"
}
mock-repoquery "$@"
Drop the above code into ~/.zfunc/mock-repoquery
and then add the following to ~/.zshrc
fpath=( ~/.zfunc "${fpath[@]}" )
autoload -Uz mock-repoquery
Then you can use mock-repoquery
by passing a mock profile as the first argument. Any additional arguments will be forwarded to repoquery. For example:
$ mock-repoquery /etc/mock/fedora-20-x86_64.cfg --requires tig
git
libc.so.6(GLIBC_2.15)(64bit)
libncursesw.so.5()(64bit)
libtinfo.so.5()(64bit)
rtld(GNU_HASH)
Note that mock-repoquery
will only work in Zsh due to my usage of Zsh parameter expansion. Converting this function to work in Bash is possible, but I use Zsh so I didn’t bother. Patches will be accepted happily!