Description of problem: smart crashes when trying a smart update / upgrde Version-Release number of selected component (if applicable): 0.41-31.fc6 How reproducible: allways Steps to Reproduce: 1. smart upgrade or update 2. 3. Actual results: [root@macbook ~]# smart update Traceback (most recent call last): File "/usr/bin/smart", line 194, in ? main(sys.argv[1:]) File "/usr/bin/smart", line 161, in main forcelocks=opts.ignore_locks, loglevel=opts.log_level) File "/usr/lib/python2.4/site-packages/smart/__init__.py", line 115, in init ctrl = Control(configfile, forcelocks) File "/usr/lib/python2.4/site-packages/smart/control.py", line 53, in __init__ self._fetcher = Fetcher() File "/usr/lib/python2.4/site-packages/smart/fetcher.py", line 53, in __init__ self._mediaset = MediaSet() File "/usr/lib/python2.4/site-packages/smart/media.py", line 34, in __init__ self.discover() File "/usr/lib/python2.4/site-packages/smart/media.py", line 41, in discover for lst in hooks.call("discover-medias"): File "/usr/lib/python2.4/site-packages/smart/hook.py", line 64, in call val = hook[0](*hookparam, **hookkwparam) File "/usr/lib/python2.4/site-packages/smart/media.py", line 329, in discoverAutoMountMedias prefix, mapfile = line.split()[:2] ValueError: need more than 1 value to unpack Expected results: working smart ;) Additional info: this is on a fully updated FC6 devel
smart needs a rebuild on rawhide, but currently it breaks: smart/util/celementtree/expat/xmlparse.c:75:2: error: #error memmove does not exist on this platform, nor is a substitute available
When I opened bug #201435 I didn't realize that it was a duoplicate of this one, sorry. Since the resolution is in the other bug I'm closing this as a duplicate of the other. In case it's not the same issue please reopen, thanks! *** This bug has been marked as a duplicate of 201435 ***
I should better read the description not my own comment. While smart didn't build until now for FC6, it doesn't really explain the error you see. Can you please try again with the latest smart package? If it still fails (I assume it will), please post the contents of auto.master. Thanks!
I've just updated to the latest smart package (smart-0.42-35.fc6), and it failed to start giving the same traceback as in the initial bug report. If it matters, this is a x86_64 system.
That was expected, what about the contents of /etc/auto.master?
Sorry, it seems I didn't read comment #3 ver well earlier. Below is the entire content of /etc/auto.master >>> # # $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $ # # Sample auto.master file # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # For details of the format look at autofs(5). # /misc /etc/auto.misc /net /etc/auto.net # # Include central master map if it can be found using # nsswitch sources. # # Note that if there are entries for /net or /misc (as # above) in the included master map any keys that are the # same will not be seen as the first read key seen takes # precedence. # +auto.master <<<<
The last line is what causes the breakage. smart assumes that all non-commented entries in this file have at least two words. If you comment that line smart will work again. See als bug #193831.
(In reply to comment #7) > The last line is what causes the breakage. smart assumes that all non-commented > entries in this file have at least two words. > > If you comment that line smart will work again. See als bug #193831. Yes you're right, it did work with the last line commented.
I can confirm that commenting the last line of /etc/auto.master makes smart work again.
Upcoming package (-37) will have a check to skip +<map> entries in auto.master. This is a short term fix, long term smart should query autofs directly instead of replicating its parsing. Upstream has been notified and will fix it in a next release.
The patch is bogus: it applies the fix a couple lines too high. :(
*** Bug 208647 has been marked as a duplicate of this bug. ***
Fixed the fixing patch.