Note: I drafted this neglected post in Feb '07, and since I'm talking about the build service at the Mono Summit, I decided to post as is.
I'm trying out the build service with the intent of migrating as much of Mono's packaging as possible.
I first heard about this service at BrainShare 2006 and thought it looked really neat. They did a demo build from the web client.
I just discovered the command line client: osc, and it's amazing! You can do local builds of your projects for multiple distributions! Then you can makes changes, tweak your files, do a local test build, and then commit your changes to the server. The server will add your packages to the queue and create a repository for download.
The package build system that Mono uses has cut out a lot of the manual work with building packages. The problem with it is that no one else besides me can use the system to build packages. (Someone could, but it would require creating jails, setting up ssh authentication, etc...). The great thing about the build service is that anyone that is a maintainer on the package can test a local build and submit changes from their local machine.
I've always been impressed with SuSE's autobuild system. It allowed for local builds and submitting build jobs to be done on the build farm. This is fine for SuSE builds, but I was unable to utilize this service for Mono packaging because I needed to build on several non-SUSE distros.
The buildservice has solved that. There are a few remaining issues that I'll need to sort out before I can move completely over. First of all, only x86 and x86_64 is supported. Plus, I'll need to figure out how to make previous releases available in the build service. (I'm assuming I can create a new namespace for each release, but I haven't looked into this).
This will also give better testing on the various distros, since for Mono, we only build on a lowest common denominator distro and use it everywhere for that arch.
Good job on SUSE's part, and all I gotta say is, "Wow" :)
Thursday, November 15, 2007
Friday, July 13, 2007
Monobuild updates
During the latter part of this week I revamped monobuild to use the .spec files from SuSE's buildservice rather than using Ximian buildbuddy. This was a long overdue move. When our build machine's 700 GB disk crashed, I decided to dive in. There are some nice advantages to this:
It is interesting to note that there has been some talk of coming up with a cross linux distro xml description to be used in the buildservice. Kinda funny, since buildbuddy had the ability to build rpm and deb. Oh well...
One of the other monobuild features I finished up is the ability to build rpms on your local machine. Previously you could only build on a machine connected through ssh. It's not real user friendly to get this working, but it's possible. I mainly wanted to implement this to work toward to goal of enabling others to easily create the installers.
The easiest way to build local rpms is definitely with the suse buildservice. It rocks. In fact, it has replaced much of the functionality of monobuild. But, since the build service doesn't support all the platforms or distros that we build on, we'll continue to use monobuild for releases of those missing platforms. Monobuild also works great for continuously building from trunk. (There's no reason monobuild could use the buildservice tools to locally build out of trunk, but there hasn't been a need at this point.)
- I'm not using the obsolete buildbuddy
- I maintain only .spec files now instead of merging changes back and forth in buildbuddy
- Those spec files can be shared with monobuild, suse build service, and suse autobuild
- When setting up a new distro chroot, I don't have to rebuild buildbuddy with the new distro info
It is interesting to note that there has been some talk of coming up with a cross linux distro xml description to be used in the buildservice. Kinda funny, since buildbuddy had the ability to build rpm and deb. Oh well...
One of the other monobuild features I finished up is the ability to build rpms on your local machine. Previously you could only build on a machine connected through ssh. It's not real user friendly to get this working, but it's possible. I mainly wanted to implement this to work toward to goal of enabling others to easily create the installers.
The easiest way to build local rpms is definitely with the suse buildservice. It rocks. In fact, it has replaced much of the functionality of monobuild. But, since the build service doesn't support all the platforms or distros that we build on, we'll continue to use monobuild for releases of those missing platforms. Monobuild also works great for continuously building from trunk. (There's no reason monobuild could use the buildservice tools to locally build out of trunk, but there hasn't been a need at this point.)
Monday, July 2, 2007
Novell Hack Week
There are two technologies that I really want to use all the time:
PulseAudio
Xgl
The problem is that I run mythtv quite a bit, and myth doesn't work very well with either of the aforementioned pieces of software. As a result, I usually don't have PulseAudio nor Xgl running, because it's a pain to constantly switch them on and off.
So I decided to hack on mythtv for a week to fix this.
PulseAudio
Rationale:
In order to output to pulseaudio from MythTV, you have to use an oss emulation wrapper (padsp). Patch myth to have real pulseaudio support.
Results:
I took Monday to set up the myth development environment, set up my usb tuner on my laptop, and get the build infrastructure for PULSE output set up. By Tuesday morning I had unsynchronized audio/video going to the pulse server using the simple api. I assumed that by using this api, a/v would be out of sync. But by trying it out I was able to make sure of this, as well as get the basic framework implemented.
I read some pulse documentation about the asynchronous api, and before diving in, decided to look at fixing the alsa output support to see what that would take. It ended up being really simple to fix alsa: don't use mmap access to the sound device. In case there were objections for my patch because I didn't use mmap, the final patch tries to use mmap, but then falls back to non-mmap. I spent the rest of Tuesday and most of Wednesday reading ALSA documentation, doing the final patch and making some packman derived mythtv packages that included my patch: (which are hosted here , although I'm hoping this will get into the myth sources, so these packages will eventually disappear.)
Patch posted to the myth bug http://svn.mythtv.org/trac/ticket/3598 .
Fixing ALSA was also nice in the fact that no new dependencies were needed for myth. If for some reason there are additional benefits of implementing native pulse support, I might re-address this later.
Xgl
Rationale:
I usually don't run XGL because mythtv crashes Xgl when you try to display video. This needs fixing.
Results:
I figure that mplayer works under Xgl using XVideo just fine, and that Myth should be able to do the same.
MythTV has a branch called mythtv-vid where they are working on an OpenGL output driver. I spent a while installing this branch and getting the latest xgl and compiz-fusion running, just to make sure this problem wasn't fixed already. It wasn't, and I couldn't get the opengl output on myth working.
At this point I wondered if I should just drop this idea and wait for the mythtv-vid project to finish the GL out support. I decided to do some simple benchmarks with mplayer to compare gl out and xvideo out. This can be done by disabling sound and telling mplayer to spit out the frames as fast as possible. The xvideo out ended up being slightly faster. (This was using ATI's fglrx driver. It would be interesting to run the same test with some different video cards and drivers). That was Thursday and a little bit of Friday.
The rest of Friday morning I spent debugging the myth sources to find the crash. This went rather slowly because each testrun crashed Xgl and I had to constantly re-login. The crash is happening during some xvideo initializations. I've located the X calls that cause the crash, but that's as far as I got. I don't know enough about xvideo to debug this further, so I've got some more digging to do. That took me until about noon on Friday.
The next few hours were spent setting up another machine so that I could demo mythtv running on a computer with synchronized output to 2 computers. The demo was video taped, but it's kind of difficult to experience synchronized output with a video camera :) I finished the rest of the day debugging xgl a little more, but ended up not making any progress.
Conclusion
I have MythTV working with PulseAudio (even though it didn't quite happen as expected), and made some good progress towards finding out why MythTV crashes Xgl. The hack week was a blast and it seems like overall a lot of great progress was made. Can't wait for the next one!
Update! Lightning talk:
PulseAudio
Xgl
The problem is that I run mythtv quite a bit, and myth doesn't work very well with either of the aforementioned pieces of software. As a result, I usually don't have PulseAudio nor Xgl running, because it's a pain to constantly switch them on and off.
So I decided to hack on mythtv for a week to fix this.
PulseAudio
Rationale:
In order to output to pulseaudio from MythTV, you have to use an oss emulation wrapper (padsp). Patch myth to have real pulseaudio support.
Results:
I took Monday to set up the myth development environment, set up my usb tuner on my laptop, and get the build infrastructure for PULSE output set up. By Tuesday morning I had unsynchronized audio/video going to the pulse server using the simple api. I assumed that by using this api, a/v would be out of sync. But by trying it out I was able to make sure of this, as well as get the basic framework implemented.
I read some pulse documentation about the asynchronous api, and before diving in, decided to look at fixing the alsa output support to see what that would take. It ended up being really simple to fix alsa: don't use mmap access to the sound device. In case there were objections for my patch because I didn't use mmap, the final patch tries to use mmap, but then falls back to non-mmap. I spent the rest of Tuesday and most of Wednesday reading ALSA documentation, doing the final patch and making some packman derived mythtv packages that included my patch: (which are hosted here , although I'm hoping this will get into the myth sources, so these packages will eventually disappear.)
Patch posted to the myth bug http://svn.mythtv.org/trac/ticket/3598 .
Fixing ALSA was also nice in the fact that no new dependencies were needed for myth. If for some reason there are additional benefits of implementing native pulse support, I might re-address this later.
Xgl
Rationale:
I usually don't run XGL because mythtv crashes Xgl when you try to display video. This needs fixing.
Results:
I figure that mplayer works under Xgl using XVideo just fine, and that Myth should be able to do the same.
MythTV has a branch called mythtv-vid where they are working on an OpenGL output driver. I spent a while installing this branch and getting the latest xgl and compiz-fusion running, just to make sure this problem wasn't fixed already. It wasn't, and I couldn't get the opengl output on myth working.
At this point I wondered if I should just drop this idea and wait for the mythtv-vid project to finish the GL out support. I decided to do some simple benchmarks with mplayer to compare gl out and xvideo out. This can be done by disabling sound and telling mplayer to spit out the frames as fast as possible. The xvideo out ended up being slightly faster. (This was using ATI's fglrx driver. It would be interesting to run the same test with some different video cards and drivers). That was Thursday and a little bit of Friday.
The rest of Friday morning I spent debugging the myth sources to find the crash. This went rather slowly because each testrun crashed Xgl and I had to constantly re-login. The crash is happening during some xvideo initializations. I've located the X calls that cause the crash, but that's as far as I got. I don't know enough about xvideo to debug this further, so I've got some more digging to do. That took me until about noon on Friday.
The next few hours were spent setting up another machine so that I could demo mythtv running on a computer with synchronized output to 2 computers. The demo was video taped, but it's kind of difficult to experience synchronized output with a video camera :) I finished the rest of the day debugging xgl a little more, but ended up not making any progress.
Conclusion
I have MythTV working with PulseAudio (even though it didn't quite happen as expected), and made some good progress towards finding out why MythTV crashes Xgl. The hack week was a blast and it seems like overall a lot of great progress was made. Can't wait for the next one!
Update! Lightning talk:
Friday, June 29, 2007
PulseAudio
Like Linux needs any more sound libraries/backends... but this one is cool!
PulseAudio has been compared to the 'compiz' of audio streams.
You can do some really cool things with it: output all sound to another machine, play synchronous audio to multiple clients on a lan, move streams from one sink to another on the fly, virtual surround sound using two soundcards, stream and application specific volume adjustments. (Plus, using avahi, sound servers on the network are automatically discovered.) They may seem like useless esoteric cases, but here are some practical things I use it for:
I've got a few computers in my house. It's cool being able to have banshee playing on one machine, and the output going to all the speakers in the house, all synchronized.
I have two computers side by side that I use in a kvm fashion. One of the computers has much nicer speakers. I mostly use the computer that doesn't have nice speakers. I can have all the sound go through the nice speakers, and I don't have to plug and unplug things all the time.
I like to watch movies on a laptop to have the screen closer. Instead of plugging some speakers in the laptop and having wires all over, I play the sound through the computer's nice speakers.
Some of the computers I have use soundcards with only one sound channel. (Alsa dmix can mix streams into one, but PulseAudio can do the same, as well give me all the above features. Plus, I don't have to worry about dmix not playing well with certain alsa drivers.)
Not all the Pulse utils are shipped in openSUSE 10.2, but Takashi has packaged most everything up to be included in 10.3. (Check here for packages to use in 10.2 and 10.3). The only packages remaining at this point are gstreamer010-pulse and libflashsupport, which supports pulse output for Flash 9. These are both available in the build service.
Seems like a great sound solution and a wonderful fix of all sound mixing nightmares linux users have had to face over the years. I wish Gnome and openSUSE would configure PulseAudio by default and configure all the shipped applications to output in a pulseaudio compatible way (See Pulse Audio Perfect Setup for what apps and backends can and need to be configured).
Lennart gave a great presentation showing off and advocating PulseAudio:
Video Presentation
Slides
(In actuality, this blog posting has been in draft mode for a while, but since my 'Hack Week' project involved PulseAudio, I needed to finish this post first.)
PulseAudio has been compared to the 'compiz' of audio streams.
You can do some really cool things with it: output all sound to another machine, play synchronous audio to multiple clients on a lan, move streams from one sink to another on the fly, virtual surround sound using two soundcards, stream and application specific volume adjustments. (Plus, using avahi, sound servers on the network are automatically discovered.) They may seem like useless esoteric cases, but here are some practical things I use it for:
I've got a few computers in my house. It's cool being able to have banshee playing on one machine, and the output going to all the speakers in the house, all synchronized.
I have two computers side by side that I use in a kvm fashion. One of the computers has much nicer speakers. I mostly use the computer that doesn't have nice speakers. I can have all the sound go through the nice speakers, and I don't have to plug and unplug things all the time.
I like to watch movies on a laptop to have the screen closer. Instead of plugging some speakers in the laptop and having wires all over, I play the sound through the computer's nice speakers.
Some of the computers I have use soundcards with only one sound channel. (Alsa dmix can mix streams into one, but PulseAudio can do the same, as well give me all the above features. Plus, I don't have to worry about dmix not playing well with certain alsa drivers.)
Not all the Pulse utils are shipped in openSUSE 10.2, but Takashi has packaged most everything up to be included in 10.3. (Check here for packages to use in 10.2 and 10.3). The only packages remaining at this point are gstreamer010-pulse and libflashsupport, which supports pulse output for Flash 9. These are both available in the build service.
Seems like a great sound solution and a wonderful fix of all sound mixing nightmares linux users have had to face over the years. I wish Gnome and openSUSE would configure PulseAudio by default and configure all the shipped applications to output in a pulseaudio compatible way (See Pulse Audio Perfect Setup for what apps and backends can and need to be configured).
Lennart gave a great presentation showing off and advocating PulseAudio:
Video Presentation
Slides
(In actuality, this blog posting has been in draft mode for a while, but since my 'Hack Week' project involved PulseAudio, I needed to finish this post first.)
Tuesday, February 13, 2007
Switch User in openSUSE 10.2
Being able to switch users without logging out has been a long lost favorite. Here's how to enable the "Switch User" button on the gnome screensaver for suse 10.2:
gconftool-2 --set --type bool /apps/gnome-screensaver/user_switch_enabled true
Taken from:
http://lists.opensuse.org/opensuse/2006-12/msg01947.html
Very very handy when Cheryl and I use the same computer.
gconftool-2 --set --type bool /apps/gnome-screensaver/user_switch_enabled true
Taken from:
http://lists.opensuse.org/opensuse/2006-12/msg01947.html
Very very handy when Cheryl and I use the same computer.
Thursday, January 18, 2007
Firmware updates without a floppy
I've had to do some firmware updates lately. This isn't a very friendly process being a linux user (unless the manufacturer provides bootable iso images).
The firmware I needed to install came as a win32 self-extracting 'create a set of boot floppies' program. As I started running the program, I realized that the only windows box I had access to at the moment didn't have a floppy drive. Ugh. Searching led me to find this virtual floppy driver:
http://chitchat.at.infoseek.co.jp/vmware/vfd.html
It worked like a charm. I ended up with a floppy image file. After some more searching I found out how to create a bootable iso image from this floppy image:
http://www.troubleshooters.com/linux/floppy_image_on_cd.htm
From this article:
* As root, make sure there's a /mnt/test directory
* As root, mount -o loop,ro /scratch/linuxinst/m91inst/images/network.img /mnt/test
* The remainder of the steps are done as a regular user
* mkdir /tmp/floppycopy
* cp -Rp /mnt/test/* /tmp/floppycopy
* cp -p /scratch/linuxinst/m91inst/images/network.img /tmp/floppycopy
* mkisofs -pad -b network.img -R -o /tmp/cd.iso /tmp/floppycopy
* cdrecord dev=0,3,0 speed=12 blank=fast -pad -v -eject /tmp/cd.iso
It actually worked. It would be nice if all manufacturers provided bootable iso images for all their updates.
Sidenote: Be careful when updating the cd drive's firmware using a cd. IBM had a bootable iso image to update the cd's firmware which worked fine, but in my case, using an image on a cd that was designed for a floppy didn't work. Luckily running it again from a floppy fixed the drive.
The firmware I needed to install came as a win32 self-extracting 'create a set of boot floppies' program. As I started running the program, I realized that the only windows box I had access to at the moment didn't have a floppy drive. Ugh. Searching led me to find this virtual floppy driver:
http://chitchat.at.infoseek.co.jp/vmware/vfd.html
It worked like a charm. I ended up with a floppy image file. After some more searching I found out how to create a bootable iso image from this floppy image:
http://www.troubleshooters.com/linux/floppy_image_on_cd.htm
From this article:
* As root, make sure there's a /mnt/test directory
* As root, mount -o loop,ro /scratch/linuxinst/m91inst/images/network.img /mnt/test
* The remainder of the steps are done as a regular user
* mkdir /tmp/floppycopy
* cp -Rp /mnt/test/* /tmp/floppycopy
* cp -p /scratch/linuxinst/m91inst/images/network.img /tmp/floppycopy
* mkisofs -pad -b network.img -R -o /tmp/cd.iso /tmp/floppycopy
* cdrecord dev=0,3,0 speed=12 blank=fast -pad -v -eject /tmp/cd.iso
It actually worked. It would be nice if all manufacturers provided bootable iso images for all their updates.
Sidenote: Be careful when updating the cd drive's firmware using a cd. IBM had a bootable iso image to update the cd's firmware which worked fine, but in my case, using an image on a cd that was designed for a floppy didn't work. Luckily running it again from a floppy fixed the drive.
Monday, January 15, 2007
New Blog Location
Seems like about a year ago I was migrating services to my little server. Now I'm heading in the opposite direction and trying to migrate services off of it. I guess I shouldn't give my wife such a hard time for wanting totally different wall colors than she did 2 years ago :)
Couple of reasons for doing so:
I didn't have that many blog posts for the previous site so I copied and pasted them over.
There weren't that many comments on the old site so I simply pasted them in right along with the post.
Maybe I'll blog more now... maybe not. But this will be it's home until the "Google goes Evil" prophecies start to come true (outrageous advertising, fees, etc...), then maybe I'll return to my original color choices.
Couple of reasons for doing so:
- The power has gone out a few times in the last year, and I'd rather not worry about availability, especially when I can get this blog for free.
- For the first time in 2 1/2 years, my qwest dsl was down for a day. I'm not sure exactly how the outage was since I was out of town, but again, I'd rather not worry about it. Plus, I only had < 1 Mbps upload capacity.
- I didn't really feel like keeping wordpress updated or tracking their security vulnerabilities. (wordpress, or any blog hosting software, doesn't ship in openSUSE)
- Most importantly, it seems to be a nice time to follow suit in migrating blogs.
I didn't have that many blog posts for the previous site so I copied and pasted them over.
There weren't that many comments on the old site so I simply pasted them in right along with the post.
Maybe I'll blog more now... maybe not. But this will be it's home until the "Google goes Evil" prophecies start to come true (outrageous advertising, fees, etc...), then maybe I'll return to my original color choices.
Subscribe to:
Posts (Atom)
