Bug#1029182: Uploaded to DELAYED/3
I just fixed package (git diff in attachment) and uploaded pgcli 3.5.0-4.1 to DELAYED/3. Feel free to provide your own fix, or just we can just wait for a bit :-). Best regards. -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C diff --git a/debian/changelog b/debian/changelog index e23fada..0c93a07 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +pgcli (3.5.0-4.1) sid; urgency=medium + + * Non-maintainer upload. + * Fix psycopg depends (Closes: #1029182). + + -- Tomasz Rybak Sat, 21 Jan 2023 01:24:45 +0100 + pgcli (3.5.0-4) sid; urgency=medium * Uploading to sid. diff --git a/debian/control b/debian/control index c414842..9cc1f84 100644 --- a/debian/control +++ b/debian/control @@ -25,7 +25,7 @@ Depends: python3-pgspecial (>= 2), python3-pkg-resources, python3-prompt-toolkit (>= 3.0), - python3-psycopg | python3-psycopg3 (>= 3.0.14), + python3-psycopg, python3-sqlparse (>= 0.3), python3-tabulate, python3-terminaltables, signature.asc Description: This is a digitally signed message part
Bug#1029182: Just rebuild with psycopg 3.1.7-4
I noticed this bug, and similar for python-pgspecial. You can fix it by rebuilding with python3-psycopg 3.1.7-4, like I've just done with python-pgspecial. Long story short - dh_python3 has hardcoded mapping of psycopg to python3-psycopg3, and this is added to binary dependencies via python3:Depends; you can find details in https://lists.debian.org/debian-python/2023/01/msg00051.html I added pydist override to psycopg 3.1.7-4. I also experimented a bit with rebuilding pgcli; you could replace line 28 of debian/control python3-psycopg | python3-psycopg3 (>= 3.0.14) with python3-psycopg, (see attached diff file) and it'll generate proper dependency on python3-psycopg (>= 3.0.14). Full dependency after this change looks like: Depends: python3-cli-helpers, python3-pendulum, python3-pgspecial (>= 2), python3-pkg-resources, python3-prompt-toolkit (>= 3.0), python3- psycopg (>= 3.0.14), python3-sqlparse (>= 0.3), python3-tabulate, python3-terminaltables, python3-click, python3-configobj, python3- pygments, python3-setproctitle, python3:any Best regards. -- Tomasz Rybak, Debian Developer GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C diff --git a/debian/control b/debian/control index c414842..9cc1f84 100644 --- a/debian/control +++ b/debian/control @@ -25,7 +25,7 @@ Depends: python3-pgspecial (>= 2), python3-pkg-resources, python3-prompt-toolkit (>= 3.0), - python3-psycopg | python3-psycopg3 (>= 3.0.14), + python3-psycopg, python3-sqlparse (>= 0.3), python3-tabulate, python3-terminaltables, signature.asc Description: This is a digitally signed message part
Bug#755513: nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1
Why did nvidia-cuda-toolkit tried to install nvidia-opencl-dev when you had ocl-icd-libopencl1 installed? $ apt-cache show nvidia-cuda-toolkit Package: nvidia-cuda-toolkit Version: 5.5.22-4 Installed-Size: 44180 Maintainer: Debian NVIDIA Maintainers Architecture: amd64 Depends: nvidia-profiler (= 5.5.22-4), nvidia-cuda-dev (= 5.5.22-4), nvidia-opencl-dev (= 5.5.22-4) | opencl-dev, gcc, g++, libc6 (>= 2.3.4), libgcc1 (>= 1:4.1.1), libnvvm2 (>= 5.5), libstdc++6 (>= 4.1.1) ocl-icd-opencl-dev depends on ocl-icd-libopencl1, and ocl-icd-libopencl1 conflicts with libopencl1, preventing other packages with libOpenCL.so from being installed. Can you provide what you were doing? I have situation similar to described by you (ocl-icd-opencl-dev and ocl-icd-libopencl1 and nvidia-cuda-toolkit) and did not have any troubles - I even prepare and test PyCUDA and PyOpenCL packages on such a setup. Best regards. Tomasz Rybak -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730263: pycuda: needs to be rebuilt against nvidia-cuda-toolkit 5.5
I have tested PyCUDA with CUDA 5.5 and it worked without problems. I'll look into whether to add some newer stuff from upstream git repository or not during upload, as there were some fixes in upstream. The new version should be in unstable before the next weekend. Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#711926: pyopencl: FTBFS during binNMU
I assume binNMU was part of the Python3.3 transition, unrelated to Boost 1.53 transition? Does it mean that I do not need to add python3.3 to Build-dependencies? I've added it to all my packages (pytools - #707310, pycuda, pyopencl) but have not yet uploaded anything. Dnia 2013-06-11, wto o godzinie 00:11 -0400, Scott Kitterman pisze: > Package: pyopencl > Version: 2012.1-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) [ cut ] >dh_sphinxdoc -a > dh_sphinxdoc: Sphinx documentation not found > make: *** [binary-arch] Error 2 > dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit > status 2 PyOpenCL needs binary module (pyopencl) to be present when building Sphinx documentation because it imports some OpenCL constants into documentation. I've added "make -C docs" (with PYTHONPATH pointing to newly-build module) to override_dh_auto_build to deal with it. As it seems to be a problem now, is there a better way to do it? -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#674000: python-pyopencl-headers: fails to upgrade from 'testing' - trying to overwrite /usr/include/pyopencl/pyopencl-ranluxcl.cl
Dnia 2012-05-29, wto o godzinie 11:33 +0200, Andreas Beckmann pisze:
> On 2012-05-27 21:06, Tomasz Rybak wrote:
> > Should I put
> > Breaks/Replaces: python-pyopencl (<< 2011.2.2+git20120508-1)
> > or
> > Breaks/Replaces: python-pyopencl (<< ${source:Version})?
> > Policy 7.6 uses hard-coded version, but many packages put
> > ${source:Version} into debian/control. What is advised?
>
> A hardcoded version would be advised because there was a change once in
> the past, but any version afterwards is not affected by this.
>
> source:Version is used for other purposes (usually for Relationships
> with arch:all packages that don't have a matching binary:Version (at
> least after an NMU).
Thanks for the explanation.
I have decided to put:
Replaces: python-pyopencl (<< 2011.2+git20120508-1)
Breaks: python-pyopencl (<< ${source:Version}),
python-pyopencl (>> ${source:Version}),
python3-pyopencl (<< ${source:Version}),
python3-pyopencl (>> ${source:Version})
for python-pyopencl-headers and
Depends: python-pyopencl-headers (= ${source:Version})
for both python-pyopencl and python3-pyopencl
*-headers Replaces hard-coded version (because *-headers was introduced
in that version) and Breaks Python modules in all versions not equal
to itself because those modules include headers during compilation,
which might mean that compiler needs headers from its version.
Regards
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
Bug#674000: python-pyopencl-headers: fails to upgrade from 'testing' - trying to overwrite /usr/include/pyopencl/pyopencl-ranluxcl.cl
Dnia 2012-05-22, wto o godzinie 14:10 +0200, Andreas Beckmann pisze:
> Package: python-pyopencl-headers
> Version: 2011.2+git20120508-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'unstable' fails
> because it tries to overwrite files that are owned by other packages
> without declaring a Breaks/Replaces relation.
>
> See policy 7.6 at
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
>
> >From the attached log (scroll to the bottom...):
>
> Selecting previously unselected package python-pyopencl-headers.
> Unpacking python-pyopencl-headers (from
> .../python-pyopencl-headers_2011.2+git20120508-1_all.deb) ...
> dpkg: error processing
> /var/cache/apt/archives/python-pyopencl-headers_2011.2+git20120508-1_all.deb
> (--unpack):
>trying to overwrite '/usr/include/pyopencl/pyopencl-ranluxcl.cl', which is
> also in package python-pyopencl 2011.2-1
>
>
Should I put
Breaks/Replaces: python-pyopencl (<< 2011.2.2+git20120508-1)
or
Breaks/Replaces: python-pyopencl (<< ${source:Version})?
Policy 7.6 uses hard-coded version, but many packages put
${source:Version} into debian/control. What is advised?
Regards.
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
Bug#599874: intent to NMU
Thanks, but I have all fixes ready. Here is repository with new version of packaging files: http://git.debian.org/?p=collab-maint/python-pyopencl.git Now release maintainers are thinking whether to allow for upload of new version (full 0,92 instead of 0.92 beta which is in Squeeze) or only to accept fixes: http://lists.debian.org/debian-release/2010/10/msg00669.html Should I tag somehow bugs related to pyopencl to let everybody know that I have fixes waiting for decision? Should it be patch or pending, knowing that release managers have not taken decision yet? -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#599782: pyopencl: FTBFS: ImportError: No module named pyopencl
Dnia 2010-10-12, wto o godzinie 15:38 +0200, Evgeni Golov pisze: > Jakub Wilk wrote: > > > * Tomasz Rybak , 2010-10-12, 12:06: > >>I have changed this to PYTHONPATH=../build/lib.*-*-$(firstword > >>$(PYVERS)) > >>and it works on my machine. > > > > This would set PYTHONPATH to "PYTHONPATH=../build/lib.*-*-2.6/" > > (literally). Doesn't look good. > > > > You probably want something like: > > > > PYTHONPATH=../$(wildcard build/lib.*-*-$(firstword $(PYVERS)))/ > > > > or > > > > PYTHONPATH=../$$(ls -d build/lib.*-*-$(firstword $(PYVERS)))/ > > wildcard seems not to work, no idea why (it does when I call make -f > debian/rules build, but not when invoked via dpkg-buildpackage). > > the ls version works fine for me on amd64 with i386 chroot (failed before). > > @Thomasz: If you need a sponsor, I'm willing to help (either the > existing or the 0.92 version if you get the OK from RT) :) > > Sorry for mess - I keep forgetting that debian/rules is Makefile, not ordinary shell script. Thanks for suggestions, and testing changes. I played a little bit with $(wildcard) but was not able to make it working; each time I got PYTHONPATH=..//. I have changed debian/rules to $$(ls ...), tested in after purging old version of pyopencl, tested using pbuilder on i386 and amd64, and it builds every time. New version is, as previously, at http://www.bogomips.w.tkb.pl/cuda/pyopencl_0.92-1.dsc Now we need to wait for release team decision. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#599782: #599782 - pyopencl: FTBFS: ImportError: No module named pyopencl
Dnia 2010-10-12, wto o godzinie 01:00 +0200, Jakub Wilk pisze: > * Evgeni Golov , 2010-10-11, 18:54: > >this one is "funny". setuptools uses python's os.uname() to check which > >arch it is running on, and where the temp-build-path is. This fails > >nicely on machines with 64bit-kernel and 32bit-userland (at least amd64, > >as it has x86_86 in uname, as the kernel is for x86_64). > > > >In this particular bug, it's not 64 vs 32 bit, but i686 vs i486, quoting > >the build-log: > >> g++ -pthread -shared -Wl,-Bsymbolic-functions -g -O2 > >build/temp.linux-i686-2.6/src/wrapper/wrap_cl.o > >build/temp.linux-i686-2.6/src/wrapper/wrap_cl_part_1.o > >build/temp.linux-i686-2.6/src/wrapper/wrap_cl_part_2.o > >build/temp.linux-i686-2.6/src/wrapper/wrap_constants.o > >-lboost_python-py26 -lOpenCL -o build/lib.linux-i686-2.6/pyopencl/_cl.so > >> PYTHONPATH=../build/lib.linux-i486-2.6/ /usr/bin/make -C doc html > > > >the stuff is built in build/lib.linux-i686-2.6/, but PYTHONPATH is set > >to build/lib.linux-i486-2.6/. This is done in debian/rules: > >PYTHONPATH=../build/lib.$(DEB_BUILD_ARCH_OS)-$(DEB_BUILD_GNU_CPU)-$(firstword > >$(PYVERS)) > > There's another problem here: DEB_BUILD_* variables are used, but they > are not defined anywhere. The code in question works only thanks to > dpkg-buildpackage exporting these variables. It will fail (on any > architecture) if debian/rules is run by hand. > > >$(DEB_BUILD_GNU_CPU) is wrong here, as is expands correctly to i486 > >(even on amd64 kernel with a i386 chroot). > >I fear we have to "parse" `uname -m` here, to fix that issue and match > >setuptools' algorithm. > > The idiomatic approach to this problem is to use wildcards. > I used PYTHONPATH=../build/lib.$(DEB_BUILD_ARCH_OS)-$(DEB_BUILD_GNU_CPU)-$(firstword$(PYVERS)) because I build library for all python versions (here 2.5 and 2.6) Using wildcard would mean that I do not have control over which library will be given to python - risking that python2.6 will get library 2.5. I have changed this to PYTHONPATH=../build/lib.*-*-$(firstword $(PYVERS)) and it works on my machine. Please test whether it work on i386. Version with fixes for all opened bugs: #599785, #599873, #599874, #599875 is on: http://www.bogomips.w.tkb.pl/cuda/pyopencl_0.92-1.dsc I am waiting for decision of release team whether to put new upstream version (with packaging fixes) or fix existing one. After decision is made I will ask for sponsorship. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Bug#595677: Uninstallable because of conflict with llvm-2.7-dev: /usr/share/vm/vimcurrent
Package: vim-common Version: 2:7.2.445+hg~cb94c42c0e1a-1 Severity: grave Tags: sid During upgrade: # LANG=C apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: vim-common 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/160kB of archives. After this operation, 0B of additional disk space will be used. Do you want to continue [Y/n]? (Reading database ... 521378 files and directories currently installed.) Preparing to replace vim-common 2:7.2.445+hg~cb94c42c0e1a-1 (using .../vim-common_2%3a7.3.000+hg~ee53a39d5896-1_amd64.deb) ... Unpacking replacement vim-common ... dpkg: error processing /var/cache/apt/archives/vim-common_2%3a7.3.000+hg~ee53a39d5896-1_amd64.deb (--unpack): trying to overwrite '/usr/share/vim/vimcurrent', which is also in package llvm-2.7-dev 2.7-5 configured to not write apport reports Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/vim-common_2%3a7.3.000+hg~ee53a39d5896-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) # Thanks. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vim-common depends on: ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib Versions of packages vim-common recommends: pn vim | vim-gnome | vim-gtk | v (no description available) vim-common suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595598: Fails to start - cannot find dconf-service
Package: gnome-shell Version: 2.31.5-2 Severity: grave Tags: experimental When trying to start gnome-shell: $ gnome-shell Starting dconf-service... Failed to start /usr/lib/d-conf/dconf-service: [Errno 2] No such file or directory $ I keep all required packages up-to-date (including glib from experimental) but cannot run gnome-shell. It does not start even when variable WINDOW_MANAGER=gnome-shell is set. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii gconf2 2.31.5-1 GNOME configuration database syste ii gir1.0-clutter-1.0 1.2.12-3 GObject introspection data for the ii gir1.0-freedesktop 0.6.14-1+b1 Introspection data for some FreeDe ii gir1.0-gconf-2.02.31.5-1 GNOME configuration database syste ii gir1.0-glib-2.0 0.6.15~git20100713-1 Introspection data for GLib, GObje ii gir1.0-gtk-2.0 0.6.5-6+b1 GObject introspection data for the ii gir1.0-json-glib-1. 0.10.2-2 GLib JSON manipulation library (do ii gir1.0-mutter-2.31 2.31.5-1 GObject introspection data for Mut ii gjs 0.7.1-1 Mozilla-based javascript bindings ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-5 The Cairo 2D vector graphics libra ii libclutter-1.0-01.2.12-3 Open GL based interactive canvas l ii libcroco3 0.6.2-1 a generic Cascading Style Sheet (C ii libdbus-1-3 1.2.24-3 simple interprocess messaging syst ii libdbus-glib-1-20.88-2 simple interprocess messaging syst ii libffi5 3.0.9-2 Foreign Function Interface library ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.2-2 FreeType 2 font engine, shared lib ii libgconf2-4 2.31.5-1 GNOME configuration database syste ii libgirepository1.0- 0.6.14-1+b1 Library for handling GObject intro ii libgjs0a0.7.1-1 Mozilla-based javascript bindings ii libgl1-mesa-glx [li 7.7.1-4 A free implementation of the OpenG ii libglib2.0-02.25.15-1The GLib library of C routines ii libgnome-desktop-2- 2.30.2-1 Utility library for loading .deskt ii libgnome-menu2 2.30.2-1 an implementation of the freedeskt ii libgstreamer0.10-0 0.10.30-1Core GStreamer libraries and eleme ii libgtk2.0-0 2.21.7-1 The GTK+ graphical user interface ii libjson-glib-1.0-0 0.10.2-2 GLib JSON manipulation library ii libmozjs2d 1.9.1.11-2 The Mozilla SpiderMonkey JavaScrip ii libnspr4-0d 4.8.6-1 NetScape Portable Runtime Library ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libstartup-notifica 0.10-1 library for program launch feedbac ii libx11-62:1.3.3-3X11 client-side library ii libxcomposite1 1:0.4.2-1X11 Composite extension library ii libxdamage1 1:1.1.3-1X11 damaged region extension libra ii libxext62:1.1.2-1X11 miscellaneous extension librar ii libxfixes3 1:4.0.5-1X11 miscellaneous 'fixes' extensio ii libxml2 2.7.7.dfsg-4 GNOME XML library ii mesa-utils 7.7.1-4 Miscellaneous Mesa GL utilities ii mutter 2.31.5-1 lightweight GTK+ window manager ii pkg-config 0.25-1 manage compile and link flags for ii python 2.6.6-1 interactive high-level object-orie ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnome-shell recommends: ii xserver-xephyr2:1.7.7-5 nested X server gnome-shell suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590322: Experimental version uninstallable because of dependency on libgjs0a
Package: gnome-shell Version: 2.31.2-1 Severity: grave Tags: experimental I am unable to install new version of gnome-shell: # LANG=C apt-get -t experimental install gnome-shell Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gnome-shell: Depends: libgjs0a (>= 0.7.1) but 0.7-1 is to be installed E: Broken packages and after upgrade gir packages old gnome-shell is not usable: $ gnome-shell (mutter:2310): mutter-WARNING **: Could not load library [/usr/lib/mutter/plugins/libgnome-shell.so (/usr/lib/mutter/plugins/libgnome-shell.so: undefined symbol: mutter_plugin_effect_completed)] -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii gconf2 2.28.1-3 GNOME configuration database syste ii gir1.0-clutter-1.0 1.2.12-2 GObject introspection data for the ii gir1.0-freedesktop 0.6.14-1+b1 Introspection data for some FreeDe ii gir1.0-glib-2.0 0.6.14-1+b1 Introspection data for GLib, GObje ii gir1.0-gtk-2.0 0.6.5-6+b1 GObject introspection data for the ii gir1.0-json-glib-1.00.10.2-2 GLib JSON manipulation library (do ii gir1.0-mutter-2.31 2.31.5-1 GObject introspection data for Mut ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libclutter-1.0-01.2.12-2 Open GL based interactive canvas l ii libcroco3 0.6.2-1 a generic Cascading Style Sheet (C ii libdbus-1-3 1.2.24-2 simple interprocess messaging syst ii libdbus-glib-1-20.86-1 simple interprocess messaging syst ii libffi5 3.0.9-2 Foreign Function Interface library ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.0-2 FreeType 2 font engine, shared lib ii libgconf2-4 2.28.1-3 GNOME configuration database syste ii libgirepository1.0-00.6.14-1+b1 Library for handling GObject intro ii libgjs0a0.7-1Mozilla-based javascript bindings ii libgl1-mesa-glx [libgl1 7.7.1-4 A free implementation of the OpenG ii libglib2.0-02.24.1-1 The GLib library of C routines ii libgnome-desktop-2-17 2.30.2-1 Utility library for loading .deskt ii libgnome-menu2 2.30.2-1 an implementation of the freedeskt ii libgstreamer0.10-0 0.10.30-1Core GStreamer libraries and eleme ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii libjson-glib-1.0-0 0.10.2-2 GLib JSON manipulation library ii libmozjs2d 1.9.1.11-1 The Mozilla SpiderMonkey JavaScrip ii libnspr4-0d 4.8.4-2 NetScape Portable Runtime Library ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libstartup-notification 0.10-1 library for program launch feedbac ii libx11-62:1.3.3-3X11 client-side library ii libxcomposite1 1:0.4.2-1X11 Composite extension library ii libxdamage1 1:1.1.3-1X11 damaged region extension libra ii libxext62:1.1.2-1X11 miscellaneous extension librar ii libxfixes3 1:4.0.5-1X11 miscellaneous 'fixes' extensio ii libxml2 2.7.7.dfsg-4 GNOME XML library ii mesa-utils 7.7.1-4 Miscellaneous Mesa GL utilities ii mutter 2.31.5-1 lightweight GTK+ window manager ii pkg-config 0.25-1 manage compile and link flags for ii python 2.6.5-9 interactive high-level object-orie ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnome-shell recommends: ii xserver-xephyr2:1.7.7-3 nested X server gnome-shell suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#464168: trac: Does not work with PostgreSQL 8.3 - column type conflict
Package: trac Version: 0.10.4-2 Severity: serious Today I upgraded PostgreSQL to 8.3. This version more strictly checks types of columns and parameters. After this upgrade any operations in Trac that try to access Subversion repository (Timeline, Browse Source) fails. For example "Browse source" results in following web page: Python Traceback Traceback (most recent call last): File "/var/lib/python-support/python2.4/trac/web/main.py", line 406, in dispatch_request dispatcher.dispatch(req) File "/var/lib/python-support/python2.4/trac/web/main.py", line 237, in dispatch resp = chosen_handler.process_request(req) File "/var/lib/python-support/python2.4/trac/versioncontrol/web_ui/browser.py", line 143, in process_request self._render_directory(req, repos, node, rev) File "/var/lib/python-support/python2.4/trac/versioncontrol/web_ui/browser.py", line 168, in _render_directory changes = get_changes(self.env, repos, [i['rev'] for i in info]) File "/var/lib/python-support/python2.4/trac/versioncontrol/web_ui/util.py", line 37, in get_changes changeset = repos.get_changeset(rev) File "/var/lib/python-support/python2.4/trac/versioncontrol/cache.py", line 45, in get_changeset self.authz) File "/var/lib/python-support/python2.4/trac/versioncontrol/cache.py", line 247, in __init__ "WHERE rev=%s", (rev,)) File "/var/lib/python-support/python2.4/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/var/lib/python-support/python2.4/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) ProgrammingError: operator does not exist: text = integer LINE 1: SELECT time,author,message FROM revision WHERE rev=238 ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. Problem lies in table revision, column rev; this column has type text, which conflicts with number given to query as parameter. Changing type of this column to integer helps. It looks like there is no other column referencing revisions.rev, so this can be done without problem. Following SQL commands allow for fixing exisitng Trac database; after those, Trac works again. alter table revision add column r integer; update revision set r = rev::int; alter table revision drop column rev; alter table revision rename column r to rev; alter table revision alter column rev set not null; alter table revision add primary key (rev); I set severity for serious because this error makes Trac only partially usable, although it does not cause data loss. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23 Locale: LANG=polish, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to pl_PL.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages trac depends on: ii python 2.4.4-6 An interactive high-level object-o ii python-clearsilver 0.10.4-1 python bindings for clearsilver ii python-pysqlite22.4.0-2 python interface to SQLite 3 ii python-subversion 1.4.4dfsg1-1 Python bindings for Subversion ii python-support 0.7.6automated rebuilding support for p ii subversion 1.4.4dfsg1-1 Advanced version control system Versions of packages trac recommends: ii apache2 2.2.8-1Next generation, scalable, extenda ii apache2-mpm-worker [httpd]2.2.8-1High speed threaded model for Apac ii python-setuptools 0.6c7-1Python Distutils Enhancements -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459746: postgresql-server-dev-8.3: Fails to install because of conflicting files with libpq-dev
Package: postgresql-server-dev-8.3 Version: 8.3~rc1-1 Severity: grave Justification: renders package unusable LC_ALL=C apt-get -t experimental install postgresql-server-dev-8.3 Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: postgresql-server-dev-8.3 0 upgraded, 1 newly installed, 0 to remove and 198 not upgraded. Need to get 0B/760kB of archives. After unpacking 3615kB of additional disk space will be used. Reading package fields... Done Reading package status... Done Retrieving bug reports... Done Parsing Found/Fixed information... Done (Reading database ... 294978 files and directories currently installed.) Unpacking postgresql-server-dev-8.3 (from .../postgresql-server-dev-8.3_8.3~rc1-1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/postgresql-server-dev-8.3_8.3~rc1-1_i386.deb (--unpack): trying to overwrite `/usr/share/postgresql/8.3/man/man1/pg_config.1', which is also in package libpq-dev dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: Errors were encountered while processing: /var/cache/apt/archives/postgresql-server-dev-8.3_8.3~rc1-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23 Locale: LANG=polish, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to pl_PL.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages postgresql-server-dev-8.3 depends on: ii libc6 2.7-5 GNU C Library: Shared libraries ii libpq-dev 8.3~rc1-1 header files for libpq5 (PostgreSQ postgresql-server-dev-8.3 recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348050: More information, successful upgrade
After I've removed libsemanage-dev (which, as I observed, was removed from Debian archive), installing python2.4-semanage and upgrading policycoreutils went fine. I think adding Replaces: (or Conflicts: libsemanege-dev) header to new policycoreutils should fix that problem. Regards. -- Tomasz Rybak <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348050: python2.4-semanage: Cannot be installed. Conflicting file with libsemanage-dev
Package: python2.4-semanage Version: 1.4-3 Severity: grave Justification: renders package unusable # LC_ALL=C apt-get install python2.4-semanage Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: python2.4-semanage 0 upgraded, 1 newly installed, 0 to remove and 158 not upgraded. 1 not fully installed or removed. Need to get 0B/37.7kB of archives. After unpacking 377kB of additional disk space will be used. Reading package fields... Done Reading package status... Done Retrieving bug reports... Done (Reading database ... 190850 files and directories currently installed.) Unpacking python2.4-semanage (from .../python2.4-semanage_1.4-3_i386.deb) ... dpkg: error processing /var/cache/apt/archives/python2.4-semanage_1.4-3_i386.deb (--unpack): trying to overwrite `/usr/include/semanage/context_record.h', which is also in package libsemanage-dev Errors were encountered while processing: /var/cache/apt/archives/python2.4-semanage_1.4-3_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) It leaves policycoreutils, which depends on python2.4-semanage, in unconfigured state, and apt-get writes: You might want to run `apt-get -f install' to correct these: The following packages have unmet dependencies: policycoreutils: Depends: python2.4-semanage but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=polish, LC_CTYPE=pl_PL (charmap=ISO-8859-2) (ignored: LC_ALL set to pl_PL) -- Tomasz Rybak <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
