|
Size: 3407
Comment: nightly builds are now disabled
|
← Revision 10 as of 2023-11-14 09:37:58 ⇥
Size: 4759
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## Please edit system and help pages ONLY in the master wiki! ## For more information, please see MoinMoin:MoinDev/Translation. ##master-page:Unknown-Page ##master-date:Unknown-Date #acl AdminGroup:read,write,revert All:read #format wiki #language en |
|
| Line 2: | Line 10: |
== Getting a backtrace == Let's say you've found a way to crash XBMC. If you can make it crash reliably, even better. In addition to XBMC's own log file, the other piece that will help is a backtrace. XBMC has a lot of pieces that could crash: a problem in the display driver, a problem in a codec, a problem in XBMC core, or a problem in the addons. A backtrace allows developers to see exactly where the crash occurs. To get a backtrace, you'll need to install Fedora's debuginfo packages for XBMC and its dependencies. This allows your debugger to give meaningful information in the backtrace. Open up a terminal, get root, and run: {{{ debuginfo-install xbmc }}} The debuginfo-install command will use yum to install a slew of -debuginfo packages on your system. (Don't worry, you can clean them up after you're done if you care about disk space.) Next, ensure that you have gdb installed: {{{ yum install gdb }}} Next, as an unprivileged user (not root), start xbmc via GDB: {{{ gdb -ex run /usr/lib64/xbmc/xbmc.bin }}} XBMC will launch inside GDB. Now navigate to your video or do whatever you do to replicate the crash. After the crash, look again at your terminal. GDB should drop you at a "(gdb)" prompt. You should type a couple commands: {{{ (gdb) set pagination 0 (gdb) set logging on (gdb} thread apply all bt full 10 }}} You will now have a "gdb.txt" file in your current working directory. Upload that file to your bug in Bugzilla. |
|
| Line 5: | Line 54: |
| NOTE: nightly builds are disabled because I need web hosting. If you have server space available with HTTP access, please let me know. Unfortunately since XBMC bundles ffmpeg, I can't host these on fedorapeople.org. (Thank you to Brian Faris for being willing to hosting the nightlies build infrastructure through 2013.) | NOTE: nightly builds are disabled because I have not had time to resurrect them. |
| Line 7: | Line 56: |
| Nightly packages from xbmc's master Git branch are available at [[http://xbmc.ktdreyer.com]]. | Nightly packages from xbmc's master Git branch are available at (removed). |
| Line 9: | Line 58: |
| To use these builds, download [[http://xbmc.ktdreyer.com/fedora/xbmc-nightly.repo]] to /etc/yum.repos.d/ and run "yum update xbmc". To get back to RPM Fusion's official XBMC package, run "yum --disablerepo=xbmc-nightly downgrade xbmc" | To use these builds, download [[http://(removed)/fedora/xbmc-nightly.repo]] to /etc/yum.repos.d/ and run "yum update xbmc". To get back to RPM Fusion's official XBMC package, run "yum --disablerepo=xbmc-nightly downgrade xbmc" |
| Line 19: | Line 68: |
| To do a checkout with Git: | === Building from Git === To do a build from Git: |
| Line 22: | Line 73: |
| git clone git://fedorapeople.org/home/fedora/alexlan/public_git/xbmc-rpm.git | $ git clone git://github.com/mooninite/xbmc-rpm.git $ cd xbmc $ ./xbmc-generate-tarball-xz.sh $ md5sum xbmc-*-patched.tar.xz > sources $ fedpkg --dist f20 mockbuild --root fedora-20-x86_64-rpmfusion_free |
| Line 24: | Line 79: |
Use `fedpkg` inside the Git repo in order to do the build. Because RPM Fusion's infrastructure is not yet plumbed up together with dist-git and fedpkg, we can't use this command for real package maintenance, but it is useful for easily doing local mock builds. Maybe you're already familiar with mock and fedpkg... if so, great! If not, read over some of the relevant fedoraproject.org wiki pages. * https://fedoraproject.org/wiki/Projects/Mock * https://fedoraproject.org/wiki/Package_update_HOWTO * https://fedoraproject.org/wiki/Using_Fedora_GIT |
|
| Line 34: | Line 98: |
| The next step is to verify whether `xbmc-pvr-addons-generate-tarball-xz.sh` requires an updated hash value. It's possible that the upstream developers bumped the git sha-1 hash in your new version. If so, you'll need to update the hash and re-run the script. If not, you can just leave it as-is. Next, update the version in xbmc.spec, and I also like to use `fedpkg new-sources` to automatically update the .gitignore and sources files. It's ok if fedpkg complains about failure to upload, since RPM Fusion technically doesn't use fedpkg. |
Next, update the version in xbmc.spec. You will also need to put the md5sum of the new tarball into the `sources` file. You can run `md5sum xbmc-*-patched.tar.xz > sources`, but I like to use `fedpkg new-sources` to automatically update the .gitignore and sources files. (It's ok if fedpkg complains about failure to upload, since RPM Fusion's infrastructure technically doesn't use fedpkg.) |
| Line 41: | Line 102: |
| === Building from Git === Use `fedpkg srpm` inside the Git repo in order to get a new SRPM. As mentioned above, because RPM Fusion's not yet plumbed up together with fedpkg, you must then use mock directly in order to build that SRPM as a binary RPM. {{{ fedpkg srpm mock -r fedora-18-i386-rpmfusion_free rebuild xbmc...src.rpm }}} (make sure you have the `mock-rpmfusion-free package` installed) Once you're sure it builds on a couple platforms (like F18 and F19), then you get a patch with `git format-patch` and attach it to your bugzilla report. Maybe you're already familiar with mock and fedpkg... if so, great! If not, read over some of the relevant fedoraproject.org wiki pages. * https://fedoraproject.org/wiki/Projects/Mock * https://fedoraproject.org/wiki/Package_update_HOWTO * https://fedoraproject.org/wiki/Using_Fedora_GIT |
Once you're sure it builds on a couple platforms (like F19 and F20), then create a patch with `git format-patch` and attach it to your bugzilla report. |
XBMC in RPM Fusion
Getting a backtrace
Let's say you've found a way to crash XBMC. If you can make it crash reliably, even better. In addition to XBMC's own log file, the other piece that will help is a backtrace.
XBMC has a lot of pieces that could crash: a problem in the display driver, a problem in a codec, a problem in XBMC core, or a problem in the addons. A backtrace allows developers to see exactly where the crash occurs.
To get a backtrace, you'll need to install Fedora's debuginfo packages for XBMC and its dependencies. This allows your debugger to give meaningful information in the backtrace.
Open up a terminal, get root, and run:
debuginfo-install xbmc
The debuginfo-install command will use yum to install a slew of -debuginfo packages on your system. (Don't worry, you can clean them up after you're done if you care about disk space.)
Next, ensure that you have gdb installed:
yum install gdb
Next, as an unprivileged user (not root), start xbmc via GDB:
gdb -ex run /usr/lib64/xbmc/xbmc.bin
XBMC will launch inside GDB. Now navigate to your video or do whatever you do to replicate the crash.
After the crash, look again at your terminal. GDB should drop you at a "(gdb)" prompt. You should type a couple commands:
(gdb) set pagination 0 (gdb) set logging on (gdb} thread apply all bt full 10
You will now have a "gdb.txt" file in your current working directory. Upload that file to your bug in Bugzilla.
Nightly builds
NOTE: nightly builds are disabled because I have not had time to resurrect them.
Nightly packages from xbmc's master Git branch are available at (removed).
To use these builds, download http://(removed)/fedora/xbmc-nightly.repo to /etc/yum.repos.d/ and run "yum update xbmc". To get back to RPM Fusion's official XBMC package, run "yum --disablerepo=xbmc-nightly downgrade xbmc"
Note that these builds may be in various states of disrepair, or even altogether unusable. Be prepared to upgrade or downgrade as needed. You have been warned.
The build script that does this is available at https://gitorious.org/ktdreyer/xbmc-nightly.
Modifying and building a custom package
RPM Fusion uses CVS to manage the spec files and associated files for a package. To add to the complexity, Alex and Ken keep the canonical RPM spec in a separate Git repository, since Git is much easier to work with than CVS. We do all commmits to Git first, and then periodically sync that to CVS.
Building from Git
To do a build from Git:
$ git clone git://github.com/mooninite/xbmc-rpm.git $ cd xbmc $ ./xbmc-generate-tarball-xz.sh $ md5sum xbmc-*-patched.tar.xz > sources $ fedpkg --dist f20 mockbuild --root fedora-20-x86_64-rpmfusion_free
Use fedpkg inside the Git repo in order to do the build. Because RPM Fusion's infrastructure is not yet plumbed up together with dist-git and fedpkg, we can't use this command for real package maintenance, but it is useful for easily doing local mock builds.
Maybe you're already familiar with mock and fedpkg... if so, great! If not, read over some of the relevant fedoraproject.org wiki pages.
Doing an XBMC upgrade
Let's say RPM Fusion is shipping an older version of XBMC, and you want a newer version.
Clone the Git repo, and maybe even looking through the history of commits (git log -p), so you can see how we do each update.
The first step is to change the Git tag in xbmc-generate-tarball-xz.sh and re-run that script. That will download a tarball to your working directory and strip it of all the unneeded bits.
Next, update the version in xbmc.spec. You will also need to put the md5sum of the new tarball into the sources file. You can run md5sum xbmc-*-patched.tar.xz > sources, but I like to use fedpkg new-sources to automatically update the .gitignore and sources files. (It's ok if fedpkg complains about failure to upload, since RPM Fusion's infrastructure technically doesn't use fedpkg.)
Lastly, make a git commit (fedpkg commit -c) that updates everything to the latest version.
Once you're sure it builds on a couple platforms (like F19 and F20), then create a patch with git format-patch and attach it to your bugzilla report.