gonchik / munki

Automatically exported from code.google.com/p/munki
Other
0 stars 0 forks source link

Unhelpful error message with corrupt pkgsinfo #35

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Add a bad pkgsinfo file
2. Run makecatalogs
3. Get an unhelpful error message that makes it 

What is the expected output? What do you see instead?

butler:munki lits$ makecatalogs .
Adding Adium-1.3.10 to common...
Adding AdobeFlashPlayer-10.1r82 to common...
Adding Ebrary-0.9.6 to common...
Adding EndNoteX3-13.0.0.5726 to common...
Adding Firefox_EN-3.6.9 to english...
Adding Firefox_SV-3.6.9 to swedish...
Adding Flip4MacWMV-2.3.4.1 to common...
Traceback (most recent call last):
  File "/usr/local/munki/makecatalogs", line 135, in <module>
    main()
  File "/usr/local/munki/makecatalogs", line 132, in main
    makecatalogs(repopath)
  File "/usr/local/munki/makecatalogs", line 76, in makecatalogs
    pkginfo = plistlib.readPlist(filepath)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plistlib.py", line 78, in readPlist
    rootObject = p.parse(pathOrFile)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plistlib.py", line 405, in parse
    parser.ParseFile(fileobj)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 0
butler:munki lits$ 

What version of the product are you using? On what operating system?

0.6.0.759

Please provide any additional information below.

Actually printing which file fails and why would make it easier to correct the 
error.

Original issue reported on code.google.com by MagerV...@gmail.com on 8 Oct 2010 at 12:14

GoogleCodeExporter commented 8 years ago
Oh, and the reason for the bad file is that Property List Editor sometimes 
decides to save an edited plist in the old openstep text format. Really 
annoying.

Original comment by MagerV...@gmail.com on 8 Oct 2010 at 12:37

GoogleCodeExporter commented 8 years ago
That's helpful info. I was trying to figure out how a plist could make it past 
plutil -lint, but still cause plistlib to choke on it.  I guess a plist in 
binary format would cause the same issue.

A couple of ways we could deal with this, but I'm not sure of the right one.  I 
may take this to the munki-dev list for discussion.

Original comment by gregnea...@mac.com on 8 Oct 2010 at 1:24

GoogleCodeExporter commented 8 years ago
It's doubly annoying as the text format is lossy - integers and bools turn into 
strings.

Original comment by MagerV...@gmail.com on 8 Oct 2010 at 1:38

GoogleCodeExporter commented 8 years ago
New makecatalogs that addresses this issue in revision 785 in SVN.

Original comment by gregnea...@mac.com on 8 Oct 2010 at 6:03