Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move data files to /usr/share on Linux #195

Closed
wants to merge 12 commits into from

Conversation

turboencabulator
Copy link
Contributor

Basic idea is to make it easier to create a native package on Linux, but the program is searching for data files relative to its own location. Instead use QStandardPaths to find the data files so we can place everything in their customary locations.

The last few commits fix some complaints by lintian for the Debian package.

* Fix whitespace at EOL and EOF; replace tabs

* Normalize line endings
Combine the Android and non-Android implementations.  Only difference
now is the path to the waveform data.

Remove arbitrarily-sized buffers and most C-style string handling
function calls.  Use native Qt string methods instead; this should
improve memory safety.
Use QString::asprintf() instead of a buffer.
Convert to a C string using qPrintable().
Skip installing the .exe and .bat files on Linux.

Other platforms could also search QStandardPaths::AppDataLocation but I
am not familiar with how they are packaged.  The locations searched
corresponds to $XDG_DATA_DIRS; prepend the right path to it when running
from the AppImage container.
Fix the labrador -> Labrador symlink so that it's created in
${INSTALL_ROOT} when supplied; previously it was installed directly to
/usr/bin.  This symlink may not be necessary anymore.
New list generated by matching up the output of
`readelf -d /usr/bin/Labrador | grep NEEDED`
with the available Debian packages.
@mi-hol
Copy link

mi-hol commented Jan 12, 2025

@EspoTek this PR was never commented, probably because it is a very big one, but at least for some parts (i.e. commit 19ae371 ) I'd see benefits.
May I kindly ask for your view?

@EspoTek
Copy link
Owner

EspoTek commented Jan 15, 2025

@EspoTek this PR was never commented, probably because it is a very big one, but at least for some parts (i.e. commit 19ae371 ) I'd see benefits. May I kindly ask for your view?

Honestly, at this stage it's not something I'd want to merge. It's just too out of date and would be a lot of work to bring in.

@EspoTek EspoTek closed this Jan 15, 2025
@mi-hol
Copy link

mi-hol commented Jan 15, 2025

Well from the viewpoint of a single (overloaded) maintainer, I fully understand the answer but have you considered to ask some of the most active contributors to step in as co-maintainer(s)?
Such a step could have many benefits for the product and yourself

@EspoTek
Copy link
Owner

EspoTek commented Jan 15, 2025

Are you offering to co-maintain?

@mi-hol
Copy link

mi-hol commented Jan 15, 2025

yes, I was a product owner once upon a time

@EspoTek
Copy link
Owner

EspoTek commented Jan 15, 2025

Fantastic! How do I add you?

@mi-hol
Copy link

mi-hol commented Jan 15, 2025

@mi-hol
Copy link

mi-hol commented Jan 15, 2025

@EspoTek may I suggest to reopen this PR too?
@turboencabulator would you mind to assess feasibility of merging this PR?

@turboencabulator
Copy link
Contributor Author

I can take another look when I get a chance. I know the first two commits were added and later reverted for some unknown reason, but they made the rest somewhat simpler to review/understand. Those two might be the bulk of the differences.

@mi-hol
Copy link

mi-hol commented Jan 15, 2025

@turboencabulator thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants