Closed Oneiroi closed 11 years ago
That's because we Ain't Got One of Those in Fedora. I did this: http://mattdm.org/misc/fedora/scratch-1.4.0.6-workaround-missing-pulse-plugin.patch
That's just a workaround, though. I assume the eventual right fix is to get that plugin into the squeak-vm package (or as its own package). Source at https://www.assembla.com/code/scratchonlinux/subversion/nodes/scratch-1.4.0/src/plugins/vm-sound-pulse?rev=44
Thanks Matt,
Unsure from a code standpoint if there is a compatible library provided by pulseaudio-libs or indeed pulseaudio assuming not then the links file could be built as a subpackage of scratch using the linked source with a Build Requires pulseaudio-devel (or relevant devel package).
That being said seeing your email re; mp3 license issue begs the question if a strait up conversion to ogg (per your notes) is really the way to go in this case.
On Mon, Sep 10, 2012 at 12:59:47PM -0700, David Busby wrote:
Unsure from a code standpoint if there is a compatible library provided by pulseaudio-libs or indeed pulseaudio assuming not then the links file could be built as a subpackage of scratch using the linked source with a Build Requires pulseaudio-devel (or relevant devel package).
It sounds like the plugin is really for squeak, and just happens to be used by scratch, so I don't think it should be a scratch subpackage, should it?
Anyway, sound isn't working at all in my current package. The ALSA module is loading but I get 'soundStart: snd_add_pcm_handler: Function not implemented', which I haven't even started to diagnose.
That being said seeing your email re; mp3 license issue begs the question if a strait up conversion to ogg (per your notes) is really the way to go in this case.
Hopefully that'll just make everyone happy. :)
Did you get a chance to look at my specfile? It's significantly more complicated than yours because I've made a bunch of subpackages. I think this is a good approach because really everything but the squeak plugins are noarch, and because there's a variety of different licenses (GPLv2, MIT, CC-BY-SA) but with clear segmentation.
I also had a few comments on your launch script. Just testing for /usr/lib64
is probably okay, but I went with parsing the output of squeak -version
--
that way, if for whatever reason the lib64 dir exists but the binary is 32
bit, it'll do the right thing. It's a bit more kludgy, though, so I don't
have a strong attachment.
Also, the $SQ_DIR variable seems to be unnecessary, because the -plugins flag adds to the default path. So all that part can just be skipped.
Matthew Miller mattdm@mattdm.org http://mattdm.org/
On Mon, Sep 10, 2012 at 04:09:42PM -0400, Matthew Miller wrote:
Anyway, sound isn't working at all in my current package. The ALSA module is loading but I get 'soundStart: snd_add_pcm_handler: Function not implemented', which I haven't even started to diagnose.
Meh: http://bugs.squeak.org/view.php?id=7328
Matthew Miller mattdm@mattdm.org http://mattdm.org/
On Mon, Sep 10, 2012 at 9:09 PM, mattdm notifications@github.com wrote:
On Mon, Sep 10, 2012 at 12:59:47PM -0700, David Busby wrote:
Unsure from a code standpoint if there is a compatible library provided by pulseaudio-libs or indeed pulseaudio assuming not then the links file could be built as a subpackage of scratch using the linked source with a Build Requires pulseaudio-devel (or relevant devel package).
It sounds like the plugin is really for squeak, and just happens to be used by scratch, so I don't think it should be a scratch subpackage, should it?
Hmmm, indeed.
Anyway, sound isn't working at all in my current package. The ALSA module is loading but I get 'soundStart: snd_add_pcm_handler: Function not implemented', which I haven't even started to diagnose.
That being said seeing your email re; mp3 license issue begs the question if a strait up conversion to ogg (per your notes) is really the way to go in this case.
Hopefully that'll just make everyone happy. :)
looks like .wav is preferable from the email chain, ho hum something to push for at a later date :)
Did you get a chance to look at my specfile? It's significantly more complicated than yours because I've made a bunch of subpackages. I think this is a good approach because really everything but the squeak plugins are noarch, and because there's a variety of different licenses (GPLv2, MIT, CC-BY-SA) but with clear segmentation.
Yes I've had a quick look, and it looks good ... the spec file I'm using per my original emails to the mit guys was > 3 years old :-/ and heavily modified as a result.
I also had a few comments on your launch script. Just testing for /usr/lib64
is probably okay, but I went with parsing the output of
squeak -version
that way, if for whatever reason the lib64 dir exists but the binary is 32 bit, it'll do the right thing. It's a bit more kludgy, though, so I don't have a strong attachment.
I'll have to look into that more, getting the path from the symlink at /usr/bin/squeak may be a more reliable method as it's unlikely to change from a symlink (I hope).
Also, the $SQ_DIR variable seems to be unnecessary, because the -plugins flag adds to the default path. So all that part can just be skipped.
Cool will have to look into that, just been concentrating on a working version.
Matthew Miller mattdm@mattdm.org http://mattdm.org/
— Reply to this email directly or view it on GitHubhttps://github.com/Oneiroi/scratch/issues/1#issuecomment-8436612.
Matt, being as your spec is more up to date than the one I had as a source I'd like to take that spec, make it CI compatible via Makefile for rapid builds and tie that into a Jenkins deploy @ rhcloud.com; at least until it is made officially available as a fedora project, at which point it would become their git systems, lookaside cache and koji.
what are your thoughts?
For me at least it makes sense to be using a more up to date spec file as a source as apposed to firefighting issues in the current one.
On Tue, Sep 11, 2012 at 04:49:27AM -0700, David Busby wrote:
Matt, being as your spec is more up to date than the one I had as a source I'd like to take that spec, make it CI compatible via Makefile for rapid builds and tie that into a Jenkins deploy @ rhcloud.com; at least until it is made officially available as a fedora project, at which point it would become their git systems, lookaside cache and koji. what are your thoughts?
That sounds great. Working together is much better.
Let's also try and get this into Rawhide as soon as it's in decent enough shape so we can take advantage of the infrastructure.
Matthew Miller mattdm@mattdm.org http://mattdm.org/
My latest RPM also uses an mp3-binary free tarball until upstream produces a clean one (which they said they'll do in the next release, so that shouldn't be a blocker). It doesn't use the converted wav files yet, since I haven't tested them, because audio doesn't work anyway.
My preference is to not make the audio issue a blocker for landing in rawhide -- let's get it there and then fix in place.
Review request for my package as it stands: https://bugzilla.redhat.com/show_bug.cgi?id=856238
I've added you as a collaborator on this project, will work on pulling in your spec and making CI compatible asap, just working on a new jenkins instance with the repo in it's current state, before enabling hooks so that post push a jenkins build runs.
On Tue, Sep 11, 2012 at 07:41:53AM -0700, David Busby wrote:
I've added you as a collaborator on this project, will work on pulling in your spec and making CI compatible asap, just working on a new jenkins instance with the repo in it's current state, before enabling hooks so that post push a jenkins build runs.
Cool. I've got some Real Work™ to do right now, so I'll sit back and see how it all settles out. :)
Matthew Miller mattdm@mattdm.org http://mattdm.org/
opeshift @ rhcloud seems to be a no go got the jenkins deploy complete, could not figure our a way to install the devel packages required for the scratch build, deploying a jenkins deploy @ my rackspace cloudserver now seems to be the way to go.
And on that note build success using the current spec
Started by user David Busby Building in workspace /var/lib/jenkins/workspace/scratch Checkout:scratch / /var/lib/jenkins/workspace/scratch - hudson.remoting.LocalChannel@4ce1e2b3 Using strategy: Default Last Built Revision: Revision 58fb8480a6ef9b2049604ca80346700d9939622e (origin/HEAD, origin/master) Fetching changes from 1 remote Git repository Fetching upstream changes from git://github.com/Oneiroi/scratch.git Seen branch in repository origin/HEAD Seen branch in repository origin/master Commencing build of Revision 71d1f9d30c0829cfa07956882f50d134b9a89df6 (origin/HEAD, origin/master) Checking out Revision 71d1f9d30c0829cfa07956882f50d134b9a89df6 (origin/HEAD, origin/master) Warning : There are multiple branch changesets here [scratch] $ /bin/sh -xe /tmp/hudson7483863428358381922.sh
/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src' make clean -C src/plugins/scratch/ make build -C src/plugins/scratch/ make[2]: Entering directory
/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/scratch'
rm -f .o ../../../Plugins/so.ScratchPlugin
make[2]: Entering directory `/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/scratch'
gcc -fPIC -c .c
make[2]: Leaving directory/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/scratch' make clean -C src/plugins/unicode/ make[2]: Entering directory
/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/unicode'
rm -f .o ../../../Plugins/so.UnicodePlugin
make[2]: Leaving directory/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/unicode' make clean -C src/plugins/camera/ make[2]: Entering directory
/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/camera'
rm -f .o ../../../Plugins/so.CameraPlugin
make[2]: Leaving directory/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/camera' make clean -C src/plugins/wedo/ make[2]: Entering directory
/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/wedo'
rm -f .o ../../../Plugins/so.WeDoPlugin
make[2]: Leaving directory`/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/wedo'
gcc -shared .o -o ../../../Plugins/so.ScratchPlugin
make[2]: Leaving directory /var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/scratch' make build -C src/plugins/unicode/ make[2]: Entering directory
/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/unicode'
gcc -fPIC -c pkg-config --cflags pangocairo
.c
gcc -shared pkg-config --libs pangocairo
-lc .o -o ../../../Plugins/so.UnicodePlugin
make[2]: Leaving directory /var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/unicode' make build -C src/plugins/camera/ make[2]: Entering directory
/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/camera'
gcc -fPIC -c .c
gcc -shared .o -o ../../../Plugins/so.CameraPlugin
make[2]: Leaving directory /var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/camera' make build -C src/plugins/wedo/ make[2]: Entering directory
/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/wedo'
gcc -fPIC -Wall -c -O2 .c
WeDoLinux.c: In function 'WeDoOpenPort':
WeDoLinux.c:162:3: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
WeDoLinux.c: In function 'WeDoClosePort':
WeDoLinux.c:175:2: warning: implicit declaration of function 'close' [-Wimplicit-function-declaration]
gcc -shared .o -o ../../../Plugins/so.WeDoPlugin
make[2]: Leaving directory /var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src/src/plugins/wedo' make[1]: Leaving directory
/var/lib/jenkins/workspace/scratch/dist/BUILD/scratch-1.4.0.6.src'Hooks are giving me issues due to authentication defaulting to polling at this time.
Closing this issue per email chain moving to .wav format should make this irrelevant both from a license and functional standpoint.
Also note Jenkins builds using the make dist-test
output are available here: http://oneiroi.co.uk/scratch/ at the time of writing this is still the old spec, this will change this evening when I work through integrating your spec file, these poll every 5 minute from this github project if the HEAD hash changes a new build is run.
Post commit: af0205b375480aa6ee67e40182ca944623fb63fa Testing launch yields
Executing: /usr/bin/squeak -encoding UTF-8 -vm-display-x11 -xshm -vm-sound-pulse /usr/lib64/scratch/Scratch.image could not find module vm-sound-pulse
Relevant strace