Bug#590224: python-sqlalchemy: sqlalchemy crashes on import
Package: python-sqlalchemy Version: 0.6.2-1 Severity: grave Justification: renders package unusable When running any application using python-alchemy, the application crashes with the following error message: File /usr/lib/python2.6/dist-packages/sqlalchemy/__init__.py, line 51, in module from sqlalchemy.types import ( ValueError: bad marshal data I noticed the problem when trying to run anki, but the following testcase is sufficient to experience the problem: echo from sqlalchemy import * /tmp/test.py python /tmp/test.py -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-sqlalchemy depends on: ii python 2.6.5-5 An interactive high-level object-o ii python2.5 2.5.5-6 An interactive high-level object-o ii python2.6 2.6.5+20100706-1 An interactive high-level object-o Versions of packages python-sqlalchemy recommends: ii python-sqlalchemy-ext 0.6.2-1SQL toolkit and Object Relational Versions of packages python-sqlalchemy suggests: pn python-kinterbasdbnone (no description available) pn python-mysqldbnone (no description available) pn python-psycopg2 none (no description available) pn python-pymssqlnone (no description available) pn python-sqlalchemy-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551989: gcalctool: ignores shift key in keyboard shortcuts
Package: gcalctool Version: 5.22.3-2 Severity: important Numeric point cannot be used from belgian (and other) keyboards. The problem seems to lie in the fact that typing '.' requires shift and gcalctool ignores shift state. This bug has already been detected, confirmed and fixed in Ubuntu [1] and upstream [2], would be nice if it could be fixed in Debian too, as it severely affects usability of gcalctool. [1]: https://bugs.launchpad.net/gcalctool/+bug/269303 [2]: https://bugzilla.gnome.org/show_bug.cgi?id=574358 -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcalctool depends on: ii gconf2 2.22.0-1 GNOME configuration database syste ii gnome-icon-theme2.22.0-1 GNOME Desktop icon theme ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libc6 2.7-18 GNU C Library: Shared libraries ii libgconf2-4 2.22.0-1 GNOME configuration database syste ii libglade2-0 1:2.6.2-1library to load .glade files at ru ii libglib2.0-02.16.6-2 The GLib library of C routines ii libgtk2.0-0 2.12.12-1~lenny1 The GTK+ graphical user interface ii libpango1.0-0 1.20.5-5 Layout and rendering of internatio gcalctool recommends no packages. gcalctool suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684123: argyll: dispwin fails to load ICC profile
Package: argyll Version: 1.4.0-6 Severity: normal Dear Maintainer, I used to load my monitor ICC profile with: dispwin ~/.local/share/icc/LP156WD1_TLB2_D65.icm where LP156WD1_TLB2_D65.icm is my monitor profile. It used to work perfectly. However, since last upgrade (see below), it does not work anymore. dispwin reports no error but the display is not affected. Here is the output of dispwin -v -D1 ~/.local/share/icc/LP156WD1_TLB2_D65.icm: Checking XRandR 1.2 VideoLUT access Display 0 name = ':0.0' Got EDID for display About to open dispwin object on the display new_dispwin: Opened display OK new_dispwin: return sucessfully dispwin_get_ramdac called Getting gamma using Randr 1.2 dispwin_get_ramdac returning OK About to set display to given calibration dispwin_set_ramdac called Setting gamma using Randr 1.2 XF86VidModeSetGammaRamp returning OK Calibration set About to destroy dispwin object dispwin_del called About to close display finished As everything seems OK, I would have expected the monitor profile to be loaded but it is apparently not the case. The profile loads fine with: xcalib ~/.local/share/icc/LP156WD1_TLB2_D65.icm Once the profile is loaded with xcalib, I cannot clear it either: dispwin -c has no effect. I upgraded libicc2 at the same time than argyll so that the bug may lie with the library and not with dispwin (xcalib does not depend on libicc2). Here is the relevant excerpt from my APT history log: argyll:amd64 (1.4.0-4, 1.4.0-6) libicc2:amd64 (2.12+argyll1.4.0-4, 2.12+argyll1.4.0-6) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages argyll depends on: ii libc6 2.13-33 ii libicc2 2.12+argyll1.4.0-6 ii libimdi0 1.4.0-6 ii libjpeg8 8d-1 ii libtiff4 3.9.6-7 ii libusb-0.1-4 2:0.1.12-20 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxinerama1 2:1.1.2-1 ii libxrandr22:1.3.2-2 ii libxss1 1:1.2.2-1 ii libxxf86vm1 1:1.1.2-1 Versions of packages argyll recommends: ii consolekit 0.4.5-3 ii udev175-3.1 argyll suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656330: ocaml-tools: Missing OMLet files
Package: ocaml-tools Version: 20120103-1 Severity: important Dear Maintainer, Since last package update, ocaml-tools misses the following files providing OMLet functionality: - ftplugin/omlet.vim - indent/omlet.vim - syntax/omlet.vim - ftdetect/omlet.vim As a result, OMLet is no more available. One has either no more OCaml support in vim, or falls back on traditional OCaml editing mode provided with vim. OMLet README, changelog and vim registry files are still present. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ocaml-tools depends on: ii ocaml-base-nox [ocaml-base-nox-3.12.1] 3.12.1-2 Versions of packages ocaml-tools recommends: ii vim-addon-manager 0.4.4 ii vim-gnome [vim]2:7.3.363-1 Versions of packages ocaml-tools suggests: pn autoconf 2.68-1 pn otags none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656426: ocaml-tools: Dead link in README.omlet
Package: ocaml-tools Version: 20120103-2 Severity: minor Tags: patch Dear Maintainer, In README.omlet, the given URL is http://perso.ens-lyon.fr/david.baelde/productions/omlet.php but this URL leads to a 404 error. Current address of this page seems to be http://www.lix.polytechnique.fr/~dbaelde/productions/omlet.html -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ocaml-tools depends on: ii ocaml-base-nox [ocaml-base-nox-3.12.1] 3.12.1-2 Versions of packages ocaml-tools recommends: ii vim-addon-manager 0.4.4 ii vim-gnome [vim]2:7.3.363-1 Versions of packages ocaml-tools suggests: pn autoconf 2.68-1 pn otags none -- no debconf information --- README.omlet 2012-01-19 09:31:19.039844328 +0100 +++ README.omlet.new 2012-01-19 09:32:06.497791258 +0100 @@ -8,4 +8,4 @@ - A plugin which performs folding, plus the official features For customization tips: -http://perso.ens-lyon.fr/david.baelde/productions/omlet.php +http://www.lix.polytechnique.fr/~dbaelde/productions/omlet.html
Bug#398897: ocaml-tools: omlet does not respect the efm variable
tags 398897 + patch thanks Hello, Here is a patch extending efm to account for make recursive invocations. efm is set to the same value as in ftplugin/ocaml.vim provided with vim 7.3. This includes verbatim every pattern that is included with upstream OMLet so that it should be no worse than current version. I tested it quickly and it seems to jump properly to error locations both with and without recursive make. Cheers, -- As we enjoy great Advantages from the Inventions of others, we should be glad of an Opportunity to serve others by any Invention of ours; and this we should do freely and generously. Benjamin Franklin Cyril Soldani devmusi...@legiasoft.com http://devmusings.legiasoft.com/ --- omlet.vim 2012-01-19 09:19:13.017898855 +0100 +++ omlet.vim.new 2012-01-19 09:22:27.388449492 +0100 @@ -49,7 +49,12 @@ \%Eocamlyacc:\ e\ -\ line\ %l\ of\ \%f\\\,\ %m, \%Wocamlyacc:\ w\ -\ %m, \%-Zmake%.%#, - \%C%m + \%C%m, + \%D%*\\a[%*\\d]:\ Entering\ directory\ `%f', + \%X%*\\a[%*\\d]:\ Leaving\ directory\ `%f', + \%D%*\\a:\ Entering\ directory\ `%f', + \%X%*\\a:\ Leaving\ directory\ `%f', + \%DMaking\ %*\\a\ in\ %f Add mappings, unless the user didn't want this. if !exists(no_plugin_maps) !exists(no_ocaml_maps) signature.asc Description: PGP signature
Bug#654863: xdg-open: fails with URLs containing ampersands
Package: xdg-utils Version: 1.1.0~rc1+git20111210-4 Severity: normal Tags: patch Dear Maintainer, When trying to open an HTTP(S) URL containing ampersands with xdg-open, it fails. Rather than passing the given URL to the browser, it replaces ampersands with '%u' (which becomes %25u, once URL-encoded). For example, xdg-open https://www.google.com/search?q=grailie=utf-8; opens https://www.google.com/search?q=grail%uie=utf-8; instead, searching for 'grail%uie=utf-8' instead of searching for 'grail'. Investigating a bit, I found the problem to be at line 552 of xdg-open: arguments_exec=`echo $arguments | sed -e 's*%[fFuU]*'$1'*g'` In our case, $arguments contains '%u'. The problem is with the sed expression, which uses $1 (our URL) without escaping ampersands in it. In the replacement part of a sed expression, an unescaped stands for the portion of the pattern that matched. In our case, every in the URL is thus replaced by a '%u'. As a quick fix, I modified mine as follows: escaped=`echo $1 | sed -e 's//\\\/g'` arguments_exec=`echo $arguments | sed -e 's*%[fFuU]*'$escaped'*g'` This allows me to open HTTP URLs with ampersands as expected. However, I give it more as an illustration of the problem than as a serious fix proposal: - It may not be the most elegant way to fix it. - It may be necessary also in other places. - It is necessary also for other characters. E.g. xdg-open https://www.google.com/search?q=grail\1; fails with the message sed: -e expression #1, char 53: invalid reference \1 on `s' command's RHS instead of opening the URL. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash xdg-utils depends on no packages. Versions of packages xdg-utils recommends: ii libfile-mimeinfo-perl 0.15-2 ii libnet-dbus-perl 1.0.0-1+b1 ii libx11-protocol-perl 0.56-2 ii x11-utils 7.6+4 ii x11-xserver-utils 7.6+3 Versions of packages xdg-utils suggests: ii gvfs-bin 1.10.1-2 -- no debconf information --- xdg-open 2012-01-06 12:12:54.078811539 +0100 +++ xdg-open.new 2012-01-06 12:10:44.149866844 +0100 @@ -549,7 +549,8 @@ command=`grep -E ^Exec(\[[^]=]*])?= $file | cut -d= -f 2- | first_word` command_exec=`which $command 2/dev/null` arguments=`grep -E ^Exec(\[[^]=]*])?= $file | cut -d= -f 2- | last_word` -arguments_exec=`echo $arguments | sed -e 's*%[fFuU]*'$1'*g'` +escaped=`echo $1 | sed -e 's//\\\/g'` +arguments_exec=`echo $arguments | sed -e 's*%[fFuU]*'$escaped'*g'` if [ -x $command_exec ] ; then if echo $arguments | grep -iq '%[fFuU]' ; then eval $command_exec $arguments_exec
Bug#654863: xdg-open: fails with URLs containing ampersands
On Fri, 06 Jan 2012 15:18:13 +0100
Per Olofsson pe...@dsv.su.se wrote:
Hmm, perhaps it is better to use awk here. How about this:
arguments_exec=`echo $arguments | awk -v url=$1 \
'{gsub(/%[fFuU]/, url); print}'`
I think the problem stays the same, as GNU awk also replaces ampersands
by the matched pattern (and \1 to \9 are also replaced by matched
groups with awk).
I did a quick research myself revealing that it is a somehow frequent
problem, but I found no solution other than escaping URL first.
Apparently, the only two characters to be escaped are and \ (both for
sed and for awk).
Regards,
--
As we enjoy great Advantages from the Inventions of others, we should
be glad of an Opportunity to serve others by any Invention of ours;
and this we should do freely and generously. Benjamin Franklin
Cyril Soldani devmusi...@legiasoft.com
http://devmusings.legiasoft.com/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654863: xdg-open: fails with URLs containing ampersands
On Sun, 08 Jan 2012 18:57:48 +0100 Per Olofsson pe...@dsv.su.se wrote: Apparently, the only two characters to be escaped are and \ (both for sed and for awk). '\' is not allowed unescaped in URI's though. But it is probably safer to escape it as well. I agree. Although my example was a bit contrived, it seems to work as intended when passed directly to iceweasel so it is probably safer to escape it as well. I guess escaping is the way to go then. So how about this clever pattern which escapes both characters: local escaped=$(echo $1 | sed -e 's/[\\]/\\/g') Nice one. Does the job, clear and short. P.S. : I checked the remainder of xdg-open script if there were other occurrences of sed with $1 in the replacement string, and this was the only one. Regards, -- As we enjoy great Advantages from the Inventions of others, we should be glad of an Opportunity to serve others by any Invention of ours; and this we should do freely and generously. Benjamin Franklin Cyril Soldani devmusi...@legiasoft.com http://devmusings.legiasoft.com/ signature.asc Description: PGP signature
Bug#684123: argyll: dispwin fails to load ICC profile
On Mon, 10 Sep 2012 14:06:53 +0200 Andreas Beckmann deb...@abeckmann.de wrote: Please try 304.43-1 which just entered sid. It works for me. dispwin commands now works without the ARGYLL_IGNORE_XRANDR1_2=yes workaround. Some video overlays (e.g. mplayer, Adobe Flash Player) continue to ignore my profile, but I could never manage to get those color managed with nVidia drivers (it works with nouveau drivers). Thanks to all that contributed to solve the issue! -- L'imprimerie est l'artillerie de la pensée. Antoine Rivaroli, dit comte de Rivarol Cyril Soldani cyril.sold...@legiasoft.com signature.asc Description: PGP signature
Bug#761257: systemd: disrupts hugepages support
Package: systemd Version: 208-8 Severity: normal Dear Maintainer, We are developing Intel DPDK applications on several Debian-powered servers. Those applications make use of 1GB huge pages, allocated through kernel parameters in /etc/defaults/grub, and an entry in /etc/fstab to mount them in /mnt/huge_1GB. After some upgrades, our applications stopped working on most servers due to hugepages being unavailable. They were still appearing in /proc/meminfo but were neither free, nor reserved. After hours of debugging (we had also updated Intel DPDK so we thought that was the culprit), we noticed a difference between the failing servers and the ones still working was that systemd was running as init on the failing ones and not on the working ones. We tried uninstalling systemd-sysv (installing sysvinit-core and systemd-shim), rebooting, and then it worked as before. After investigations, it looks like systemd, when run as init, mounts the hugepages in /dev/hugepages (IMHO, an unexpected place for a mount point), before them being remounted on /mnt/huge_1GB as per fstab. It looks like hugepages won't work when mounted twice. A likely culprit is /lib/systemd/system/dev-hugepages.mount. The workaround looks trivial (remove fstab entry and link /dev/hugepages to /mnt/huge_1GB), but I still have the feeling this should not have happened in the first place, hence this bug report. I would expect either (by order of preference): 1) systemd *not* messing with the existing hugepages setup; 2) being warned when installing systemd-sysv that systemd handles hugepages differently (especially when I have hugepages entries in my fstab). -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/12 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-1.1 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.4 ii libacl1 2.2.52-1.1 ii libaudit11:2.3.7-1 ii libblkid12.20.1-5.8 ii libc62.19-10 ii libcap2 1:2.24-4 ii libcap2-bin 1:2.24-4 ii libcryptsetup4 2:1.6.6-1 ii libdbus-1-3 1.8.6-2 ii libgcrypt11 1.5.4-3 ii libkmod2 18-1 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd-daemon0 208-8 ii libsystemd-journal0 208-8 ii libsystemd-login0208-8 ii libudev1 208-8 ii libwrap0 7.6.q-25 ii sysv-rc 2.88dsf-53.4 ii udev 208-8 ii util-linux 2.20.1-5.8 Versions of packages systemd recommends: ii libpam-systemd 208-8 Versions of packages systemd suggests: pn systemd-ui none -- no debconf information 0 overridden configuration files found. == /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.nm-dispatcher.service == == /var/lib/systemd/deb-systemd-helper-enabled/bluetooth.target.wants/bluetooth.service == == /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.bluez.service == == /var/lib/systemd/deb-systemd-helper-enabled/acpid.service.dsh-also == /etc/systemd/system/multi-user.target.wants/acpid.service == /var/lib/systemd/deb-systemd-helper-enabled/avahi-daemon.socket.dsh-also == /etc/systemd/system/sockets.target.wants/avahi-daemon.socket == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/atd.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/anacron.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cron.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/avahi-daemon.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ssh.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/binfmt-support.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/lm-sensors.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/pppd-dns.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/NetworkManager.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ModemManager.service == == /var/lib/systemd/deb-systemd-helper-enabled/lvm2-lvmetad.socket.dsh-also == /etc/systemd/system/sockets.target.wants/lvm2-lvmetad.socket /etc/systemd/system/sysinit.target.wants/lvm2-lvmetad.socket == /var/lib/systemd/deb-systemd-helper-enabled/lm-sensors.service.dsh-also ==
Bug#761257: systemd: disrupts hugepages support
On Fri, 12 Sep 2014 19:25:21 +0200 m...@linux.it (Marco d'Itri) wrote: 1) systemd *not* messing with the existing hugepages setup; This will not happen: it would be too much complex and anyway the new standard location is /dev/hugepages/ . It looks questionable to me, but you certainly know better (as I don't know anything about it) and I won't argue any further. 2) being warned when installing systemd-sysv that systemd handles hugepages differently (especially when I have hugepages entries in my fstab). But I think that we can add a preinst check, can you provide a simple shell test case that checks for this condition? I must first mention that the problem is less severe than initially thought. As Ben Hutchings helped me discover (see #761299), you can still use hugepages even when mounted several times. Our problem was that the two mount points had different permissions, and our applications were using the wrong one. It thus likely to affect less users than initially thought. If you are still willing to add a warning (which could still be nice, IMO), a test like this might be sufficient: if 21 grep -E '^[^#]*hugetlbfs' /etc/fstab /dev/null; then echo Hugepages entries found fi Regards, -- The nationalist not only does not disapprove of atrocities committed by his own side, he has a remarkable capacity for not even hearing about them.George Orwell Cyril Soldani devmusi...@legiasoft.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761299: systemd: disrupts hugepages support
On Fri, 12 Sep 2014 18:37:52 +0100 Ben Hutchings b...@decadent.org.uk wrote: After investigations, it looks like systemd, when run as init, mounts the hugepages in /dev/hugepages (IMHO, an unexpected place for a mount point), before them being remounted on /mnt/huge_1GB as per fstab. It looks like hugepages won't work when mounted twice. [...] Please explain 'won't work'. I am able to create files on multiple hugetlbfs mounts. I suspect that some other application may be automatically using hugepages in /dev/hugepages, whereas previously there was no default location available for it to use. You are right. I tried again and, indeed, our application is trying to use /dev/hugepages instead of /mnt/huge_1GB, as it is doing when /dev/hugepages is not present. Permissions on /dev/hugepages are different and that causes hugepages mapping to fail. So, there was no Linux bug here. However, it might still be nice to warn users that have hugetlbfs entries in /etc/fstab on systemd-sysv install. Thanks for helping clarifying that issue, -- Of all the enemies to public liberty, war is perhaps the most to be dreaded because it comprises and develops the germ of every other. James Madison Cyril Soldani cyril.sold...@legiasoft.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742408: connman: Please package release = 1.24 to fix DNS lookup bug
Package: connman Version: 1.21-1.1 Followup-For: Bug #742408 Dear Maintainer, When doing a name lookup with only the host name, version 1.21 of connman fails even when the search should succeed (thanks to the search domain transmitted by the DHCP server). It seems that this long-standing bug has been fixed in version 1.24 according to [1]. Could you please consider packaging this (or a latter) version of connman? 1: https://01.org/connman/blogs/pflykt/2014/connman-1.24 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'testing-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages connman depends on: ii dbus 1.8.6-2 ii init-system-helpers 1.21 ii libc62.19-11 ii libdbus-1-3 1.8.6-2 ii libglib2.0-0 2.42.0-1 ii libgnutls-deb0-283.3.8-2 ii libreadline6 6.3-8 ii libxtables10 1.4.21-2 ii lsb-base 4.1+Debian13 Versions of packages connman recommends: ii bluez 5.23-1 ii ofono 1.15-1 ii wpasupplicant 2.2-1 Versions of packages connman suggests: pn indicator-network none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#858626: libllvm-3.8-ocaml-dev: Package is empty
Package: libllvm-3.8-ocaml-dev Version: 1:3.8.1-18 Severity: grave Justification: renders package unusable Dear Maintainer, The package `libllvm-3.8-ocaml-dev` does not ship any library. It only contains the following files: /usr/share/doc/libllvm-3.8-ocaml-dev/NEWS.Debian.gz /usr/share/doc/libllvm-3.8-ocaml-dev/changelog.Debian.gz /usr/share/doc/libllvm-3.8-ocaml-dev/copyright /usr/share/lintian/overrides/libllvm-3.8-ocaml-dev /var/lib/ocaml/lintian/libllvm-3.8-ocaml-dev.info /var/lib/ocaml/md5sums/libllvm-3.8-ocaml-dev.md5sums It misses the `/usr/lib/ocaml/llvm-3.8` folder, which should contain the libraries, making the package totally unusable. It looks like this folder is missing since `libllvm-3.6-ocaml-dev`, and is still missing in `libllvm-3.9-ocaml-dev`. Last version containing it was `libllvm-3.5-ocaml-dev`, but it is not installable on `stretch`. The change log mentions that OCaml bindings were disabled in November 2014, because `libctypes-ocaml` 0.3.3 was needed, but not available. Would it work with a current version of that library? (0.7.0 is installed on my system) Thanks in advance for your help. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libllvm-3.8-ocaml-dev depends on: ii llvm-3.8-dev 1:3.8.1-18 libllvm-3.8-ocaml-dev recommends no packages. Versions of packages libllvm-3.8-ocaml-dev suggests: pn llvm-3.8-doc -- no debconf information
Bug#858626: libllvm-3.8-ocaml-dev: Package is empty
Hello, On Sat, 25 Mar 2017 16:37:20 +0100 Sylvestre Ledru <sylves...@debian.org> wrote: > Le 24/03/2017 à 17:04, Cyril Soldani a écrit : > > It looks like this folder is missing since `libllvm-3.6-ocaml-dev`, > > and is still missing in `libllvm-3.9-ocaml-dev`. Last version > > containing it was `libllvm-3.5-ocaml-dev`, but it is not > > installable on `stretch`. > Thanks! > As it has been in this state for a while and nobody complained about, > I will probably just remove it from the packaging... I understand your rationale, but I would still like to give the following arguments in favour of keeping (and fixing) the package: * While nobody seemed to have complained up to now, this may be at least partly due to the fact that `libllvm-3.5-ocaml-dev` is working fine. It is available (and used) on jessie, and was co-installable on stretch until recently (indeed, I may still install it, provided I am willing to downgrade half of my system). * Even if not legions, there are still users (at least me and about 15 students each year), and at least a few tens of other installs according to popcon. * It would be extremely hard to package for someone else. Since the OCaml bindings are directly supported inside the upstream LLVM project, my feeling is that packaging them separately would require basically a copy of `llvm-toolchain` source package, with other binary packages stripped off, and keeping that in close synchronization with the other packages from the *true* `llvm-toolchain`. * I don't know about the long-term maintenance cost, but fixing the package right now looks feasible (see attached patch, and explanations below). Playing a bit with the `llvm-toolchain` source package, it looks like the OCaml bindings are already generated, and only need copying into the corresponding package. Here is what seems to work on my system (using revision r2501, just before the removal): sudo apt-get build-dep libllvm-3.8-ocaml-dev debcheckout llvm-toolchain-3.8 cd llvm-toolchain-3.8 svn up -r 2501 patch -p0 < ../../libllvm-3.8-ocaml-dev-enable.patch # Attached debuild -b -uc -us # Fetch a drink and a book cd .. sudo dpkg -i libllvm-3.8-ocaml-dev_3.8.1-19\~exp2_amd64.deb \ llvm-3.8-dev_3.8.1-19\~exp2_amd64.deb \ libllvm3.8_3.8.1-19\~exp2_amd64.deb \ llvm-3.8_3.8.1-19\~exp2_amd64.deb \ llvm-3.8-runtime_3.8.1-19\~exp2_amd64.deb # Build and test some OCaml programs using the library The patch is only a few lines long. It makes the doc and renames the OCaml library folder in `debian/rules` (because `dh_install` can't rename, and it is called `ocaml` instead of `llvm-3.8`). The patch also uncomments (and fixes some paths in) the install directives in `libllvm-X.Y-ocaml-dev.install.in`. Note however that this was not tested on a clean (i.e. newly installed, minimal) system, and that the package was FTBFS before I modified it (cmake was complaining about not finding `ocamldoc/html` in `docs/cmake_install.cmake`). I also tested the generated library quite superficially (most of my codebase needs a few changes to accommodate the non retro-compatible changes between LLVM 3.5 and 3.8). So, if you choose to stick to removing the package, I won't complain (you are the one(s) doing the work, and knowing the maintenance burden of it). But if it can be kept without too much difficulty, it would be appreciated. Thanks anyway, Regards, -- "If Tyranny and Oppression come to this land, it will be in the guise of fighting a foreign enemy." James Madison Cyril Soldani <cyril.sold...@legiasoft.com> Index: debian/libllvm-X.Y-ocaml-dev.install.in === --- debian/libllvm-X.Y-ocaml-dev.install.in (revision 2501) +++ debian/libllvm-X.Y-ocaml-dev.install.in (working copy) @@ -1,2 +1,2 @@ -#@OCAML_STDLIB_DIR@/llvm-@LLVM_VERSION@ @OCAML_STDLIB_DIR@/ -#usr/lib/llvm-@LLVM_VERSION@/docs/llvm/ocamldoc/html usr/share/doc/libllvm-@LLVM_VERSION@-ocaml-dev/ +@OCAML_STDLIB_DIR@/llvm-@LLVM_VERSION@ @OCAML_STDLIB_DIR@/ +usr/lib/llvm-@LLVM_VERSION@/docs/ocaml/html/html usr/share/doc/libllvm-@LLVM_VERSION@-ocaml-dev/ Index: debian/rules === --- debian/rules (revision 2501) +++ debian/rules (working copy) @@ -284,6 +284,7 @@ build_doc: cd $(CURDIR)/docs && make -f Makefile.sphinx && make -f Makefile.sphinx man cd $(CURDIR)/clang/docs && make -f Makefile.sphinx && make -f Makefile.sphinx man + $(PRE_PROCESS) $(MAKE) $(NJOBS) -C "$(TARGET_BUILD)/docs" ocaml_doc # Rename manpages d=$(CURDIR)/docs/_build/man/; \ @@ -441,6 +442,13 @@ $(CURDIR)/debian/libclang-common-$(LLVM_VERSION)-dev/usr/lib/llvm-$(LLVM_VERSION)/include/; \ fi +# Rename OCaml bindings + if test -d "$(DEB_INST)/usr/lib/llvm
Bug#858626: libllvm-3.8-ocaml-dev: Package is empty
On Sun, 9 Apr 2017 14:36:14 +0200
Sylvestre Ledru <sylves...@debian.org> wrote:
> If you are interested to bring it back, please start from r2529
> (and try in a clean pbuilder, your patch had missing build deps)
I could not make it work for r2529 specifically (some dependency
generation problems with `dh_shlibdeps` at the end of the build), but
attached patch seems to work with later r2543. Is it OK? I can
investigate r2529 some more if necessary.
Here are the steps I took:
sudo pbuilder clean
sudo pbuider update
mkdir libllvm-3.8-ocaml-dev-test
cd libllvm-3.8-ocaml-dev-test
debcheckout llvm-toolchain-3.8 # Checked out r2543
cd llvm-toolchain-3.8
patch -p0 < ../../libllvm-3.8-ocaml-dev-enable.patch
sudo pdebuild -- --debbuildopts "-j6 -b -uc -us" # Have a walk
cd /var/cache/pbuilder/result
dpkg -c libllvm-3.8-ocaml-dev_3.8.1-19\~exp4_amd64.deb # Looks OK
sudo dpkg -i libllvm-3.8-ocaml-dev_3.8.1-19\~exp4_amd64.deb \
llvm-3.8-dev_3.8.1-19\~exp4_amd64.deb \
libllvm3.8_3.8.1-19\~exp4_amd64.deb \
llvm-3.8_3.8.1-19\~exp4_amd64.deb \
llvm-3.8-runtime_3.8.1-19\~exp4_amd64.deb
I then tested the library with some of my OCaml codebase, and it looks
fine so far. My tests are far from exhaustive, but result certainly
looks better than with the empty package :-)
> This is blocking me on other bugs and I don't have time for this bug.
I am already grateful that you are willing to accept contributions for
this seldom-used package. I hope this patch applies more cleanly.
Thanks,
--
"Liberty and democracy become unholy when their hands are dyed red
with innocent blood." Mahatma Gandhi
Cyril Soldani <cyril.sold...@legiasoft.com>
Index: debian/control
===
--- debian/control (revision 2543)
+++ debian/control (working copy)
@@ -7,8 +7,8 @@
cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= 3.0.9),
lsb-release, patchutils, diffstat, xz-utils, python-dev,
libedit-dev, swig, python-six, python-sphinx, binutils-dev,
-libjsoncpp-dev,
-# ocaml-nox, libctypes-ocaml, ocaml-findlib, libctypes-ocaml-dev, dh-ocaml,
+libjsoncpp-dev, ocaml-nox, libctypes-ocaml, ocaml-findlib,
+libctypes-ocaml-dev, dh-ocaml,
lcov, procps, help2man, zlib1g-dev,
g++-multilib [amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel powerpc ppc64 s390 s390x sparc sparc64 x32]
Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, libllvm-3.5-ocaml-dev,
@@ -332,26 +332,26 @@
.
This package provides tools for testing.
-# Package: libllvm-3.8-ocaml-dev
-# Section: ocaml
-# Architecture: any
-# Suggests: llvm-3.8-doc
-# Depends: ${shlibs:Depends}, ${misc:Depends}, ${ocaml:Depends}, llvm-3.8-dev (= ${binary:Version})
-# Provides: ${ocaml:Provides}
-# Description: Modular compiler and toolchain technologies, OCaml bindings
-# LLVM is a collection of libraries and tools that make it easy to build
-# compilers, optimizers, just-in-time code generators, and many other
-# compiler-related programs.
-# .
-# LLVM uses a single, language-independent virtual instruction set both
-# as an offline code representation (to communicate code between
-# compiler phases and to run-time systems) and as the compiler internal
-# representation (to analyze and transform programs). This persistent
-# code representation allows a common set of sophisticated compiler
-# techniques to be applied at compile-time, link-time, install-time,
-# run-time, or "idle-time" (between program runs).
-# .
-# This package provides the OCaml bindings to develop applications using llvm.
+Package: libllvm-3.8-ocaml-dev
+Section: ocaml
+Architecture: any
+Suggests: llvm-3.8-doc
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${ocaml:Depends}, llvm-3.8-dev (= ${binary:Version})
+Provides: ${ocaml:Provides}
+Description: Modular compiler and toolchain technologies, OCaml bindings
+ LLVM is a collection of libraries and tools that make it easy to build
+ compilers, optimizers, just-in-time code generators, and many other
+ compiler-related programs.
+ .
+ LLVM uses a single, language-independent virtual instruction set both
+ as an offline code representation (to communicate code between
+ compiler phases and to run-time systems) and as the compiler internal
+ representation (to analyze and transform programs). This persistent
+ code representation allows a common set of sophisticated compiler
+ techniques to be applied at compile-time, link-time, install-time,
+ run-time, or "idle-time" (between program runs).
+ .
+ This package provides the OCaml bindings to develop applications using llvm.
Package: llvm-3.8-doc
Section: doc
Index: debian/rules
===
--- debian/rules (revision 2543)
+++ debian/rules (working copy)
Bug#873480: Confirmation and more information
Dear Maintainer, I can confirm this bug on my system. One-direction maximization stopped working between versions 3.6.1-4 and 3.6.1-5. On my system, I have the following mappings: - W-m toggles full maximization. - W-h toggles horizontal maximization. - W-v toggles vertical maximization. Here are the differences I noted since last upgrade: - W-h (or W-v) no more maximizes up to the edges of the screen, leaving a few pixels uncovered. - W-h W-h (or W-v W-v) does not restore original window size, window stays maximized. It looks like original height (or width) has been overwritten. - W-m W-h (or W-m W-v) does not de-maximize horizontally (or vertically), window stays fully maximized. Moreover, an additional W-m makes the window size vanish to nearly nothing (W-m W-h W-m results in the window having close to no width, W-m W-v W-m results in the window having close to no height). I suspect RPI patch de67618ea9e3e22e7623d56530934d3a3fc272e0 to be the culprit. Thanks for your help, Regards, -- "There is no reason for any individual to have a computer in his home." Ken Olsen, CEO of DEC, 1977 Cyril Soldani Email: cyril.sold...@ulg.ac.be Research Unit in Networking (RUN) Phone: +32 4 366 26 99 University of Liège Fax: +32 4 366 29 89 Institut Montefiore (B28, P32) Allée de la découverte 10, 4000 Liège, Belgium pgpFB7wK1n5BP.pgp Description: OpenPGP digital signature
