Bugzilla Bug 25008

Created an attachment (id=14841) [details]
app-sci/tbass/tbass-3.3.ebuild

Created an attachment (id=14842) [details]
files/tbass-3.3-balsa-lard-configure.patch

Created an attachment (id=14843) [details]
files/tbass-3.3-tech-example-configure.patch

Created an attachment (id=14844) [details]
files/tbass-3.3-tech-verilog-configure.patch

Created an attachment (id=14845) [details]
files/tbass-3.3-tech-xilinx-configure.patch

please read comments in ebuild regarding balsa-lard interface 

Hi Chris.

Thanks for an update!
I will take a look at it shortly. 
However there seems to be an issue with older tbass ebuilds which I think we need to solve before commiting an update - it might influence the ebuild. 

For exampe the build of 20030318 fails if 20020729 is installed on the system. Looks like it tries to use some already installed files instead of supplied with the source and fails because comment format has changed..
Could you please take a look at #24494?

George

Hi Chris.

Looked at the ebuild. Looking good in general (I think stuff under /usr/share might have been condensed, but IMHO its no biggy. Also 4 supplied patches could have been combined into one, but as I see they are applied to different dirs under ${WORKDIR}, so this may do as it is as well).

However, when I tried building this version with 20020729 installed, I triggered the same error :(. So, yes, this has not been fixed. Looks like a configure issue to me - if it finds some installed stuff it tries to use it instead of supplied (which is generally bad and normally considered an application bug (unless this is done on purpose)).
Well, I suspect there is no quick-n-easy fix for this. So I will just do some checking in pkg_setup (although this is indeed a dirty fix, as you called it :)).

There is another issue: versioning of this ebuild. All previous versions were called after the dates when the snapshots were taken and this one has a "real" version number. Unfortunately portage does not recognise 3.3 as an update, since 2003xxyy is apparently larger number than just plain 3. 
I seem to remember you mentioning that the releases for balsa are rare, although bug fixes are plenty. Therefore majority of ebuilds we will have will be date-stamped. If this is indeed the case, and we are going to see a chain of date-stamped updates after this release, I think it is easiest to rename this one correspondingly and put explanations and version correspondance table in ChangeLog.
If, on contrary, we are going to see only "properly" versioned ebuilds from this point on, I will have to remove or rename older versions (to something like 3.3_preX..) when the 3.3 will be becoming stable.
What do you think?

George

Created an attachment (id=15078) [details]
app-sci/tbass/tbass-3.3.ebuild

Can you test this one, it should fix the problem building when old versions are
present (I set an environment variable that points to ${S}). It also does the
actual compiling in compile stage, and the uri for the manual changed. 

Maybe the version could be changed to 2003xxxx-3.3? 

I make my own snapshot ebuilds for dev-util/eric and use the following pattern:

PN-#.#_preSNAPSHOTDATE eg.: eric-3.3_pre20030719.ebuild

In the ebuild I use this line: MY_P=${P/"?.?_pre"/"snapshot-"}. If there is a new snapshot, only the name of the ebuild has to be changed and the snapshots don't interfere with releases.


The ebuild works fine - if one has not 20020729 installed. ;-) I wouldn't mind - if there were someone really interested in balsa, the bug would have been filled long ago. But shouldn't the pdf only be fetched, if the doc flag is set?


Added the gtkwave update (#25387), btw.. 

Sorry for the delay.
Processed and committed the ebuild. The interference with that old version did go away, thanks Chris!
I changed ebuild version to 20030725.3.3, there can be no "-" in the PV part, after the '-' the rX is supposed to go..
Please test, closing this and 24494..

George

Thanks, works fine! 

Thanks for testing!
Since this is a bug-fix as well, marked stable now.

George

as this one is in portage, isn't it the time to close this one ?

Yes.