Tidal App discussion

I did test it and it did work for me, bit i have had also local builds on my phone

OAuth.qml

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.

1 Like

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>

4 Likes

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.

1 Like

Ok, I’m going to suggest a two pronged approach.

  1. First we supply them using the technique I often use Packaging Python dependencies, a not-yet-guide - #17 by poetaster

  2. When time is there, I will package those (dateutil and future) on chum

  3. 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:

  1. first get dateutil in a separate package on chum
  2. push the build that works (with future) to chum proper after some testing
  3. move future to it’s own package. this is where I wish @nephros had gotten to these :slight_smile:
1 Like

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.

1 Like

I’m really thankful for all the examples in your devel repo :slight_smile: Looks like I’ve ā€˜sortof’ got dateutil going, though I don’t like how :slight_smile:

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 :slight_smile:

1 Like

You’ve got (OBS) mail :slight_smile:

In this specific case it’s a sitearch vs sitelib thing.

One is specific on aarch64, and the same on 32bit.

5 Likes

You are a veritable rock god among base bit twiddlers such as I. Thank you.

4 Likes

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.

2 Likes

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 :slight_smile: 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).

1 Like

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

1 Like