Packaging for Fedora/Red Hat and some issues with it
matej
I again begin to work on package of jBrout for Fedora/Red Hat (and
hoping to get it into Fedora/Extras) and I have these problems:
1) all (or most) .py files in the tarball have shebang line (the first
line beginning with #!/usr/bin/...) -- are these required for ALL .py
files? rpmlint (program for checking quality of RPM packages) complains
loudly (and it is correct, IMHO) when executable programs are in wrong
places. I am currently liquidating them with sed, but it seems wrong
anyway.
2) gpl.txt is required for running of the program, but they have CRLF
end-of-lines -- shouldn't it be LF only?
3) the most important problems is this -- when starting the program
with removed ~/.jbrout I got errors and when restarting jbrout after
importing testing images and making one tag for one file, jbrout
crashed. See this output of stderr/stdout:
[matej@chelcicky redhat]$ rm -rf .jbrout
[matej@chelcicky redhat]$ cd
[matej@chelcicky ~]$ rm -rf .jbrout
[matej@chelcicky ~]$ jbrout
/usr/share/jbrout/jbrout.py:977: GtkWarning: gtk_tree_store_get_path:
assertion `iter->stamp == tree_store->stamp' failed
path = model.get_path(iter0)
/usr/share/jbrout/jbrout.py:381: GtkWarning: gtk_tree_store_get_value:
assertion `VALID_ITER (iter, tree_store)' failed
node = self.get_value(it,2)
Traceback (most recent call last):
File "/usr/share/jbrout/jbrout.py", line 1846, in
on_btn_addFolder_clicked
self.on_drop_folders_from_os(self.treeviewdb.get_model(),[folder])
File "/usr/share/jbrout/jbrout.py", line 1151, in
on_drop_folders_from_os
self.select(model,newIterFolder)
File "/usr/share/jbrout/jbrout.py", line 978, in select
node = model.get(iter0)
File "/usr/share/jbrout/jbrout.py", line 381, in get
node = self.get_value(it,2)
File "/usr/lib/python2.4/warnings.py", line 61, in warn
warn_explicit(message, category, filename, lineno, module,
registry)
File "/usr/lib/python2.4/warnings.py", line 82, in warn_explicit
for item in filters:
TypeError: unknown type (null)
[matej@chelcicky ~]$ jbrout
Traceback (most recent call last):
File "/usr/share/jbrout/jbrout.py", line 2164, in ?
main()
File "/usr/share/jbrout/jbrout.py", line 2133, in main
JBrout.init(canModify)
File "/usr/share/jbrout/db.py", line 1297, in init
JBrout.db = DBPhotos( JBrout.getConfFile("db.xml") )
File "/usr/share/jbrout/db.py", line 118, in __init__
self.root = ElementTree(file=file).getroot()
File "etree.pyx", line 1504, in etree.ElementTree
File "parser.pxi", line 687, in etree._parseDocument
File "parser.pxi", line 624, in etree._parseDocFromFile
File "parser.pxi", line 364, in etree._BaseParser._parseDocFromFile
File "parser.pxi", line 432, in etree._handleParseResult
File "parser.pxi", line 403, in etree._raiseParseError
etree.XMLSyntaxError: line 1: PCDATA invalid Char value 2
[matej@chelcicky ~]$
Any comments?
Thanks,
Matěj
manatlan
hi
> I again begin to work on package of jBrout for Fedora/Red Hat (and
> hoping to get it into Fedora/Extras) and I have these problems:
great
> 1) all (or most) .py files in the tarball have shebang line (the first
> line beginning with #!/usr/bin/...) -- are these required for ALL .py
> files? rpmlint (program for checking quality of RPM packages) complains
> loudly (and it is correct, IMHO) when executable programs are in wrong
> places. I am currently liquidating them with sed, but it seems wrong
> anyway.
you've right ...
I always put a shebang line on top of all my python file ;-(
(i use it to test my unittest by hand, but it's not a good practice)
only jbrout.py should have one (and convert.py, but i will discard convert.py)
> 2) gpl.txt is required for running of the program, but they have CRLF
> end-of-lines -- shouldn't it be LF only?
sure, it's a mistake
yes i've always worked on this trouble, and i don't find a patch ;-(
It worked well with dapper, and it appears with edgy
I'm pretty sure it's a pygtk/gtk problem ...
it's a real problem ...
(but you gave me an idea, i should test with py2.5 .... but sure, i'll
prefer to stick on 2.4 for now)
> [matej@chelcicky ~]$ jbrout
> Traceback (most recent call last):
> File "/usr/share/jbrout/jbrout.py", line 2164, in ?
> main()
> File "/usr/share/jbrout/jbrout.py", line 2133, in main
> JBrout.init(canModify)
> File "/usr/share/jbrout/db.py", line 1297, in init
> JBrout.db = DBPhotos( JBrout.getConfFile("db.xml") )
> File "/usr/share/jbrout/db.py", line 118, in __init__
> self.root = ElementTree(file=file).getroot()
> File "etree.pyx", line 1504, in etree.ElementTree
> File "parser.pxi", line 687, in etree._parseDocument
> File "parser.pxi", line 624, in etree._parseDocFromFile
> File "parser.pxi", line 364, in etree._BaseParser._parseDocFromFile
> File "parser.pxi", line 432, in etree._handleParseResult
> File "parser.pxi", line 403, in etree._raiseParseError
> etree.XMLSyntaxError: line 1: PCDATA invalid Char value 2
it's a xml trouble which may comes from the last trouble ...
> Any comments?
i'd like to resolve the first problem ...
> Thanks,
>
> Matěj
manatlan
> [matej@chelcicky ~]$ jbrout
> /usr/share/jbrout/jbrout.py:977: GtkWarning: gtk_tree_store_get_path:
> assertion `iter->stamp == tree_store->stamp' failed
[...]
> File "/usr/lib/python2.4/warnings.py", line 61, in warn
> warn_explicit(message, category, filename, lineno, module,
> registry)
> File "/usr/lib/python2.4/warnings.py", line 82, in warn_explicit
> for item in filters:
> TypeError: unknown type (null)
it seems to be a real pygtk trouble ...
see there : https://launchpad.net/products/pygtk/+bug/56744
ubuntu/edgy users should upgrade their pygtk !! (PyGTK 2.10.3 seems to be good)
(fedora users too ;-)
i will try that tonight ...
manatlan
the bad : i don't find any pygtk package wich avoid the bug ...
the good : i've remake a find functiion (recursive one) which doesn't
use the treemodel.foreach() method ...
so this trouble doesn't exists anymore ...
see SVN rev 136 ....
--
"Oui, oui."
-- Shakespeare (Richard III, Acte I, Scène IV)
manatlan
- gpl.txt : no more CRLF, only LF
- no more shebang line at the top of all py files, except jbrout
- and, the biggest, no more bug when importing/refreshing folder
--> SVN rev 138
Matej Cepl
> - gpl.txt : no more CRLF, only LF
> - no more shebang line at the top of all py files, except jbrout
> - and, the biggest, no more bug when importing/refreshing folder
>
> --> SVN rev 138
Could I ask for new release -- I don't think I will have much success
when trying to push SVN version into Fedora...
Thanks a lot for the fast reaction!
Matěj
Matej Cepl
> it seems to be a real pygtk trouble ...
> see there : https://launchpad.net/products/pygtk/+bug/56744
> ubuntu/edgy users should upgrade their pygtk !! (PyGTK 2.10.3 seems to be good)
> (fedora users too ;-)
Chmm, except:
[matej@chelcicky ~]$ rpm -q pygtk2
pygtk2-2.10.3-2.fc6
[matej@chelcicky ~]$
I already have pygtk2 2.10.3. Any other ideas?
Matěj
--
http://www.ceplovi.cz/matej/blog/, Jabber: ceplma<at>jabber.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
His mother should have thrown him away and kept the stork.
-- Mae West
--
Matej Cepl <matej...@gmail.com>
manatlan
> pygtk2-2.10.3-2.fc6
> [matej@chelcicky ~]$
>
> I already have pygtk2 2.10.3. Any other ideas?
i really think this is the same trouble as :
http://bugzilla.gnome.org/show_bug.cgi?id=347273
it seems it's not corrected in any pygtk version (foreach/treestore)...
But in the actual SVN, i don't use foreach/treestore anymore
(i've replaced it with a self made recursive search)
so this bug should not produce anymore ....
matej
> But in the actual SVN, i don't use foreach/treestore anymore
> (i've replaced it with a self made recursive search)
> so this bug should not produce anymore ....
I am afraid we are not there yet:
[matej@chelcicky jbrout-svn]$ svn up
At revision 138.
[matej@chelcicky jbrout-svn]$ ./jbrout.py
Traceback (most recent call last):
File "./jbrout.py", line 2254, in ?
main()
File "./jbrout.py", line 2225, in main
JBrout.init(canModify)
File "/home/matej/WP/kompiliste/jbrout/jbrout-svn/db.py", line 1307,
in init
JBrout.db = DBPhotos( JBrout.getConfFile("db.xml") )
File "/home/matej/WP/kompiliste/jbrout/jbrout-svn/db.py", line 118,
in __init__
self.root = ElementTree(file=file).getroot()
File "etree.pyx", line 1504, in etree.ElementTree
File "parser.pxi", line 687, in etree._parseDocument
File "parser.pxi", line 624, in etree._parseDocFromFile
File "parser.pxi", line 364, in etree._BaseParser._parseDocFromFile
File "parser.pxi", line 432, in etree._handleParseResult
File "parser.pxi", line 403, in etree._raiseParseError
etree.XMLSyntaxError: line 1: PCDATA invalid Char value 2
[matej@chelcicky jbrout-svn]$
Any ideas?
Matěj
manatlan
precedent bug/crash ...
i you delete it, and re-up yours folders, it might be ok
Matej Cepl
> i think it's your DB (~/.jbrout/db.xml) which was corrupted by a
> precedent bug/crash ...
> i you delete it, and re-up yours folders, it might be ok
Of course, I did do rm -rf ~/.jbrout before testing that.
Matěj
--
http://www.ceplovi.cz/matej/blog/, Jabber: ceplma<at>jabber.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
It would be very good idea.
-- Gandhi, when asked what he thinks about Western
civilization?
matej
> i think it's your DB (~/.jbrout/db.xml) which was corrupted by a
> precedent bug/crash ...
> i you delete it, and re-up yours folders, it might be ok
Of course, I did that. However, when I asked on python-lxml list, I got
this answer
(http://article.gmane.org/gmane.comp.python.lxml.devel/2140), when I
uploaded my db.xml file to http://www.ceplovi.cz/matej/tmp/db.xml:
> When you try to open this url in Firefox, you get an XML Parsing Error.
> The photo elements contain a "^B" character, which is not allowed.
Does it make any sense to you?
Matěj
manatlan
uploaded my db.xml file to http://www.ceplovi.cz/matej/tmp/db.xml:
> When you try to open this url in Firefox, you get an XML Parsing Error.
> The photo elements contain a "^B" character, which is not allowed.
Does it make any sense to you?
it makes sense ...
you've got a bad chars in an UTF8 file ...
the bad chars comes from the "jpeg comment " of your "p20060902_161054.jpg"
jbrout shouldn't let you input a "bad char" ... but if it's the case : it's a real bug
what encoding are you using under your gtk/linux ?
Matěj
matej
cs_CZ.UTF-8