Summary: | media-sound/ladish - Successor of media-sound/lash. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | tokiclover <tokiclover> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | UNCONFIRMED --- | ||
Severity: | enhancement | CC: | dominique.c.michel, futurehypoon, gerion.entrup, ibuyandtrade0+bugs.gentoo.org, kripton, mgorny, nedko, proaudio, proxy-maint, simon.vanderveldt+gentoo, yngwin |
Priority: | Normal | Keywords: | EBUILD, PATCH, PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/34884 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 923642 | ||
Bug Blocks: | |||
Attachments: |
media-sound/ladish-9999.ebuild
media-sound/ladish-1.ebuild Manifest media-sound/metadata.xml media-sound/files/lash-1.0.pc.patch ladish-1.ebuild from proaudio (revision 2) ladish-9999.ebuild form proaudio overlay (revision 1) media-sound/ladish-1-r2.ebuild lash to ladish compatibility ABI compat report public ABI compat report |
Description
tokiclover
2012-11-12 21:27:46 UTC
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. |