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.
In reply to always looking for builders by Thomas
If noone other does it I'd try it for i386 on ubuntu 8.04 and soon on 8.10.
In reply to If noone other does it I'd by Cdh
There is no one else at this moment, so you will be the hero ;-)
In reply to always looking for builders by Thomas
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?
In reply to Now? by Cdh
Check your mailbox.
In reply to ftp credentials sent by Thomas
First test:
http://prereleases.musescore.org/linux/mscore_0.9.4-r1774_i386-ubuntu80…
Not a very good one but it should work for the beginning.
In /usr/lib/qt4/plugins/script is a file libqtscript_gui.so which is decompressed 117 mb. Do we really need that?
I'll read a maintainer guide and try to build "lintian clean" packages for some minimum quality of the software releases even if it's "only" prerelease.
In reply to First test by Cdh
Here is some info on the QtScript and why it is so big right now:
http://n2.nabble.com/libawlplugin.so-and-the-scripting-interface-tp1319…
In reply to Here is some info on the by David Bolton
Looks better now in the proper build package. libqtscript_gui.so only 12 mb decompressed. Only important things seem to be in it now...
In reply to always looking for builders by Thomas
Question:
How can there be a prerelease 1187 for windows when the code in the svn is still 1174?
http://mscore.svn.sourceforge.net/viewvc/mscore/trunk/mscore/mscore/rev…
In reply to prereleases? by Cdh
Actually, it's 1188 already: http://cia.vc/stats/project/mscore
In reply to svn by Thomas
So the revision i compiled and packed there http://prereleases.musescore.org/linux/r1774/ from the source of https://mscore.svn.sourceforge.net/svnroot/mscore/trunk is not really 1774 and only the information in mscore/mscore/revision.h is not up to date?
In reply to always looking for builders by Thomas
Another Issue:
mscore/manual/MuseScore-*.pdf are missing.
In reply to Another by Cdh
Cross posted on the developers mailing list:
http://n2.nabble.com/Download-MuseScore-handbook-in-pdf-tt1299465.html#…
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.
In reply to Current commit in 1189. When by [DELETED] 5
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.
In reply to Why? by Cdh
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).
In reply to Because I didn't think about by [DELETED] 5
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.
In reply to SVN revision number by [DELETED] 3
Thks ! It works great here too.
Maybe updaterevision file can be deleted ? and mscore/CmakeList.txt has references to this file as well.
In reply to Thks ! It works great here by [DELETED] 5
Yes, i think updaterevision can be deleted.
Is there any feedback yet? The packages do work for me, but do they work for others, too?
In reply to ANY feedback? by Cdh
I think we will have to do some promotion for the packages on the download page as well as on the mailing list. How would you advertise the prereleases on the download page?
In reply to Promotion on download page by Thomas
But putting a link to http://prereleases.musescore.org/linux on the "download" page would not be wrong, I guess.
In reply to ANY feedback? by Cdh
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.
In reply to Divergence from official Debian packaging by Toby Smithe
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. :)
In reply to Thanks by Cdh
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.
Please see http://www.musescore.org/en/blog/2008/11/02/announcement-ubuntu-prerele…
If you wish to contribute to the packaging, please check out the bzr branch as described in the above announcement, and submit any patches to the mscore-developer mailing list.
Thanks,
Toby
In reply to Official prerelease packages available by Toby Smithe
Finally exactly what I was asking for.
Just wanted to say thank you:
Thank you very much.
:)