Thank for the update to deal with files in /etc/portage. However, I'm still having issues - should they be discussed here, in the Gentoo forums, or ...?
(quick symptoms is that kuroo seems confused about which versions of packages are stable or not, and I thought I saw console messages that seemed to indicate kuroo doesn't know anything about slots.)
Jack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Notifications go to #gentoo-guis on freenode when things update here so I'll see it quicker. If you update an old thread on the forums I have notifications for them, but i won't see new posts. I lurk in #gentoo-guis and I check it at least each weekday, generally not on weekends though.
Unfortunately, Kuroo hasn't been keeping up with recent developments in portage because my C++ skills are pretty rusty and I can't motivate myself to sit in front of a computer programming after doing that for my whole day job. Thanks to facconeau and cazou88 we were able to get it ported to KDE4 but some features were disabled to do that (dependency tree in the package inspector) and there are some rough edges too (repaint code in the queue doesn't trigger unless there's a mouseover event). Anyways, I was able to deal with the make.conf move because it's relatively easy, but properly supporting SLOTs is a big thing that's beyond me at the moment. I don't recall having any issues with knowing which packages are stable or unstable though, could you give an example for me?
Thanks,
-Andrew
Last edit: A Schenck 2014-09-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, without slots, it won't be very useful, because mamy of the things I'd like to see graphically are related to slot issues.
I wish I could help, but I doubt my C++ is any better than yours.
Regarding knowing about stable/testing, it now looks better - perhaps I had something stuck in cache last time I looked. However, as an example, for mail-client/balse I have version 2.5.1 ~amd64 installed (from local overlay) and 2.4.13 and 2.4.14 are marked stable in the tree. Kuroo main display and details says 2.5.1 is stable, but details says "Not on" for the other two. (part of the problem appears to be that kuroo doesn't know about my local overlay.) Oddly, on the destails page, versions tab, the right half is grayed out, but does have Testing Version checked even though 2.5.1 Stability column on the left says "Stable".
Second example: dev-python/simplejson 3.3.0 (stable) installed, 3.6.3-r1 (~amd64) also in tree. Kuroo shows "Not on" for both of them, although it does show (U) for upgradable (it's not in any package.xxx file at all.)
Is the issue that I just don't understand what is meant by "Stable" vs "Not on" in the Stability column?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kuroo only displays the versions of ebuilds in /usr/portage in the package list, so it doesn't pick up things from overlays. That's a feature I wanted to add for a long time, and it should mean just parsing the overlays variable and repeating the package scan loop for each entry, but that hasn't been done yet. It does show overlay things that are installed, but as you have seen it thinks they are "Not on <arch>". Since it runs actual command-line emerge commands those will correctly handle overlays at least. For the upgrade list it parses the output of 'emerge -u' and lists those packages regardless of whether they're in /usr/portage or an overlay, this gets really confusing because it shows that the package is upgradeable but you can't actually see the details of the ebuild. Portage changed to pre-generate the metadata cache and serve it up in tree, but I'm not sure about how the cache is generated for overlays anymore, probably on the fly as portage reads them.
Anyways, the upshot of all this is that "Stable", "Unstable", and "Not on" only reference what's in /usr/portage. The version listed with the checkmark is what is parsed out of 'emerge -u' whether it's in /usr/portage or an overlay.
I confess I actually run 'emerge -uptvND @world' in the console so I can see the pretty colors, then choose what to update in Kuroo and let it manage the queue and show the progress nicely. For the packages in portage it is also much nicer for searching and displaying most of the metadata like actual ebuild code and changelogs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank for the update to deal with files in /etc/portage. However, I'm still having issues - should they be discussed here, in the Gentoo forums, or ...?
(quick symptoms is that kuroo seems confused about which versions of packages are stable or not, and I thought I saw console messages that seemed to indicate kuroo doesn't know anything about slots.)
Jack
Hi Jack,
Notifications go to #gentoo-guis on freenode when things update here so I'll see it quicker. If you update an old thread on the forums I have notifications for them, but i won't see new posts. I lurk in #gentoo-guis and I check it at least each weekday, generally not on weekends though.
Unfortunately, Kuroo hasn't been keeping up with recent developments in portage because my C++ skills are pretty rusty and I can't motivate myself to sit in front of a computer programming after doing that for my whole day job. Thanks to facconeau and cazou88 we were able to get it ported to KDE4 but some features were disabled to do that (dependency tree in the package inspector) and there are some rough edges too (repaint code in the queue doesn't trigger unless there's a mouseover event). Anyways, I was able to deal with the make.conf move because it's relatively easy, but properly supporting SLOTs is a big thing that's beyond me at the moment. I don't recall having any issues with knowing which packages are stable or unstable though, could you give an example for me?
Thanks,
-Andrew
Last edit: A Schenck 2014-09-08
Unfortunately, without slots, it won't be very useful, because mamy of the things I'd like to see graphically are related to slot issues.
I wish I could help, but I doubt my C++ is any better than yours.
Regarding knowing about stable/testing, it now looks better - perhaps I had something stuck in cache last time I looked. However, as an example, for mail-client/balse I have version 2.5.1 ~amd64 installed (from local overlay) and 2.4.13 and 2.4.14 are marked stable in the tree. Kuroo main display and details says 2.5.1 is stable, but details says "Not on" for the other two. (part of the problem appears to be that kuroo doesn't know about my local overlay.) Oddly, on the destails page, versions tab, the right half is grayed out, but does have Testing Version checked even though 2.5.1 Stability column on the left says "Stable".
Second example: dev-python/simplejson 3.3.0 (stable) installed, 3.6.3-r1 (~amd64) also in tree. Kuroo shows "Not on" for both of them, although it does show (U) for upgradable (it's not in any package.xxx file at all.)
Is the issue that I just don't understand what is meant by "Stable" vs "Not on" in the Stability column?
Kuroo only displays the versions of ebuilds in /usr/portage in the package list, so it doesn't pick up things from overlays. That's a feature I wanted to add for a long time, and it should mean just parsing the overlays variable and repeating the package scan loop for each entry, but that hasn't been done yet. It does show overlay things that are installed, but as you have seen it thinks they are "Not on <arch>". Since it runs actual command-line emerge commands those will correctly handle overlays at least. For the upgrade list it parses the output of 'emerge -u' and lists those packages regardless of whether they're in /usr/portage or an overlay, this gets really confusing because it shows that the package is upgradeable but you can't actually see the details of the ebuild. Portage changed to pre-generate the metadata cache and serve it up in tree, but I'm not sure about how the cache is generated for overlays anymore, probably on the fly as portage reads them.
Anyways, the upshot of all this is that "Stable", "Unstable", and "Not on" only reference what's in /usr/portage. The version listed with the checkmark is what is parsed out of 'emerge -u' whether it's in /usr/portage or an overlay.
I confess I actually run 'emerge -uptvND @world' in the console so I can see the pretty colors, then choose what to update in Kuroo and let it manage the queue and show the progress nicely. For the packages in portage it is also much nicer for searching and displaying most of the metadata like actual ebuild code and changelogs.