Re: [proaudio] gsampler: needs packaging

[ Thread Index | Date Index | More lists.tuxfamily.org/proaudio Archives ]


В письме от 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?

 

>

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

 

>

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

 

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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/