Re: [proaudio] gsampler: needs packaging

[Dominique Michel <dominique.michel@xxxxxxxxx>]

Le Mon, 30 Dec 2013 11:48:51 +0600,
Zlobin Nikita <nick87720z@xxxxxxxxx> a écrit :

> В письме от 29 декабря 2013 19:24:32 пользователь Dominique Michel
> написал:
> > Le Fri, 20 Dec 2013 18:09:24 +0600,
> > 
> > Zlobin Nikita <nick87720z@xxxxxxxxx> a écrit :
> > > Hello.
> > > I recently (yesterday) faced this frontend for linuxsampler,
> > > which is claimed to be jsampler rewriting. Unlike jsampler,
> > > however, it doesn't support orchestras, which are not even LS
> > > feature, and are thus exclusive for JS. It uses gtk and in one
> > > review claimed supporting both gtk3 and 2, but current last
> > > version (0.3) seems to be last supporting both, because there is
> > > relatively recent (just several commits ago) commit, removing
> > > gtk2 support.
> > > 
> > > Build system is autoconf.
> > > Choosing gtk version is done by just specifying GTK_LIBS and
> > > GTK_CFLAGS env variables for configure (using pkg-config of
> > > course).
> > 
> > Hi,
> > I take a look into your ebuild. It is another way to do that in
> > portage. See the toolchain eclass:
> > http://devmanual.gentoo.org/eclass-reference/toolchain-funcs.eclass/index.ht
> > ml
> > 
> > Also, you KEYWORD="" is wrong. Such a keyword is valid only when it
> > is impossible to test the resulting software, as example with live
> > ebuilds using cvs or git to download the code, code that can change
> > at any time. In the overlay, most of the non live ebuilds use
> > "~amd64 ~x86". That also make an easy way for an user to choose
> > between a live ebuild or an ebuild that use an archive.
> I did not want, what keywords to add by default, so left decision for
> others, who know :) Does impossible to test that ebuild simply
> written and posted without even test, does it work correctly?

We just follow gentoo policy. Well tested software are keyworded arch,
the other ones are keyworded ~arch, and the live ebuilds are keyworded
with the non keyword: "".

That imply all new ebuilds are keyworded ~arch, which in most cases is
"~amd64 ~x86".

If by work you mean it install the software, yes it work. But it is
other issues mentioned above.

> 
> > 
> > > And one drawback: version 0.3 doesn't build with gcc 4.7, because
> > > linker gets flag -Wl, which is now valied only for compiler only.
> > > In gcc 4.6 there is no problem. To minimize efforts for self i
> > > just built it with own versions of CC, CXX and CPP. Not sure,
> > > could it be reason, but version, build with GTK3 did not show
> > > gui, though it did not freeze and respond to interruption signal
> > > (C^c in terminal).
> > 
> > As it doesn't show anything with gtk2, I didn't see any point to
> > install a gtk3 version when the gtk2 version is working.
> Hm, so may be just remove gtk2 flag and use only on dep? This should
> simplify ebuild a bit.
> 
> > 
> > Also, your ebuild install the doc files in both /usr/share/doc/$P
> > and /usr/doc/$PN. This second location should not exist.
> > 
> > Last, when I start gsampler, it show me a message like what is was
> > compiled without sqlite3 support. This need an USE flag and the
> > associated depend. And maybe some fix because sqlite-3.8.0 is
> > installed into my system.
> Never got problem about sqlite3: i have it showing database,
> previously created in jsampler, but it is under ubuntu, with sqlite
> 3.7.9 (gentoo is on second pc, without my user account). Do you have
> linuxsampler built with sqlite use flag? Anyway, i need to try it
> under gentoo again.

No, linuxsampler is installed without sqlite support here. That imply it
must be an USE flag for that in gsampler ebuild, and gsampler must
depend on linuxsampler[sqlite] when sqlite support is wanted.

> 
> > 
> > So next question. gsampler is almost 2 years old, and the last
> > commit into its repo is from July 2012. We already have jsampler
> > which work and have orchestras support. The only issue with it are
> > 1) it's in java and its GUI is slow, 2) it pollute like hell my log
> > file if I don't redirect its output to /dev/null.
> > 
> Does its oldness make sence? The only thing, preventing me from using
> it, unlike q/jsampler is that when you load GM sf2 bank, only few of
> >100 instruments are visible. I guess it possible if it uses only MSB
> >without LSB for bank discovery and 
> selection. But also, for sf2 only jsampler gives correct instruments
> list (in qsampler it items are some nameless default, still can't
> manage to report this issue).

OK, so it is worth to have it. I will see what I can do, the main issue
is to remove that /usr/doc directory.

> 
> > So, is it worth to make an ebuild for gsampler, and if yes, would it
> > not be better to use the code from its repo which is more recent
> > than the last release?
> > 
> > Best,
> > Dominique
> > 
> Yeah, i tried fresh version, this version works only with gtk3, but
> does it well. But surprise: for me it was half-working. Some things
> absent or did not work (dumb, functionless, etc).

OK. Did you ask upstream if he have any plan to continue the
development?

Dominique