Archive for the ‘packages’ Category.

Shooting An Iceray

So I am working on learning a few things, all at the same time. The coolest thing is Go, the “programming environment that makes it easy to build simple, reliable, and efficient software” from Google. But I’m also playing with GitHub, as the whole environment can be tightly integrated with it. And so, by extension, I’m playing with Git. More on all of those at a later, probably over on my Daemon Dancing In The Dark more generalized Linux blog.

Anyway, I’m working on a program I call Iceray. It is a command line application that will send MP3 files to an Icecast / Shoutcast server, like my Vehement Flame radio station. I wanted something I could run that would just feed the server without me handholding it.

So I went to work on packaging it up and finally got a PKGBUILD to work. I spent way too much time working on it, especially when it turned out the Go Packing Guidelines wiki page is pretty good. The sample PKGBUILDs should have worked better for me, but I got a few of my streams crossed which took me out of my game for a bit.

The first thing was actually in my Go program. I changed all the package declarations to be ‘package iceray’, not realizing that if it isn’t ‘package main’ it will build a library and not an application. And I also had the _gourl in my PKGBUILD wrong, in that I originally created it as a Git package, so I had the git: protocol in there.

And the page is still a little confusing, in that I needed to use a combination of the sample PKGBUILDs. While iceray in the end boils down to an application, I still found it necessary to use ‘go get‘ in the build() routine, because I don’t think ‘go build‘ pulls in the necessary remote libraries (I use go-libshout, gcfg, and go-id3). And the application ones use the path “$srcdir/$pkgname-$pkgdir”, but “$srcdir” worked just fine for me. So here’s the final PKGBUILD:

# Contributor: Jonathan Arnold <jdarnold@buddydog.org>

pkgname=iceray
pkgver=0.2
pkgrel=2
pkgdesc="Icecast/Shoutcast commandline client"
arch=('i686' 'x86_64')
url="https://github.com/jdarnold/iceray"
license=('MIT')
depends=('libshout')
makedepends=('go')
conflicts=('iceray')
provides=('iceray')
options=('!strip' '!emptydirs')
_gourl="github.com/jdarnold/iceray"
install=${pkgname}.install

build() {
    cd "$srcdir"
    GOPATH="$srcdir" go get -v -x ${_gourl}/...
}

package() {
    install -Dm755 "$srcdir/bin/$pkgname" "$pkgdir/usr/bin/$pkgname"
    install -Dm644 "$srcdir/src/$_gourl/iceray.gcfg.sample" "$pkgdir/usr/share/$pkgname/iceray.gcfg.sample"
    #install -D -m644 iceray.1 $(DESTDIR)$(MANPREFIX)/man1/iceray.1
}

So, in the end, the PKGBUILD was pretty simple, despite my flailing about. Hope this helps someone else!

AUR (en) – iceray.

gcc-libs / gcc-libs-multilib conflict

My morning updating ritual was interrupted by an annoying question from pacman:

$ packer -Syu
:: Synchronizing package databases...
core 106.7 KiB 650K/s 00:00 [######################] 100%
extra 1422.5 KiB 1151K/s 00:01 [######################] 100%
community 1786.4 KiB 927K/s 00:02 [######################] 100%
multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
:: gcc-libs and gcc-libs-multilib are in conflict. Remove gcc-libs-multilib? [y/N] ^C

That’s no fun. I can’t be removing gcc-libs or things will be blowing up. But why is it asking me to remove gcc-libs-multilib anyway? As a multilib dependent 64bit OS user, I can’t replace that. Luckily, I happened to check the forums this morning and someone else ran into this same problem. Turns out that for me, anyway, I had a tool that still relied on gcc-libs, as I hadn’t replaced it with its -multilib doppleganger. In my case, I had libtool and I should have had libtool-multilib. Not sure exactly how I got in that state. You wouldn’t think it would let me replace gcc-libs with gcc-libs-multitool if there were things that depended on it. But I guess it says it provides ‘gcc-libs’, so libtool was happy. But when it came time to upgrade, it wanted to use gcc-libs.

So to fix it I merely installed libtool-multilib, allowing it to replace libtool. Then my upgrade went as planned, as there wasn’t anything asking for gcc-libs any more.

Here’s the list brain0 posted in the forums, saying if you replace one of them with its multilib compatriot, you need to replace them all:

inutils-multilib
gcc-ada-multilib
gcc-fortran-multilib
gcc-go-multilib
gcc-libs-multilib
gcc-multilib
gcc-objc-multilib
libtool-multilib

conflict between gcc-libs / gcc-libs-multilib (gcc-objc related) (Page 1) / Pacman & Package Upgrade Issues / Arch Linux Forums.

iedit for Emacs

Just added a new package to the AUR for iedit, which is a pretty cool mode for Emacs to edit in place a bunch of regions containing the same text. See this post by Mastering Emacs for some usage and a nice little defun to narrow the changes to the current defun:

IEDIT: INTERACTIVE, MULTI-OCCURRENCE EDITING IN YOUR BUFFER

AUR (en) – emacs-iedit-git.

AUR – bootchart

Now this looks like a pretty cool package. Set bootchart up in your boot process and it tracks everything that happens. After you’ve logged in, you can run a utility that will generate a nice little chart, showing what and when for your boot up. There’s a very nice ArchWiki page for it (natch).

One caveat is that the project itself (bootchart.org) hasn’t been updated in like 5 years. But I guess if it works, it works. I’ll give it a try and post my picture here. Maybe I can then figure out why some daemons fail at startup…

AUR (en) – bootchart.

mimeo

Mime handling is always confusing, esp. in regards to file associations. I currently have a couple broken ones, like the fact that launchy opens all my desktop shortcuts in emacs :( If I click on them in my file manager (Thunar), they open fine.

Anyway, the prolific Xyne has a new package called ‘mimeo’ that offers to help. I’m going to give it a try.

mimeo

Yapan – Yet Another Package mAnager Notifier

I installed Yapan the other day and have been really happy with it. It sits in the notifier area of my tint2 window in my Openbox window manager and periodically checks to see if any packages have been updated. I’m pretty good about running my update once a day, but this is kind of fun too.

I set it up to use my package manager of choice, bauerbill, thusly:

Synchonize: sudo bauerbill -Sy
Packages to update: bauerbill -Qu
Update: sudo bauerbill -Su

Because bauerbill is a command-compatible with pacman, it works like a charm and includes checking the AUR for updates too.

otsug / Yapan / wiki / Home – Bitbucket.