Arch Linux User Repository

Won't start after major python upgrade today: Traceback (most recent call last): File "/usr/lib/pkgbrowser/main.py", line 9, in <module> sys.exit(app.run()) File "/usr/lib/pkgbrowser/pkgbrowser/app.py", line 112, in run app.window().setup() File "/usr/lib/pkgbrowser/pkgbrowser/app.py", line 56, in window from pkgbrowser.window import Window File "/usr/lib/pkgbrowser/pkgbrowser/window.py", line 18, in <module> from pkgbrowser.backend import ( File "/usr/lib/pkgbrowser/pkgbrowser/backend.py", line 6, in <module> from html.parser import HTMLParser, HTMLParseError ImportError: cannot import name 'HTMLParseError' and won't build either: install: cannot stat ‘pkgbrowser/__pycache__/*.pyo’: No such file or directory Makefile:50: recipe for target 'install' failed make: *** [install] Error 1 ==> ERROR: A failure occurred in package(). python (3.4.3-3 -> 3.5.0-2) python-pyqt5 (5.5-1 -> 5.5-2) pyqt5-common (5.5-1 -> 5.5-2)

@kachelaqa OK. You are right. Rebuilding pkgbrowser solved this problem. yaourt -G pkgbrowser && cd pkgbrowser && makepkg -sirc

@majo. Looks like the "bug" is at your end. Everything works fine for me.

I see this bug: $ pkgbrowser Traceback (most recent call last): File "/usr/lib/pkgbrowser/main.py", line 9, in <module> sys.exit(app.run()) File "/usr/lib/pkgbrowser/pkgbrowser/app.py", line 114, in run app.window().setup() File "/usr/lib/pkgbrowser/pkgbrowser/app.py", line 58, in window from pkgbrowser.window import Window File "/usr/lib/pkgbrowser/pkgbrowser/window.py", line 16, in <module> from pkgbrowser.backend import ( File "/usr/lib/pkgbrowser/pkgbrowser/backend.py", line 13, in <module> from pkgbrowser import alpm, conf, utils ImportError: /usr/lib/pkgbrowser/pkgbrowser/alpm.cpython-34m.so: undefined symbol: AnnotateIgnoreReadsEnd

@rcrath. what update are you talking about? everything still works perfectly fine for me...

update breaks, need to download & extract tarball and run makepkg -i in the pkgbrowser folder and then it works fine

I got this after the update of python: ImportError: /usr/lib/pkgbrowser/pkgbrowser/alpm.cpython-34m.so: undefined symbol: AnnotateIgnoreReadsEnd Solution: rebuild pkgbrowser

@Thah Please make a proper bug report (either on the upstream issue tracker, or on the arch forum thread). It would also be a good idea to delete your comment here, as most of it is not relevant to the AUR.

Build fails on systems with non-Bash /bin/sh Background: In the aftermath of the Shellshock vulnerability it was pointed out that Bash is not the most reasonable choice for a system shell. I changed it to point to /usr/bin/dash. Build failure: Running makepkg ends with > removed directory: ‘build/src’ > removed directory: ‘build’ > for f in designer/[^_]*.ui; do \ > /usr/bin/pyuic4 --from-imports -w -o "pkgbrowser/ui/$(basename $f .ui).py" > "$f"; > \ > done > Error: No such file or directory: "designer/[^_]*.ui" > Makefile:35: recipe for target 'pyqt' failed > make: *** [pyqt] Error 1 > ==> ERROR: A failure occurred in build(). > Aborting... > $ Explanation: make does not use the user's $SHELL environment variable as a shell (see (p)info make, 5.3.2 Choosing the Shell) on recipe lines but /bin/sh. Patching the Makefile with *** 20,25 **** --- 20,27 ---- distname := $(APPNAME)-$(VERSION) source := $(distdir)/$(distname) + export SHELL := /bin/bash + all: alpm pyqt scripts compile cython: and rebuilding with makepkg -e succeeds. Running checkbashisms -f on the Makefile reports among other things > possible bashism in Makefile line 37 ([^] should be [!]): > for f in designer/[^_]*.ui; do \ > $(PYUIC) --from-imports -w -o "$(APPNAME)/ui/$$(basename $$f .ui).py" > "$$f"; \ > done The above and comparing the man pages for bash/dash show that checkbashisms's output is correct. Fix: A quick fix is explicitly telling make to use Bash as above (or maybe /usr/bin/bash ? ). In this case there should be a build dependency on Bash although Bash would be installed on almost all systems anyway. A more elegant solution would be to avoid bashisms at all but I haven't checked the makefile for other bashisms. OTOH sticking to POSIX compliant recipe lines would avoid any problems with possible shell changes in the future. In any case, as /bin/sh is supposed to be POSIX compliant and nothing more it should not be used for cases, that use more that POSIX. In this case the use of /bin/sh is disguised quite well...