Yeah, that is what I mean. Alien, RPMBuild, and Checkfile will do that for you, or at least ask you questions if it cannot find the information in the tarbal.
I suggested on calling the local Red Hat/Fedora gods on the forvm. I am a Debian and ArchLinux boi. I basically just keep the RHEL systems alive at work but they are still running RHEL 5, 6, and 7 here so, no real updates.
Well Alien is available, but I always thought that is just to convert different package formats? Would that help me when there is no package available in the first place? I mean if I am compiling from scratch and then itâs just copying files around, that wouldnât work with alien, or so I thought?
I donât know. I have not used Alien since like 2005.
You could install checkinstall from git.
http://checkinstall.izto.org/download.php
But if you just want to know where files are going, tee or some redirect of the output to a file is your best bet. If you want to manage stuff in the future, build the package to native and then use checkinstall.
That would require that make install is telling me what itâs writing/copying where, right? But the premise of my question was how to do it if it is not telling me that 
Iâll look into checkinstall tho
I am sorry, I think I blocked out that bit of information. Yeah, the only other way is to look at the make files. That will tell you where it installs files. but that is an icky way of going about it, unless you just want to know.
yeah and also for some projects (like the one I linked) itâs not as straight forward because there is not just a simple list of files itâs copying. For this particular project there is not even a regular make step, they go straight to make install which (from what I can tell) only builds a few temporary files (not the actual .so, and then calls libtool which builds the actual .so file and installs it. I tried looking through the files to find what it is actually doing but I donât even know what Iâm looking for 
edit: also just noticed, the package is called rpm-build, while the command is called rpmbuild. Just gotta figure out how this works⌠maybe
1 Like
For me, that sounds suspect⌠but if Winamp nostalgia is that important. Have you looked into Audacious , Quad Libet, Amarok, Strawberry, or Rhythmbox?
I used to use Audacious but eventually shifted to Rhythmbox in 2015 and have been using them. they both have a Winamp Classic interface if you want it. I have not used the other ones mentioned. Those two are the only music players that I liked with the Winamp Classic interface that are still being developed. And honestly, I donât even use the winamp interface anymore.
**Edit
The other ones mentioned are being developed but I have never used them. just to clarify.
Also Rhythmbox was the old Gnome Music until our lord and savior decided that he needed to dumb down the music player in Gnome and made the Rhythmbox devs start hosting their own project as the unofficial offically functional music player for gnome.
The player itself is in the official Fedora repo, the github thing is just a plugin.
I tested a few different audio players on Linux already and DeaDBeeF is the closest I could get to what I had with Foobar2000 on Windows.
I got a few plugins from GitHub, most of them self compiled and after compilation they just provided an .so that I copied into the plugins directory myself. This is the first one I have seen that does it this way.
gotcha.
so you should be find with an rpmbuild -bb <source package>. If that fails, then you can do rpmbuild --rebuild <source package>.
The first will should go through the /configure, make, and then give you binary rpm file that you will then manually install. It may ask you questions during this process.
The second option should do the same thing, but it will try to build the spec file based on what it sees during the make stage. It should only ask you questions if it cannot figure anything out. I donât remember if it will automagically install the rpm for you.
What does the plugin do?
It provides the integration for the Media Controls in KDE (and presumably other DEs since it is a freedesktop standard?), so I can also control it via KDEConnect:
I tried executing rpmbuild inside the source directory, in the parent using rpmbuild -bb <directory>, and on the archive, but it doesnât seem to take any 
rpmbuild -bb deadbeef-1.13/
error: File /home/tarulia/Documents/dev/deadbeef-1.13/ is not a regular file.
Yeah no shit it is a directoryâŚ
Also according to man rpmbuild:
-bb Build a binary package (after doing the %prep, %build, and %install stages).
So that would still require a spec file, no?
It did not in the past. Basically those stages is where it would grab info and create the spec file as it went.
how about rpmbuild --rebuild <source dir>?
** If either commands do not work on the tar.gz, then I donât know what to say. I used it before RPM4 was a thing. I think the RPM world has finally converged on one rpm standard. I just donât remember if RPM4 won the war or not. RPM4 attempted to function more like debian packages.
[tarulia@localhost dev]$ rpmbuild --rebuild deadbeef-1.13/
Installing deadbeef-1.13/
error: deadbeef-1.13/: read failed: Is a directory (21)
error: deadbeef-1.13/ cannot be installed
I also tried re-packaging the directory into a tar (thought that it might have issues with the .tar.xz), but then it wants a spec file again:
[tarulia@localhost dev]$ rpmbuild --ti mpris.tar
error: Failed to read spec file from mpris.tar
It just assumes there is one in the tar 
Which is also what the documentation says.
Why does it have to be so complicated 
1 Like
Fedora mate. /s
What happens when you just run make in the archive folder. If it builds temp files, I assume the make install then has buildtools work on those filse.
It builds the temp files, but not the .so.
Yes that is my understanding as well. From what I can tell make install runs libtool which builds the .so and puts it into the pre-defined directory at the same time.
Re-running just tells me thereâs nothing more to do:
[tarulia@localhost deadbeef-mpris2-plugin]$ make
CC src/mpris_la-mpris.lo
CC src/mpris_la-mprisServer.lo
CC src/mpris_la-logging.lo
CCLD mpris.la
[tarulia@localhost deadbeef-mpris2-plugin]$ make
make: Nothing to be done for 'all'.
It is the weirdest build system I have come across so farâŚ
Ah, okay. so the plugin is written in C++. So LO files are library objects (like DLLs or SOs). libtool is then possibly converting those files in to .so files. either way, those files will be moved to one of your lib folders
**Edit,
the .la file should be human readable and should tell you what libtool is to actually do with the .lo files. If my memory serves me right. I have not done anything with C+ in ages.
Seems to be C but either way yeah, thatâs pretty much how it appears to work. Would be nice if there was a local build option so it would just generate the .so file somewhere in the source directory. The default location it put it into didnât work for me anyway, had to put it into ~/.local/lib/deadbeef instead (which I prefer anyway instead of systemwide).
1 Like
While going through all of that effort, you can also run fubar under wine. Sacrilege, I know but, if you like it, why change?
But I would rather you run native apps.