abrt version: 2.0.5 cmdline: comment: The input was wrong, but the tool should give a proper error message and not end up with a crash that abrt catches. executable: /usr/bin/livecd-creator kernel: 3.0.0-3.fc16.x86_64 reason: kickstart.py:63:read_kickstart:KickstartError: Failed to parse kickstart file 'fedora-livecd-desktop.ks' : The following problem occurred on line 0 of the kickstart file: time: Thu Aug 4 13:46:15 2011 uid: 0 username: root backtrace: :kickstart.py:63:read_kickstart:KickstartError: Failed to parse kickstart file 'fedora-livecd-desktop.ks' : The following problem occurred on line 0 of the kickstart file: : :Unable to open input kickstart file: Could not open/read file:///home/dev/lars/fedora-live-base.ks : : :Traceback (most recent call last): : File "/usr/bin/livecd-creator", line 187, in <module> : sys.exit(main()) : File "/usr/bin/livecd-creator", line 145, in main : ks = imgcreate.read_kickstart(options.kscfg) : File "/usr/lib/python2.7/site-packages/imgcreate/kickstart.py", line 63, in read_kickstart : "'%s' : %s" % (path, e)) :KickstartError: Failed to parse kickstart file 'fedora-livecd-desktop.ks' : The following problem occurred on line 0 of the kickstart file: : :Unable to open input kickstart file: Could not open/read file:///home/dev/lars/fedora-live-base.ks : : :Local variables in innermost frame: :ks: <pykickstart.parser.KickstartParser instance at 0x1601a28> :path: 'fedora-livecd-desktop.ks' :version: <f16.F16Handler object at 0x15e9e10> :e: KickstartError() :ksfile: '/home/dev/lars/fedora-livecd-desktop.ks' smolt_data: : : :General :================================= :UUID: 0bfc48e7-5093-4faf-8426-fcb77b3b929d :OS: Fedora release 16 (Verne) :Default run level: Unknown :Language: en_US.UTF-8 :Platform: x86_64 :BogoMIPS: 6118.81 :CPU Vendor: GenuineIntel :CPU Model: Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz :CPU Stepping: 5 :CPU Family: 6 :CPU Model Num: 37 :Number of CPUs: 4 :CPU Speed: 3059 :System Memory: 7969 :System Swap: 10047 :Vendor: Apple Inc. :System: iMac11,2 1.0 :Form factor: All In One :Kernel: 3.0.0-3.fc16.x86_64 :SELinux Enabled: 1 :SELinux Policy: targeted :SELinux Enforce: Permissive :MythTV Remote: Unknown :MythTV Role: Unknown :MythTV Theme: Unknown :MythTV Plugin: :MythTV Tuner: -1 : : :Devices :================================= :(32902:11361:32902:32902) pci, None, HOST/PCI, Core Processor QuickPath Architecture Generic Non-core Registers :(32902:11521:32902:32902) pci, None, HOST/PCI, Core Processor QuickPath Architecture System Address Decoder :(32902:64:0:0) pci, None, HOST/PCI, Core Processor DRAM Controller :(32902:65:32902:0) pci, pcieport, PCI/PCI, Core Processor PCI Express x16 Root Port :(32902:11536:32902:32902) pci, None, HOST/PCI, Core Processor QPI Link 0 :(32902:11537:32902:32902) pci, None, HOST/PCI, Core Processor QPI Physical 0 :(4172:33342:0:0) pci, None, PCI/PCI, XIO2213A/B/XIO2221 PCI Express to PCI Bridge :(32902:11539:32902:32902) pci, None, HOST/PCI, Core Processor Reserved :(32902:15152:32902:29296) pci, i801_smbus, SERIAL, 5 Series/3400 Series Chipset SMBus Controller :(32902:15138:32902:29296) pci, ahci, STORAGE, 5 Series/3400 Series Chipset 6 port SATA AHCI Controller :(32902:15106:32902:29296) pci, None, PCI/ISA, 5 Series Chipset LPC Interface Controller :(32902:15154:32902:0) pci, None, NONE, 5 Series/3400 Series Chipset Thermal Subsystem :(5348:5764:5348:5764) pci, tg3, ETHERNET, NetXtreme BCM5764M Gigabit Ethernet PCIe :(32902:15163:32902:29296) pci, None, USB, 5 Series/3400 Series Chipset USB Universal Host Controller :(32902:9294:32902:29296) pci, None, PCI/PCI, 82801 PCI Bridge :(32902:15156:32902:29296) pci, ehci_hcd, USB, 5 Series/3400 Series Chipset USB2 Enhanced Host Controller :(32902:15164:32902:29296) pci, ehci_hcd, USB, 5 Series/3400 Series Chipset USB2 Enhanced Host Controller :(5772:42:4203:143) pci, ath9k, NETWORK, AR928X Wireless Network Adapter (PCI-Express) :(32902:15174:32902:29296) pci, pcieport, PCI/PCI, 5 Series/3400 Series Chipset PCI Express Root Port 3 :(32902:15170:32902:29296) pci, pcieport, PCI/PCI, 5 Series/3400 Series Chipset PCI Express Root Port 1 :(32902:15172:32902:29296) pci, pcieport, PCI/PCI, 5 Series/3400 Series Chipset PCI Express Root Port 2 :(32902:15190:32902:29296) pci, HDA Intel, MULTIMEDIA, 5 Series/3400 Series Chipset High Definition Audio :(32902:15158:32902:29296) pci, None, USB, 5 Series/3400 Series Chipset USB Universal Host Controller :(4098:43576:4203:43576) pci, HDA Intel, MULTIMEDIA, RV710/730 :(4098:38024:4203:182) pci, None, VIDEO, N/A :(32902:11538:32902:32902) pci, None, HOST/PCI, Core Processor Reserved :(4172:33343:0:0) pci, firewire_ohci, FIREWIRE, XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller : : :Filesystem Information :================================= :device mtpt type bsize frsize blocks bfree bavail file ffree favail :------------------------------------------------------------------- :/dev/mapper/VolGroup-lv_root / ext4 4096 4096 5160607 3047574 2995166 1310720 1132291 1132291 :/dev/sda4 /boot ext4 1024 1024 495844 415549 389949 128016 127720 127720 :/dev/sda1 WITHHELD vfat 512 512 403218 342205 342205 0 0 0 :
abrt really shouldn't be catching errors like this. This is perfectly reasonable behavior for a python application that raises a variety of errors.
If notabug in livecd-creator then it must be a bug in abrt? Re-opening and re-assigning to abrt. It might however be more of a packaging guidelines issue - it should perhaps be specified more clearly which application behaviour that is acceptable and what is bugs that should be reported and fixed? (FWIW, IMHO it is no more reasonable behaviour for a Python application to exit with an arbitrary exception than it is for a C application to exit with a segmentation fault.)
Well, it's a matter of opinion, for me any unhandled exception is a bug and there is no way for ABRT to determine which exception is a real bug and which exception is just deliberately uncaught.
On a second thought - it's never ok to consider exception as a proper exit from an application unless it's a situation which should never occur. Reassigning back to livecd-creator.
It seems like there are different opinions on this, and unfortunately the opinions are incompatible and conflicting. IMO that is why have the packaging guidelines to clarify how we do in Fedora - and FESCo and the packaging committee that could and should be asked for clarification when the guidelines isn't sufficiently clear on how this issue shold be solved.
(Re-reassigning to livecd-creator instead of liveusb-creator.)
I went thru the code and this is what I found: except IOError, e: raise errors.KickstartError("Failed to read kickstart file " "'%s' : %s" % (path, e.strerror or e.args[0])) except kserrors.KickstartError, e: raise errors.KickstartError("Failed to parse kickstart file " "'%s' : %s" % (path, e)) can you tell me why it is better to raise an exception instead of just print ("Failed to parse kickstart file '%s' : %s" % (path, e)) if you don't want to catch it anyway? This just leads to printing traceback where error msg would be good enough and unnecessary scares users who thinks this is a bug.
The traceback is being generated by the python-imgcreate library, so that isn't the right place to print errors. Maybe this should be caught higher up in livecd-creator, but then you run into a situation where you are having to try to catch all conceivable errors and convert them to prints. It seems more reasonable to me to let it raise the error, which includes both the easy to read output and a traceback to where the original error happened in the library. I think it is a mistake for abrt to be catching tracebacks in python code at all. If the python interpreter crashes, fine. But abrt doesn't (and very likely can't) provide any useful additional information to a traceback.
(In reply to comment #8) > The traceback is being generated by the python-imgcreate library, so that isn't > the right place to print errors. > > Maybe this should be caught higher up in livecd-creator, but then you run into > a situation where you are having to try to catch all conceivable errors and > convert them to prints. It seems more reasonable to me to let it raise the > error, which includes both the easy to read output and a traceback to where the > original error happened in the library. > - error msg or error dialog would be imho the right solution, but it's your code and no one can force you to fix it.. > I think it is a mistake for abrt to be catching tracebacks in python code at > all. If the python interpreter crashes, fine. But abrt doesn't (and very likely > can't) provide any useful additional information to a traceback. - it's you one problem with it against many bugs in python code fixed thanks to ABRT reports...