new packages in Fedora updates-testing (2010-04-10)

[Orcan Ogetbil]

Hi all,

Here are the latest pushes to updates-testing on Fedora:

flowcanvas-0.6.0 (this was already in PlanetCCRMA, now it got imported
to Fedora):
https://admin.fedoraproject.org/updates/flowcanvas-0.6.0-1.fc13
https://admin.fedoraproject.org/updates/flowcanvas-0.6.0-1.fc12
https://admin.fedoraproject.org/updates/flowcanvas-0.6.0-1.fc11

muse-1.0.1-2 (includes the synti path fix on 64bit systems. Also a
rebuild was needed in F-13 to pick up proper soname deps):
https://admin.fedoraproject.org/updates/muse-1.0.1-2.fc13
https://admin.fedoraproject.org/updates/muse-1.0.1-2.fc12
https://admin.fedoraproject.org/updates/muse-1.0.1-2.fc11

hydrogen-0.9.4.1-1 (this is a bugfix release, with the following fixes:
        * added czech translation
        * Bugfix: Exported songs have now the correct length.
        * Bugfix: Generate new instrument id's correctly.
        * Bugfix: Fixed the deletion of midi bindings
        * Workaround: Update the SongeditorPositionRuler safely even if
          the pPattern pointer is NULL RHBZ#570348
        * Bugfix: Add 64bit ladspa plugin path for detection
        * New: build ladspa-wasp-plugins
64bit ladspa plugin path issue was resolved finally.)
https://admin.fedoraproject.org/updates/hydrogen-0.9.4.1-1.fc13
https://admin.fedoraproject.org/updates/hydrogen-0.9.4.1-1.fc12
https://admin.fedoraproject.org/updates/hydrogen-0.9.4.1-1.fc11

ladspa-wasp-plugins:
A new set of ladspa plugins. The code was distributed with the
hydrogen tarball for a while. It appears that the author donated the
code to the hydrogen project. So I build these plugins together with
hydrogen. The above hydrogen links also applies to ladspa-wasp-plugins

Please give a day or two until the updates appear in the
updates-testing repo. You can give positive or negative feedback on
bodhi, i.e. the above links.

guitarix-0.07.1 (failed):
I also tried to update guitarix to 0.07.1. However this version
requires zita-resampler, which doesn't exist in Fedora yet. But it
exists in PlanetCCRMA. Maybe we should build guitarix 0.07.1 on
PlanetCCRMA until we get zita-resampler into Fedora (which may take a
while since I am really busy these days. If anyone wants to give a
hand I would be very happy).

Orcan

[Niels Mayer]

On Sat, Apr 10, 2010 at 5:01 PM, Orcan Ogetbil <oget.fedora(a)gmail.com&gt;wrote:

>  flowcanvas-0.6.0 (this was already in PlanetCCRMA, now it got
> imported to
>  Fedora) ... muse-1.0.1-2 (includes the synti path fix on 64bit systems. Also
>  a rebuild was needed in F-13 to pick up proper soname deps) ...
>  hydrogen-0.9.4.1-1 (this is a bugfix release, with the following fixes ... 

I installed all the rpm's announced on 2.6.32.11-99.fc12.x86_64 (latest F12
kernel, not CCRMA's RT kernel). I tested them very briefly -- enough to
determine that they run & don't crash.

(1) Testing https://admin.fedoraproject.org/updates/hydrogen-0.9.4.1-1.fc12basically
consisted of playing around with
http://www.hydrogen-music.org/forum/pub/attach/2495-pauls_blues_box.h2son...
at 120BPM instead of 60BPM :-)  I didn't exercise the new/changed items (
http://koji.fedoraproject.org/koji/buildinfo?buildID=166387 )

>  Build the wasp plugins 
Fixes ladspa plugin path on 64bit systems


(2) My tests of
https://admin.fedoraproject.org/updates/muse-1.0.1-2.fc12were even
less in-depth, since, as usual, I got fed-up before I got it to
produce any sounds. I did get it to flash lights on a midi box and loaded a
few plugins and their GUIs, including TX81Z/DX11 FM synth (
/usr/share/muse/presets/deicsonze/ARCH_ALIN ), VAM: Virtual Analog for MusE
( /usr/share/doc/muse-1.0.1/README.vam ), and
others, /usr/share/doc/muse-1.0.1/README.softsynth . W/r/t not getting it
working, it's just that for a supposedly easy to use system, i'm still
blocked on getting midi input from keyboards/etc to actually play or record.
(It's too bad muse doesn't have a decent preinstalled set of demos -- that's
really what helped get me up and running w/ rosegarden and hydrogen.) I'm
sure next time I spend another hour with it I'll get it working, as I'm
"this" close -- I might need to break down and read some documentation
(which is sort of a "fail" for a GUI app, although the norm for a music
app).

(3) https://admin.fedoraproject.org/updates/flowcanvas-0.6.0-1.fc12 -- I
tested by running patchage. Unfortunately, after installing flowcanvas, "yum
update" wants to update back to the CCRMA version:

gnulem-119-~/Download> sudo yum update

Loaded plugins: fastestmirror, refresh-packagekit

Loading mirror speeds from cached hostfile

 * fedora: mirrors.usc.edu

 * rpmfusion-free: mirrors.cat.pdx.edu

 * rpmfusion-free-updates: mirrors.cat.pdx.edu

 * rpmfusion-nonfree: mirrors.cat.pdx.edu

 * rpmfusion-nonfree-updates: mirrors.cat.pdx.edu

 * updates: mirrors.usc.edu

Setting up Update Process

Resolving Dependencies

--> Running transaction check

---> Package flowcanvas.x86_64 0:0.6.0-1.fc12.ccrma set to be updated

--> Finished Dependency Resolution


>  Updating: 
 flowcanvas                        x86_64
>   0.6.0-1.fc12.ccrma                        planetccrma
>   133 k 

>  Transaction Summary 
Install       0 Package(s)

Upgrade       1 Package(s)


>  Total download size: 133 k 
Is this ok [y/N]: n


I installed the f12 version of flowcanvas, ran patchage verifying it's ok,
then reinstalled the ccrma version so as to not get an unnecessary 'updates
available' icon...
....................

>  guitarix-0.07.1 (failed): 
I also tried to update guitarix to 0.07.1. However this version

requires zita-resampler, which doesn't exist in Fedora yet. But it

exists in PlanetCCRMA. Maybe we should build guitarix 0.07.1 on

PlanetCCRMA until we get zita-resampler into Fedora (which may take a

while since I am really busy these days. If anyone wants to give a

hand I would be very happy).


I'm intrigued by guitarix && would like to see it's interface to
jconvolver
be more useful (there's always jcgui, which seems to be the jconvolver parts
of guitarix minus the "the knob goes to 11 so it's really loud" :-) part.).
IMHO both should be part of fedora since they're basically the same
"pattern" with the same dependencies.

The thing that would help w/ guitarix/jcgui's usage of jconvolver would be
better-working examples & hints for loading them up within the app... see
also http://comments.gmane.org/gmane.comp.audio.planetccrma.general/9587 .

How can I help?

FYI, I have not received reply regarding access to some of the jconvolver
files:

Excerpt of discussion on jconvolver package from Stanford University
>  PlanetCCRMA mailing list: "... However, other files, the more
> interesting
>  ones like 
'/usr/share/jconvolver/reverbs/spacenet/Minster1_000_WXYZ_48k.amb' are still
>  missing. ... http://space-net.org.uk/?q=node/50 suggests where to
> find
>  them: "96kHz versions are available at 5deg intervals for the complete
>  measurement circle through negotiation with the authors." 

>  For context/details, see
>
> http://old.nabble.com/new-packages-in-Fedora-updates-testing-%282010-03-1...

>  Question: 
(1) May I get access to these files for my own educational use, e.g.

http://old.nabble.com/Any-3d-midi-controlled-audio-mixer-using-HRTFs--tp2...


>  (2) Would it be possible for these files to be distributed alongside
>  jconvolver, as a separate and related package, much like debian's 
http://ftp.riken.go.jp/pub/pub/Linux/MandrivaLinux/devel/cooker/x86_64/me...


....................

PS: Here's my overall installation "method" for these updates. (Btw, what
should I do to get rid of the --nogpgcheck option
when i don't want to include the updates-testing repo, and prefer to do it
"manually" as below, yet would also like a GPG check of package integrity:

gnulem-118-~/Download> sudo yum --nogpgcheck install
>  hydrogen-0.9.4.1-1.fc12.x86_64.rpm
>  ladspa-wasp-plugins-0.9.4.1-1.fc12.x86_64.rpm muse-1.0.1-2.fc12.x86_64.rpm
>  flowcanvas-0.6.0-1.fc12.x86_64.rpm 
Examining hydrogen-0.9.4.1-1.fc12.x86_64.rpm: hydrogen-0.9.4.1-1.fc12.x86_64

Marking hydrogen-0.9.4.1-1.fc12.x86_64.rpm as an update to
>  hydrogen-0.9.4-1.fc12.x86_64 
Examining ladspa-wasp-plugins-0.9.4.1-1.fc12.x86_64.rpm:
>  ladspa-wasp-plugins-0.9.4.1-1.fc12.x86_64 
Marking ladspa-wasp-plugins-0.9.4.1-1.fc12.x86_64.rpm to be installed

Examining muse-1.0.1-2.fc12.x86_64.rpm: 1:muse-1.0.1-2.fc12.x86_64

Marking muse-1.0.1-2.fc12.x86_64.rpm as an update to
>  1:muse-1.0.1-1.fc12.x86_64 
Examining flowcanvas-0.6.0-1.fc12.x86_64.rpm: flowcanvas-0.6.0-1.fc12.x86_64

Marking flowcanvas-0.6.0-1.fc12.x86_64.rpm to be installed

Resolving Dependencies

--> Running transaction check

---> Package flowcanvas.x86_64 0:0.6.0-1.fc12 set to be updated

---> Package hydrogen.x86_64 0:0.9.4.1-1.fc12 set to be updated

---> Package ladspa-wasp-plugins.x86_64 0:0.9.4.1-1.fc12 set to be updated

---> Package muse.x86_64 1:1.0.1-2.fc12 set to be updated

--> Finished Dependency Resolution

Dependencies Resolved

====================================================================================================================================================

 Package                           Arch                 Version
>           Repository                                               
> Size 
====================================================================================================================================================

Installing:

 flowcanvas                        x86_64               0.6.0-1.fc12
>          /flowcanvas-0.6.0-1.fc12.x86_64                          289
> k 
 ladspa-wasp-plugins               x86_64               0.9.4.1-1.fc12
>          /ladspa-wasp-plugins-0.9.4.1-1.fc12.x86_64                56
> k 
Updating:

 hydrogen                          x86_64               0.9.4.1-1.fc12
>          /hydrogen-0.9.4.1-1.fc12.x86_64                          8.8
> M 
 muse                              x86_64               1:1.0.1-2.fc12
>          /muse-1.0.1-2.fc12.x86_64                                9.0
> M 
Transaction Summary

====================================================================================================================================================

Install       2 Package(s)

Upgrade       2 Package(s)

Total size: 18 M

Is this ok [y/N]: y

Downloading Packages:

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

  Installing     : flowcanvas-0.6.0-1.fc12.x86_64
>                                                                     
> 1/6 
  Updating       : 1:muse-1.0.1-2.fc12.x86_64
>                                                                     
> 2/6 
  Installing     : ladspa-wasp-plugins-0.9.4.1-1.fc12.x86_64
>                                                                    
> 3/6 
  Updating       : hydrogen-0.9.4.1-1.fc12.x86_64
>                                                                     
> 4/6 
  Cleanup        : 1:muse-1.0.1-1.fc12.x86_64
>                                                                     
> 5/6 
  Cleanup        : hydrogen-0.9.4-1.fc12.x86_64
>                                                                     
> 6/6 
Installed:

  flowcanvas.x86_64 0:0.6.0-1.fc12
>   ladspa-wasp-plugins.x86_64 0:0.9.4.1-1.fc12
>  
Updated:

  hydrogen.x86_64 0:0.9.4.1-1.fc12
>   muse.x86_64 1:1.0.1-2.fc12 
Complete!


-- Niels
http://nielsmayer.com

[Orcan Ogetbil]

Thank you Niels, for the feedback.

On Sun, Apr 11, 2010 at 5:57 PM, Niels Mayer wrote:
>  On Sat, Apr 10, 2010 at 5:01 PM, Orcan Ogetbil
> <oget.fedora(a)gmail.com&gt; 
> > > guitarix-0.07.1 (failed):
> >
> > I also tried to update guitarix to 0.07.1. However this version
> >
> > requires zita-resampler, which doesn't exist in Fedora yet. But it
> >
> > exists in PlanetCCRMA. Maybe we should build guitarix 0.07.1 on
> >
> > PlanetCCRMA until we get zita-resampler into Fedora (which may take a
> >
> > while since I am really busy these days. If anyone wants to give a
> >
> > hand I would be very happy).
>
>  I'm intrigued by guitarix && would like to see it's interface to
> jconvolver
>  be more useful (there's always jcgui, which seems to be the jconvolver parts
>  of guitarix minus the "the knob goes to 11 so it's really loud" :-)
> part.).
>  IMHO both should be part of fedora since they're basically the same
>  "pattern" with the same dependencies.
>  The thing that would help w/ guitarix/jcgui's usage of jconvolver would be
>  better-working examples & hints for loading them up within the app... see
>  also http://comments.gmane.org/gmane.comp.audio.planetccrma.general/9587 .
>  How can I help? 
The issue is, it takes time to get packages reviewed since there are
about 700 review requests pending. If we had 2 people on Fedora (1
will package, 1 will review) then things would go faster. But as 1
person, I am packaging stuff and waiting some external person to take
time to review the package. a2jmidi, for instance, I submitted it for
review months ago and nobody looked at it yet.

But I can't force anyone to become a packager. It takes time to learn
and get into it, especially if the person does not have some
programming background. I am just announcing here, if there is anyone
who can spare a couple hours every week and is willing to do packaging
work, we would be very pleased.

>  FYI, I have not received reply regarding access to some of the
> jconvolver
>  files: 
Yeah, I don't know of an email address of him that he checks and
replies emails. I tried a couple addresses of him I found here and
here but no luck still.

>  PS: Here's my overall installation "method" for these
> updates. (Btw, what
>  should I do to get rid of the --nogpgcheck option
>  when i don't want to include the updates-testing repo, and prefer to do it
>  "manually" as below, yet would also like a GPG check of package integrity:
When the updates get signed and put into updates-testing repo (takes a
couple days after my announcements), you can temporarily enable the
updates-testing repo for once to install specific packages, like
$ yum --enablerepo updates-testing update muse
$ yum --enablerepo updates-testing install ladspa-wasp-plugins
etc. When this command finishes its work, your updates-testing repo
will be disabled.


Cheers,
Orcan

[Niels Mayer]

On Sun, Apr 11, 2010 at 3:58 PM, Orcan Ogetbil <oget.fedora(a)gmail.com&gt;wrote:

>  The issue is, it takes time to get packages reviewed since there are
>  about 700 review requests pending. If we had 2 people on Fedora (1
>  will package, 1 will review) then things would go faster. But as 1
>  person, I am packaging stuff and waiting some external person to take
>  time to review the package. a2jmidi, for instance, I submitted it for
>  review months ago and nobody looked at it yet.
>  
I'd be willing to do the "review" part, and could eventually apprentice on
writing appropriately compliant fedora RPM specs.

a2jmidi -- i was going to look into it back when i thought i'd be using
firewire... didn't bother now that midi. is under control.

(Are there any advantages to using a2jmidi and turning off the 'seq'  driver
in qjackctl/jackd when using the alsa back-end? Other than having the same
config for audio setups using either alsa or ffado/freebob ...)

But I can't force anyone to become a packager. It takes time to learn
>  and get into it, especially if the person does not have some
>  programming background. I am just announcing here, if there is anyone
>  who can spare a couple hours every week and is willing to do packaging
>  work, we would be very pleased.
>  
I have programming background and would be interested in learning how
packaging is done. I have my own build of http://vamp-plugins.org , for
example, since I'm using them for my own website project/idea:
http://nielsmayer.com/trainspodder-prototype.jpg
http://nielsmayer.com/prototype-11-17-2009.jpg (which needs to be the focus
of my time so I can't get too distracted w/ too much time-commitment ).

>  (Btw, what
>  > should I do to get rid of the --nogpgcheck option
>  > when i don't want to include the updates-testing repo, and prefer to do
>  it
>  > "manually" as below, yet would also like a GPG check of package
>  integrity:
>
>  When the updates get signed and put into updates-testing repo (takes a
>  couple days after my announcements), you can temporarily enable the
>  updates-testing repo for once to install specific packages, like
>  $ yum --enablerepo updates-testing update muse
>  $ yum --enablerepo updates-testing install ladspa-wasp-plugins
>  etc. When this command finishes its work, your updates-testing repo
>  will be disabled.
>  
Thanks for suggesting the correct way to do it.

-- Niels.

[Orcan Ogetbil]

On Sun, Apr 11, 2010 at 8:30 PM, Niels Mayer wrote:
>  On Sun, Apr 11, 2010 at 3:58 PM, Orcan Ogetbil
>  wrote:
> >
> > The issue is, it takes time to get packages reviewed since there are
> > about 700 review requests pending. If we had 2 people on Fedora (1
> > will package, 1 will review) then things would go faster. But as 1
> > person, I am packaging stuff and waiting some external person to take
> > time to review the package. a2jmidi, for instance, I submitted it for
> > review months ago and nobody looked at it yet.
>
>  I'd be willing to do the "review" part, and could eventually apprentice on
>  writing appropriately compliant fedora RPM specs. 
Great. To join, basically you need to come up with a new package, then
prove that you understand the Fedora guidelines during your package
review and get sponsored in Fedora.

The process is described in detail, with all the relevant links at
http://fedoraproject.org/wiki/PackageMaintainers/Join

The rule is, your first package needs to be reviewed by a sponsor.
Unfortunately, I am not a sponsor, so I can't help with that. (maybe
it's time for me to apply for sponsorship. oh well...)

Do you see the difficulty here? Your first package will have to go
into a pool of 700 packages, and hopefully a sponsor will find it
interesting for a review. But once that is done, everything will go
easier. It took me ~2 weeks to get sponsored but I know people for
whom it took months.

>  a2jmidi -- i was going to look into it back when i thought i'd be
> using
>  firewire... didn't bother now that midi. is under control.
>  (Are there any advantages to using a2jmidi and turning off the 'seq'  driver
>  in qjackctl/jackd when using the alsa back-end? Other than having the same
>  config for audio setups using either alsa or ffado/freebob ...) 
Frankly, I don't know the answer. I packaged it per user request.
Maybe the actual users will shed us some light.

Cheers,
Orcan

[Niels Mayer]

On Sun, Apr 11, 2010 at 6:12 PM, Orcan Ogetbil <oget.fedora(a)gmail.com&gt;wrote:
>  Great. To join, basically you need to come up with a new package, then
>  prove that you understand the Fedora guidelines during your package
>  review and get sponsored in Fedora.
>
>  The process is described in detail, with all the relevant links at
>  http://fedoraproject.org/wiki/PackageMaintainers/Join
>
>  The rule is, your first package needs to be reviewed by a sponsor.
>  Unfortunately, I am not a sponsor, so I can't help with that. (maybe
>  it's time for me to apply for sponsorship. oh well...)
>
>  Do you see the difficulty here? Your first package will have to go
>  into a pool of 700 packages, and hopefully a sponsor will find it
>  interesting for a review. But once that is done, everything will go
>  easier. It took me ~2 weeks to get sponsored but I know people for
>  whom it took months.
>  
Yipes! Sounds like the open-sourcerers apprentice....

For right now, it probably makes sense for me to continue testing packages
you announce.

At some point I'm going to get fed up having to manually load a file into
qmidiroute-0.2.1-4.fc12.ccrma.x86_64 every time I log-in (
http://old.nabble.com/using-qmidiroute-for-midi-device-control....-ts2796...
).
So at some point that may motivate me to compile
http://sourceforge.net/projects/alsamodular/files/QMidiRoute/0.3.0/NEWS.t...
 and
maybe package it. Some of the work has already been done for F10:
http://sourceforge.net/projects/alsamodular/files/QMidiRoute/0.3.0/qmidir...
http://sourceforge.net/projects/alsamodular/files/QMidiRoute/0.3.0/qmidir...

Finally, and longer term, I'd like to see QMidiCtl and QMidiNet added to
fedora:
http://old.nabble.com/QMidiCtl-and-QMidiNet-(was-Re:--Pd-%2B-PulseAudio-)...
;
even longer term I'd also like to add another program to the "qmidinet bus"
-- qmidiprolog or qmidilisp or perhaps just a way of getting CommonMusic
integrated w/ qmidinet: some way of allowing "event-driven, rule-based midi
programming" to happen. That could allow for something as simple as
implementing different "curves" on controllers, or as complex as algorithmic
arpeggiators, or even music parsing and live accompaniment. Using the
application partitioning already in place for qmidinet and qmidictl, one
could add a different kind of "controller" that just happens to be rules
firing based on midi input, generating midi output.

>  a2jmidi -- i was going to look into it back when i thought i'd be
> using
>  > firewire... didn't bother now that midi. is under control.
>  > (Are there any advantages to using a2jmidi and turning off the 'seq'
>   driver
>  > in qjackctl/jackd when using the alsa back-end? Other than having the
>  same
>  > config for audio setups using either alsa or ffado/freebob ...)
>
>  Frankly, I don't know the answer. I packaged it per user request.
>  Maybe the actual users will shed us some light.
>  
Here's what I learned previously: (see
http://old.nabble.com/help-getting-netjack-MIDI-working--(looks-like-it&#...
 )

summary -- we're missing an ALSA<->JACK bridge on the "slave" side.
The
>  slave side is sitting there talking to netjack ports not connected
> or
>  bridged to the ALSA devices in any way. 
(1) For MIDI only, use:
>  http://ccrma.stanford.edu/planetccrma/man/man1/aseqnet.1.html 
(2) Alternately&&more complicated, if using netjack, must also bridge midi
>  to jack with
>
> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/12/...
>  
Unfortunately, planetccrma version is obsolete, version 6 from GIT is
>  current/stable version. 
(3) Audio also requires an ALSA<->JACK bridging too, like alsa_in and
>  alsa_out on the slave-side netjack. 

#2 indicates another use/need for a2jmidid -- which is obviated by skipping
the whole netjack mess and using facilities like QMidiCtl and QMidiNet
instead.

<http://old.nabble.com/help-getting-netjack-MIDI-working--(looks-like-it&#...
--
Niels
http://nielsmayer.com

[Orcan Ogetbil]

Sorry I missed this one.

On Sun, Apr 11, 2010 at 5:57 PM, Niels Mayer wrote:
>  (3) https://admin.fedoraproject.org/updates/flowcanvas-0.6.0-1.fc12
> -- I
>  tested by running patchage. Unfortunately, after installing flowcanvas, "yum
>  update" wants to update back to the CCRMA version: 
It won't harm to revert back to the CCRMA version. Since they have the
same content, if you have CCRMA's flowcanvas installed, in theory, you
won't need to download and install Fedora's. That's why I left the
version-release number smaller than CCRMA's.

Hmm, maybe I shouldn't have. Is it confusing? :)

Orcan