Le Mon, 30 Dec 2013 11:48:51 +0600, Zlobin Nikita <[email protected]> a écrit :
> В письме от 29 декабря 2013 19:24:32 пользователь Dominique Michel > написал: > > Le Fri, 20 Dec 2013 18:09:24 +0600, > > > > Zlobin Nikita <[email protected]> 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
