Created attachment 329388 [details] media-sound/ladish-9999.ebuild media-sound/ladish is the successor of media-sound/lash which is a complete re-written the latter. No need to say that the former is very useful and handy compared to the later which has an option to build lash libraries and python bindings. It has a very nice and usefull media-sound/patchage [gtk] gui which can save/load session and a nice status bar. There are an ebuild in ladi overlay but I won't recommand that one because the overlay is not that oftenly updated and I remember fighting to only contact the maintainers to update missing dependency that I did not try again. I will attach the current ebuilds+Manifest but I will not update this bug as everything is on my [bar-]overlay at https://github.com/tokiclover/bar-overlay.
Created attachment 329390 [details] media-sound/ladish-1.ebuild
Created attachment 329392 [details] Manifest
Created attachment 329394 [details] media-sound/metadata.xml
Created attachment 329402 [details] media-sound/files/lash-1.0.pc.patch lash-1.0.pc file wich correct the wrong or old media-sound/lash pkgconfig file. Actually, the header files are installed in '${prefix}/include' and not in '${prefix}/include/lash-1.0'. And anyway, even correcting the location of the heder files, some pkg like media-sound/hydrogen have hard coded header files like '<lash-1.0/lash/$headerfile.h>' instead of using 'pkg-config --cflags lash-1.0' and include header file in a standard way like '<lash/$headerfile.h>'. I will be posted a huge patch to add this package in a 'lash? ( || ( media-sound/ladish media-sound/lash ) )' for the related ebuilds. Hydrogen compile just fine with media-sound/ladish. Last but not least, I had to include a symlink to the ebuild 'ln -s ${prefix}/include/{,lash-1.0/}lash' to cope with that mess.
And yes, media-sound/lash was not updated for months so there is no particular reason to keep maintaining it and leave the new rewrite on the side.
Would love this ebuild, too. ladi and proaudio overlay defines a virtual/liblash, so the user could choose his favorite implementation. Both overlays workaround the hardcoded lash dependencies in the official tree. At least it would be useful to create a virtual/liblash, that link to media-sound/lash, so the workarounds are not necessary. I just looked at the last commits. The last ladish commit was 6 month ago, the last lash commit was 2009.
If the problem is a missing maintainer, I am willing to maintain this.
See here, too: https://bugs.gentoo.org/show_bug.cgi?id=504884
*** Bug 504884 has been marked as a duplicate of this bug. ***
(In reply to gerion from comment #7) > If the problem is a missing maintainer, I am willing to maintain this. That's something that can happen, yes; are you okay with the attached files?
No, there are newer more tested ones from the proaudio overlay I would prefer (much cleaner and use of python and waf eclass). Unfortunately the website of ladish is down, so I can't test ladish-1 (download fails), ladish-9999 compiles fine and the ebuild looks good to me. See attached ebuilds.
Created attachment 373454 [details] ladish-1.ebuild from proaudio (revision 2)
Created attachment 373456 [details] ladish-9999.ebuild form proaudio overlay (revision 1)
See also here for the changelog and metadata.xml: http://svnweb.tuxfamily.org/filedetails.php?repname=proaudio%2Fproaudio&path=%2Ftrunk%2Foverlays%2Fproaudio%2Fmedia-sound%2Fladish%2FChangeLog http://svnweb.tuxfamily.org/filedetails.php?repname=proaudio%2Fproaudio&path=%2Ftrunk%2Foverlays%2Fproaudio%2Fmedia-sound%2Fladish%2Fmetadata.xml
9999 compiles fine with all combination of useflags and configure output matches with the useflag configuration. The useflag dependencies are also correct (python needs lash).
Is it meaningful to provide a "debug" useflag? The waf configure script says: "--debug Build debuggable binaries" Then this line has to be added: '$(usex debug --debug "")'
Created attachment 410682 [details] media-sound/ladish-1-r2.ebuild Thereby attaching a new unfied versioned/live ebuild with multilib support; so, a live version can be obtained by copying this one. NOTE: I added proaudio herd, so, @yngwin can commit the addition to the main tree after a discusion in @pro-audio thread in the forums. Thanks.
How and why is proxy-mantainers added here? Does tokiclover wish to proxy maintain the package under the project / herd? proxy-mantainers does new packages like this now.
How can we progress this issue? Adding the virtual/liblash would be a simple first step, then updating the packages that current hard depend on lash and adding ladish can be done after that. Does that make sense?
That's the ideal solution, add both virtual/liblash[1] and media-sound/ladish[2] to have the newer ladish[2] choice and offer the possibility to use the newer library by providing a virtual package. This the solution used in proaudio overlay or in my overlay. So fee free to pull the ebuilds of proaudio or bar overlay. I would have thought than @yngwin would have pulled those two ebuilds in the main tree since ages ago. [1]: https://github.com/tokiclover/bar-overlay/tree/master/virtual/liblash [2]: https://github.com/tokiclover/bar-overlay/tree/master/media-sound/ladish
Do the both packages provide ABI-compatible libraries? If not, then the virtual is not an option.
I discussed by emails with Nedko Arnaudov, the developper of ladish. He just answered me: "ladish has API compatible implementation of liblash. The ladish liblash implementation talks to ladish daemon." I just asked fot the ABi compatibility, but I suppose it is OK. We provide ladish from years into the pro-audio overlay, and we never get a complain about it.
@Michał Górny AFAIK they are compatible, though I don't know for sure if they are ABI compatible. How can we check that/make sure that that's the case?
I suppose you could try using dev-util/abi-compliance-checker. It's a really cool tool. You should be able to find some good docs online.
Created attachment 493990 [details] lash to ladish compatibility
I made that test, and it look like they are not ABI compatible. But I am not sure because it is the first time I made such a test. So someone more capable than me need to take a look.
So, what is the right solution? I guess something like a) as ladish is the successor of lash, remove lash and add ladish, and modify the depend of the few portage packages depending on liblash - if they run with ladish, remove them otherwise. b) keep lash, provide ladish, and make a depend like lash? ( || ( media-sound/lash media-sound/ladish[lash] ) ) in the packages which depend on liblash.
The public ABI is actually 100% compatible, see output below: $ abi-compliance-checker -l lashpublic -old first-binary.dump -new second-binary.dump Preparing, please wait ... Comparing ABIs ... Comparing APIs ... Creating compatibility report ... Binary compatibility: 100% Source compatibility: 100% Total binary compatibility problems: 0, warnings: 53 Total source compatibility problems: 0, warnings: 0 I guess that's the part of the ABI that's actually important, right?
Simon, could you attach the results?
Created attachment 494258 [details] ABI compat report Attached the compat report for the entire ABI Created this way: emerge -1av lash abi-dumper /usr/lib64/liblash.so.1.1.1 -o lash.dump -lver 0 --search-debuginfo=/usr/lib/debug emerge -Cav lash emerge -1av ladish abi-dumper /usr/lib64/liblash.so.1.1.1 -o ladish.dump -lver 1 --search-debuginfo=/usr/lib/debug abi-compliance-checker -l lash2ladish -old lash.dump -new ladish.dump
Created attachment 494260 [details] public ABI compat report Attached the compat report for the public ABI Created this way: emerge -1av lash abi-dumper /usr/lib64/liblash.so.1.1.1 -o lash-public.dump -lver 0 -public-headers /usr/include/lash-1.0/lash/ --search-debuginfo=/usr/lib/debug emerge -Cav lash emerge -1av ladish abi-dumper /usr/lib64/liblash.so.1.1.1 -o ladish-public.dump -lver 1 -public-headers /usr/include/lash-1.0/lash/ --search-debuginfo=/usr/lib/debug abi-compliance-checker -l lash2ladishpublic -old lash-public.dump -new ladish-public.dump
Michał what do you think? If the public ABI is compatible both of them can be used interchangeably, right?
In that case, yes, they can.
OK, then in reply to the question you asked > So, what is the right solution? I guess something like > > a) as ladish is the successor of lash, remove lash and add ladish, and > modify the depend of the few portage packages depending on liblash - if they > run with ladish, remove them otherwise. > > b) keep lash, provide ladish, and make a depend like > lash? ( || ( media-sound/lash media-sound/ladish[lash] ) ) > in the packages which depend on liblash. I would suggest to add ladish and remove lash. Ladish is lash's successor and since the ABI is compatible ladish can simply replace it.
media-sound/cadence prints error messages to the console when I try to launch claudia. I assume it's because ladish is not installed. Cadence can't depend on ladish because there's no ladish ebuild (in the main tree, at least). /usr/bin/python3.9 /usr/share/cadence/src/claudia.py & Using Tray Engine 'Qt' Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/dbus/bus.py", line 177, in activate_name_owner return self.get_name_owner(bus_name) File "/usr/lib/python3.9/site-packages/dbus/bus.py", line 361, in get_name_owner return self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH, File "/usr/lib/python3.9/site-packages/dbus/connection.py", line 652, in call_blocking reply_message = self.send_message_with_reply_and_block( dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.ladish': no such name During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/share/cadence/src/claudia.py", line 2753, in <module> gDBus.ladish_control = gDBus.bus.get_object("org.ladish", "/org/ladish/Control") File "/usr/lib/python3.9/site-packages/dbus/bus.py", line 241, in get_object return self.ProxyObjectClass(self, bus_name, object_path, File "/usr/lib/python3.9/site-packages/dbus/proxies.py", line 250, in __init__ self._named_service = conn.activate_name_owner(bus_name) File "/usr/lib/python3.9/site-packages/dbus/bus.py", line 182, in activate_name_owner self.start_service_by_name(bus_name) File "/usr/lib/python3.9/site-packages/dbus/bus.py", line 277, in start_service_by_name return (True, self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH, File "/usr/lib/python3.9/site-packages/dbus/connection.py", line 652, in call_blocking reply_message = self.send_message_with_reply_and_block( dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ladish was not provided by any .service files
The ladish upstream here, The ladish gtk frontend currently still depends on gtk2. Cadence's Claudia being another frontend for ladishd, can depend on ladish ebuild that does not provide the optional gtk frontend gladish. I'm maintaining an ebuild in the LADI overlay: https://github.com/LADI/os-gentoo-overlay/blob/stable/media-sound/ladish/ladish-1.9999.ebuild
The ebuild in the pull request build without gladish and thus there is no gtk(2) dependency. media-sound/cadence provides claudia - Qt frontend for media-sound/ladish
In the ebuild in the pull request, into RDEPEND, it is: lash? ( !!media-sound/lash ) I don't find this to be the right solution for a main tree ebuild, that because media-sound/ladish[lash] will block media-sound/lash and all the ebuilds that depend on it. To solve that blocking, I can see 2 possibilities: 1) media-sound/lash get removed from the tree, which imply that line can be deleted and the depends on media-sound/lash in the tree must be replaced by media-sound/ladish[lash]. In that case, we must be sure the main tree contain no ebuild that depend on media-sound/lash[gtk], as ladish doesn't provide it, or find a way to fix it. 2) Use a virtual: That line can be removed, all the lash ebuilds in the tree must depend on virtual/lash instead of media-sound lash, and virtual/lash take care of media-sound/lash|ladish
Using equery and after simplification, I get that list of package that depend on media-sound/lash: ♯ In the main tree: media-sound/amsynth media-sound/fluidsynth media-sound/hydrogen media-sound/jack-keyboard media-sound/jack-rack media-sound/jack-smf-utils media-sound/seq24 media-sound/timemachine media-sound/vkeybd media-sound/zynaddsubfx ♯ Not in main tree: media-sound/jackmixdesk media-sound/museseq media-sound/sequencer64
For the one into the main tree, they all have a lash USE flag, they all compile and are working fine with ladish, and no one of them depend on lash[gtk], but only on lsh. Which imply media-sound/ladish can be used as a replacement of media-sound/ladish, so that media-sound/lash can be removed from the tree and it is no need for a virtual. That's my preferred solution because it add no complexity into the main tree. At that point, it would be great if some devs can comment on this and say what must be done. I guess that one bug must be open for each of media-sound/amsynth media-sound/fluidsynth media-sound/hydrogen media-sound/jack-keyboard media-sound/jack-rack media-sound/jack-smf-utils media-sound/seq24 media-sound/timemachine media-sound/vkeybd media-sound/zynaddsubfx I am not sure if that bug can centralize the progress of the other bugs, or if another bug must be open for that.
I made bug 932851 for virtual/lash
