Languages

Breadcrumb

Wanted: Linux Binary Download

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

Lasconic is the one who builds the prereleases for windows. If there is anyone else interested in building prereleases for any other platform, we can grant ftp access to http://prereleases.musescore.org

So if you or anyone else is willing to distribute prereleases, reply to this comment.

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?

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.

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.

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).

I found another way to find out the project revision number. There is a special svn utility for this: "svnversion". I updated the toplevel Makefile with this command. "make revision" should update the revision.h file.

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.

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.

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.

"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?

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.