Balsa is both a framework for synthesising asynchronous hardware sy stems and the language for describing such systems
Created attachment 2652 [details] balsa-20020422.ebuild
Updated ebuild for 20020729 version of balsa. it is based off the old version but fixes a few bugs. i suggest that it go in app-sci/balsa since other VHDL tools and similar things are there. Can we get this into cvs and masked for now?
Created attachment 4102 [details] Updated ebuild with a few fixes - xilinx support dropped and verilog is only sort of working, don't know if its a ebuild or balsa problem yet
can we commite this to portage but mask it? there are several gentoo users waiting for this to arrive for testing.... because there hasn't been any response by aliz i'm reassigning this to default bugs so someone with cvs might respond dave
First of all, Gentoo is in an ebuild freeze until 1.4 is officially released. People can still pick up his ebuild and use it from their local portage tree. Second, the name Balsa is confusing. There is a GTK email client with the same name, so i suggest a name change or something. Thats why the bugwrangler passed it on to us, i'm passing it back now :)
i suggest tbass btw :)
i didn't know there was a ebuild freeze as there is no public documentation about it which is another issue all together... was it announced on one of them mailing lists, if so which one because i must have overlooked it. having balsa listed in app-sci/balsa should take care of nameing problems shouldn't it? isn't that the whole reason packages are catagorized? not being familiar with the current portage status are you suggesting renaming out of convenience (which is bad because these async process design academics probobly won't be able to find it with a different name) or because its not technically possible to have two different packages with the same name even though they are not in the same app-whatever/ group? dave
I don't see the name being a problem; I'm sure there are already packages in portage with the same names but different categories. otoh, this balsa existed years before the gnome balsa so maybe the gnome one should be renamed :-)
*** This bug has been marked as a duplicate of 9293 ***
this bug needs to be reopened as it IS NOT a duplicate of the gnome/balsa bug as Spanky marked it...
Hi guys. Dave: now you see why this should be renamed ;). Seriously, the portage database became more flattish since few month ago, when everybody received the ability of doing "emerge pkgname" rather than "emerge cat/pkg". Therefore two packages with the same name will cause name clashes in certain situations even if they sit in different categories. As for which one of these two balsa's should be renamed, I think it should be this one: 1. even though it existed before the gnome mailer, the latter one is more famous. This can be checked by the quick google search for "balsa", which turns up gnome mailer on the first page, while this package does not show up there. 2. gnome balsa is already in portage, so it gets its priority there. As a side effect it takes less labor to change the name of this package, especially considering possible dependencies. Ok, back to the package processing: I cleaned-up, checked and committed the package. For the lack of any apparent preference (which involved glancing at package homepage) I took foser's suggestion and named it tbass. It resides inside app-sci as suggested. The names of binaries do not seem to conflict with gnome, so it should be Ok. Also emerge has the ability of searching the description strings, therefore this naming should be less of an issue at this point. Please check and report. The ebuild is keymasked at the moment. George P.S. I see that balsa has a release version available now. Anybody up to making an update? ;)
i'll give up on the naming although i still believe it is a fundemental problem with portage if we can not have two packages with the same name even in different categories.... the ebuild you committed is from a snapshot that is much newer and has much more functionality than any of the 3.0 or 3.1 release series. no need to update the ebuild except to new snapshots. i think we can close this bug and wait for new ones to pop up now! =) dave
Made few more touches (added IUSE, cleaned up spaces...). Tested again, unmasking as this seems to be ready. George
i'm a little confused, earlier today i checked and it appeared that the ebuild was already in portage ie not masked as tbass20020729.ebuild along with lard and its other dependancies... what exactly did you modify and unmask?
Well, it still was keyword masked (are you by chance running with ACCEPT_KEYWORDS="~x86" in your make.conf? ;)). I removed '~' thus marking it "stable" after testing it again and not getting any complaints in over few months (positive test reports would have sped this up. And btw, lard was already unmasked). As for the changes - just a few cosmetic touches, such as removed hanging spaces... Most importantly added IUSE="", which was missing. Hope this explains the changes. George
