Re: [proaudio] gsampler: needs packaging |
[ Thread Index | Date Index | More lists.tuxfamily.org/proaudio Archives ]
В письме от 30 декабря 2013 17:30:27 пользователь Dominique Michel написал: > > > > 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. > Yeah, first time i did not get, what you meaned. Same is about jsampler too :)
> > > 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. > Just looked to own installation - indeed; seems to be quite strange.
> > > 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 Last commit is from 2012, so i don't expect any work. Version 0.3 for me is good, issues in sf2 bank selector are not so serious.
p.s.. I remember rule to try keep entire talk line in message, for easy following in discussion. But if some subbranch is not commented, is it not bad to remove it? Like in begining of this. |
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |