Wanted: Linux Binary Download

• Oct 18, 2008 - 20:43

Is there a good reason why you don't provide .deb files for the prereleases or at least for the current version as you provide .exe for windows? I like the new features and improvements in every new version but I really don't like to compile it every time, because it's consuming much time... Also tons of -dev libs are needed to build mscore which is useless for most users.
Ubuntu 8.04 has a binary in it's repo, but only 0.9.1, the upcoming 8.10 has (currently) 0.9.2

Comments

• Oct 20, 2008 - 23:08

So I have a .deb (60 mb) now which is working for me. Anyone wants to test if it's working on a system where musescore hasn't been installed before?
Where can I upload it?
What does mscore depend on? Only libqt4 and libasound2?

Reply

• Oct 22, 2008 - 15:15

Current commit in 1189. When I create the windows release, I update by hand and don't commit revision.h. There is something in the build process to get the revision number from the svn and write it in revision.h, but it does not work.

Reply

• Oct 22, 2008 - 15:30

Why don't you update revision.h when you know the current method doesn't work? oO

I guess I have to correct the revision number to the ones the svn says by building the prerelease? Because in the Makefile it says:
21 REVISION = `cat mscore/mscore/revision.h`
25 VERSION = "0.9.4b${REVISION}"
which obviously results in 0.9.4b1774. Which is wrong.

Reply

• Oct 22, 2008 - 19:53

Because I didn't think about it :)
So after thinking a bit :
Commiting the revision.h each time is not a solution, it will increment the commit number and generate a lot of "shadow" commit.
There is something in place to change the content of the revision.h file during the build : /trunk/mscore/mscore/updaterevision
This file is called by the build process but all lines in it are commented. We should remove the # on the second line.
(I already know that does not work on my french system because grep Revision failed. The svn client is in french and Revision is Révision, but I will take a look).

Reply

• Nov 1, 2008 - 15:54

Hi,

Thanks for picking up this task. However, being the maintainer of the official Debian/Ubuntu packages, I'd like to request that you do not deviate from my sources too far, to avoid confusion and invalid bug reports. For instance, debian/control does not specify any build dependencies (which means that on a fresh system, or in a buildd, your package will not build), nor does it build two packages (mscore and mscore-common). Your sources aren't patched in the same, or similar, way as the Debian sources, for instance to provide default support for fluid-soundfont (and to enable redistributability).

Below is an addition to my debian/rules file that automates updating to svn head, whilst retaining the current Debian packaging.

update-to-svn: version = $(shell svn up > /dev/null; make version)
update-to-svn: pkgdate = $(shell date +"%a, %d %b %Y %T %z")
update-to-svn:
mv debian ..
find -name *sf2 -exec rm {} +
find -name *pdf -exec rm {} +
tar czf ../mscore_$(version)+dfsg.orig.tar.gz .
mv ../debian .
mv debian/changelog debian/changelog.old
echo "mscore ($(version)+dfsg-1) unstable; urgency=low" > debian/changelog.new
echo >> debian/changelog.new
echo " * New svn revision" >> debian/changelog.new
echo >> debian/changelog.new
echo " -- Toby Smithe $(pkgdate)" >> debian/changelog.new
echo >> debian/changelog.new
cat debian/changelog.new debian/changelog.old > debian/changelog
rm debian/changelog.new debian/changelog.old

A script as simple as the following would thus automate building a Debian unstable package in a controlled environment. If any errors are produced, the package would fail to build, ensuring that the produced binaries diverge as little as possible.

#!/bin/sh
rm -f mscore_*
cd trunk
version=`make version`
debian/rules update-to-svn
debuild --no-tgz-check -S -sa -us -uc
cd ..
pbuilder-dist sid build mscore_${version}+dfsg-1.dsc

Of course, there are downsides to this:

1. The .svn directory is included in the sources. There's not much we can do about this.
2. The packages are unsigned. If we want this automated (ie, without human input), again, there's not much we can do about this
3. The debian/changelog entries are unhelpful. This could be fixed by parsing `svn log` or trunk/mscore/ChangeLog, but I feel that, for the purposes of these test-releases, this would be too much work.

Attachment Size
mscore_0.9.4b1225+dfsg-1.diff_.txt 30.6 KB

Reply

• Nov 1, 2008 - 20:02

Thanks for finally writing something. :)

I just learned the basics of packaging from http://www.debian.org/doc/maint-guide/ and mscore is the first package I ever made, so don't expect too much. :)

"debian/control does not specify any build dependencies"
That was a beginner mistake, now (1221 and 1205) I use the ones from the Ubuntu package:
libasound2 (>> 1.0.16), libc6 (>= 2.4), libfluidsynth1, libgcc1 (>= 1:4.1.1), libjack0 (>= 0.109.2), libportaudio2, libqt4-script (>= 4.4.0), libqt4-svg (>= 4.4.0), libqt4-xml (>= 4.4.0), libqtcore4 (>= 4.4.0), libqtgui4 (>= 4.4.0), libstdc++6 (>= 4.1.1), libx11-6, libxext6, zlib1g (>= 1:1.1.4)

"nor does it build two packages (mscore and mscore-common)"
I still didn't figure out why one should do it this way? But I'm not very familiar in building packages at all or debian/Ubuntu standars...

"Your sources aren't patched in the same, or similar, way as the Debian sources, for instance to provide default support for fluid-soundfont (and to enable redistributability)."
Ok, I'll look at your official package and try to do it similar.
What do you mean with the support for fluid soundfont? You mean preconfigured as default?

Anyway, I'll try to use your input to produce a better output myself. :)

Reply

• Nov 1, 2008 - 20:13

Apologies for any delay; I find myself very busy these days.

Please see http://sourceforge.net/mailarchive/message.php?msg_name=2d14528f0811011… for a summary of the status of my automated svn package builds. Note that these have so far only been built for Debian unstable, though building for Ubuntu Hardy or Intrepid should just be a matter of changing "sid" in the "build-svn" rule to "hardy" or "intrepid" respectively.

'"nor does it build two packages (mscore and mscore-common)"
I still didn't figure out why one should do it this way? But I'm not very familiar in building packages at all or debian/Ubuntu standars...'
mscore contains the binaries only, mscore-common the "common" files: examples, images, instrument lists. It adds a further level of precision to the packaging.

"What do you mean with the support for fluid soundfont? You mean preconfigured as default?"
My Debian packages contain much customisation to make life easier and more straightforward for users of Debian or Ubuntu systems: there are certain assumptions we can make about their systems, and as a result, we can tweak the packages to play to our advantage. Look at the headers of the files in debian/patches/* for descriptions of what the patches do.

Also, note that my official packages wrap the binary with a script that disables PulseAudio, as currently, mscore likes to enjoy access to the soundcard. Where systems do not have hardware or dmix software mixing, pulseaudio causes this to fail.

Finally, the official packages install an update notification (to be shown in the taskbar) if a soundfont is not installed, explaining why the user may not be hearing any sound in that case.

If I come across as stand-offish, do not believe it is because I do not appreciate your work; I do: you've got me to get off my ass and code an automation system. However, I am wary of the costs of duplicating work that has already been done.

Reply

Do you still have an unanswered question? Please log in first to post your question.