I released elogviewer 1.0.0 on sourceforge.
It now comprises both elogviewer (gtk frontend) and kelogviewer (qt frontend --- updated to qt4)
Steps to Reproduce:
Please note that, although the UI is mostly untouched, the program has been heavily refactored. Whereas it used to live in a single file, I split the code such as the pygtk code and the core of the functionality are in separate files. That in turned allowed me to resurrect the pyqt version (now obviously PyQt4).
Everything is now in the directory libelogviewer. There also is a python launcher ./libelogviewer/elogviewer.py that takes care of parsing the command line arguments and selecting the frontend.
The ebuild should therefore propose the user to either
1. install and use the gtk2 frontend (USE=gtk), with dependencies on dev-python/pygtk and gnome-base/librsvg and install an "elogviewer" shell script launcher in /usr/bin similar to the one I include in the root of the archive
2. install and use the qt4 frontend (USE=qt or kde), with dependency on dev-python/PyQt4 only and install a "kelogviewer" shell script launcher in /usr/bin similar to the one I include in the root of the archive
3. there is no problem I am aware of installing with both frontends
I also included an icon for the program in the svg format, it comes from gnome and is gpl2 as well. It is saved in libelogviewer/rsc/scalable. I did not rename it either.
<overlay contact="firstname.lastname@example.org" name="kde-sunset" ...>
IMO this is wrong. Mailing lists are not bugzilla subscribers, so please change  to reflect that, or bugs cannot be assigned appropriately.
I am probably wrong in assigning this to kde@ but it's the closest I could find right now.
it is properly documented:
Maybe you should make a note of that in layman-global.txt. How else can people know they should not file a bug report?
it is already there (if that's what you mean):
<overlay contact="email@example.com" name="kde-sunset" src="git://git.overlays.gentoo.org/proj/kde-sunset.git" status="unofficial" type="git">
<!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
<description>User-maintained overlay for old KDE packages removed from the tree, such as KDE3.</description>
Plus we advertised it a lot when we removed kde3 from tree, what else can we do?
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/overlays/layman-global.txt,v
retrieving revision 1.483
diff -u -B -r1.483 layman-global.txt
--- layman-global.txt 3 Mar 2011 11:29:03 -0000 1.483
+++ layman-global.txt 8 Mar 2011 19:20:35 -0000
@@ -600,7 +600,8 @@
<overlay contact="firstname.lastname@example.org" name="kde-sunset" src="git://git.overlays.gentoo.org/proj/kde-sunset
.git" status="unofficial" type="git"> <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
- <description>User-maintained overlay for old KDE packages removed from the tree, such as KDE3.</description>
+ <description>User-maintained overlay for old KDE packages removed from the tree, such as KDE3.
+ Please do not file bug reports, but subscribe to the contact mailing list.</description>
<overlay contact="email@example.com" name="kerberos" src="git://git.overlays.gentoo.org/proj/kerberos.git" status="unofficial" typ
e="git"> <!-- THIS FILE IS GENERATED, PLEASE EDIT repositories.xml INSTEAD. -->
I believe there was some misunderstanding in this thread.
elogviewer and kelogviewer is an application that displays gentoo's elogs, generated by portage. I am now proposing it with two frontends: elogviewer uses gtk and kelogviewer, qt.
elogviewer (gtk2 frontend) has been slightly updated, with only a few user-facing changes.
kelogviewer (qt4 frontend) has been updated to run with the current version of qt in the tree, i.e., qt4. It is not a KDE application, it does not require KDE. It actually has nothing to do with KDE, it only uses the same toolkit, and should therefore look native in KDE.
elogviewer and kelogviewer are now two frontends to the same codebase, I am not sure that having an ebuild for each is a good idea, but I definitely leave that up to you, maintainers.
Since I honestly have no idea how anything that has been discussed in the thread so far applies to my poor little software, I would like to reopen this bug and kindly ask again for its update/inclusion in the tree.
Thank you for giving a little bit more consideration to my contribution, no matter how little it appears to be.
Yeah, there has been a communication failure here. Anyway, Jeroen reassigned it to proper maintainers (and as a side note I did the update in layman xml file)
Sorry for the noise
Please do not hesitate to tell me if I may help in any way to get this update into the tree. I think the Qt version, even though it may not be perfect, is a worthy addition to this program.
Mathias, we now have a gentoo-guis overlay for development work on guis for gentoo tools. We can help you get the ebuild/installation sorted out and host the ebuild in the overlay. Once it is proven good it should be easy to move it to the tree.
There is an email list for gentoo-guis and #gentoo-guis on the freenode irc network. Come join us, the more the better.
could this be added to $ARCH for testing? I've a suggestion or two for this application but cannot even test a current version.
I'd love to see a script to run that showed in a pane the $date postinstall information
Perhaps it already has something like this but cannot say.
Seems to be a nice tool Thanks Mathias ;)
I'm not having fun trying to get this working properly. I am unable to get elogviewer or kelogviewer to run at all from the elogviewer-1.0.0.tar.bz2 file from sourceforge. This really needs a lot more work before we can put it into the tree. I'm willing to work with you but your best bet is to probably work with gentoo-guis overlay since there are several people that can help with getting this working well.
My advice would be to take the time to figure out how to make the package installable using distutils from python. Once that is done, it is fairly simple for me to write an ebuild to install the software correctly.
Created attachment 337300 [details]
ebuild for elogviewer 1.0.1
The ebuild is only tested on amd64 with python2_7
Created attachment 337302 [details, diff]
And it's broken again after today's update :(
I get lots of Index out of range errors in get_contents() function, e.g. when the elog file has "ERROR: pretend", then again "ERROR: setup" works.
I cloned from svn (where is the new repo?) which appears to have version 0.7.0. I added xz and gz support and it seems relatively stable.
(In reply to comment #15)
> I cloned from svn (where is the new repo?) which appears to have version
> 0.7.0. I added xz and gz support and it seems relatively stable.
git clone git://git.code.sf.net/p/elogviewer/code elogviewer-code
Created attachment 350310 [details]
- works for me on amd64 in a VM with PyQt4 (pyside segfaults)
- the program (not the ebuild) was tested on python 2.7 and python 3
OK, starting some testing. it works on python-2.6 and up, but since I didn't have argparse intalled in 3.1 it fails, so, I'll add the argparse dep for 2.6 & 3.1
Is there a way to set column widths? It's annoying having to make the window real wide just to get the timestamp to show in one line, and have other columns with a single icon super wide.
Second. Is there a way to change the light yellow error text on a white background to something else?
I'll push the 2 ebuilds, 2.0 & 2.1 to gentoo-guis after adjusting the ebuild.
Well, virtual/argparse was already in the ebuild.
updated to add python-2.6.
I've pushed both 2.0 and 2.1 ebuilds to the gentoo-guis overlay for initial testing/debugging.
One small code bug I've noticed. The important flag is being set at times when changing the selection. Not clicking the important column.
Color selection. I see it is hard coded in the source. I changed the error to red and the warn to papaya orange, ... much better :)
prefix = '<p style="color: red">'
prefix = '<p style="color: #E56717">'
> I've pushed both 2.0 and 2.1 ebuilds to the gentoo-guis overlay for initial
> One small code bug I've noticed. The important flag is being set at times
> when changing the selection. Not clicking the important column.
I do not know how this is even possible. I could make the 'important' flag react only on double click?..
> Color selection. I see it is hard coded in the source. I changed the error
> to red and the warn to papaya orange, ... much better :)
That is fixed in 2.1a. The keyboard shortcuts are also now shown in the tooltip to make them more obvious.
Tested elogviewer-2.1 from gentoo-guis overlay.
Works like charm, a wonderful program :)
I think I'll start using it instead of elogv, the read/undread and important bookmaking for later processing is a great idea.
The only thing missing that elogv has better is that the "Highest eclass" only lists the name of the eclass, not the color like elogv. If colorizing in that column was added, that would be great.
(In reply to Ondrej Grover from comment #21)
> Tested elogviewer-2.1 from gentoo-guis overlay.
> Works like charm, a wonderful program :)
> The only thing missing that elogv has better is that the "Highest eclass"
> only lists the name of the eclass, not the color like elogv. If colorizing
> in that column was added, that would be great.
I added that in 2.2. The ebuild is on sourceforge as well.