I did test it and it did work for me, bit i have had also local builds on my phone
Maybe I do not get how it is supposed to work but it does exactly how it it is written. That means opens sailfishos.org url.
start it from command line and check the log
i assume that python did not get initialized properly
and you should be able to see that on the console.
you can look on the phone via ssh or in terminal and check that python was deployed
start with:
/usr/bin/sailfish-qml harbour-tidalplayer
look here:
/usr/share/harbour-tidalplayer/
inside should be a python folder and a qml folder
in the python folder should be tidalapi folder with a bunch of py files
Could still be a missing python package ā¦
I had the problem one year ago (https://forum.sailfishos.org/t/tidal-app-discussion/16657/24)) due to missing python3-dateutil
.
python3-python-dateutil published by lpr
I have also future installed
In the past this (āadd lpr repoā) has shown many times to break the upgrade to the next SailfishOS release later; hence it is a ābad ideaā¢ā, IMO.
If this package is really needed (and a non-alpha release should not depend on non-default dependencies, i.e. others than the ones provided by Jolla or in oneās own RPM repository, the latter may be the SailfishOS Chum community repo), I strongly suggest to provide it by other means than one of lprās repos at OpenRepos.
P.S.: If manually installing these Python packages is defined as the usual procedure for alpha-testers to satisfy the dependencies of this native Tidal app, these alpha-testers should download packages separately and install them by pkcon install-local <space-separated-list-of-package-paths>
Thank you for the details.
I hope somebody can pick up the task.
P
If someone gives me a heads up when thereās a new tag available, Iāll push it. Otherwise, you need to get an obs account and then we can make one of the active users maintainer.
Iām looking at the dateutil and futures issue. I also use those somewhere, but I think I supply them with the rpm.
Ok, Iām going to suggest a two pronged approach.
-
First we supply them using the technique I often use Packaging Python dependencies, a not-yet-guide - #17 by poetaster
-
When time is there, I will package those (dateutil and future) on chum
-
requires picking a release, including the directories of the sources and adding a line to the spec file.
EDIT: or, we simply use the install lib approach:
In project file (this is the way itās done in audiocut):
python.files = lib/pydub/*
python.path = "/usr/share/harbour-audiocut/lib/pydub"
and in my qml python I include it:
import sys
sys.path.append('/usr/share/harbour-audiocut/lib/')
This is the most simple approach.
Sigh. Or we use git submodules just the way the tidal apis are pulled. Iāll look at this approach.
EDIT: So, future builds on github and chum, dateutls does not. Iām going to split the difference:
- first get dateutil in a separate package on chum
- push the build that works (with future) to chum proper after some testing
- move future to itās own package. this is where I wish @nephros had gotten to these
Huh. Packaging python. So much fun.
Since some PEP decided that now every module can require their own bespoke build system, you add one depencency and have to support yet another builder. Which will have dependenciesā¦
Anyway, I can see that work has started for python 3.11 at the Jolla repos, maybe things improve wrt. packaged modules in one of the future releases.
Iām really thankful for all the examples in your devel repo Looks like Iāve āsortofā got dateutil going, though I donāt like how
Maybe if you have a minute, you could look at Show home:poetaster / python-dateutil - SailfishOS Open Build Service and tell me why aarch builds seem to fail? I thought that might be an obs feature.
@nephros if you have a moment, could you look at Show sailfishos:chum:testing / python-dateutil - SailfishOS Open Build Service ⦠itās building on all but aarch64 ⦠I frankly donāt get whatās going on with the version foo naming. I think itās not just me
Youāve got (OBS) mail
In this specific case itās a sitearch
vs sitelib
thing.
One is specific on aarch64, and the same on 32bit.
You are a veritable rock god among base bit twiddlers such as I. Thank you.
python-dateutil is functional from chum and Iāve just updated tidalplayer to use python3-future internally. Installing from chum will install all deps.
When I have some time, Iāll pull the future package to itās own on chum. But Iād like to get dateutil up to the latest version first and donāt have much time right now.
Iāve submitted this to chum proper, but testing is available now.
EDIT: Iāve also tested github actions within my repo (works fine) and it seems to build correctly in @contra 's , too.
I merged the requests. But there is a name change from python3-dateutil to python-dateutil. So it can not be installed from SDK or github right now, because there is no python-dateutil unless Chum testing is enabled.
Chum testing version works nicely Thanks a lot for making this possible
Is there a version of python3-dateutil available in the jolla reposittories?
I went with python (without3) since that was their preference and fedora seemed to keep to it. But, I could change it. or add it when I update to 2.9.0
Ah, I forgot that I was testing in SDK just producing the rpms, which works. Soon, it will be in chum, so it should work for āmostā people (assuming they have chum).
Some other third-party repo. Just as info for the testers, who might have testing not enabled.
I successfully installed the Chum testing version on an older Xperia XA2 Ultra