Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Hi! I have attached an ebuild for Portato-0.5.1. Portato is a graphical frontend for portage/emerge. It is written in Python and offers a GTK-Interface (Qt is planned). It allows the user to emerge, unemerge packages, do an update world a.s.o. More details can be found in the gentoo-forums: http://forums.gentoo.org/viewtopic-t-502350.html This project mainly (!) depends on gentoolkit and pygtk. It does not work with portage-2.1.2, because some internals seem to have changed.
Created an attachment (id=102940) [details] The ebuild
Let us know when this works w/ uptodate portage versions and reopen the bug then. Thanks.
So ... I recently added support for portage-2.1.2 ... I'll upload the new ebuild
Created an attachment (id=103055) [details] new portato-0.5.1b.ebuild
Created an attachment (id=103286) [details] Portato-SVN-ebuild This is an OPTIONAL (!) ebuild for the svn-version of portato. As portato is quite young and under development, a package might be outdated, when it goes into the tree.
Created an attachment (id=103689) [details] portato-0.5.1b-r1.ebuild Small changes to have a correct differentiation between DEPEND and RDEPEND. This change should be done in the svn-ebuild too, but I'll leave it alone to avoid spamming ;)
i might be interested in this. It looks a good project but it seem to me it lacks of an easy gui to simply update and upgrade your system like a systray icon. What are your main goals for future releases ? Any thoughts about managing /etc/portage/* files ? Keep up with good work
(In reply to comment #7) > but it seem to me it > lacks of an easy gui to simply update and upgrade your system like a systray > icon. I don't really get your point here. The GUI offers an "Update world"-button which is a wrapper around "emerge [--newuse] [--deep] --update world". Adding functionality to a systray icon is not a good idea imho, because not all DE's offer one. > What are your main goals for future releases ? The next release will mainly consist of enhancements (slot support, enhanced --newuse, full 2.1.2 compatibility etc.) For the nearer future I do not have ideas for completely new things (except an elog-viewer), so the main goal is to enhance existing features. A different goal is to offer other GUI's - Qt is planned and ncurses is thought about ;) > Any thoughts about managing /etc/portage/* files ? "Do not touch the user's configuration files if not necessairy" - so there won't come anything about "managing conf-files". > > Keep up with good work > Thanks :) - and thanks for you interest
Created an attachment (id=108067) [details] portato-0.5.2.ebuild As I released a new release (0.5.2)- here is the ebuild. I did not mark the 0.5.1b-r1.ebuild as obsolete, because the new release does only work with portage-2.1.2 which is still testing. ChangeLog can be found here: http://forums.gentoo.org/viewtopic-p-3864447.html#3864447
Created an attachment (id=115109) [details] portato-0.6.1p.ebuild Here is a new version (0.6.1) of Portato. Changelog can be found here: http://portato.svn.sourceforge.net/viewvc/portato/tags/0.6.1/doc/Changelog?revision=216 IMPORTANT: This ebuild is different in some points to the one found in the svn, as some ebuilds used in the overlay do not exist in the official portage tree. One big difference is the use of gnome-python-desktop instead of pygtksourceview for the "syntax"-flag which makes the package depend on dozens of gnome-packages. Additionally the "etcproposals"-flag needs a package (app-portage/etcproposals) not in the tree (this should be removed when portato makes its way into the tree).
Created an attachment (id=116826) [details] portato-0.7.0p.ebuild This is the new revision of Portato. The most important change from 0.6.1 is the new Qt-Frontend. This allows the user to chose between Gtk and Qt, taking the one which fits better.
Created an attachment (id=116878) [details] fixed portato-0.7.0p.ebuild "built_with_use x11-libs/vte python" kills emerge process, if vte is not installed -> changed to "use gtk && built_with_use [...]", as vte is a dependency if "gtk" is set
Created an attachment (id=118684) [details] portato-0.7.3.ebuild This is the new version (0.7.3) of portato. The major ebuild changes are: - do not depend on gnome-python-desktop anymore (but on portatosourceview) - removed the "etcproposals" useflag as long as etcproposals is not in the official tree Application changes: - added an icon - added a systray (yes - I finally did it ^^) - confirmation dialog to not close the app while there is something emerging =)
Created an attachment (id=118685) [details] portatosourceview-2.16.0 This is the now used implementation of the gtksourceview widget for portato. This is a slightly modified version of the one found in gnome-python-desktop. It can be merged into the normal portato-ebuild, but I haven't done it, to not require the user to compile it each time he installs Portato.
Should respect ROOT settings. don't hardcode /etc/ into the ebuild.
Created an attachment (id=119084) [details] portato-0.7.3.ebuild I applied for the sunrise-overlay. Here is the new ebuild I applied with :). - Should also respect $ROOT now, as it uses doins instead of cp.
Created an attachment (id=119085) [details] portatosourceview-2.16.0 Same for the portatosourceview ebuild. Changing proposed category for "portatosourceview" from "app-portage" to "dev-util".
Portato and portatsourceview now are in the sunrise overlay. You can find it at: http://overlays.gentoo.org/svn/proj/sunrise/reviewed/app-portage/portato http://overlays.gentoo.org/svn/proj/sunrise/reviewed/dev-util/portatosourceview
Created an attachment (id=120884) [details] portato-0.7.4.1.ebuild Version bump ... - now working with PyQt4-4.2 Other changes: - added name of overlay the package comes from - filtering "--ask" from EMERGE_DEFAULT_OPTS - show reason for a package being masked as a tooltip - added settings: gtk: console font - show emerge progress in window title (Already committed to sunrise overlay.)
Created an attachment (id=121019) [details] portato-0.7.4.2.ebuild Bug fix release 0.7.4.2 (I am wondering how many attachments bugzilla allows ;))
Created an attachment (id=122847) [details] portatosourceview-2.16.0-r1.ebuild New ebuild with cleaned up dependencies (already in sunrise)
Created an attachment (id=122848) [details] portato-0.7.5.ebuild New Portato Release with mostly internal changes and a revised terminal for the Qt-Users. As portatosourceview is not bloated with dependencies anymore, the "syntax" useflag has been removed, making the portatosourceview package mandatory for gtk-users. (ebuild committed to sunrise already)
Created an attachment (id=126427) [details] portato-0.8.0.ebuild New ebuild for a new version :). Lots of changes in the program - most important point: removed Qt as it is broken and unlikely to get fixed prior to Konsole is capable of Qt4.
Created an attachment (id=126428) [details] portatosourceview-2.16.1.ebuild New portatosourceview version as needed by portato-0.8.0. Only changes in the portato-plugin xml.
Created an attachment (id=126991) [details] portato-0.8.1.ebuild Bugfix Release ... is in sunrise overlay :)
I would like to get this package on the tree. But there are some things i thing it would be better for this application. For i.e i think when we need to install a package/update world etc.. it should pull a new dialog with a progressbar instead of having the vte window this gives the feeling of having a more automated process when installing the packages. Another thing is pygtk bindings provite gtksourceview why have another sourceview binding pkg ? Anyway great job doing this application! Congrats
(In reply to comment #26) > I would like to get this package on the tree. :) > For i.e i think when we need to > install a package/update world etc.. it should pull a new dialog with a > progressbar instead of having the vte window And where is the Gentoo feeling after this? :) And what should the progress bar display? - I (personally) think losing scrolling by compiling output would be ... not good. I would prefer to have the systray icon showing when sth is being done. But I can't figure out in the moment how to do this. > Another thing is pygtk > bindings provite gtksourceview why have another sourceview binding pkg ? PyGtk does not provide GtkSourceview-Bindings. They are normally provided with the gnome-python-desktop package. Unfortunately this package pulls in half of gnome (see bug #160991). That's why I have taken this package and ripped out all gnome dependencies. > Anyway great job doing this application! Congrats Thanks :)
Created an attachment (id=129201) [details] portato-0.8.5.ebuild This is the new portato release 0.8.5. New Features: - added an uncaught exception dialog - i18n - internal enhancements / killed bugs - added splash screen - added notifies (via libnotify) - added listener / launch gksu/kdesu by ourselves - now showing differences between "installed" and "enabled" useflags Additionally I added the "ppc" keyword (it should be added to the portatosourceview ebuild too - but don't want to submit a new file just for this small change). This is the first version I can call "nearly feature complete" (one thing known not to work are interactive emerges). If any I would suggest this one for the addition into the portage tree. The next version will most probably take one to two months...
What i mean is a dialog like this one from a freebsd ports gui: http://www.meowfishies.com/img/bpm/bpm-install.png http://www.freebsd.org/gnome/images/ss218-2.png This would be wonderful to have on portato and it will be much more userfriendly :).
(In reply to comment #29) > What i mean is a dialog like this one from a freebsd ports gui: > http://www.meowfishies.com/img/bpm/bpm-install.png > http://www.freebsd.org/gnome/images/ss218-2.png > > This would be wonderful to have on portato and it will be much more > userfriendly :). > As I said - it would only be pseudo-userfriendly. My notice (with genlop -c) is that the times are most often not correct-. Also (and this is the most important point), to get the time, I would need to get the information which package is currently being emerged. This is not possible at the moment - and I think it will take it's time to get it done. Perhaps next but more probably the one after it would allow the feature. With other words: When I implemented the prerequisite, I will implement the feature you are asking for =).
(In reply to comment #30) > With other words: When I implemented the prerequisite, I will implement the > feature you are asking for =). > Wonderful feel free to ping me if you need testers.
As this will take one to two months (I plan like doing one release every month) - would it be possible to get the current version into the tree never the less? - Or is your requested feature a "must have"?
Imported to cvs now :)
