| Summary: | dev-vcs/bzr-svn seems to overwrite postinstall files of dev-vcs/bzr | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Guenther Brunthaler <gb_about_gnu> |
| Component: | New packages | Assignee: | bazaar+obsolete |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
This ebuild managed to emerge the inappropriate version of bzrtools
This is the ebuild I am using now |
||
I tried really hard to install a wrong version of bzrtools, whose ebuild already contains a correct dependency setting for bzr. Please provide more information how you achieved that situation.
# eix -e bzr
[I] dev-vcs/bzr
Available versions: 2.2.2-r1!t{tbz2} (~)2.4.0{tbz2} (~)2.4.1{tbz2} **9999 {bash-completion curl doc emacs kerberos +sftp test}
Installed versions: 2.4.1{tbz2}(15:48:06 17.09.2011)(bash-completion curl doc emacs sftp -test)
# emerge =bzrtools-2.2* -p
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild UD ] dev-vcs/bzr-2.2.2-r1 [2.4.1] USE="bash-completion curl doc emacs sftp -test" 0 kB
[ebuild UD ] dev-vcs/bzrtools-2.2.0 [2.4.0] 72 kB
Total: 2 packages (2 downgrades), Size of downloads: 72 kB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-vcs/bzr:0
(dev-vcs/bzr-2.2.2-r1::gentoo, ebuild scheduled for merge) pulled in by
=dev-vcs/bzr-2.2* required by (dev-vcs/bzrtools-2.2.0::gentoo, ebuild scheduled for merge)
(dev-vcs/bzr-2.4.1::gentoo, installed) pulled in by
>=dev-vcs/bzr-2.4 required by (dev-vcs/qbzr-0.21.1::gentoo, installed)
# emerge =bzr-2.2* -p
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild UD ] dev-vcs/bzr-2.2.2-r1 [2.4.1] USE="bash-completion curl doc emacs sftp -test" 0 kB
Total: 1 package (1 downgrade), Size of downloads: 0 kB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-vcs/bzr:0
(dev-vcs/bzr-2.2.2-r1::gentoo, ebuild scheduled for merge) pulled in by
=bzr-2.2*
(dev-vcs/bzr-2.4.1::gentoo, installed) pulled in by
=dev-vcs/bzr-2.4* required by (dev-vcs/bzrtools-2.4.0::gentoo, installed)
>=dev-vcs/bzr-2.4 required by (dev-vcs/qbzr-0.21.1::gentoo, installed)
OK. First, here is my emerge --info: Portage 2.1.10.11 (default/linux/amd64/10.0, gcc-4.5.3, glibc-2.12.2-r0, 2.6.27.59-xquad-11.222 x86_64) ================================================================= System uname: Linux-2.6.27.59-xquad-11.222-x86_64-AMD_Phenom-tm-_9600_Quad-Core_Processor-with-gentoo-2.0.3 Timestamp of tree: Wed, 21 Sep 2011 10:15:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 2.4 [enabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.1-r1, 3.1.3-r1 dev-util/ccache: 2.4-r9 dev-util/cmake: 2.8.4-r1 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.8.3-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 4.5.3-r1 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 2.6.30-r1 (virtual/os-headers) sys-libs/glibc: 2.12.2 Repositories: gentoo sunrise x-mscgen x-simplux x-xworld x-xworld_attic x-xworld_experimental x-xworld_hotfixes x-xworld_serviced x-xworld_thirdparty gamerlay-stable proaudio x-kde4noconkit xfce-dev x-crossdev-m68k x-overlay x-local_sets_overlay ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=amdfam10 -O3 -DNDEBUG -pipe -fno-stack-check" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/fax /usr/local/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /var/lib/citadel /var/lib/hsqldb /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/host-variants/ /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=amdfam10 -O3 -DNDEBUG -pipe -fno-stack-check" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner --with-bdeps=y" FEATURES="assume-digests binpkg-logs ccache distlocks ebuild-locks fakeroot fixlafiles fixpackages metadata-transfer news notitles prelink-checksums protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="" GENTOO_MIRRORS="/usr/local/portage/distfiles/local /usr/local/portage/distfiles /usr/local/portage/distfiles/precious /usr/local/portage/distfiles/mnt http://tux.rainside.sk/gentoo/ http://cesium.di.uminho.pt/pub/gentoo/ http://ftp.twaren.net/Linux/Gentoo/ ftp://ftp.jaist.ac.jp/pub/Linux/Gentoo/ http://ftp.ncnu.edu.tw/Linux/Gentoo/ http://ftp.jaist.ac.jp/pub/Linux/Gentoo/ ftp://ftp.twaren.net/Linux/Gentoo/ http://ftp.lecl.net/pub/gentoo/ http://ftp.daum.net/gentoo/ ftp://tux.rainside.sk/gentoo/" LANG="de_AT.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de_AT@boldquot de_AT@quot de_AT de_DE@boldquot de_DE@quot de_DE de@boldquot de@quot de en_US@boldquot en_US@quot en_US en@boldquot en@quot en" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_COMPRESS="lzma" PORTAGE_COMPRESS_FLAGS="-9" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/sunrise /var/lib/layman/mscgen /var/lib/layman/simplux /var/lib/layman/xworld /var/lib/layman/xworld_attic /var/lib/layman/xworld_experimental /var/lib/layman/xworld_hotfixes /var/lib/layman/xworld_serviced /var/lib/layman/xworld_thirdparty /var/lib/layman/gamerlay /var/lib/layman/pro-audio /var/lib/layman/kde4noconkit /var/lib/layman/xfce-dev /var/lib/layman/crossdev-m68k /usr/local/portage/overlay /etc/portage/local_sets_overlay" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac aalib accessibility acpi agg alsa amd64 aspell audiofile bash-completion berkdb branding bzip2 cairo caps cddb cdr cleartype cli cracklib crypt css cups curl custom-cflags custom-cxxflags cxx dbus development device-mapper dri dts dv dvd dvdr dvdread ecc encode exif expat faac faad ffmpeg fftw firefox flac fontconfig fontforge foomaticdb freetype ftp fuse gd gdbm gif gimp glade glut gmp gpm gstreamer gtk gtk2 i18n iconv icu id3tag idea ieee1394 imagemagick imlib inotify iptc jack java6 javascript jbig jp2 jpeg jpeg2k kdehiddenvisibility kdexdeltas kerberos kpathsea ladspa lame lash lcms ldap libcaca libclamav libnotify libsamplerate lm_sensors logrotate lua lzma lzo mad matroska mikmod mmap mmx mmxext mng modules mp3 mp4 mpeg mudflap mule multilib musepack musicbrainz ncurses netlink nls nodrm nptl nptlonly oav odbc offensive ofx ogg openal opengl openmp pam pango pch pcre pda pdf pic png ppds pppd qt qt3support qt4 quicktime quotas readline samba sasl screen sdl session sharedmem slang smartcard smp sndfile sox speex spell sqlite sqlite3 sse sse2 sse3 sse4a ssl startup-notification svg swig sysfs taglib tetex theora threads threadsafe tiff truetype unicode usb userlocales utf8 vcd vde vorbis wavpack webkit wxwindows x264 xcb xft xinetd xml xorg xosd xpm xrandr xscreensaver xsl xulrunner xv xvid xvmc zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev joystick keyboard mouse void" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de_AT@boldquot de_AT@quot de_AT de_DE@boldquot de_DE@quot de_DE de@boldquot de@quot de en_US@boldquot en_US@quot en_US en@boldquot en@quot en" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="dummy ati v4l vesa vga" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS I have also checked by /etc/portage.* files - there is no unmasking or version restriction for any ebuild containing the substring "bzr" there.
However, I do have used customized USE flags for the primary package:
# equery uses dev-vcs/bzr
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for dev-vcs/bzr-2.2.2-r1:
U I
+ + bash-completion : Enable bash-completion support
+ + curl : Adds support for client-side URL transfer library
+ + doc : Adds extra documentation (API, Javadoc, etc)
- - emacs : Adds support for GNU Emacs
+ + sftp : Enable sftp support
- - test : Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles
this internally, so don't set it in make.conf/package.use anymore
On the other hand, I have been using those USE flags for a long time; there are no recent changes for this package.
Created attachment 287349 [details]
This ebuild managed to emerge the inappropriate version of bzrtools
Created attachment 287351 [details]
This is the ebuild I am using now
This ebuild omits the problematic packages.
And as you can see, bzr-svn also created a problem.
BTW, this may perhaps be of relevance: With bzr-svn installed, svn://
URLs did no longer work with Bazaar.
When I uninstalled bzr-svn, it still did not work!
However, re-emering bzr fixed the problem.
Maybe something might have been escaping the Sandbox's attention.
However, this has nothing to do with the bzr version number. But maybe
the problem is indirectly related and has some adverse effect on
dependency calculation.
Finally, the output of $ for E in $(eix --format '<installedversions:EQNAMEVERSION>' -I bzr | grep ^=); do equery depgraph --depth=1 "$E"; done follows so that you can see which versions I have installed: dev-vcs/bzr-2.2.2-r1: [ 0] dev-vcs/bzr-2.2.2-r1 [ 1] virtual/emacs-23 [ 1] dev-lang/python-2.7.1-r1 [ 1] dev-lang/python-2.6.6-r2 [ 1] dev-lang/python-2.5.4-r4 [ 1] dev-python/celementtree-1.0.5-r1 [ 1] dev-python/pycurl-7.19.0 [ 1] dev-python/paramiko-1.7.6 [ 1] dev-python/medusa-0.5.4 [ 1] dev-python/subunit-0.0.6 [ 1] dev-python/testtools-0.9.8 [ 1] app-admin/eselect-python-20100321 [ 1] app-shells/bash-completion-1.3 [ 1] app-admin/eselect-1.2.15 dev-vcs/bzr-git-0.5.2: [ 0] dev-vcs/bzr-git-0.5.2 [ 1] app-admin/eselect-python-20100321 [ 1] dev-lang/python-2.7.1-r1 [ 1] dev-python/dulwich-0.7.1 [ 1] dev-vcs/bzr-2.2.2-r1 dev-vcs/bzr-rewrite-0.6.1: [ 0] dev-vcs/bzr-rewrite-0.6.1 [ 1] dev-vcs/bzr-2.2.2-r1 [ 1] app-admin/eselect-python-20100321 [ 1] dev-lang/python-2.7.1-r1 dev-vcs/qbzr-0.19.3: [ 0] dev-vcs/qbzr-0.19.3 [ 1] dev-vcs/bzr-2.2.2-r1 [ 1] dev-python/PyQt4-4.8.4 [ 1] app-admin/eselect-python-20100321 [ 1] dev-lang/python-2.7.1-r1 xworld-evaluation/bzr-w-plugins-1.2: [ 0] xworld-evaluation/bzr-w-plugins-1.2 [ 1] dev-python/pyenchant-1.6.5 [ 1] dev-python/pygments-1.4 [ 1] dev-vcs/bzr-2.2.2-r1 [ 1] dev-vcs/bzr-git-0.5.2 [ 1] dev-vcs/bzr-rewrite-0.6.1 [ 1] dev-vcs/qbzr-0.19.3 On the other hand, I performed a portage update today; so maybe some version might have been updated. I will try to re-install the 1.1-version of the meta-ebuild in order to verify that it still does not work. It is getting "better and better" - I now have installed # emerge -av1 bzrtools These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild N ] dev-vcs/bzrtools-2.2.0 0 kB Total: 1 package (1 new), Size of downloads: 0 kB (i. e. the exact same version as yesterday) - but now it suddenly seems to work: # bzr branch-history Guenther Brunthaler <root@xtreme.xworld.mine.nu> / etc_mx5xhmzec875iwuuivvljmzuj 1 .. 6 Guenther Brunthaler <root@xquad.xworld.mine.nu> / etc 7 .. 151 Guenther Brunthaler <root@xquad.xworld.mine.nu> / etc_m1jn3gbipg2c3kkr8185vua1y 152 .. 252 Guenther Brunthaler <root@xquad.xworld.mine.nu> / xquad.xworld.mine.nu:etc:m1jn3gbipg2c3kkr8185vua1y 253 .. 283 No more complaints about version conflicts! And, BTW, still the same versions Portage did not allow you to emerge because of conflicts... ;-) Something must have happened in today's portage update! Hmmm - the only thing maybe connected to this issue which I could spot in the output of "genlop -lu" was the removal of =dev-python/subvertpy-0.8.0, obviously a left-over dependency from yesterday's uninstallation of bzr-svn. I don't get it - bzrtools still seems to work fine NOW, even after I also have emerged bzr-svn. However, bzr-svn still makes remote bzr-pulls fail. Seems I should rename the bug... A correction of my complaints about bzr-svn is in order: It is not correct that svn:// URLs fail when this plugin is installed as I thought. Rather, bzr+ssh:// URLs fail. ...and as I just detected, http:// URLs fail either: # bzr branch http://xw.ath.cx/rpo/bzr/adm/portage/overlays/xworld_bfl50a97e8jymsp237377imz7 bzr: ERROR: Unable to import library "subvertpy": bzr-svn: ('Unable to load subvertpy extensions: %s', 'No module named client') However, bzr+ssh:// URLs give a longer stack dump for the same actual repository: $ bzr branch bzr+ssh://xw.ath.cx:992/srv/www/xw.ath.cx/htdocs/rpo/bzr/adm/portage/overlays/xworld_bfl50a97e8jymsp237377imz7 bzr: ERROR: exceptions.ImportError: ('Unable to load subvertpy extensions: %s', 'No module named client') Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/bzrlib/commands.py", line 912, in exception_to_return_code return the_callable(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/bzrlib/commands.py", line 1112, in run_bzr ret = run(*run_argv) File "/usr/lib64/python2.7/site-packages/bzrlib/commands.py", line 690, in run_argv_aliases return self.run(**all_cmd_args) File "/usr/lib64/python2.7/site-packages/bzrlib/commands.py", line 705, in run return self._operation.run_simple(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/bzrlib/cleanup.py", line 135, in run_simple self.cleanups, self.func, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups result = func(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/bzrlib/builtins.py", line 1209, in run from_location) File "/usr/lib64/python2.7/site-packages/bzrlib/bzrdir.py", line 1032, in open_tree_or_branch bzrdir = klass.open(location) File "/usr/lib64/python2.7/site-packages/bzrlib/bzrdir.py", line 910, in open t = get_transport(base, possible_transports=possible_transports) File "/usr/lib64/python2.7/site-packages/bzrlib/lazy_import.py", line 125, in __call__ return obj(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/bzrlib/transport/__init__.py", line 1602, in get_transport transport, last_err = _try_transport_factories(base, factory_list) File "/usr/lib64/python2.7/site-packages/bzrlib/transport/__init__.py", line 1625, in _try_transport_factories return factory.get_obj()(base), None File "/usr/lib64/python2.7/site-packages/bzrlib/transport/remote.py", line 110, in __init__ medium, credentials = self._build_medium() File "/usr/lib64/python2.7/site-packages/bzrlib/transport/remote.py", line 516, in _build_medium user = auth.get_user('ssh', self._host, self._port) File "/usr/lib64/python2.7/site-packages/bzrlib/config.py", line 1176, in get_user path=path, realm=realm) File "/usr/lib64/python2.7/site-packages/bzrlib/config.py", line 1105, in get_credentials scheme, host, port, user, path, realm) File "/usr/lib64/python2.7/site-packages/bzrlib/config.py", line 1283, in get_fallback_credentials cs = self.get_credential_store(name) File "/usr/lib64/python2.7/site-packages/bzrlib/config.py", line 1264, in get_credential_store cs = self.get(encoding) File "/usr/lib64/python2.7/site-packages/bzrlib/registry.py", line 173, in get return self._dict[self._get_key_or_default(key)].get_obj() File "/usr/lib64/python2.7/site-packages/bzrlib/registry.py", line 61, in get_obj self._do_import() File "/usr/lib64/python2.7/site-packages/bzrlib/registry.py", line 70, in _do_import obj = __import__(self._module_name, globals(), locals(), names) File "/usr/lib64/python2.7/site-packages/bzrlib/plugins/svn/auth.py", line 20, in <module> import subvertpy File "/home/group/admdevel/plugin/bzr/subvertpy/subvertpy/__init__.py", line 113, in <module> raise ImportError("Unable to load subvertpy extensions: %s", e.message) ImportError: ('Unable to load subvertpy extensions: %s', 'No module named client') I forgot to report that I have installed several plug-ins for the local user also. Fortunately, completely removing all those plugins did not change anything. I also repeated my svn-bzr attempt from yesterday: First I installed dev-vcs/bzr-svn-1.0.4. dev-python/subvertpy-0.8.0 got installed as a dependency. After that, the beforementioned errors occurred. Next, I uninstalled bzr-svn (but left subvertpy installed). Still the same errors. Now I re-emerged bzr - subvertpy still installed - and now the errors are gone. Although I have no idea why bzrtools now work miracuously when they did not yesterday (although exactly the same versions), one thing is clear: bzr-svn is the primary package to blame. It must damage the files of bzr somehow, and do this in a way that the sandbox cannot spot it. I have verified this now. The problem must be in one of the postinstall-phases of bzr-svn. I did an "equery check svn" before and after emerging bzr-svn - all files were reported "good" before and after that. However, http:// and bzr+ssh:// URLs did no longer work after emerging bzr-svn. Obviously, bzr-svn damages or overwrites some files created in the postinstall-phase of bzr. I have changed the bug title as only the svn-bzr problem seems to be left. Correction: (In reply to comment #11) > I did an "equery check svn" before and after emerging bzr-svn - all files were I meant "equery check bzr", of course. As another test, I have emerged svn-bzr and then immediately re-emerged bzr, i. e. without uninstalling bzr-svn first. This did not help; the errors remained. I really had to uninstall bzr-svn and then reinstall bzr. Only then it worked again. Interesting. I have expected both packages to overwrite the same file. Obviously, only bzr-svn does the overwriting. As subvertpy is also included within the stack trace, I ran "equery check" for that package also - all files good, and bzr still working. bzr-svn modifies something for bzr which results in an error message from subverty. Thank you for your valuable input. Could you please try with Bazaar 2.4.1 and bzr-svn 1.1.0? (In reply to comment #16) > Thank you for your valuable input. Could you please try with Bazaar 2.4.1 and > bzr-svn 1.1.0? I did it: # eix '-I*' --format '<installedversions:NAMEVERSION>' bzr -o subv -o svn dev-python/subvertpy-0.8.0 dev-vcs/bzr-2.4.1 dev-vcs/bzr-git-0.5.2 dev-vcs/bzr-rewrite-0.6.1 dev-vcs/bzr-svn-1.1.0 dev-vcs/bzrtools-2.2.0 dev-vcs/cvs2svn-2.2.0 dev-vcs/qbzr-0.19.3 dev-vcs/subversion-1.6.17 net-misc/ssvnc-1.0.27 xworld-evaluation/bzr-w-plugins-1.3 but it seems now the *other* tools have problems: # bzr plugins bash_completion 2.4.1 Generate a shell function for bash command line completion. bzrtools 2.2.0 Various useful commands for working with bzr. changelog_merge 2.4.1 Merge hook for GNU-format ChangeLog files git (failed to load) ** Unable to load plugin 'git'. It requested API version (2, 2, 0) of module <module 'bzrlib' from '/usr/lib64/python2.7/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 4, 0), and the maximum is (2, 4, 1) launchpad 2.4.1 Launchpad.net integration plugin for Bazaar. netrc_credential_store 2.4.1 Use ~/.netrc as a credential store for authentication.conf. news_merge 2.4.1 Merge hook for bzr's NEWS file. qbzr (failed to load) ** Unable to load plugin 'qbzr'. It requested API version (2, 2, 0) of module <module 'bzrlib' from '/usr/lib64/python2.7/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 4, 0), and the maximum is (2, 4, 1) rewrite (failed to load) ** Unable to load plugin 'rewrite'. It requested API version (2, 2, 0) of module <module 'bzrlib' from '/usr/lib64/python2.7/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 4, 0), and the maximum is (2, 4, 1) svn 1.1.0 Support for Subversion branches weave_fmt 2.4.1 Weave formats. And bzrtools gives the same sort of message again, for which I originally reported this bug (and which is not an issue any longer with the stable versions): # bzr branch-history Plugin "Bzrtools" is not up to date with installed Bazaar version 2.4.1. There should be a newer version of Bzrtools available, e.g. 2.4. However, after uninstalling the new versions an reverting to the old ones (I need a working bzr for my daily work) I noticed something interesting: Even after unmerging the new bzr-svn, the following message is still being displayed: # bzr plugins Unable to load plugin 'svn'. It requested API version (2, 4, 0) of module <module 'bzrlib' from '/usr/lib64/python2.7/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 2, 0), and the maximum is (2, 2, 2) bash_completion 2.2.2 Generate a shell function for bash command line completion. bzrtools 2.2.0 Various useful commands for working with bzr. git 0.5.2 A GIT branch and repository format implementation for bzr. launchpad 2.2.2 Launchpad.net integration plugin for Bazaar. netrc_credential_store 2.2.2 Use ~/.netrc as a credential store for authentication.conf. news_merge 2.2.2 Merge hook for bzr's NEWS file. qbzr 0.19.3 QBzr - Qt-based frontend for Bazaar rewrite 0.6.1 Rebase support. That is, bzr complains about a module which is no longer installed at all! And neither there are any per-user plugins installed: # find ~/.bazaar/plugins/ | tee /dev/stderr | wc -l /home/user/root/.bazaar/plugins/ 1 And as before, re-emerging bzr after umerging bzr-svn eliminated the warning message. Do you use dev-vcs/qbzr and dev-vcs/bzr-git or are they manual checkouts in your plugin directory? (In reply to comment #20) > Do you use dev-vcs/qbzr and dev-vcs/bzr-git or are they manual checkouts in > your plugin directory? The are from the official tree. BTW, if you need out-of-band feedback for further investigations, you can also reach me via IM at guenther_brunthaler@jabber.rueckgr.at OK, my answer might look a bit confusing. I meant they are ebuilds, not manual checkouts. Global plugins, that is. Guenther, may be I ask something really evident, but have you run python-updater? I think it's good idea to drop old versions if you don't need it (emerge -uDN world && python-updater and emerge --depclean should do the trick). After you do above, please, summarize your findings a bit. 22 comments is really great source of information but I'd like to have some terse starting point to work with. (In reply to comment #23) > Guenther, may be I ask something really evident, but have you run > python-updater? Well, I certainly have tun it each time the Elog entries told me so. Which was essentially at every major Python update. However, I don't run it on a regular basis because I have been assuming that it is only intended to be run after updates of Python itself. > I think it's good idea to drop old versions if you don't need > it (emerge -uDN world && python-updater and emerge --depclean should do the > trick). I always run the following commands in sequence when I do a Portage update: $ emerge --sync $ layman -S $ emerge -avuDN1 world $ emerge -a --depclean $ revdep-rebuild $ prelink In the past, I also used to run "lafilefixer --justfixit", but as there is a Portage FEATURE for that now I assumed it is no longer necessary to run it manually. Then I process all Elog-Entries created during the updates and follow the instructions there, if any. Should I add "python-updater" also to the above list of commands to be processed manually? And, btw, perl-cleaner also? Anything else I might be missing and should do in order to avoid future problems? > After you do above, please, summarize your findings a bit. 22 comments > is really great source of information but I'd like to have some terse starting > point to work with. I'm running python-updater right now in addition to the above commands which I do regularly and which include your suggested commands. As soon as it is finished, I will report about the success regarding the behaviour bzr-svn. python-updater should be run each time new major python version is installed. But there are old python versions (2.5, 2.6) installed on you system and this makes me wonder - either python-updated have not finished or emerge --depclean. In other case they should be removed... Or... do you have that old versions in your world file (/var/lib/portage/world). If yes, remove them with emerge --depclean python:2.5 python:2.6. (In reply to comment #25) > python-updater should be run each time new major python version is installed. OK, that's what I did then. > But there are old python versions (2.5, 2.6) installed on you system Nope, no such versions: I only have =dev-lang/python-2.7.1-r1 and =dev-lang/python-3.1.3-r1 installed. Nothing other versions of python. I *do* run "emerge --depclean" regularly and take care what gets into my "world" list. > and this makes me wonder - either python-updated have not finished I only could think of the second one. To be sure, I have now run python-updater *twice* - because it re-emerged several packages when I ran it, and I wanted to see whether those packages are *always* re-emerged or whether this was a one-time repair task. Python updater re-emerged the following packages - both times: sys-apps/file-5.07-r3 sys-libs/cracklib-2.8.16 sys-libs/libcap-ng-0.6.5 app-pda/pilot-link-0.12.5 dev-libs/libxslt-1.1.26-r1 dev-vcs/subversion-1.6.17 app-accessibility/speech-dispatcher-0.7.1-r1 app-mobilephone/obexftp-0.23-r1 The only interesting package of those seems to be subversion itself. > In other case they should be removed... Or... do you have that old versions in > your world file (/var/lib/portage/world). If yes, remove them with emerge > --depclean python:2.5 python:2.6. Not necessary; both slots are not installed. It seems the output of "emerge --depgraph" lists all possible dependencies, and not just the ones which actually apply. Correction: I meant "equery depgraph". Test after running python-updater twice and then emerging the current stable version bzr-2.2.2-r1 with bzr-svn-1.0.4 and subvertpy-0.8.0:
=============
# layman -s xworld
* Running... # ( cd /var/lib/layman/xworld && /usr/bin/bzr pull --overwrite bzr+ssh://xw.ath.cx:992/srv/www/xw.ath.cx/htdocs/rpo/bzr/adm/portage/overlays/xworld_bfl50a97e8jymsp237377imz7 )
bzr: ERROR: exceptions.ImportError: ('Unable to load subvertpy extensions: %s', 'No module named client')
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/bzrlib/commands.py", line 912, in exception_to_return_code
return the_callable(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/bzrlib/commands.py", line 1112, in run_bzr
ret = run(*run_argv)
File "/usr/lib64/python2.7/site-packages/bzrlib/commands.py", line 690, in run_argv_aliases
return self.run(**all_cmd_args)
File "/usr/lib64/python2.7/site-packages/bzrlib/commands.py", line 705, in run
return self._operation.run_simple(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/bzrlib/cleanup.py", line 135, in run_simple
self.cleanups, self.func, *args, **kwargs)
File "/usr/lib64/python2.7/site-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
result = func(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/bzrlib/builtins.py", line 997, in run
possible_transports=possible_transports)
File "/usr/lib64/python2.7/site-packages/bzrlib/bundle/__init__.py", line 48, in read_mergeable_from_url
possible_transports=possible_transports)
File "/usr/lib64/python2.7/site-packages/bzrlib/lazy_import.py", line 125, in __call__
return obj(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/bzrlib/transport/__init__.py", line 1602, in get_transport
transport, last_err = _try_transport_factories(base, factory_list)
File "/usr/lib64/python2.7/site-packages/bzrlib/transport/__init__.py", line 1625, in _try_transport_factories
return factory.get_obj()(base), None
File "/usr/lib64/python2.7/site-packages/bzrlib/transport/remote.py", line 110, in __init__
medium, credentials = self._build_medium()
File "/usr/lib64/python2.7/site-packages/bzrlib/transport/remote.py", line 516, in _build_medium
user = auth.get_user('ssh', self._host, self._port)
File "/usr/lib64/python2.7/site-packages/bzrlib/config.py", line 1176, in get_user
path=path, realm=realm)
File "/usr/lib64/python2.7/site-packages/bzrlib/config.py", line 1105, in get_credentials
scheme, host, port, user, path, realm)
File "/usr/lib64/python2.7/site-packages/bzrlib/config.py", line 1283, in get_fallback_credentials
cs = self.get_credential_store(name)
File "/usr/lib64/python2.7/site-packages/bzrlib/config.py", line 1264, in get_credential_store
cs = self.get(encoding)
File "/usr/lib64/python2.7/site-packages/bzrlib/registry.py", line 173, in get
return self._dict[self._get_key_or_default(key)].get_obj()
File "/usr/lib64/python2.7/site-packages/bzrlib/registry.py", line 61, in get_obj
self._do_import()
File "/usr/lib64/python2.7/site-packages/bzrlib/registry.py", line 70, in _do_import
obj = __import__(self._module_name, globals(), locals(), names)
File "/usr/lib64/python2.7/site-packages/bzrlib/plugins/svn/auth.py", line 20, in <module>
import subvertpy
File "/home/group/admdevel/plugin/bzr/subvertpy/subvertpy/__init__.py", line 113, in <module>
raise ImportError("Unable to load subvertpy extensions: %s", e.message)
ImportError: ('Unable to load subvertpy extensions: %s', 'No module named client')
bzr 2.2.2 on python 2.7.1 (Linux-2.6.27.59-xquad-11.222-x86_64-AMD_Phenom-tm-_9600_Quad-Core_Processor-with-gentoo-2.0.3)
arguments: ['/usr/bin/bzr', 'pull', '--overwrite', 'bzr+ssh://xw.ath.cx:992/srv/www/xw.ath.cx/htdocs/rpo/bzr/adm/portage/overlays/xworld_bfl50a97e8jymsp237377imz7']
encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'de_AT.utf8'
plugins:
bash_completion /usr/lib64/python2.7/site-packages/bzrlib/plugins/bash_completion [2.2.2]
bzrtools /usr/lib64/python2.7/site-packages/bzrlib/plugins/bzrtools [2.2.0]
git /usr/lib64/python2.7/site-packages/bzrlib/plugins/git [0.5.2]
launchpad /usr/lib64/python2.7/site-packages/bzrlib/plugins/launchpad [2.2.2]
netrc_credential_store /usr/lib64/python2.7/site-packages/bzrlib/plugins/netrc_credential_store [2.2.2]
news_merge /usr/lib64/python2.7/site-packages/bzrlib/plugins/news_merge [2.2.2]
qbzr /usr/lib64/python2.7/site-packages/bzrlib/plugins/qbzr [0.19.3]
rewrite /usr/lib64/python2.7/site-packages/bzrlib/plugins/rewrite [0.6.1]
svn /usr/lib64/python2.7/site-packages/bzrlib/plugins/svn [1.0.4]
*** Bazaar has encountered an internal error. This probably indicates a
bug in Bazaar. You can help us fix it by filing a bug report at
https://bugs.launchpad.net/bzr/+filebug
including this traceback and a description of the problem.
*
* Errors:
* ------
*
* Failed to sync overlay "xworld".
* Error was: Syncing overlay "xworld" returned status 4!
*
=============
As you can see, there is python-2.7 everywhere - but the basic problem seems to be the same as before.
As the next test, I re-emerged the unstable version dev-vcs/bzr-2.4.1 - and now it works! :-) I did not reinstall bzr-svn or subvertpy. (In reply to comment #29) > I did not reinstall bzr-svn or subvertpy. Please, try (better all bzr packages) to see if you'll be able to reproduce problem. Test # 2 also successful: After reinstalling bzr-svn the previously installed bzr-2.4.1 *still* works! I have no idea why the same did not work before when I tried exactly the same sequence of tests the last time. I can only assume that running python-updater (which led to re-installation of subversion itself) did something good after all (which is still strange because I did not have USE=python enabled for that package anyway). Nevertheless, it seems that this bug does no longer occur for >=bzr-2.4.1, while it still applies (and is reproducable at least on my box) for the current stable version of bzr-2.2. I guess the easiest method to "fix" that bug would therefore be to wait for stabilization of =bzr-2.4.1... (In reply to comment #30) > Please, try (better all bzr packages) to see if you'll be able to reproduce > problem. What I have found to be reproducable is the following: * The problem only occurs with the current stable version of bzr. bzr-2.4.1 does no longer trigger the problem. * In order to get rid of the problem for bzr-2.2, it is necessary to uninstall bzr-svn (subvertpy can be left installed; it does not matter) and then re-install bzr. Uninstalling bzr-svn does *not* get rid of the problem. * When downgrading from bzr-2.4.1 (with the working bzr-svn installed) to bzw-2.2 the problem occurs again and the already-installed bzr-svn does no longer work. * When downgrading bzr from 2.4.1 to 2.2.2 the bug occurs no matter whether bzr-svn has already been installed before or if it is installed afterwards. * When installing bzr-2.4.1 and bzr-svn, then downgrading to bzr-2.2 so that the bug occurs, and then upgrading to bzr-2.4.1 again (without re-emerging bzr-svn), the bug is gone again and bzr-svn works again. Thank you for your feedback. Since our bugzilla mostly reflects problems in ~arch I'm closing this bug. Stabilization is currently happening in bug 383751. So very soon this problem will be fixed in stable tree too. Unfortunately it seems I was too quick to report svn-bzr had no troubles with bzr-2.4.1: In fact, svn-bzr does no longer load due to version conflicts, and without that plugin being active bzr seems to work fine. I nevertheless suggest that we let this bug rest until 2.4.1 is stabilized, and I will reopen it then as required. It is too tiresome to uninstall/reinstall/up-/downgrade bzr and its plugins all the time for testing; I need a working bzr configuration for my daily work. Until then I will just unmerge bzr-svn - it would have been nice-to-have, but I can live without it. Anyway, thanks for your support in trying to track down this mean bug. Let's see how things look once 2.4.1 is stabilized. At least then there will no further need for those constant up/downgrades which make the testing process so tiresome. |
dev-vcs/bzrtools allows to be installed together with a bzr version which is too old for bzrtools to work. Reproducible: Always Steps to Reproduce: 1. $ emerge --search '%^(bzrtools|bzr)$' * dev-vcs/bzr Latest version available: 2.2.2-r1 Latest version installed: 2.2.2-r1 Size of files: 6,735 kB Homepage: http://bazaar-vcs.org/ Description: Bazaar is a next generation distributed version control system. License: GPL-2 * dev-vcs/bzrtools Latest version available: 2.2.0 Latest version installed: 2.2.0 Size of files: 71 kB Homepage: http://bazaar-vcs.org/BzrTools Description: bzrtools is a useful collection of utilities for bzr. License: GPL-2 2. $ bzr branch-history Installed Bazaar version 2.2.2 is too old to be used with plugin "Bzrtools" 2.3.0. Actual Results: The above error message. Expected Results: No such error message should appear, because the package dependencies of dev-vcs/bzrtools should enforce an appropriate version of dev-vcs/bzr. In order to fix this, appropriate >=dev-vcs/bzr restrictions should be added to RDEPEND.