Attached is an ebuild for kuroo, the new version fixes problems with changing portage. Workarounds to add FEATURES="metadata-transfer" are no longer necessary. I am creating this bug prior to submitting the ebuild to sunrise, so that it can be referenced by the sunrise team. Reproducible: Always Steps to Reproduce:
Created attachment 197386 [details] kuroo-0.82.0 released
I should note, this could be considered related to bug #236772
Created attachment 197425 [details] updated ebuild after talking to dzhus and ssuominen in #gentoo-sunrise
Very happy to see this being updated, I have always loved this program. I was able to emerge the first version of the ebuild but the second one failed on the configure part
Just tried latest version of ebuild that was to be added to sunrise overlay and that one seems to build fine.
(In reply to comment #4) > Very happy to see this being updated, I have always loved this program. I was > able to emerge the first version of the ebuild but the second one failed on the > configure part I'd like to see what your failure was on the configure so I can try to fix it, could you paste it in or send me an email? (In reply to comment #5) > Just tried latest version of ebuild that was to be added to sunrise overlay and > that one seems to build fine. > I don't see kuroo in sunrise yet, though I'm talking with the people on #gentoo-sunrise to try to get it in there. Were you trying kuroolito instead? kuroolito (bug #192007) was another project by the former kuroo developer which never made it into portage, but I see is available on sunrise.
The version I got that seemed to be the most recent (at least I thought it was, when I emerged this version it actually showed up as the new version asking me to back up all my files before using) I downloaded from here http://kuroo.svn.sourceforge.net/viewvc/kuroo/ebuilds/
Is it also my understanding that I no longer need in my make.conf FEATURES="buildpkg distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch metadata-transfer" Which of these can I remove and expect kuroo to function correctly?
(In reply to comment #7) > The version I got that seemed to be the most recent (at least I thought it was, > when I emerged this version it actually showed up as the new version asking me > to back up all my files before using) I downloaded from here > http://kuroo.svn.sourceforge.net/viewvc/kuroo/ebuilds/ > I mis-read your previous comment, you said "Just tried latest version of ebuild that was _to be_ added to sunrise" and I just read that it was already added. The one you're using is the right one, so it's great to hear that it works for you! (In reply to comment #8) > Is it also my understanding that I no longer need in my make.conf > FEATURES="buildpkg distlocks fixpackages parallel-fetch preserve-libs > protect-owned sandbox sfperms strict unmerge-orphans userfetch > metadata-transfer" > > Which of these can I remove and expect kuroo to function correctly? > The only important additional feature that was required to get the old kuroo to work was "metadata-transfer" I think the ebuild used some kind of trick to determine your previous FEATURES setting and append metadata-transfer to the end in the postinst message. For instance my log of the kuroo emerge had this list: FEATURES="ccache distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch metadata-transfer" which has metadata-transfer twice (since I already had it in my features), and includes ccache which I've added separately. I see your features includes buildpkg, which I assume you must have added manually yourself. Any of the others that you don't recognize are probably defaults and would be safe to remove, since FEATURES is an incremental variable according to 'man make.conf' It's important to note that the metadata-transfer feature is how older portage merged the gentoo package repository and all overlays you had included, so in 'fixing' the dependency on that metadata, I broke overlay support in the new kuroo. This is one of the features that is on the list to fix in an upcoming release.
Yes you did, all ebuilds from my personal overlay show up in the new kuroo as no longer available.
(In reply to comment #10) > Yes you did, all ebuilds from my personal overlay show up in the new kuroo as > no longer available. > kuroo had the same problem as Ed Catmur's udept has (hence it's hardmasked status). We depended on the files in /var/cache/edb/dep/ for all our metadata, when that was generated on the server and moved into the tree for the gentoo repository, the 'metadata-transfer' step which previously generated the data in /var/cache/edb/dep was disabled and portage was changed to use what's in the tree. I believe for overlays portage will still generate that cache and put it in that location, but I need to come up with logic that is able to determine the right location to look at the right time, I've been thinking of a fallback scheme for this, look in the tree first for server-generated metadata, then in /var/cache/edb/dep. The problem with this is that, in addition to not generating the metadata anymore, the metadata in the tree reverted to an older format where each line number has special meaning, instead of the newer format where the file is a list of variables and assignments. There was code to check the version of portage and use the new format if portage was high enough, but I had to take that out and always use the old format to work with the metadata in the tree. Complicating my efforts, none of this is documented to speak of, the changes just happen to portage code so to figure out what is going on I have to read ebuild.sh (which isn't commented very well) and try to decode its logic for reading these files.
Please keep up the great work, 0.82 works great and I believe that kuroo is an important program for gentoo users. Did I see the beginnings of a porting to kde4?
(In reply to comment #12) > Please keep up the great work, 0.82 works great and I believe that kuroo is an > important program for gentoo users. Did I see the beginnings of a porting to > kde4? > Yes, actually Matthias Fauconneau has been doing a lot of the porting work in parallel that I didn't even know about, but he contacted me and we merged his code into the sf.net project at a new kuroo4 branch. We're at the point where it compiles, but won't run because of the changes from kde3 to kde4. I'm going to be working on trying to get it to run over the next several weeks while Matthias is on holiday.
This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/proj/sunrise/browser/sunrise/app-portage/kuroo
Created attachment 198107 [details] Final version committed to sunrise with help from Tommy[D]
I believe I saw some work being done to port kuroo to kde4. Is it almost ready? Any chance for an ebuild. I am using kuroo with kde 4.3 and it works fine but it would be super if it was using the new kdelibs instead of the old.
As far as kde4 and kuroo4 that I saw some work being done on, I believe it might be best to have kuroo4 be a separate slot. When I use kuroo in kde4, it changes permissions on .ICEauthority and doesn't allow me to login to kde3 until that file has permissions adjusted or is deleted.
(In reply to comment #16) > I believe I saw some work being done to port kuroo to kde4. Is it almost ready? > Any chance for an ebuild. I am using kuroo with kde 4.3 and it works fine but > it would be super if it was using the new kdelibs instead of the old. > (In reply to comment #17) > As far as kde4 and kuroo4 that I saw some work being done on, I believe it > might be best to have kuroo4 be a separate slot. When I use kuroo in kde4, it > changes permissions on .ICEauthority and doesn't allow me to login to kde3 > until that file has permissions adjusted or is deleted. > There is work being done at the sourceforge project, but it is not close to ready yet. Matthias Fauconneau is making really good progress on the KDE4 front after originally trying to keep most of the UI code kuroo had he instead decided that it would be easier to write most of it from scratch instead of porting over. Anyways, the UI is there in KDE4 just in an incomplete state where you probably don't want to be actually using it to mess with packages yet. I've already planned on having kuroo4 in a separate slot, the ebuild for kuroo that's in sunrise right now is in slot 3.5 so that it would be easier to put the new kuroo in slot 4. Both kuroos should be able to exist side-by-side because they'll install in different directories (prefix for kde 3 and just /usr/bin for kde 4), but we'll have to make sure they don't do anything with the data in /var/cache/kuroo that the other client would get mad about.
kuroo4 --- /var/cache/kuroo4
Have you removed the functionality of add to world and remove from world? It no longer seems to work on mine.
(In reply to comment #19) > kuroo4 --- /var/cache/kuroo4 > That would potentially work, but we shouldn't need to duplicate all that data, and it looks like it would be reasonably safe as long as you weren't using both at the same time just to use /var/cache/kuroo. Also, I don't plan on changing the name of the executable since the KDE4 version will just install in /usr/bin like all of KDE4, while the KDE3 version installs in /usr/kde/3.5/bin like all of KDE3. (In reply to comment #20) > Have you removed the functionality of add to world and remove from world? It no > longer seems to work on mine. > The functionality is still all there, but I noticed while I was working on it that kuroo has very iffy support for slots. I have lots of slotted kde*-meta packages in my world because I have both 3.5 and 4 slots installed and kuroo doesn't parse the slots correctly so it doesn't display in the UI. Also, when you try to add / remove any of these slotted packages that are already in the world, kuroo finds the package in world, then sees the slot and doesn't do anything. This is one of the to-dos for some time in the future, but I'm not sure how to make a UI that can display all this information without cluttering things up too much. To summarize, if your world file has no slots in it then everything is great, if you do have slots kuroo will work with the non-slotted parts of it, but not with the slotted parts.
Deprecated KDE3 application, nothing for kde@ here, removing CC. Please add us back if the upstream development if continued with a KDE4 release, thanks!
Kuroo 0.82 has been added to kde-sunset since sunrise cleaned out all the KDE 3.5 packages.
The latest kuroo crashes. Any update on this?
(In reply to comment #24) > The latest kuroo crashes. > Any update on this? I think you may be commenting on the wrong bug. This was from back when there wasn't any viable KDE4 version of Kuroo. If you are still on the KDE3 version from kde-sunset I'd recommend switching to the version in the portage tree now. If you are using the tree version I'd still need more info because its working fine for me (aside from a few known bugs).
Given that app-portage/kuroo4-0.90.5 just entered the tree, should this be closed as no longer relevant?
