g-octave is a tool that generates and installs ebuilds for Octave-Forge packages "on-the-fly". This tool was created to don't bloat the Portage tree with tens of almost identicals ebuilds, where the eclass do all the work. I'm asking for inclusion of this RC on Portage or some overlay, because at this point I need some real users to report issues. More info can be found in the URL, or can be asked here. I'm the upstream of this package. Thanks, Rafael Reproducible: Always
Created attachment 214670 [details] g-octave-0.1_rc2.ebuild ebuild to app-portage/g-octave-0.1_rc2
Created attachment 214672 [details] g-octave-9999.ebuild also attached the live ebuild.
To add more background to this work I want to note here that I'm currently recruiting Rafael to help me with sci-electronics but his interests are more than just that. He worked on g-octave and its ebuild as part of his hands-on training. Denis.
Thanks a bunch, Rafael! As soon as I find some time I'll have a closer look. cheers, Markus
Any news here? I really need some users testing this...
Sorry, I am swamped at work at the moment. I'll get to it eventually. However, some testing by other folks would certainly be appreciated. Markus
Markus, as I'll probably join the development team soon, if you and Denis agree he can be my proxy for now and I can maintain this package. This package can be hard masked until you can analyze and suggest your changes. When you feel that the package is ready, you can remove the hard mask. What do you think? Additionally, I'm preparing a new release, with some minor fixes. Thanks, Rafael
I'm moving the g-octave project page to a new place. http://g-octave.rafaelmartins.eng.br/ It's a Trac instance, from where I'll receive bug reports and contributions for this project. Thanks, Rafael
I have finally gotten to test g-octave. I installed the communications package, ran the self tests and it worked. Rafael, could you please make an _rc3 tarball with the recent fix from your repo? I will then commit it masked to the tree. Markus, it will be up to you to unmask it when you feel it's ready or tell me to do so. Denis.
(In reply to comment #9) > I have finally gotten to test g-octave. I installed the communications package, > ran the self tests and it worked. > > Rafael, could you please make an _rc3 tarball with the recent fix from your > repo? I will then commit it masked to the tree. > > Markus, it will be up to you to unmask it when you feel it's ready or tell me > to do so. > > Denis. > Thanks a lot for all the great work. I think this package has to first go into the science overlay before committing it to the main portage tree. It will need a lot of testing to iron out bugs and get much more of it when unmasked in the science overlay as opposed to when masked in the portage tree. Best, Markus
(In reply to comment #10) > I think this package has to first go into the science overlay before > committing it to the main portage tree. It will need a lot of testing > to iron out bugs and get much more of it when unmasked in the science > overlay as opposed to when masked in the portage tree. As you like. I don't have commit access to the science overlay though, so you or somebody else who can will have to commit it. Note that Rafael prepared an _rc3 release with a minor fix. The ebuild can be found here: http://hg.rafaelmartins.eng.br/g-octave/file/c827870282d6/ebuilds Thanks, Denis.
(In reply to comment #10) > > Thanks a lot for all the great work. > > I think this package has to first go into the science overlay before > committing it to the main portage tree. It will need a lot of testing > to iron out bugs and get much more of it when unmasked in the science > overlay as opposed to when masked in the portage tree. > No problem for me. My only need for now is have someone to test this package. But with all this delay, my fear is that the only way to have someone testing and reporting bugs is ask the layman maintainers to add my overlay to the layman list, or something like that. Honestly, you and some others Gentoo guys know exactly how to disappoint someone wanting to contribute. You have the ebuilds, do what you think that's better. Thanks anyway, Rafael
A few people that tested this package said that it works and haven't reported bugs. So I'll stop the development of g-octave for now and refocus on my quizzes. I think that I'll be able to restart this after finish my recruitment. Thanks, Rafael
(In reply to comment #12) > Honestly, you and some others Gentoo guys know exactly how to disappoint > someone wanting to contribute. > I apologize if I came across that way and it certainly was not mean to disappoint you. You're contribution is very welcome and appreciated. If I'd had that extra day per week it would be long done ;) I will have a look at it later tonight and if all is well commit it to the science overlay. I hope it is all right if I cc you an all upcoming issues should there be any so we can work on solving them together. Thanks again, Markus
Hi Rafael, I've had a look at g-octave and it is very impressive! Thanks again for the hard work. Before I start adding it to the overlay there are a few things I wanted to discuss with you and ask for your opinion: - I think we need to change g-octave such that the octave-forge.eclass is not part of the download but rather resides permanently in the eclass directory. That said, I suggest that we rename the eclass g-octave.eclass at least for the time being so we can keep it alongside with the octave.forge eclass. - One of the questions I have been pondering is how to best handle the distribution of the database file containing the package descriptions and the patches also from a security point of view. In other words, I'd really like these files to be part of g-octave's manifest to make sure we don't pull in any bogus or corrupted files or what not. Hence, I was thinking if it might not be better to drop g-octave's sync step and distribute the database as well as patch file with g-octave on our mirrors. We could, e.g, release incremental versions of g-octave with upstream's octave-forge releases and then just update the patches/db files at these occasions. Any thoughts on this? Once g-octave is in the overlay I'll probably remove the current octave-forge framework after a transitory period so we get all the present users into our testing pool. Thanks, Markus
(In reply to comment #14) > I apologize if I came across that way and it certainly was not mean > to disappoint you. You're contribution is very welcome and > appreciated. If I'd had that extra day per week it would be long > done ;) Don't worry... I was a bit discouraged that day, but it's all ok. (In reply to comment #15) > Before I start adding it to the overlay there are a few things I > wanted to discuss with you and ask for your opinion: > > - I think we need to change g-octave such that the octave-forge.eclass > is not part of the download but rather resides permanently in the > eclass directory. That said, I suggest that we rename the eclass > g-octave.eclass at least for the time being so we can keep it alongside > with the octave.forge eclass. No problem here. I can change this. > - One of the questions I have been pondering is how to best handle > the distribution of the database file containing the package descriptions > and the patches also from a security point of view. In other words, > I'd really like these files to be part of g-octave's manifest to make sure > we don't pull in any bogus or corrupted files or what not. Hence, I was > thinking if it might not be better to drop g-octave's sync step and > distribute the database as well as patch file with g-octave on our mirrors. > We could, e.g, release incremental versions of g-octave with upstream's > octave-forge releases and then just update the patches/db files at these > occasions. Any thoughts on this? I need think about that. My plan was implement checksums in the fetch module, but reinvent the wheel is always bad. As I said before, the development is stopped. I'm finishing the end-quiz and working on some sci-electronics stuff. I'll be back after the recruitment. Best Regards. Rafael
(In reply to comment #16) > (In reply to comment #14) > > I apologize if I came across that way and it certainly was not mean > > to disappoint you. You're contribution is very welcome and > > appreciated. If I'd had that extra day per week it would be long > > done ;) > > Don't worry... I was a bit discouraged that day, but it's all ok. I fully understand and I'd probably feel the same way if I'd be you. > I need think about that. My plan was implement checksums in the fetch module, > but reinvent the wheel is always bad. > I think the main thrust should be to have as much as possible under the control of portage and the rest be properly checksummed. Since upstream does not release very often (at least until now) it seems like a good idea to make the database and patch files part of the manifest and put them on the mirrors. It might in addition be good to have the actual digests for the individual packages be part of the database file so we can checksum each one as the user downloads them (good both from a security point of view and also to make sure the user grabs the proper source). Good luck with your end quiz and I am looking forward to having you on the team. cheers, Markus
(In reply to comment #17) > I think the main thrust should be to have as much as possible under the > control of portage and the rest be properly checksummed. Since upstream > does not release very often (at least until now) it seems like a good idea > to make the database and patch files part of the manifest and put them > on the mirrors. It might in addition be good to have the actual digests > for the individual packages be part of the database file so we can checksum > each one as the user downloads them (good both from a security point of > view and also to make sure the user grabs the proper source). We need discuss this later, but probably I'll change this. > Good luck with your end quiz and I am looking forward to having you > on the team. Thanks Rafael
Moved to the tree. +*g-octave-0.4 (27 Sep 2010) + + 27 Sep 2010; Rafael G. Martins <rafaelmartins@gentoo.org> + +g-octave-0.4.ebuild, +metadata.xml: + Initial commit, moved from the science overlay. (bug #299039) +
