Maintenance of g-octave is dead, as homepage of this project. That's why I have written two short scripts in bash (KISS rule), for automation ebuilds templates prepare. In my concept Octave Forge packages ebuilds should be located in sci-misc directory with names octave-<package name> ie. sci-misc/octave-image/octave-image-2.0.0.ebuild. This way, it will be much comfortable for all Octave and Octave Forge Gentoo Users, and Developers. Reproducible: Always
Created attachment 330632 [details] set of scripts for automation Octave Forge packages ebuilds development Run main.script.sh Then You get tree of directories like this: ./ |-+ octave-forge-<packagename> | |- <package_source_tarbal>tar.gz | |-+ <package_source_dir> | |- some_sources ... |-+ portage |-+ sci-misc |-+ octave-<package_name> | |- octave=<package_name>-<packave_version>.ebuild ... For all newest octave forge packages. Than You can work with each ebuild manually to fits it to Your system.
Created attachment 330636 [details] set of scripts for automation Octave Forge packages ebuilds development
(In reply to comment #0) > Maintenance of g-octave is dead, as homepage of this project. That's why I > have written two short scripts in bash (KISS rule), for automation ebuilds > templates prepare. In my concept Octave Forge packages ebuilds should be > located in sci-misc directory with names octave-<package name> ie. > sci-misc/octave-image/octave-image-2.0.0.ebuild. This way, it will be much > comfortable for all Octave and Octave Forge Gentoo Users, and Developers. > First of all, g-octave maintenance isn't dead, g-octave was created to reduce the maintenance effort needed for octave-forge packages [1]. The webpage is really down, due to a server move that I needed to do some time ago, but I'll recover http and hg services for g-octave.org as soon as I find some time. Anyway you can build the docs by installing g-octave with USE=doc, and the sources are on gentoo mirrors. this isn't a big deal at all. I don't think that we are going to get back to an almost manual maintenance process, like you're proposing. Your scripts aren't following the KISS principle, they are actually pretending to do something, while they fails to solve almost all the problems solved by g-octave, like the usage of non-octave dependencies, patches, proper resolution of dependencies between octave-forge packages, etc. I'll repeat this for the last time: g-octave is mostly self-maintainable. Anyone can create a package database like the official one, using the scripts provided by g-octave, and as explained in the docs. If you think that something is wrong with the code or the docs, open a bug please, but let's try to move forward with g-octave, instead of get back to the old days of manual maintenance of octave-forge packages. [1] http://rafaelmartins.eng.br/post/g-octave-past-present-and-future/ Thanks.
(In reply to comment #3) Sorry to start this Rafael, but your reply is not constructive at all. Please encourage contributions instead of stamping them down. Don't feel personally attacked because somebody is trying to implement a different solution for a problem that you also worked on. This is open source, get over it. > First of all, g-octave maintenance isn't dead At least it smells funny. > g-octave was created to > reduce the maintenance effort needed for octave-forge packages [1]. The > webpage is really down, due to a server move that I needed to do some time > ago, but I'll recover http and hg services for g-octave.org as soon as I > find some time. Anyway you can build the docs by installing g-octave with > USE=doc, and the sources are on gentoo mirrors. this isn't a big deal at all. You keep iterating that g-octave was created to reduce maintenance effort and when people feel that their maintenance effort is not reduced, or it is not working for them, then you call them stupid. Don't do this! > I don't think that we are going to get back to an almost manual maintenance > process, like you're proposing. Your scripts aren't following the KISS > principle, they are actually pretending to do something, while they fails to > solve almost all the problems solved by g-octave, like the usage of > non-octave dependencies, patches, proper resolution of dependencies between > octave-forge packages, etc. > > I'll repeat this for the last time: g-octave is mostly self-maintainable. Hack_leberry Finn decided that it would be easier to write a new solution than to use g-octave. That tells us something about g-octave. The list of open-bugs on bugzilla tells the rest. > Anyone can create a package database like the official one, using the > scripts provided by g-octave, and as explained in the docs. If you think > that something is wrong with the code or the docs, open a bug please, but > let's try to move forward with g-octave, instead of get back to the old days > of manual maintenance of octave-forge packages. Your argument is basically: Use my stuff, everything else is "going back to the old hell". When I tried g-octave I found it pretty much unusable, so I suggest we give new options a chance too. Cheers, Thomas
(In reply to comment #4) > (In reply to comment #3) > > Sorry to start this Rafael, but your reply is not constructive at all. > Please encourage contributions instead of stamping them down. Don't feel > personally attacked because somebody is trying to implement a different > solution for a problem that you also worked on. This is open source, get > over it. You clearly failed to understand my points, then I'll try to explain them better, to avoid bigger problems. I'm not felling personally attacked. I dream with the day that someone will offer to take the g-octave maintainership from my hands, or propose something better, because I'm not even a octave user these days. I just don't think that these scripts are going to fix the issue. > > First of all, g-octave maintenance isn't dead > > At least it smells funny. Well, I'm doing what I can, I'm sorry if it isn't enough for you. > > g-octave was created to > > reduce the maintenance effort needed for octave-forge packages [1]. The > > webpage is really down, due to a server move that I needed to do some time > > ago, but I'll recover http and hg services for g-octave.org as soon as I > > find some time. Anyway you can build the docs by installing g-octave with > > USE=doc, and the sources are on gentoo mirrors. this isn't a big deal at all. > > You keep iterating that g-octave was created to reduce maintenance effort > and when people feel that their maintenance effort is not reduced, or it is > not working for them, then you call them stupid. Don't do this! I'm strictly talking about ebuild maintenance effort here. I don't know if you remember how painful was to maintain the octave-forge ebuilds in the science overlay, a few years ago. With the new system we don't need to maintain ebuilds, do updates, etc., but looks like people failed to understand this. Something isn't building? Report upstream. You have a patch? submit it as a pull request to the package database on github [1] *and* upstream. Some package is outdated? Run the script to update the database, and submit a pull request on Github. Something is wrong with g-octave itself, or the eclass, etc., open a bug here. That's simple enough, I think. g-octave isn't about putting all the efforts on the hand of one person, it is about keep the packages working on a collaborative way, using github. Also, I'm not calling nobody stupid, don't put words on my mouth, please. > > I don't think that we are going to get back to an almost manual maintenance > > process, like you're proposing. Your scripts aren't following the KISS > > principle, they are actually pretending to do something, while they fails to > > solve almost all the problems solved by g-octave, like the usage of > > non-octave dependencies, patches, proper resolution of dependencies between > > octave-forge packages, etc. > > > > I'll repeat this for the last time: g-octave is mostly self-maintainable. > > Hack_leberry Finn decided that it would be easier to write a new solution > than to use g-octave. That tells us something about g-octave. The list of > open-bugs on bugzilla tells the rest. As said before, I'm fine with new initiatives to deal with this problem, and I'm willing to support the efforts, if the proposed solution is good enough. > > Anyone can create a package database like the official one, using the > > scripts provided by g-octave, and as explained in the docs. If you think > > that something is wrong with the code or the docs, open a bug please, but > > let's try to move forward with g-octave, instead of get back to the old days > > of manual maintenance of octave-forge packages. > > Your argument is basically: Use my stuff, everything else is "going back to > the old hell". When I tried g-octave I found it pretty much unusable, so I > suggest we give new options a chance too. That said, if you want to work with Hack_leberry Finn to make these scripts the default way to install octave-forge package on gentoo, thanks a lot. You'll be doing me a big favor. I'm not trying to push my stuff over users. I just know the problem good enough to know that these scripts aren't going to fix it, that g-octave solves a big part of the problem, and that would be easier just improve g-octave that start with a totally new approach. I hope that things are clear now.
Lots of typos... (In reply to comment #5) > > g-octave isn't about putting all the efforts on the hand of one person, it > is about keep the packages working on a collaborative way, using github. s/hand/hands/ > That said, if you want to work with Hack_leberry Finn to make these scripts > the default way to install octave-forge package on gentoo, thanks a lot. > You'll be doing me a big favor. > > I'm not trying to push my stuff over users. I just know the problem good > enough to know that these scripts aren't going to fix it, that g-octave > solves a big part of the problem, and that would be easier just improve > g-octave that start with a totally new approach. > s/good/well/ s/know that these scripts/see that theses scripts/ s/that start/then start/
(In reply to comment #6) > s/that start/then start/ *than start* I should sleep now, definitely.
how hard would it be to automatically generate all the octave-forge ebuilds on a cron job on a server (with occasional maintenance)? so a gentoo octave user would only need to do familiar commands: layman and emerge, and keep whichever g-octave or these scripts on the server.
Hi Rafael, nice to see You with us. I thought that g-octave project is dead, because in science overlay 9999 version is buggy, as same as stable, and url of g-octave page (taken from g-octave ebuild) replay 403 error. As I remember "--sync" option was never proper implemented in stable version, but it was solution to manual update g-octave database via extra tools. I think it was not very easy and time saving solution. To give option to smooth switching from g-octave I placed in RDEPEND !g-octave/<package> request. So I think it will be possible to use my solution and g-octave parallel, and only package installation have to be collision protected. Personally, for Me it was easier write those new scripts than debug g-octave without support (I thought that nobody works now over g-octave). Especially when scripts are using only as advanced options of sed as substitution, :) and g-octave is structure with it own eclass and database. My solution is still "pre alfa" version. You have to do lot of manual work on each ebuild, but now is about 90 packages to edit at start. Rafael goal was, as I understand, give ability to install octave packages from svn/cvs/git... sources. I am focused on installing stable packages. I am writing new version of this scripts that will give proper configure and Makefile in files dir in each package directory, and than move it to sources dir. (This action are the same for all packages and provided by Octave build in pkg command.) As I remember, only few packages needed patching, so proper ebuild structure will work almost for all packages. If there will be proper ebuild in portage, writing new for new version of package will be not so time consuming thing, even if g-octave goal was to do it in automatic (without user/developer work) way
(In reply to comment #8) > > how hard would it be to automatically generate all the octave-forge ebuilds > on a cron job on a server (with occasional maintenance)? > > so a gentoo octave user would only need to do familiar commands: layman and > emerge, and keep whichever g-octave or these scripts on the server. I did a quick hack to list all the octave-forge packages and create an overlay using g-octave. looks like it works reasonably, take a look: https://github.com/rafaelmartins/octave-overlay I'll add a note saying that it is automatically generated, and ask for inclusion on layman, after some testing.
(In reply to comment #8) > > how hard would it be to automatically generate all the octave-forge ebuilds > on a cron job on a server (with occasional maintenance)? > > so a gentoo octave user would only need to do familiar commands: layman and > emerge, and keep whichever g-octave or these scripts on the server. I did a quick hack to list all the octave-forge packages and create an overlay using g-octave. looks like it works reasonably, take a look: https://github.com/rafaelmartins/octave-overlay I'll add a note saying that it is automatically generated, and ask for inclusion on layman, after some testing. I built a virtual machine on my server and setup a cron job to run it weekly, let's see how it goes.
Created attachment 330856 [details] set of scripts for automation Octave Forge packages ebuilds development First "stable release" Now in directory octave-forge-framework are files: Makefile - universal makefile for octave packages building (little modified Makefile taken from octave-forge http://sourceforge.net/p/octave/code/11459/tree/trunk/octave-forge/packages/) configure -- universal script as Makefile taken from http://sourceforge.net/p/octave/code/11459/tree/trunk/octave-forge/packages/ template[12345].ebuild - universal parts of ebuilds prepared for proper installation in system and update Octave internal pkg cache. script.sh - script used for automated ebuilds writing. (Still such ebuild need to be checked and edited for typos, patching, or system-wide dependences.) main.script.sh - main script for octave-forge and portage tree building. Now it can be called by cron, it checks if there was update in the packages release list, and backup old portage and octave-forge tree, after next call it builds new dir trees. Ebuilds are protecting g-octave packages installs, so new installs from this ebuilds can successively replace g-octave ones, so other g-octave installs can live parallel with those emerge-stright. As I wrote at begin, directory tree looks now like this: ./octave-forge-framework |-+ octave-forge-<packagename> | |- <package_source_tarball>tar.gz | |-+ <package_source_dir> | |- some_sources ... |-+ portage |-+ sci-misc |-+ octave-<package_name> | |-+ files | | |- Makefile | | |- configure | |- octave=<package_name>-<packave_version>.ebuild ... Output form main script is reduced to -nv option of wget (useful for cron logs) and three types of infos: "Let's do some ebuilds writing" - when fresh trees are created "Nothing new on Octave Forge" - when no new packags ware delivered "New ebuilds calling: <package_name>-<package_version>" - when new package was released Now scripts use some more advanced sed usage (conditional substitutions), and diff, date, gzip and tar. Those three last programs are used when old dir trees are backed up (or I should write backuped). Archives get format portage.YYYY-MM-DD.tar.gz and octave-forge.YYYY-MM-DD.tar.gz. Many of new ebuilds of 94 official packages are ready "out of box", some need to place proper dependencies of external libs or other staff. (In ebuild body they are placed as commented lines, and they are proper lines form DESCRIPTION files.) Enjoy using.
Hi Hack_leberry Finn, I'd like to invite you to test and help us improving the recently created 'octave-overlay': https://github.com/rafaelmartins/octave-overlay It was entirely created by g-octave, running on a virtual machine with a weekly cronjob. I don't want to be rude, stamp down new contributors and push my stuff over the users, like Thomas accused me of doing, but let's be honest, you are trying to solve the *same* problems that I had to solve with g-octave. Please stop reinventing the wheel and help us improving what exists. :/ Please test the overlay, if you can. I'll work to add it to the layman list of repositories, so you can install it with a simple 'layman -a octave', but first we need some testers, to make sure that the overlay is in a sane state. I'll add some comments inline. (In reply to comment #12) > Created attachment 330856 [details] > set of scripts for automation Octave Forge packages ebuilds development > > First "stable release" > Now in directory octave-forge-framework are files: > Makefile - universal makefile for octave packages building (little modified > Makefile taken from octave-forge > http://sourceforge.net/p/octave/code/11459/tree/trunk/octave-forge/packages/ > ) > configure -- universal script as Makefile taken from > http://sourceforge.net/p/octave/code/11459/tree/trunk/octave-forge/packages/ > template[12345].ebuild - universal parts of ebuilds prepared for proper > installation in system and update Octave internal pkg cache. > script.sh - script used for automated ebuilds writing. (Still such ebuild > need to be checked and edited for typos, patching, or system-wide > dependences.) g-octave already uses both files, together with a custom eclass that does most of the work of install packages. This is just one of the problems that I found and solved when coding g-octave. And I can even list what are the problems you'll find next. :( > main.script.sh - main script for octave-forge and portage tree building. Now > it can be called by cron, it checks if there was update in the packages > release list, and backup old portage and octave-forge tree, after next call > it builds new dir trees. > > Ebuilds are protecting g-octave packages installs, so new installs from this > ebuilds can successively replace g-octave ones, so other g-octave installs > can live parallel with those emerge-stright. > > As I wrote at begin, directory tree looks now like this: > ./octave-forge-framework > |-+ octave-forge-<packagename> > | |- <package_source_tarball>tar.gz > | |-+ <package_source_dir> > | |- some_sources > ... > |-+ portage > |-+ sci-misc > |-+ octave-<package_name> > | |-+ files > | | |- Makefile > | | |- configure > | |- octave=<package_name>-<packave_version>.ebuild > ... > > Output form main script is reduced to -nv option of wget (useful for cron > logs) > and three types of infos: > "Let's do some ebuilds writing" - when fresh trees are created > "Nothing new on Octave Forge" - when no new packags ware delivered > "New ebuilds calling: > <package_name>-<package_version>" - when new package was released > > Now scripts use some more advanced sed usage (conditional substitutions), > and diff, date, gzip and tar. Those three last programs are used when old > dir trees are backed up (or I should write backuped). Archives get format > portage.YYYY-MM-DD.tar.gz and octave-forge.YYYY-MM-DD.tar.gz. > > Many of new ebuilds of 94 official packages are ready "out of box", some > need to place proper dependencies of external libs or other staff. (In > ebuild body they are placed as commented lines, and they are proper lines > form DESCRIPTION files.) g-octave already does all this resolution of dependencies, even for external libs, again, please stop reinventing the wheel. That said, I don't know if I still should to care about this, it would be easier for me to just let you spend your time doing what is already done, but I don't feel like doing this. Your contributions are appreciated, but they aren't being actually constructive. Regards, Rafael
Created attachment 330884 [details] set of scripts for automation Octave Forge packages ebuilds development Last (second) version, it includes licence an readme file, plus some minor changes. People who are interested in develpment ebuilds for packages from Octave Forge now got two tools. Rafael, I don't want be rude, but how g-octave solved problem of patching sources, or inconsistent directories naming? Besides as I remember it was a little bit tricky to put ready patches to g-octave database. My solution brings ebuilds back to portage tree. So if someone will find bug, He/She can write patch and place it with new ebuild version on bugzilla. Sorry, but I will prepare as many ebuilds as I can my way, because it is much easier for me than biting with your software. I gave users choice to use packages direct form portage, or from g-octave. Maybe you should add to RDEPEND of g-octave ebuilds !sci-misc/<package_name> line? Don't take it personally but if everybody will think like You, we will be using now wooden wheels instead of pneumatic tires, because "wheel was invented earlier". My main PERSONAL argument against g-octave is that I prefer manual control of system (as portage with emerge) over autopilots like C-PAN, APT, and... g-octave. I started my works over those scripts in Sunday morning, if in 1 week (working myself in free time) I will have ready and working most of 94 packages installed from octave-forge-framework (in other words directly from portage). I will say (don't take it offensive) that g-octave solved very many problems that it created by itself, because Octave Forge provides itself solution for packages application from outside of Octave. Only problem might be with hardcoded pathes, or outdated syntax in sources, not in installation via emerge or synchronization Octave internal package cache. And those problems can be solved only by one type of automates, they are usually called "coders".
(In reply to comment #14) > Rafael, I don't want be rude, but how g-octave solved problem of patching > sources, or inconsistent directories naming? Besides as I remember it was a > little bit tricky to put ready patches to g-octave database. Tricky?! You know what you're saying? You tried to read g-octave docs? Anyway I can easily allow users to add patches using epatch_user on the template ebuild. But where is your bug about this? I can't see it. > My solution > brings ebuilds back to portage tree. So if someone will find bug, He/She can > write patch and place it with new ebuild version on bugzilla. > Sorry, but I will prepare as many ebuilds as I can my way, because it is > much easier for me than biting with your software. I gave users choice to > use packages direct form portage, or from g-octave. Maybe you should add to > RDEPEND of g-octave ebuilds !sci-misc/<package_name> line? > Don't take it personally but if everybody will think like You, we will be > using now wooden wheels instead of pneumatic tires, because "wheel was > invented earlier". I don't want to reduce your motivation, but you really think that someone will maintain these ebuilds in the main portage tree? I can't see anyone taking this maintenance job, sorry. Unless you want to do the quizzes and join Gentoo as a developer, and maintain them yourself. > My main PERSONAL argument against g-octave is that I prefer manual control > of system (as portage with emerge) over autopilots like C-PAN, APT, and... > g-octave. I already offered you a complete overlay with ebuilds for almost all packages available on octave-forge. I doubt you looked at it, at least. > I started my works over those scripts in Sunday morning, if in 1 week > (working myself in free time) I will have ready and working most of 94 > packages installed from octave-forge-framework (in other words directly from > portage). I will say (don't take it offensive) that g-octave solved very > many problems that it created by itself, because Octave Forge provides > itself solution for packages application from outside of Octave. Only > problem might be with hardcoded pathes, or outdated syntax in sources, not > in installation via emerge or synchronization Octave internal package cache. > And those problems can be solved only by one type of automates, they are > usually called "coders". Well, I'll stop with this discussion now. Good luck finding a gentoo maintainer for your project. Regards. Rafael
Created attachment 330986 [details] set of scripts for automation Octave Forge packages ebuilds development Third version of scripts. Now I provided script "system-wide.script.sh" for portage checks of system-wide dependencies in ebuilds templates. Main script main.script.sh provides now "full cron readiness", in the assumption that cron call main script will be not often as one per day. Old octave forge directories with sources will be backed up separately in tar-gzip archive, and old portage tree in second tar-gzip archive, if only new package will release, and updated tree of octave-forge and portage will be created. And archives will have date in name included. For now, I think this solution is quite completed. I think that version 0.1.x should contain automatic sci-mics/octave-forge or sci-mathematic/octave-forge meta ebuild creation. Still, I want to give choice between portage ebuilds and g-octave installation. but You Rafael have to place !sci-misc/<package_name> in RDEPEND g-octave autogenerated ebuilds to make it possible in both sides. Now I can focus on writing packages ebuilds, but I will be able to check them only on ~x86, and with specific set of flags, so all hands will be helpful. Some helpful infos I found on websites prepared by Debian-oriented users. [1] [2] [3] I noticed that guys from DOG [3] have chosen the same naming convention as in my proposition (octave-<package_name>) for they debs. [1] http://www.pt.xemacs.org/wiki.pl?BuildFromSource [2] http://wiki.octave.org/Debian [3] http://wiki.debian.org/Teams/DebianOctaveGroup Please share impressions of usage here or on forum: http://forums.gentoo.org/viewtopic-t-943506.html?sid=0120f2ae159ad5cc656ac046472aade9 I hope that my solution will suit developers, as "develop-oriented"
(In reply to comment #16)i-mathematic/octave-forge meta ebuild creation. > Still, I want to give choice between portage ebuilds and g-octave > installation. but You Rafael have to place !sci-misc/<package_name> in > RDEPEND g-octave autogenerated ebuilds to make it possible in both sides. I will not do this, sorry.
(In reply to comment #17) > (In reply to comment #16)i-mathematic/octave-forge meta ebuild creation. > > Still, I want to give choice between portage ebuilds and g-octave > > installation. but You Rafael have to place !sci-misc/<package_name> in > > RDEPEND g-octave autogenerated ebuilds to make it possible in both sides. > > I will not do this, sorry. Sorry to hear this.
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16)i-mathematic/octave-forge meta ebuild creation. > > > Still, I want to give choice between portage ebuilds and g-octave > > > installation. but You Rafael have to place !sci-misc/<package_name> in > > > RDEPEND g-octave autogenerated ebuilds to make it possible in both sides. > > > > I will not do this, sorry. > > Sorry to hear this. why not installing dev-octave for both, so no need of interference, the user would only choose the overlay.
Created attachment 331012 [details] se
Created attachment 331014 [details] set of scripts for automation Octave Forge packages ebuilds development version 4. Previous "se" attachment as text file is effect of my sleepless - coding night, so don't care it and remove if it is possible. Now main script has improved wget call. In Poland We have free Internet access via AERO2 but single session is limited to one hour, that's why I added -t and -T options, to solve problem with potential Octave Forge server timeouts. There is bigger change. (I think that is still not enough to move to 0.1.0 version.) all templates are moved to files directory. I have added two files CHANGELOG and TODO. Second file shows development potentialities and directions. At weekend I will write some ebuilds for packages that I need, but I am not sure if place them in bugzilla as single ebuilds requests, or as pack of them in one request of octave-forge meta ebuild reborn. Sébastien what will suits better to science overlay development directions? Rafael I think my scripts will be helpful for your development, as same as your patches in my ebuilds, so think again about my suggestion about RDEPEND in g-octave. Sébastien as you pointed, it is possible coexistence of octave-forge-framework which is developers tool with g-octave which is package manager. Only collisions may occur if mixed g-octave and ebuild-straight installs will be pulled by user. That's why I insist to place proper RDEPEND in g-octave automagicaly prepared ebuilds (but not in g-octave it self).
(In reply to comment #21) > Sébastien as you pointed, it is possible coexistence of > octave-forge-framework which is developers tool with g-octave which is > package manager. Only collisions may occur if mixed g-octave and > ebuild-straight installs will be pulled by user. That's why I insist to > place proper RDEPEND in g-octave automagicaly prepared ebuilds (but not in > g-octave it self). users don't care how the ebuild was generated, and would only use only one of the solution. also you really don't want any rdepend cross-overlays. so if your solution works, just fill up an overlay with dev-octave/<pkg> and users would just switch between the g-octave generated overlay and yours without even changing their world file. now obviously cooperation/complementarity between the two projects is better, but i leave it to you.
This bug has nothing to do with g-octave anymore, removing myself from CC.
Were there any updates regarding this bug? Octave and its packages updated tremendously since.
