SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack-audio-connection-kit-0.100.0-1.src.rpm Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack-audio-connection-kit.spec Description: JACK is a low-latency audio server, written primarily for the Linux operating system. It can connect a number of different applications to an audio device, as well as allowing them to share audio between themselves. Its clients can run in their own processes (ie. as a normal application), or can they can run within a JACK server (ie. a "plugin"). JACK is different from other audio server efforts in that it has been designed from the ground up to be suitable for professional audio work. This means that it focuses on two key areas: synchronous execution of all clients, and low latency operation. P.S. I need a sponsor.
I'm not much of a packaging guru by any means but I can say that rpmlint doesn't complain and that it builds in mock. I'm unsure why you have packaged the jack lib separately and why the driver so's aren't in the lib package. Perhaps you could explain this to me. It would be nice to get this package in extra's as there is some cool software that has is dependant on jack: http://jackit.sourceforge.net/apps/
I catched spec from Mandrake distribution and didn't change package spliting. Also, RH ships net-snmp, rpm, bind and other as daemon (or program) + libs package. I agree that libs w/o daemon may be useless. What could you like to propose me? At least I've packaged already bio2jack, rosegarden, xmms-jack. However, I need a sponsor firstly (I'm so thinking) and after I'll commited this useful packages. It's a plan.
Perhaps you should be adapting Planet CCRMA's packages instead of Mandrake packages. http://ccrma.stanford.edu/planetccrma/software/
(In reply to comment #3) > Perhaps you should be adapting Planet CCRMA's packages instead of Mandrake packages. > > http://ccrma.stanford.edu/planetccrma/software/ Probably even contact Fernando from CCRMA how to handle future common packages.
There are patched spec file and new *.src.rpm of jack-audio-connection-kit. SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- audio-connection-kit-0.100.0-2.src.rpm Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- audio-connection-kit.spec * Fri Mar 17 2006 Andy Shevchenko <andriy.ua> - no libs subpackage - From Fernando Lopez-Lezcano <nando.edu>: - added configuration variable to build with/without capabilities - added --enable-optimize flag to configure script - disabled sse/mmx instructions in i386 build - create temporary directory as /var/lib/jack/tmp - create and erase tmp directory at install or uninstall - try to umount the temporary directory before uninstalling the package
Sorry I haven't been able to test your new packages but I have a question. According to this page http://sourceforge.net/project/showfiles.php?group_id=39687 The latest release of the jack-audio-connection-kit is 0.100.7 which was released in december, is there any particular reason that you are packaging an older version?
Unconditionally there is a old package, But I use the main page http://jackit. sourceforge.net/ where announce is not placing and current links to version 0. 100.0. I'll tried to reviewed and repackaged last version.
I've updated jack to the version 0.100.7. Please, review the following spec and package. SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- audio-connection-kit-0.100.7-1.src.rpm Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- audio-connection-kit.spec
* Tue Apr 04 2006 Andy Shevchenko <andriy.ua> - update to 0.101.1 SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- audio-connection-kit-0.101.1-1.src.rpm Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- audio-connection-kit.spec
(In reply to comment #9) > * Tue Apr 04 2006 Andy Shevchenko <andriy.ua> > - update to 0.101.1 I just tried this on x86, and it seems fine. Thanks for your effort - I hope this is approved soon.
From your latest spec file * Fri Mar 17 2006 Andy Shevchenko <andriy.ua> - no libs subpackage - From Fernando Lopez-Lezcano <nando.edu>: - added configuration variable to build with/without capabilities Why? Has Fedora ever shipped a kernel with the required capabilites enabled for this to be of any use? Planet CCRMA did so at one stage but that was a fair while ago. - create temporary directory as /var/lib/jack/tmp Why? What is wrong with the default /dev/shm directory? I'm also wondering if all the backends are needed, can you think of a good reason not to disable the port audio and oss backends?
1. Perhaps, this feature is over. Could you tell me your solution? 2. No wrong. I've read native README and catch up this feature from it. Can I use /dev/shm directly instead of %jack_tmpdir? 3. By default the portaudio and oss plugins are built. OSS may be disabled in many cases except non-ALSA cards (How many of such cases? I don't know). Portaudio may be excluded from BR and we get flexibility of packaging rule (portaudio library still present at FE repo). More better reason I can't think out.
Fernando seems to think using /dev/shm is a good idea: http://www.redhat.com/archives/fedora-extras-list/2005-March/msg00994.html Remove all the jack_tmpdir stuff and just use /dev/shm Also, capabilities is a kernel 2.4 thing. You should just remove jackstart and all the capabilities related stuff. http://www.redhat.com/archives/fedora-extras-list/2005-March/msg00984.html It appears the needed realtime and memlock permissions can be provided by pam, but I can't find any good documentation on what exactly you should set. (/etc/security/limits.conf) A README.Fedora will probably be in order for this... I've submitted Rosegarden for review, which uses jack for audio support. I'll do a full review of jack when I find some time. (But I can't sponsor) Should we start an Audio SIG?
Ah, found it. Add something like this to /etc/security/limits.conf : username - memlock 32768 username - rtprio 99 Then log out and log back in. Jack can indeed set itself RT with these settings on FC5. Dunno what memlock really needs to be. The mailing list posts I dug up set it to 4gb, which seems kind of dangerous to me...
Forgot to comment on the drivers. I see no reason why you'd want to use portaudio, when there's native ALSA support. And OSS needs to die already.
(In reply to comment #12) > 1. Perhaps, this feature is over. Could you tell me your solution? Don't enable it and remove all references to it from the spec file. The capabilities patch was used to allow a non-root process to change the scheduling policy to SCHED_FIFO and to lock pages in memory using mlock/mlockall. This is now possible using recent kernels(~2.6.12+) and pam(FC5 and devel) by setting the appropriate resource limits in the pam config file /usr/security/limits.conf but I think that is something that should be done explicitly by the user(appropriate documentation would be needed). > 2. No wrong. I've read native README and catch up this feature from it. Can I > use /dev/shm directly instead of %jack_tmpdir? Sorry, I can't give you a definitive answer about that. You might want to check if the FHS says anything but I don't think it is an issue. > 3. By default the portaudio and oss plugins are built. OSS may be disabled in > many cases except non-ALSA cards (How many of such cases? I don't know). > Portaudio may be excluded from BR and we get flexibility of packaging rule > (portaudio library still present at FE repo). More better reason I can't think > out. I was only wondering because AFAIK the portaudio and oss plugins both depend on alsa being in a working state anyway but it really doesn't matter. In response to the idea of an Audio SIG, I am definately interested. I noticed this page http://fedoraproject.org/wiki/Extras/SIGs/Multimedia has yet to be created...
(In reply to comment #13) > Should we start an Audio SIG? I'm all for this. I've been queing up some audio packages for submission here: http://people.redhat.com/green/FE/FC5/.
Updated package: SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- audio-connection-kit-0.101.1-2.src.rpm Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- audio-connection-kit.spec * Mon Apr 24 2006 Andy Shevchenko <andriy.ua> - disable oss and portaudio engines - use /dev/shm as jack tmpdir - remove capabilities stuff Due to English isn't my native language could anybody help me with README. Fedora?
(In reply to comment #18) > Updated package: > SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- > audio-connection-kit-0.101.1-2.src.rpm > Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack- > audio-connection-kit.spec > > * Mon Apr 24 2006 Andy Shevchenko <andriy.ua> > - disable oss and portaudio engines > - use /dev/shm as jack tmpdir > - remove capabilities stuff Looks good. I noticed BR: glib-devel in the spec are you sure this is needed? > Due to English isn't my native language could anybody help me with README. > Fedora? I'm attaching a rough README.Fedora but it should probably be verified for correctness, grammar, spelling etc.
Created attachment 128234 [details] Rough README.Fedora
* Wed Apr 26 2006 Andy Shevchenko <andriy.ua> - add README.Fedora - remove useless BRs Updated package: SRPM Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack-audio-connection-kit-0. 101.1-3.src.rpm Spec Name or Url: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack-audio-connection-kit. spec
(In reply to comment #20) > Created an attachment (id=128234) [edit] > Rough README.Fedora > I think this file is great, although it would be even better if it were word-wrapped at 78 columns or so. I've submitted 9 or 10 packages for review that depend on jack-audio-connection-kit in one way or another. Is there anything major holding up acceptance of this package now?
(In reply to comment #22) I've fixed after comment this issue. Please, review last update at: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack-audio-connection-kit-0. 101.1-4.src.rpm
Alright, I'm working on a full review. rpmlint output: rpmlint jack-audio-connection-kit-0.101.1-4.fc5.i386.rpm W: jack-audio-connection-kit no-version-in-last-changelog Remember to tag your changelog entries with the package version number, like so: * Thu Apr 27 2006 Andy Shevchenko <andriy.ua> - 0.101.1-4 W: jack-audio-connection-kit one-line-command-in-%post /sbin/ldconfig W: jack-audio-connection-kit one-line-command-in-%postun /sbin/ldconfig I don't know why mock is complaining. You've got exactly whats in ScriptletSnippets. Ignore it? rpmlint jack-audio-connection-kit-devel-0.101.1-4.fc5.i386.rpm W: jack-audio-connection-kit-devel no-version-in-last-changelog Ditto. rpmlint jack-audio-connection-kit-example-clients-0.101.1-4.fc5.i386.rpm W: jack-audio-connection-kit-example-clients no-version-in-last-changelog Ditto. W: jack-audio-connection-kit-example-clients no-documentation Ignorable. Also, I notice the man page for jackstart is getting installed even though the binary isn't. Looks like that's ultimately an upstream bug. And I see a %{__make} macro in there, as far as I know its useless, and its also inconsistent with the rest of the spec. Just use plain make. My preference would be to not use %{name} in source lines. And maybe not even in the subpackage Requires:. It should be unlikely that the package name would ever change.
(In reply to comment #24) > W: jack-audio-connection-kit one-line-command-in-%post /sbin/ldconfig > W: jack-audio-connection-kit one-line-command-in-%postun /sbin/ldconfig > > I don't know why mock is complaining. You've got exactly whats in > ScriptletSnippets. Ignore it? I believe it will stop complaining if you write one line commands like so: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig ScriptletSnippets should probably be updated.
for getting the package to build without rpath problems on x86_64 you have to add autoreconf --force --install a line before %configure
I've fixed all described issues. Please, review last update at: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack-audio-connection-kit-0. 101.1-5.src.rpm
(In reply to comment #13) > Should we start an Audio SIG? I just discovered fedora-music-list. http://www.redhat.com/mailman/listinfo/fedora-music-list Perhaps some of you were unaware as well. Feel free to subscribe...
I'm sorry I'm late to comment on this thread... too bad I was not made aware of it till today. I have not yet looked at the spec file but I would recommend packaging the clock_fix branch of Jack CVS. Otherwise Jack will not work correctly on machine equipped with Athlon X2 processors - it will use the TSC for internal timing and will (given enough time) spew loads of warning messages as the TSC's of both processors drift apart. That CVS branch takes care of that. Paul (Davis) was going to merge it (with changes) to current CVS a couple of days ago but I don't know if it was done. I'm successfully using (and packaging) the clock_fix branch.
BTW, you can grab a tarball from the SRPM here: http://ccrma.stanford.edu/planetccrma/mirror/all/linux/SRPMS/jack-audio-connection-kit-0.101.0-0.2.cvs.src.rpm (which includes a "jack-get-cvs" script) or do: cvs -d:pserver:anonymous.net:/cvsroot/jackit login cvs -z3 -d:pserver:anonymous.net:/cvsroot/jackit co -rclockfix jack I know this is going back to an earlier "release" but otherwise Jack will not work on X2 machines. Another alternative would be to extract the relevant modifications and apply as a patch to your version (I used to do that before that clockfix branch was there).
For review purposes, IMO, I'd recommend sticking with officially released sources. After initial import/build, upgrading to a cvs version could be a possibility.
> For review purposes, IMO, I'd recommend sticking with officially released > sources. After initial import/build, upgrading to a cvs version could be a > possibility. Would that be before the package is actually released to the repository? If the answer is "yes" then please ignore the following..... === ignorable stuff begins === :-) This version will not work correctly as released on x2 processors. It'd be a pretty bad introduction to Jack for users that have machines with those processors (ie: the program appears to not work). Maybe "not work" is too strong? This is what happens: Jack will start and depending on the time that has passed since the machine was booted and the amount of time the individual processors have been in power save modes[*] tons of warning messages of the type "delay of 3856.000 usecs exceeds estimated spare time of 2653.000; restart ..." will be printed by jackd (and I mean a lot of them). This will not (in my experience) translate into audible xruns, but the messages will be printed and users will immediately assume the system is broken. Another alternative: this patch applies cleanly over the last "official" version, I was using it till I switched to the clockfix branch: http://lalists.stanford.edu/lad/2006/01/att-0167/jack-clock3.patch This problem (drifting TSC's) existed in the kernel itself, it is fixed in the current fedora kernels, I think > 2.6.14 is needed. Who knows, there may be an official release coming soon with this fixed and hopefully that will happen before the package is released. [*] Jackd internally used to use the processor's TSC for timing, on X2 processors the TSC's of the two cpus can and do drift apart over time. Jack will hit false timing errors as the timing reference is initially set on one processor and later checked for elapsed time on the other. Original post when I first reported the problem (at the time I thought it was related to Ingo's -rt patch): http://sourceforge.net/mailarchive/forum.php?thread_id=8085535&forum_id=3040
Is there a reason this isn't in a release version already?
I've added the above patch. It was applied clearly. Updated version here: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack-audio-connection-kit-0. 101.1-6.src.rpm
I've managed to run into the memlock rlimit. Hydrogen seems to eat quite a bit of RAM, and jack apparently isn't very selective about what pages it locks down. I initially had my memlock rlimit set at 32mb, and Hydrogen would just crash on startup, with an out of memory error. I upped it to 64mb, and it would crash upon trying to load a song. I upped it to 128mb and that seems to be enough so far. (384mb RAM on this system) Changing the README.Fedora to say setting the limit to 1/2-2/3 of your RAM size or more is probably the best idea for now. As I review and use more audio apps I will get a better idea of what the minimum setting should be. Finals are over! My goal for today is to finish this review.
(In reply to comment #35) > I've managed to run into the memlock rlimit. Hydrogen seems to eat quite a bit > of RAM, and jack apparently isn't very selective about what pages it locks down. > I initially had my memlock rlimit set at 32mb, and Hydrogen would just crash on > startup, with an out of memory error. I upped it to 64mb, and it would crash > upon trying to load a song. I upped it to 128mb and that seems to be enough so > far. (384mb RAM on this system) > > Changing the README.Fedora to say setting the limit to 1/2-2/3 of your RAM size > or more is probably the best idea for now. As I review and use more audio apps I > will get a better idea of what the minimum setting should be. > > Finals are over! My goal for today is to finish this review. You don't say how you are starting jackd, you may try also to use the -u option, that will try to not lock pages for some common libraries: -u, --unlock Unlock libraries GTK+, QT, FLTK, Wine.
I'm using your Qjackctl package. Yeah, I've tried the unlock toolkit option and it doesn't really seem to help much...
MUST items: - rpmlint: Ok $ rpmlint jack-audio-connection-kit-example-clients-0.101.1-6.fc5.i386.rpm W: jack-audio-connection-kit-example-clients no-documentation Ignorable. - Package name: Ok - Spec name: Ok - Meets packaging guidelines: Ok - License: NEEDSWORK - Spec in American English: Ok - Spec legible: Ok - Sources match upstream: Ok - Builds: Ok - BuildRequires: Ok - Locales: Ok - ldconfig: Ok - Relocation: Ok - Directory ownership: Ok - %files: Ok - %clean: Ok - Macros: Ok - Code vs. Content: Ok - Documentation: Ok - devel package: Ok - .desktop file: n/a SHOULD: - Includes license text: Yes - Spec translations: Ok? - Mock build: Yes - Builds on all archs: Builds on i386, x86_64 - Package functional: Tested on i386, x86_64 - Scriptlets: Ok - Subpackages: Ok NEEDSWORK: jack is part GPL and part LGPL. The License: line should probably be set to GPL/LGPL --enable-shared isn't really necessary, it should be default. You should add a -p flag to the line that copies README.Fedora, to preserve the timestamp as advised in the packaging guidelines. I notice in the main package there is: %dir %{_libdir}/jack And in the devel package: %{_includedir}/jack Which seems inconsistent. I remember reading a discussion somewhere about the subtleties of directories, but I forget the details. Near as I can tell the directories are properly owned in both, is there a difference? I would get rid of the %dir tag unless there's a reason for it I'm not aware of. And its also a good idea to put trailing slashes on directories in %files, to make it more apparent its specifying a directory. Fix these minor issues and this package is approve-able in my opinion. I am not a sponsor so I can't give final approval. Or sponsor. ;P Okay so its now 5:45am the next day. I'm going to bed. :)
(In reply to comment #38) > I notice in the main package there is: > > %dir %{_libdir}/jack > > And in the devel package: > > %{_includedir}/jack > > Which seems inconsistent. I remember reading a discussion somewhere about the > subtleties of directories, but I forget the details. Near as I can tell the > directories are properly owned in both, is there a difference? I would get rid > of the %dir tag unless there's a reason for it I'm not aware of. The %dir tag means "include the directory but not the directory's contents". It's used where you don't want all of a directory's contents in a package, e.g. if some of the contents belong in a sub-package rather than the main package.
Ah, that was it. Also I overlooked the following line. %dir %{_libdir}/jack %{_libdir}/jack/*.so Is that still different then just specifying %{_libdir}/jack/ ? Obviously it would just include .so files, but in this case that's all that seems to be there.
We need to own the directory itself. Due to we can't use the trailing slash in form like: %{_libdir}/jack/
Updated version here: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack-audio-connection-kit-0. 101.1-7.src.rpm All changed except %files section,
(In reply to comment #41) > We need to own the directory itself. Due to we can't use the trailing slash in > form like: > %{_libdir}/jack/ Actually: %{_libdir}/jack/ works just fine in this case. The directory is owned as it should be.
Really my beef here is with inconsistency. You *are* already specifying the include dir in the devel package as simply "%{_includedir}/jack", I would prefer if you specified the lib dir in the main package the same way. And putting trailing slashes on the directories is nicer for Q/A, otherwise you can't really tell for sure from the SPEC alone that its supposed to be a directory. But I think we're mostly just nitpicking at this point. :) Everything else looks good to me. Someone please approve/sponsor, many things depend on jack...
I think the Package Guidelines should be included this interesting moment. Anyway, I uniform directories items in the spec. Updated version here: ftp://andriy.asplinux.com.ua/pub/people/andy/extras/jack-audio-connection-kit-0. 101.1-8.src.rpm
I agree with the review of comment 38. Apply for cvsextras in the account system, I'll sponsor.
Sorry for my silence - bugzilla was down for me. John, I've done all propositions in last update. Is it indicate that any reviewer can approve this package now?
I think the implication is John approves. :) Shouldn't this block FE-ACCEPT now?
At this point nobody has even signed on to review this package. It's still unassigned and blocking FE-NEW. Andy, have you applied for cvsextras membership yet? I don't recall seeing the request for sponsorship. In case you need them istructions are at http://fedoraproject.org/wiki/Extras/Contributors#head-a89c07b5b8abe7748b6b39f0f89768d595234907 John has agreed to sponsor you, so you should go ahead and apply.
Well, I would have, but FESCo recently made explicit statements that I shouldn't if I'm not a sponsor. I suppose now that he's sponsored I can do it...
Jason, I am newbie at all. I'm starting the membership process. When I finished yet I'll tell here.
Reassigning to me, as first reviews need to be from sponsors. http://fedoraproject.org/wiki/Extras/Contributors Approved, be sure to apply for cvsextras.
John, I've done register as fedora membership, but cvsextras group is unapproved for me now. What do I need to do?
(In reply to comment #53) > John, I've done register as fedora membership, but cvsextras group is unapproved > for me now. What do I need to do? I've approved your cvsextras. You now may setup your client, import, and build.
I just yum installed jack-audio-connection-kit from extras-development. Congratulations and thank you! Are you planning on putting it in the FC-5 branch as well? Thanks!
Anthony, I've put request to wiki already. I'm wating to answer now. Please, keep track the events there.
Package Change Request ====================== Package Name: jack-audio-connection-kit New Branches: EL-4 EL-5
cvs done.