Created attachment 14841 [details] app-sci/tbass/tbass-3.3.ebuild
Created attachment 14842 [details, diff] files/tbass-3.3-balsa-lard-configure.patch
Created attachment 14843 [details, diff] files/tbass-3.3-tech-example-configure.patch
Created attachment 14844 [details, diff] files/tbass-3.3-tech-verilog-configure.patch
Created attachment 14845 [details, diff] 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 attachment 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.
