Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 00:33

    juanrubio on develop

    plugins/aac_decoder: increased … clients/tunein/tuneinproxy: fix… (compare)

  • Jan 16 10:12
    lgbaldoni commented #648
  • Jan 15 19:09
    codecov[bot] commented #666
  • Jan 15 18:39
    tizonia commented #666
  • Jan 15 18:39

    tizonia on develop

    Add meson support for tunein Minor cleanup (compare)

  • Jan 15 18:39
    tizonia closed #666
  • Jan 15 18:37
    lgbaldoni opened #666
  • Jan 15 17:56

    juanrubio on develop

    Initial meson commit Merge remote-tracking branch 'o… meson.build: fixed log4c_dep in… and 17 more (compare)

  • Jan 15 16:39

    juanrubio on meson

    (compare)

  • Jan 15 14:38
    Frozen-byte commented #552
  • Jan 15 14:34
    Frozen-byte commented #576
  • Jan 15 14:33
    Frozen-byte commented #576
  • Jan 15 09:17

    juanrubio on tune-in

    (compare)

  • Jan 15 09:15

    juanrubio on color-themes

    (compare)

  • Jan 15 09:13

    juanrubio on develop

    clients/tunein: initial skeleton player/services/tunein: initial… player/services/dirble: deleted and 79 more (compare)

  • Jan 15 09:10

    juanrubio on tune-in

    clients/tunein/tuneinproxy/tizt… (compare)

  • Jan 15 00:36

    juanrubio on tune-in

    player/src/tizprogramopts.cpp: … (compare)

  • Jan 15 00:28

    juanrubio on tune-in

    clients/tunein/tuneinproxy: var… (compare)

  • Jan 14 21:19

    juanrubio on tune-in

    player/src/tizprogramopts.cpp: … clients/tunein/tuneinproxy: '_e… clients/tunein/tuneinproxy: ord… and 7 more (compare)

  • Jan 13 22:31

    juanrubio on tune-in

    clients/tunein/tuneinproxy/tizt… (compare)

Luigi Baldoni
@lbaldoni_gitlab
Are libtizonia/test_component and libtizcore/test_component used by tests? Because I see they're built by default.
Tizonia
@tizonia
if I recall correctly, the test components are used during conformance testing
The conformance test is an external program
Luigi Baldoni
@lbaldoni_gitlab
ah, must have missed any reference to it
Tizonia
@tizonia
Feature parity is really impressive. I need to look at your repo for sure.
Luigi Baldoni
@lbaldoni_gitlab
clients/chromecast/libtizchromecast/tests and clients/gmusic/libtizgmusic/tests build fail
apparently due to an API mismatch: is that a known issue?
Tizonia
@tizonia
Does meson support debian packaging well?
Luigi Baldoni
@lbaldoni_gitlab
Honest question: no idea.
Tizonia
@tizonia
The libtizgmusic/tests are most likely broken, so I would not worry too much. They are not run in Travis, so would be rotten most likely. Some of those tests need to be removed or fixed, but it is not critical at this point. So safe to ignore
Luigi Baldoni
@lbaldoni_gitlab
also still about tests: check_tizrmproxy segfaults on launch, perhaps it's missing something
check_tizplatform succeeds and check_tizyoutube times out, everything else fails. Should I worry?
Tizonia
@tizonia
yes, I guess we would need to look at each test one by one, and decide what to do with them. Some of those tests under 'clients' are not needed anymore
Luigi Baldoni
@lbaldoni_gitlab
And, last question: doxygen-src succeeds (will require a patch to make things smoother), but sphinx-src fails due to /docs/sphinx-src/development/clients/libtizchromecast.rst:4:doxygengroup: Cannot find namespace "libtizchromecast" in doxygen xml output for project "tizonia" from directory: ../doxygen-src/xml/
But it fails on autotools all the same, so I suppose it's not news.
Tizonia
@tizonia
The Debian question is kind of important, because this is the main reason why I keep autotools around, so that I can build the Debian packages
Luigi Baldoni
@lbaldoni_gitlab
I see. Will have to ask about that, but there are several distro packages that use meson and they seem to be doing fine.
Personally I'm more of a rpm kind of guy.
Tizonia
@tizonia
I am pretty sure meson supports debian packaging somehow, but I mention it because that is the feature that would make me keep autotools around even if meson is there as an alternative
Luigi Baldoni
@lbaldoni_gitlab
I didn't have to patch anything to build with meson, so they can happily co-exist.
Tizonia
@tizonia
it is a big thing to migrate from one build system to another, so they would have to coexist for some time until autotools could be replaced
but it is great that you have started this, so I'm really looking forward to it
Luigi Baldoni
@lbaldoni_gitlab
btw, I think I found an error in autotools
libtool creates 0.0.19 soversion, I think you should change SHARED_VERSION_INFO to 19:0:19 to match the project version
Which brings me also to another matter: shouldn't plugins be unversioned shared objects?
Tizonia
@tizonia
need to go now, but I'll be back in an hour
Luigi Baldoni
@lbaldoni_gitlab
OK
Tizonia
@tizonia
Hi Luigi, wrt soversion, yes there probably are some issues there. Never understood shared object versioning very well. There use to be a limitation by which the OpenMAX IL Core library would only load plugins with the same so version as the IL core itself, to avoid loading older plugins. But I think I removed that limitation some time ago. So now perhaps, the SHARED_VERSION_INFO could be fixed and the plugins made unversioned. I need some time to look into that, but I believe you might be right on that.
Luigi Baldoni
@lbaldoni_gitlab
and how about docs?
Tizonia
@tizonia

Cannot find namespace "libtizchromecast" in doxygen xml output

I believe this just requires a fix in the Doxyfile, to make this namespace appear in the docs. Or something silly like that. I will look into that as well.

Luigi Baldoni
@lbaldoni_gitlab
There's just one last concern I have: compiling the player is quite memory-intensive, so much that the build OOMs out if a parallel build is run. Do you think there's some margin of improvement there?
Tizonia
@tizonia
Very little I'm afraid. The problem there is the boost state machine library that relies so heavily on C++ templates. The only way to reduce that problem is to build with fewer jobs. DEBUG builds are also much more problematic than RELEASE builds.
Luigi Baldoni
@lbaldoni_gitlab
I see. Well, I think I have everything I need. Will send a PR for doxygen so that meson has an easier time with it and file anything else as issue if necessary.
Tizonia
@tizonia
That sounds great. I was thinking on creating a branch off of master, to receive the meson PR and do further changes as needed.
Luigi Baldoni
@lbaldoni_gitlab
I'll have to polish things a bit before that.
But yes, I suppose that's the way to do it.
Tizonia
@tizonia
ok, the 'meson' branch is already present in the repo
Luigi Baldoni
@lbaldoni_gitlab
small PR sent
Luigi Baldoni
@lbaldoni_gitlab
Sorry if I insist, but are you sure I shouldn't disable the player/src/services/spotify subdir if the player is built but libspotify is not used?
Tizonia
@tizonia
Sorry Luigi I think I wasn't clear earlier this morning. Yes, definitely, if libspotify is not used, player/src/services/spority needs to be disabled. That's already the current autotools behaviour (If I'm not mistaken)

There is this conditional in player/src/Makefile.am

if WITH_LIBSPOTIFY
SPOTIFY_SRC= \
services/spotify/tizspotifygraph.cpp \
services/spotify/tizspotifygraphfsm.cpp \
services/spotify/tizspotifygraphops.cpp \
services/spotify/tizspotifymgr.cpp
SPOTIFY_HDR= \
services/spotify/tizspotifygraph.hpp \
services/spotify/tizspotifygraphfsm.hpp \
services/spotify/tizspotifygraphops.hpp \
services/spotify/tizspotifyconfig.hpp \
services/spotify/tizspotifymgr.hpp
else
SPOTIFY_SRC=
SPOTIFY_HDR=
endif

@trueFireblade Sorry, I missed your question.
have you followed the advice in https://github.com/tizonia/docker-tizonia/blob/master/README.md about the config dir permissions?

Change Tizonia's config dir permissions

$ chmod a+wrx $HOME/.config/tizonia

Luigi Baldoni
@lbaldoni_gitlab
@tizonia right sorry, moment of confusion
Tizonia
@tizonia
no worries, when you are ready
Tizonia
@tizonia

@lbaldoni_gitlab

it looks like meson can't find "log4c" (I'm on Ubuntu 18.04).

Run-time dependency log4c found: NO (tried pkgconfig and cmake)
meson.build:52:0: ERROR: Dependency "log4c" not found, tried pkgconfig and cmake

Both debian packages liblog4c-dev and liblog4c3 are installed. I'm trying to find why meson can't find it

Luigi Baldoni
@lbaldoni_gitlab
@tizonia that's trivial to fix, replace log4c_dep = dependency('log4c', required: true) with log4_dep = declare_dependency(dependencies: cc.find_library('log4c', required: true))
Tizonia
@tizonia
@lbaldoni_gitlab
Thank!, that works great.
Tizonia
@tizonia

@lbaldoni_gitlab
I have a question: During development, I like to install Tizonia under a directory in my $HOME, so I always configure with autotools like this:
./configure --prefix=$HOME/temp

If I do the same with meson, I get this error:

meson build --prefix=$HOME/temp

plugins/vp8_decoder/meson.build:1:0: ERROR: Include dir /home/joni/temp/include/vpx does not exist.

Seeing that, I decided to try this instead:

meson build --prefix=$HOME/temp --includedir=/usr/include

but that produces this other error:

meson.build:1:0: ERROR: The value of the 'includedir' option is '/usr/include' which must be a subdir of the prefix '/home/joni/temp'.
Note that if you pass a relative path, it is assumed to be a subdir of prefix.

So how can I replicate that autotools behavior with Meson?
Tizonia
@tizonia

So now I replace the value of vpx_dep in plugins/vp8_decoder/meson.buid with this:

vpx_dep = dependency('vpx', required: true, version: '>=1.5.0')

with this, the configuration phase succeeds, but compilation fails with this error:

../plugins/vp8_decoder/src/vp8dprc_decls.h:39:10: fatal error: vpx_decoder.h: No such file or directory