Portato - A Portage GUI

[Shingoshi]

Here's the list of features as provided by pneutato (the name will be changed):

1. File Menu and a common Wget/Search entry box (share the same horizontal area, yielding more vertical space)
/edit: I have now removed the Wget box from the top area, since there is now a command prompt entry box immediately below the Console window. This entry box will satisfy the user's need for Wget, SVN, Git etc...

2. A Packaging Notebook (now providing management for Gentoo, [src2pkg and Slapt-Get] for Slackware).
/edit: RPM, Debian and PkgSrc are now included. The RPM panel uses a style reminiscent of XRPM, with options for building RPMs as well.

3. Portage & Layman repository selection panel (positioned before the Categories, Packages, Description and Versions)
4. All major controls occupy the same general horizontal area (more closely arranged for ergonomics)
5. Continuously visible and updated "Packages Remaining" queue box (on the extreme right, next to the SystemNotebook

Todo:
1. Provide the user to select which blocking packages should be removed in the dialog box (presently not in portato, currently only provides a notification)
2. Local Overlay Management
3. Cluster/Network package installation (simultaneous installation across multiple machines at once)
4. Packaging notebook may later include RPM (yum/xrpm) and Debian (apt-get) management as well
/edit: I have now included both of these systems into the Packaging Notebook. Although the Debian panel is blank, as well as the PkgSrc panel. But they are there for development from community suggestions.

5. Fully functional Xterm/Console with command prompt (Command Prompt entry box now installed below Console)

More features to come.
Shingoshi

Would someone be kind enough to help me with this. I'm just starting to use python and have no experience with it. I'm trying to migrate from using bash scripts to python. So here is what I'm trying to do. Mostly likely, it will be incorrect. This is my attempt to add the ability to use the command "autounmask" in portato/pneutato.

def cb_autounmasked_clicked (self, button):
*** Callback for autounmasking the selected package. ***
if pkg.is_missing_keyword():

I'm not even going to attempt this further. I'd rather just have someone help me, than me making a fool of myself. If you could write a simple python script explaining how it works, I may be able from there to write others on my own.

Thank you!
Shingoshi
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[Kasumi_Ninja]

It's good to see portato is so rapidly progressing! I have one request I absolutely would love to see in portato is the possibility to enable the -g (get binaries packages option). This would make the management of binaries in Gentoo a whole lot easier
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered

[Shingoshi]

Would someone kindly tell me if this occurs with the stable branch of portato (0.10)?

If you click on the Packages header, does it make all of the package names disappear? Or better yet, if you place your cursor over the Packages header, does it respond the cursor being there?

I just installed the latest version (rev. 208) of the live 9999 version. When I place my cursor over the header, it shows itself to be active. Clicking on the header then makes all of the package names disappear. Doing that produces this error message:

Traceback (most recent call last):
File "/usr/lib64/python2.5/site-packages/portato/gui/windows/main.py", line 1204, in cb_pkg_list_header_clicked
self.fill_pkg_store(self.pkgList.get_model(), self.selCatName)
File "/usr/lib64/python2.5/site-packages/portato/gui/windows/main.py", line 932, in fill_pkg_store
for cat, pkg, is_inst in self.db.get_cat(name, self.sortPkgListByName):
File "/usr/lib64/python2.5/site-packages/portato/gui/utils.py", line 207, in get_pkgs
if pkg[2]:
AttributeError: PkgData instance has no attribute '__getitem__'

Portato version: 9999 rev. 208
Used backend: Portage 2.2_pre5
pygtk: 2.12.1 (using GTK+: 2.12.9)
pygobject: 2.14.1 (using GLib: 2.16.3)
lxml: 1.3.6.0

And this is with the standard interface (not mine). I decided to check the standard interface to verify the origin of some of the errors I've been experiencing. So please, someone tell me if this is only happening in the live version.

Also, just for clarification. Are all of the files from the previous installation of portato (or any other package) always removed by each successive update? If so, the error I'm getting is not caused by anything I've done to the portato interface. I guess I could always go back to using the portato-0.10 version, so that I'm always building against the stable version of portato. That does kind of make sense, since I want to make sure that whatever I do with the interface will always be compatible with the stable release of portato.

Shingoshi

/edit: I can now verify that this error occurs with the stable branch of portato. It the exact same message as I got before.
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[Shingoshi]

[Necoro]

Hmm ... for some reason, the forum did not send me a notification that something was entered here ... =)

Regarding pneutato: Great to see that it grows =)
Regarding the bug: Already fixed in rev. 209
Regarding bin-pkgs: Yes - aniruddha asked this some time before already... Somehow vanished from my list ... Have to look into binpkg handling in portage
_________________
Inter Deum Et Diabolum Semper Musica Est.

[Shingoshi]

[Necoro]

[Shingoshi]

[Shingoshi]

I need everyone who follows the posts on this forum to offer assistance here.

I would like to know what utilities you use commonly use in the management of portage, that you would like to see added to portato/Xneutato? Please see this link as an example of what I'm speaking of:
https://forums.gentoo.org/viewtopic-t-66754-highlight-addpatches.html

I am thinking of adding the following utilities to Xneutato:
(Some of these could be handled by the addition of a command prompt in portato. But some of them require a GUI.)
addpatches
autounmask
eselect (for all pertinent packages)
denu: The Gentoo Common Menu (as posted in the above link)
etc configuration editor
ufed (The USE flags in portato/Xneutato should only be used for disabling those which conflict with, or only apply to an individual package. Ufed should be preferred for setting flags that apply to multiple packages.)

As always, I'll be adding more to the list. I'm thinking of adding these to the Package Description notebook. Either implement as additional tabs for each addition, or have one tab for all extended functions. I've yet to work this out. But there really shouldn't be any difficulty in doing this.

/edit: Check the list often, as I will be adding things without marking them as added.

Shingoshi

Necoro: I want to thank and congratulate you on your fix of the unlimited lines issue in the Console. I just noticed it. Really, thanks a lot!
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[Shingoshi]

I am offering this suggestion as a resolution to a problem that has annoyed me for some time now. The problem arises as follows:
1. You select a package to be installed.
2. A dependency also needs to be installed.
3. You want or need to change a USE flag for the dependency.
4. You now find the dependency (most likely in a different category), and change the flag.
5. You now return to the original package (category).
6. But there may be other (dependency) packages with flags you need to change also.
7. You now need to repeat the steps, 4-6 for each additional package.

The alternative:
1. Divide the Package List into two tabs on it's own notebook (using Glade).
2. Tab #1, is the original package. label: Package
3. Tab $2, is the list of all the dependencies for package #1. label: Dependencies
4. This would be kind of like the returned values given by a package search. Except there would be no categories given for the dependencies. That would be handled by the Package label shown by the (present) Package Description box (The one you already have in portato).
5. Now we have all of the dependencies listed in a common column (Tab #2: titled, Dependencies).
6. We can now get all of the information for any dependency, and change it's settings at will, without having lost our original position in the Package List tree.

I'm going to try and see if it's possible to do this with the current code of portato, by simply duplicating some things. I should only have to add a (new parent) notebook to the package list, and divide it into the two (pages) columns as stated. Glade should make this fairly easy.

I'll report back with the results.
Shingoshi

/edit: You can't edit the settings of the dependencies, or view much of their information, without leaving the package you want to install. Example: I was installing a package that needed another package to have it's flags changed to accommodate the package I wanted to install. I had to leave the package (category) I initially wanted to install, and go to the category of the dependency, find it, and then change the settings (flag) of that dependency package. Then I had to go back to the original package (category) I wanted to install, and continue from there. If you have more than one package you need to do this with, it consumes a lot of time.

/edit: This would also take care of the problem of not being able to see what the USE flags are set for any dependency, until it is already added to the queue.

/edit: I have the dual-tab Package List notebook implemented. Now I need to copy the Dependency List from the Package Description, over to the second tab. Testing this as I go along.

/edit: I think I only need this addition snippet of code from you:
1. If you were to take the current Package List code (pkgList), and modify it to show the dependencies that are listed for any package (dependencyList), and give it the the name depkgList, so that it could show the list of dependencies in the same manner as typically used for the packages (with green dots included), that would be a beginning. I'm sorry for how confusing this is.

We currently have the following:
1. pkgScroll >> pkgList
2. packageNotebook > dependencyScroll

I've change this to the following:
1. notebookPkgList >> page 1 = pkgScroll >> pkgList
2. notebookPkgList >> page 2 = depkgScroll >> depkgList
Any package (dependency) selected in depkgList, would then display all of it's values in the packageNotebook. Nothing needs to be changed there. We're basically creating a condition where portato acts as if each dependency is being viewed from it's own category. The only difference here is, that the package we're initially installing, serves as the category for the dependencies we're viewing. I hope that makes some sense.

/edit: I've posted a copy of what I have (dash2necoro.glade.gz) to our forum for Xneutato (name change). There's a picture there as well. http://portato.origo.ethz.ch/system/files/xneutato_functional1.png

/edit: Ok. You already know this. I can't just simply copy dependencyScroll into the notebookPkgList. It has to have a different name. I'd like to use depkgScroll instead. Because for one thing, you can't do anything with the packages in the dependencyList. So some of this has to be changed. Look at the files I left for you on our forum.

I could simply move the dependencyScroll out of the packageNotebook to the notebookPkgList. But that leaves you without being able to instantly see what dependencies a package has. You shouldn't have to use the second tab, unless you really need to. And also, not every package has dependencies. So having to switch to a moved dependency tab wouldn't be a fix for this. We need to keep the original dependencyScroll/dependencyList right where they are, and only add another tab to the packageList (now named: notebookPkgList)

I know! I confused you even more than I did the first time.

http://portato.origo.ethz.ch/system/files/xneutato_functional1.png
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[Necoro]

[Shingoshi]

I've changed the layout again, hoping to find a way to list the "Targets" tab as packages someone wants to install, while providing a second tab for "Depends", giving the means to edit their settings, without ever leaving (and losing your place in) the original category if different.

I would appreciate feedback here as to how this looks. That includes anyone.

Shingoshi

http://portato.origo.ethz.ch/system/files/xneutato_functional2.png
http://portato.origo.ethz.ch/system/files/xneutato_functional3.png
http://portato.origo.ethz.ch/system/files/xneutato_functional4.png

I seem to have fixed the error I posted here.

/Necoro: I really have to stop asking you to bail me out of errors of my own devising. Sometimes it takes nothing more than going back to an earlier version of my work (or yours), and I'm typically able to resolve whatever it is that's vexing me. Anyway, I seem to have the Targets and Depends tabs working just fine now. I have to try a few more things with them, and hopefully, I won't get anymore errors in the process.

You really should not have doubted how easy it is to modify your work. You did a good job coding portato. And if I really knew what I was doing, much of this could have been done in a couple of days (if not sooner). I have changed back to using the portato name, for the tab that relates to Gentoo package management. So this now more closely conforms to the concept of a framework that you and I talked about. So, essentially, portato is now embedded and identified by name, within Xneutato. Xneutato now being the envelope I envisioned it should be.

Thanks for having done such a good job in coding portato.

Shingoshi

I've posted the latest version of my working MainWindow.glade (dash2necoro.glade_.gz) on our forum. You might even notice that I've changed my desktop, to look more like the layout of my interface. I think wearing multifocal lenses is the culprit here. It's becoming a hassle to keep looking up to the top of my screen. A real pain in the neck and a strain on the eyes. So having all of the information I actually need to read at the bottom of my screen makes better sense. Even when the Console is running in portato, the most important info is now in the middle of the screen. I find these changes I've made to be very easy to work with. And for me spending virtually all of my time in portato, that really matters to me. Very few movements to do anything while using it.

/edit: This is the continuously updated (MainWindow).glade file for Xneutato. Simply remain it to MainWindow.glade, backup your original and replace it with this version. You'll then see all of the changes happening with Xneutato. The second tab is for portato.
http://portato.origo.ethz.ch/system/files/dash2necoro.glade_.gz

Anyway, I hope you're doing well with your exams.
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[Shingoshi]

The reason why I have stressed the need for a separate dependency installation "Depends" facility, without losing your place with the original "Targets" package, is because there are many times when the user knows that certain packages cannot be installed from the dependency list for the Target package. So in those instances, it is useful and very practical to load the dependencies individually, since they cannot be installed if any one of them cannot be.

/EDIT: The dependencies for any package will only be installed if all of the conditions created by the dependencies are met individually. If anyone of them fails to emerge (as in being blocked), the Queue will not process. This means also having to fix the problem, and restart the Queue. If a dependency has a USE flag which doesn't support the package-X which is wanted to be installed, package-X won't install either.

So I spend a lot of time going back and forth from my Target package, to each of the "Depends" dependency packages attempting to load each of them separately. This quickly becomes a nuisance, especially when there are numerous dependencies as there are for the gnome-2.22.1 meta package. It has version requirements for dependencies I already have installed, but not to the correct (make that latest) version. Having the ability to switch to a different tab, appropriately named "Depends", would eliminate most of this frustration. And while many of the users here may not think this is important, I'm certain once this feature were made available, each of them would sooner rather than later come to swear by it. It is something that would save everyone a tremendous amount of time, regardless of the their level of usage with Portato.

Let's face it. People use Portato, because they want to save time. So something such as this, which serves that purpose and efficiently, should not be something passed off as irrelevant or inconsequential.

See my latest glade file for the new code I've made for the interface: http://portato.origo.ethz.ch/system/files/dash2necoro.glade_.gz
And here's the latest image at the time of writing this: http://portato.origo.ethz.ch/system/files/xneutato_functional6.png

Shingoshi
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[Necoro]

I still don't get, why you are changing categories and the-like to change flags in dependencies... Just use the provided queue ...
I only get, that it might be useful to have extra windows when chosing packages in the "Dependency" tab. That's true -- but atm it's not implemented to select a package there at all... (Due to lazyness)

Another option would be to make it similar to porthole and do the dependency calculation recursive...
(Btw: Have you tested porthole? - Perhaps it fits your needs better than portato)

Ah - and regarding your UI: I hope you don't mind, if I say: Your UI is way too stuffed for me
_________________
Inter Deum Et Diabolum Semper Musica Est.

[Shingoshi]

[Necoro]

[Shingoshi]

Ok, so since I'm wrong, please just post the cb_code_for_features so that I can apply them to the Depends tab. Because in order for there to be features available in portato, there must also be the tags to enable their functioning in portato through the MainWindow.glade file. Better yet, just tell me where to find these tags in portato, because they must be among those that are somewhat hidden, like the Console and Queue menus.

That should be all that I need. I think, based on the clarity of the labels you use for callbacks, I should have no problem knowing where to attach each one of them to make this work.

Shingoshi
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[Shingoshi]

* Trying to remove package 'nemiver-0.5.2' from queue which does not exist in system. (updater.py:95)

This has been showing up on my konsole from portato:

* Trying to remove package 'nemiver-0.5.2' from queue which does not exist in system. (updater.py:95)
* Nothing to remove. (updater.py:106)
* 'dev-php/PEAR-HTML_QuickForm-3.2.10' should be removed, but is not in queue. (updater.py:112)
* Trying to remove package 'nemiver-0.5.2' from queue which does not exist in system. (updater.py:95)
* Nothing to remove. (updater.py:106)
* 'dev-php5/ezc-ConsoleTools-1.3.2' should be removed, but is not in queue. (updater.py:112)
* 'dev-libs/redlandmm-9999' should be removed, but is not in queue. (updater.py:112)
* Trying to remove package 'nemiver-0.5.2' from queue which does not exist in system. (updater.py:95)
* Nothing to remove. (updater.py:106)
* 'dev-php5/ezc-Translation-1.1.6' should be removed, but is not in queue. (updater.py:112)
* 'dev-php/PEAR-Mail_mimeDecode-1.5.0' should be removed, but is not in queue. (updater.py:112)
* Trying to remove package 'nemiver-0.5.2' from queue which does not exist in system. (updater.py:95)


The problem is, the package does exist:
dev-util/nemiver/nemiver-0.4.0-r1
dev-util/nemiver/nemiver-0.5.2.ebuild,v 1.1

So what exactly is wrong here? This has been happening with a couple of packages. I think there's more to this, but I can't remember right now what else I have seen concerning this. I'll post it when I come across it again.

I should also mention that I hadn't selected that package in the current session. It was from a previous session. If I see this again (I just restarted portato to view some more changes made), I'll let you know.

Shingoshi

/EDIT: The nemiver issue has come up again, even after restarting, and not having selected it.
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[Shingoshi]

I only need 4 callbacks to make my features within the Depends tab to work.
I need the following callbacks to be provided:

1. Categories (of the dependencies)
cb_depends_cat

2. Packages (the dependencies themselves. With the ability to show them in the Description panel)
cb_depends_pkg

3. Version/Slots (of the dependencies)
cb_depends_ver

4. Package Description (for the dependencies)
cb_depends_des

You give me those 4 callbacks, and this will go away for me (and you).

I think I may be able to do what I need with that alone. But at the very least, it would give me a starting point. I should also let you know that I'm finally looking into starting an Overlay for my project. At the very least, it will allow me to (locally) modify portato without losing my modifications on each new sync. Basically, the project would simply patch the existing portato sources to enable my extended functions.

Shingoshi
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[Shingoshi]

Dol-sen, maybe you can answer this.

If I create an entirely new application (Xneutato), which uses my interface as it's MainWindow.glade, can I then create any callbacks I want and apply them to any other application that I call as an extension module running within my new application?

I'm thinking of how Anjuta functions, in calling Glade (and others) as extensions to Anjuta. Anjuta completely changes the layout of those applications to suit it's own interface. But what I want to know is if I create a new index of my own independent callbacks, can I then apply those callbacks to the applications I'm using as backends for the extended functions my application provides (that the backends originally didn't)?

Please see my latest glade file:
http://portato.origo.ethz.ch/system/files/dash2necoro.glade_.gz
And it's latest functioning image (/EDIT: I've added the delete button back to the search box, but named "clear" now.):
http://portato.origo.ethz.ch/system/files/xneutato_functional10.png

Please advise here,
Shingoshi
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[dol-sen]

I don't know anjunta. I am not also a super experienced python coder. But you could import the backend application and use it within the limits that code is capable of. Anything else that falls short of what you need, you will have to code yourself.
That is what porthole has to do when portage info is not adequate or suitable for porthole's needs. Also remember that when the backend code changes, it may break your code relying on it.

As for your new dep tab. What I did for porthole was extract only the portion of portholes mainwindow widget tree that had all the package details and tabs, put that in a new window without the category and package listings. That new window is also attached to the same code that supports the original mainwindow package details. It did not take that many modifications to the code to be able to create and track the new dep windows. see the get_widget() commands for working with glade files.

If you studied portato's code more, I am sure you will find that it would be capable of doing similar with some code changes. But you will have to try to find where those changes need to be done and only then ask necoro for help implementing them when you get stuck. That's how I learned to code in python. It was working on porthole, now I am the main dev and project administrator. So don't be too impatient.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

[Shingoshi]

One of the things that occurs when you compile as many packages as I do, is that you come across (too) many bugs, which if you're nice, you then report to https://bugs.gentoo.org. I spend so much time each day tracking bugs I post(ed) there, that I would rather have some kind of utility to search for and read any relevant posted on that site. It makes sense, if you're getting ready to compile a large package, to know whether there are unresolved bugs hanging over it or not. Now for the casual user, this doesn't have any bearing. But if you compile more than 25 packages a day, it could save a lot of time. So I'm thinking of adding yet another tab to the systemNotebook, between the Console and Log tabs (making for a total of 4) just for this purpose.

And no Necoro, I'm not asking you to add this. I'm just saying that the idea came to me this evening after spending another batch of time posting and checking bugs. I almost envy some of you. Me, I spend all of my time practically, sitting in front of portato, installing packages. The rest of you likely have real lives. Not complaining about it though, it just has to be done for what I'm doing. When I'm not directly using portato (and it's running in the background), I'm spending my time using Anjuta (Glade) to edit portato's layout, and the rest browsing for things related to building my system.

But then, I must enjoy it. Because I can't seem to stop.
Hope all of you had a good weekend.

Shingoshi
http://portato.origo.ethz.ch/system/files/xneutato_functional10.png
_________________
The immediate equalization of all knowledge among all beings.
Xneutato - The Cluster-Distributed Package Development and Management Framework
http://portato.origo.ethz.ch/forum/23
Shingoshi's User Styles for Firefox
http://userstyles.org/users/3665

[carpman]

Does this app have same features as emwrap script, ie ability to update system without updating tool chain?

Having ability to update system minus tool chain or just update tool chain aka emwrap script would be good addition.
_________________
Work Station - 64bit
Gigabyte GA X48-DQ6 Core2duo E8400
8GB GSkill DDR2-1066
SATA Areca 1210 Raid
BFG OC2 8800 GTS 640mb
--------------------------------
Notebook
Samsung Q45 7100 4gb

[Necoro]

@Shingoshi: There is no callback for it. It is handled in the normal code... see portato.gui.windows.main.PackageTable._update_keywords
And for the four callbacks you requested:
a) - don't understand what you want
b) Please use the portato forum and not this thread for "internal" things

Regarding the "bug": Would be great if you would not crosspost - posting it only in Portato's issues is enough

@carpman: I don't know the "emwrap" script. But if I understand correctly, you want to update world w/o system. As this is normal behavior in portage-2.5, I think there is no reason to implement it. (Though I first need portage-2.5 support )

Btw: Exams done - diploma thesis, I'm coming
_________________
Inter Deum Et Diabolum Semper Musica Est.

[dol-sen]

That and he means slpit up system into the basic tool-chain and remaining system packages.

Tool-chain being ""linux-headers, glibc, binutils, gcc"

I started on it a while ago, but did not have time to get much done. Now that I have set support the toolchain will not be that difficult to make as an option.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...