Re: Orphaning qjackctl
On 9/28/20 1:51 AM, Ankur Sinha wrote: Hi Fernando, Hi Ankur, I'm a packager sponsor. I'm happy to take over qjackctl and sponsor Christoph as a co-maintainer to help look after it. Could you please give me ownership of the package? My FAS is: ankursinha. Thank you so much for helping with this! Wonderful! I just gave you ownership... rpms / qjackctl Created 3 years ago Maintained by ankursinha It would be great if the program could be upgraded to 0.6.3 to begin with... :-) Thanks again! Best regards, -- Fernando ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning qjackctl
Hi all, This wants to go to a new owner: https://src.fedoraproject.org/rpms/qjackctl I am the "official" maintainer, something I had completely forgotten about (this was a VERY long time ago). Orcan (Ogetbil) took care of it for a long time but now Christoph Karl (copied) would like to take over (and alerted me to the fact that it is my package!) Looks like this is the way to get this rolling... (let me know if there is anything else I need to do) Thanks, -- Fernando ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
login/logout hooks in fedora 17?
Hi all, Any suggestions on how I may run a script when a user logins or logouts of the graphical console? I used to do this with gdm by customizing the Post* and Pre* scripts in /etc/gdm. I see that the login/logout process is (appears to be) controlled by systemd. What would be a good approach to getting the system to run a script before a user logs in and after a user logs out (ie: for local users sitting at the console - probably now called a seat if I understand things correctly). Thanks for any advice! -- Fernando -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 12/23/2010 01:52 PM, Lennart Poettering wrote: On Mon, 20.12.10 13:07, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote: I raise this issue because The API for /dev/shm is shm_open() statement above means to me that in the future there will be no file api access to a ram mounted filesystem in Fedora (I understand that this is my own conclusion, but I can't see any other given the wording of the statement above). Before someone implements that idea, please consider the needs of a filesystem in ram for such uses as those mentioned in this thread (and that is supported by the Fedora distribution by default). Just in case... This too appears to be a good usecase for XDG_RUNTIME_DIR btw. If I understand correctly this would only be available for logged in users only. If /var/run is going to be a tmpfs in fc15+ (if I understand correctly another message you posted in this thread) then that would appear to be a better option to my eyes (the main Jack developers might have other opinions/ideas, I'll try to keep them posted). -- Fernando -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 12/22/2010 12:56 PM, Casey Dahlin wrote: On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote: This is from Paul Davis, the main architect of Jack (I forwarded him your post): this isn't exactly correct. in /dev/shm on linux we have: (a) unix-domain sockets for non-RT communication with the server Perhaps these could become abstract domain sockets. Could you explain a bit perhaps? I'm not familiar with them... (or maybe you have a url I could surf to?) Anyway, the main concern re: the subject of this thread is: (b) FIFOs for RT wakeups (this could use semaphores now) we do care about the performance of (b) These have to be very fast as they are used for waking up the next client in the round robbin transfer of control between jackd and its clients (and that's why they are in /dev/shm). -- Fernando -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 12/14/2010 09:37 PM, Lennart Poettering wrote: On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote: The project is a database system that creates and dlopen()s plugins on-the-fly, for better performance on [long-running] queries. We like the speed of creat+write+close+open+read+mmap on /dev/shm. If /dev/shm and /tmp both become off limits, then what is the recommended replacement location? The API for /dev/shm is shm_open(). Unless you are using that API you shouldn't really touch /dev/shm. What's wrong with /tmp for your use cases? [sorry to be late for this thread, I understand the original message should be treated as a bug of systemd not reapplying stuff from fstab after it was done with its own internal needs] I would like to bring to the attention of the list another current usage of the tmpfs mounted on /dev/shm in Fedora packages: Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the file api (apologies if my wording is not absolutely correct in unix terms) on the tmpfs filesystem that is mounted on /dev/shm for a very long time (10 years?). /tmp is not useful to Jack because Jack's internal communication pipes can't be stored in any disk based journaled filesystem as the latencies involved in accessing them cause glitches in the audio streams handled by Jack. I raise this issue because The API for /dev/shm is shm_open() statement above means to me that in the future there will be no file api access to a ram mounted filesystem in Fedora (I understand that this is my own conclusion, but I can't see any other given the wording of the statement above). Before someone implements that idea, please consider the needs of a filesystem in ram for such uses as those mentioned in this thread (and that is supported by the Fedora distribution by default). Just in case... -- Fernando -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 12/20/2010 02:17 PM, Adam Jackson wrote: On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote: I would like to bring to the attention of the list another current usage of the tmpfs mounted on /dev/shm in Fedora packages: Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the file api (apologies if my wording is not absolutely correct in unix terms) on the tmpfs filesystem that is mounted on /dev/shm for a very long time (10 years?). /tmp is not useful to Jack because Jack's internal communication pipes can't be stored in any disk based journaled filesystem as the latencies involved in accessing them cause glitches in the audio streams handled by Jack. This is right and wrong. Right! Thanks very much for looking at this in such detail (I presume you looked at the 1.9.6 code base?). JACK uses /dev/shm for two purposes on Linux [1]. The first is as the definition of what its configure script calls HOST_DEFAULT_TMP_DIR. This path is only used as a name to which to attach the jack sockets. The extent to which this will _ever_ touch the disk, even on a journaled filesystem, is: - eventually, the inode for that socket and the dnode for the containing directory will have to be written to the disk, once. - under memory pressure the vfs may decide to throw away the inode cache for that socket, which would then have to be re-read from disk for subsequent connecting JACK clients. In other words, these are setup costs, not maintenance costs. This may cause glitches in a realtime scenario to the extent that clients are created and destroyed, but in general I submit that the cost of exec() of those new clients is going to dwarf the cost of the inode cache miss for the JACK socket. [2] My experience (caveat: a long time ago, maybe everything has changed internally in both jack and the kernel and that has invalidated my experience cache :-) was that using /tmp would lead to constant - not all the time, but very frequent and not correlated with client connection/disconnection - xruns (glitches in the audio), using /dev/shm would fix that immediately. That was why things were moved over to /dev/shm if I remember correctly. The other usage of /dev/shm is for actual shared memory segments, but the shm layer in jack uses shm_open() and friends, so the use of /dev/shm is simply glibc's implementation detail. Thanks, -- Fernando [1] - I have read the JACK source literally once in my life (ie, just now), and I do not claim to be an expert, but this is all I was able to find. [2] - Though, should someone feel especially enterprising, it would probably be a worthwhile optimization to tweak the inode cache replacement to prefer dropping regular files to sockets, on the grounds that IPC should not be a disk operation. If it doesn't already; I haven't looked. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 12/20/2010 05:26 PM, Fernando Lopez-Lezcano wrote: On 12/20/2010 02:17 PM, Adam Jackson wrote: On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote: I would like to bring to the attention of the list another current usage of the tmpfs mounted on /dev/shm in Fedora packages: Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the file api (apologies if my wording is not absolutely correct in unix terms) on the tmpfs filesystem that is mounted on /dev/shm for a very long time (10 years?). /tmp is not useful to Jack because Jack's internal communication pipes can't be stored in any disk based journaled filesystem as the latencies involved in accessing them cause glitches in the audio streams handled by Jack. This is right and wrong. Right! Thanks very much for looking at this in such detail (I presume you looked at the 1.9.6 code base?). This is from Paul Davis, the main architect of Jack (I forwarded him your post): this isn't exactly correct. in /dev/shm on linux we have: (a) unix-domain sockets for non-RT communication with the server (b) FIFOs for RT wakeups (this could use semaphores now) (c) shared memory created via either the sysv or posix shm API we don't care about the unix domain sockets' performance characteristics, but its convenient to have them in a known location that happens to be close to where (b) is located. we do care about the performance of (b) (c) just works. -- Fernando -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: jack2
On Tue, 2010-07-20 at 10:04 -0400, Orcan Ogetbil wrote: On Tue, Jul 20, 2010 at 2:30 AM, Andy Shevchenko wrote: On Tue, May 11, 2010 at 6:17 PM, Orcan Ogetbil wrote: For F-13 it may be a little late. So shall we make this an F-14 target? I see new commit to the koji. Thanks for working on jack2, but the No problem. Although I was the one collecting the pieces, it was rather a collective work. Thanks to everyone who is involved. We need to do some testing now, and clean up the glitches before F-14. question is why the package name is jack-audio-connection-kit? As far as I know the package name should be derived from the main tarball name. I thought about doing that once. Jack1's and jack2's source codes are distributed on the same website [1], We know that JACK stands for Jack-Audio-Connection-Kit. So there shouldn't be any confusion. Sadly, there is no unique agreement on the package name across distribution. As far as I know, we were the only distro distributing jack1 under the full name jack-audio-connection-kit. There is also a very different project called jack [2], although we don't have it on Fedora. This adds more to the subtlety as Mandriva distributes this jack as just jack. What do other maintainers think? jack-audio-connection-kit is the official name of the project and it has been the suggested name for packages - I could try to dig through my very old email and find an email from Paul on the subject. I have used that name since 2001 or so (version 0.37) - I may have been one of the first if not the first to package Jack as part of Planet CCRMA. The jack1 tarball is actually named jack-audio-connection-kit, not jack. As mentioned above jack2 is a different code base that implements the same official jack API and was developed independently. Its developer chose to name the tarball jack (I don't know why, we could ask). Who knows what the future could bring. I certainly don't know :-) When/if jack2 becomes the official jack maybe the tarball will change to jack-audio-connection-kit. Of jack1 could evolve, supplant the current jack2 as the next version, and the tarball would still be jack-audio-connection-kit. I would keep the current name. -- Fernando -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
