Bug#695970: bc: Should have a terminal launcher in menus
bc should have a launcher for a terminal with bc inside in menus Bc appears in the Debian menu under Applications-Science-Math. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635131: systemd: Creates user-writable directory under /run, /run/user
On 15.12.2012 01:18, Michael Biebl wrote: We can either: a/ hard code it and ship a run-user.mount unit in /lib/systemd/system b/ generate it dynamically upon installation and store the mount unit in /etc/systemd/system If a/, the question is which size we chose, if b/ which percentage of the available RAM we use. As for a/, we could ship a file like the attached one and a symlink in /lib/systemd/systemd/local-fs.target.wants/. That would be all that is needed. The options are taken from mountall. Generating it dynamically in postinst shouldn't be much harder. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? [Unit] Description=User Runtime Directory Before=local-fs.target [Mount] What=tmpfs Where=/run/user Type=tmpfs Options=nodev,noexec,nosuid,size=104857600,mode=0755 signature.asc Description: OpenPGP digital signature
Bug#695971: unblock: freetds/0.91-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package freetds, which fixes bug #645726, an issue that affects upgrades from squeeze to wheezy. This is not a release-critical bug in freetds, but having this fix in will likely make upgrades happier for users. There are no other changes in this version of the package. unblock freetds/0.91-2 -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 2.6.30-1-iop32x Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635131: systemd: Creates user-writable directory under /run, /run/user
On Sat, Dec 15, 2012 at 01:18:13AM +0100, Michael Biebl wrote: severity 635131 important thanks On 22.07.2011 23:27, Roger Leigh wrote: /run/user is created by systemd. This contains within it directories owned by logged in users e.g. /run/user/rleigh in my case, and the environment variable XDG_RUNTIME_DIR is set to this location. There are a few problems with this: 1) Any user can now trivially DoS the system by filling up /run. I think that is a valid problem and a possible solution would be to use a separate tmpfs for /run/user as long as we don't have quota support for tmpfs. mountall (upstart) goes this route and uses none /run/user tmpfs nodev,noexec,nosuid,size=104857600,mode=0755 0 0 in /lib/init/fstab. The only tricky part here is the size. We can either: a/ hard code it and ship a run-user.mount unit in /lib/systemd/system b/ generate it dynamically upon installation and store the mount unit in /etc/systemd/system If a/, the question is which size we chose, if b/ which percentage of the available RAM we use. As discussed on IRC last week, I still fail to see a valid reason for using the /run tmpfs for user data. While using yet another tmpfs mount somewhat mitigates the DoS issue, it doesn't address the question of why it really needs to be here in the first place. I would still prefer option c/ Use tmpfs Steve, I don't know if you've seen this bug previously, but it would be useful to have your input from the upstart POV. While the tmpfs issue is important, for me I think that point (2) in my original mail has rather wider-reaching implications regarding session management. I do not wish to cripple the basic session management we have e.g. with PAM by inheriting the restrictions of GNOME session management system wide. It's fundamentally broken, and I really object to having this pushed onto the base system by systemd. Debian is not just for desktop environments. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695972: mixxx: Problem installing docs
Package: mixxx Version: 1.10.1~dfsg0-1 Severity: minor Whilst installing mixxx: Selecting previously unselected package mixxx. Unpacking mixxx (from .../mixxx_1.10.1~dfsg0-1_amd64.deb) ... Processing triggers for doc-base ... Processing 1 added doc-base file... Error in `/usr/share/doc-base/mixxx', line 7: all `Format' sections are invalid. Note: `install-docs --verbose --check file_name' may give more details about the above error. # install-docs --verbose --check /usr/share/doc-base/mixxx Warning in `/usr/share/doc-base/mixxx', line 7: file mask `/usr/share/mixxx-data/Mixxx-Manual.pdf' does not match any files. Error in `/usr/share/doc-base/mixxx', line 7: all `Format' sections are invalid. /usr/share/doc-base/mixxx: Fatal error found, the file won't be registered. $ cat /usr/share/doc-base/mixxx Document: mixxx Title: Mixxx Digital Dj Abstract: Mixxx Manual Section: Sound Format: PDF Files: /usr/share/mixxx-data/Mixxx-Manual.pdf That last line should probably refer to /usr/share/doc/mixxx/Mixxx-Manual.pdf and maybe the /usr/share/doc-base/mixxx file should be in package mixxx instead of mixxx-data? -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (99, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.7.0 (SMP w/2 CPU cores) 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 mixxx depends on: ii libc6 2.13-37 ii libflac8 1.2.1-6 ii libgcc1 1:4.7.2-4 ii libgl1-mesa-glx [libgl1] 8.0.5-3 ii libglu1-mesa [libglu1]8.0.5-3 ii libid3tag00.15.1b-10 ii libmad0 0.15.1b-7 ii libogg0 1.3.0-4 ii libportaudio2 19+svn2021-1 ii libportmidi0 1:184-2 ii libqt4-network4:4.8.2+dfsg-4 ii libqt4-opengl 4:4.8.2+dfsg-4 ii libqt4-script 4:4.8.2+dfsg-4 ii libqt4-sql4:4.8.2+dfsg-4 ii libqt4-sql-sqlite 4:4.8.2+dfsg-4 ii libqt4-svg4:4.8.2+dfsg-4 ii libqt4-xml4:4.8.2+dfsg-4 ii libqt4-xmlpatterns4:4.8.2+dfsg-4 ii libqtcore44:4.8.2+dfsg-4 ii libqtgui4 4:4.8.2+dfsg-4 ii libqtwebkit4 2.2.1-5 ii libshout3 2.3.1-1 ii libsndfile1 1.0.25-5 ii libsoundtouch01.7.0-2 ii libstdc++64.7.2-4 ii libtag1c2a1.8-dmo1 ii libvorbis0a 1.3.2-1.3 ii libvorbisenc2 1.3.2-1.3 ii libvorbisfile31.3.2-1.3 ii mixxx-data1.10.1~dfsg0-1 mixxx recommends no packages. Versions of packages mixxx suggests: ii acroread [pdf-viewer] 9.5.1-dmo7 ii evince [pdf-viewer]3.4.0-3.1 ii gv [pdf-viewer]1:3.7.3.90-1 -- 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#635131: systemd: Creates user-writable directory under /run, /run/user
On Sat, Dec 15, 2012 at 12:39:13AM +, Roger Leigh wrote: As discussed on IRC last week, I still fail to see a valid reason for using the /run tmpfs for user data. While using yet another tmpfs mount somewhat mitigates the DoS issue, it doesn't address the question of why it really needs to be here in the first place. I would still prefer option c/ Use tmpfs Sorry, I meant use /tmp. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000
On Tue, 2012-12-11 at 20:16 +0100, Stefan Nagy wrote: I tested this some more by observing the output of 'acpi -a'. When my battery is low the values (percentage, time remaining) jump. Two minutes before my notebook suddenly shut down I got 00:05:00 minutes left, a few seconds later 00:04:34 minutes, then 00:04:46 minutes, 00:04:54 minutes… Two or three seconds before my notebook finally shut down I got 00:04:42 minutes left. For all this time percentage was at 2%. After plugging in the AC adaptor and booting up I got 4% and 00:04:53 minutes until charged (!). I disconnected the AC adaptor again – now I still had 4%, but just 00:00:15 seconds left. However, a few seconds later I got 00:29:31 minutes remaining again. If 'acpi' shows ACPI information (as the manpage states), ACPI information can't be correct. For me this seems to be a kernel bug. Is this a genuine HP or third party battery? Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
Bug#695634: linux-image-3.6-trunk-amd64: fails to execute action (hibernate) on critical battery condition - HP Folio 13-2000
Ben Hutchings wrote: Is this a genuine HP or third party battery? It's a genuin HP battery. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695823: mirror submission for 91.220.215.24
Please don't silently skip the other questions/remarks, like tracefile, as we really need it. After updating the mirror will be created tracefile. Then you may consider providing the mirror at /debian/ directly, the standard path used by most mirrors. Now you can get into open-source.homelane.me/debian/ Archive-upstream: mirror.yandex.ru Seems it is mirror.mephi.ru now (that you should reference as ftp.ru.debian.org) ok. fixed. Updates: twice Please 4 per day if possible, see http://www.debian.org/mirror/ftpmirror#when not possible :-( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693197: RFS: mozilla-gnome-keyring/0.6.5-1
Hi Ximin, I'm mostly interested in this change in 0.6.6-1: * Build separate libraries against both xulrunner-dev and icedove-dev. (Closes: #690324) So I can rebuild the extension for iceweasel/icedove 7. I see that the package now builds /usr/lib/xul-ext/gnome-keyring/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so /usr/lib/xul-ext/gnome-keyring/platform/Linux_x86_64-gcc3/components/libgnomekeyring.so How does this exactly work? How does the iceweasel extension know that it should load libgnomekeyring.so whereas the icedove extension should load libgnomekeyring-icedove.so? Just for fun, I've installed 0.6.6-1 and rm'ed libgnomekeyring-icedove.so, but icedove still started without errors and the extension seems to work without issues. What is this library then good for? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#695973: unblock: im-config/0.20
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package im-config * data/24_uim.rc Fix regression on uim for #683950 caused by the 0.19~pre1 fixing #694446. Closes: #695940 (critical) This prevents choking of the input method under X for slow PC. Moving GUI programs to the PHASE 2 initialization after dbus. This was my recent oversight doing 0.19 (unstable). Excuse me. * im-config Work around zenity bug for readable display under Japanese. Closes: #695939 (normal) This add 2 extra line breaks to the zenity --text-info dialog. Without these 2 extra line breaks, configuration dialog under Japanese is totally unreadable. At least this simple work around avoids hitting this bug. Considering the intended user, this is important to fix this. Risk is very very low. zenity bug: http://bugs.debian.org/695933 (important) * po files: updated to cope with message change in im-config Excluded from debdiff. * im-config.desktop Adjust desktop file to match the gnome-shell 3.4.1-8 behavior updated just around the wheezy freeze on 23 Jun 2012. This enables display of menu under GNOME3 (Menu was disabled when zenity was severely broken in May.) attached the debdiff against the package in testing. unblock im-config/0.20 -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru --exclude po im-config-0.19/data/24_uim.rc im-config-0.20/data/24_uim.rc --- im-config-0.19/data/24_uim.rc 2012-11-28 23:22:48.0 +0900 +++ im-config-0.20/data/24_uim.rc 2012-12-15 01:00:23.0 +0900 @@ -4,12 +4,6 @@ if [ $IM_CONFIG_PHASE = 2 ]; then # start uim-xim daemon /usr/bin/uim-xim -fi - -if [ $IM_CONFIG_PHASE = 1 ]; then -# set variables for the plain XIM -XMODIFIERS=@im=uim - # Starting GUI if [ -x /usr/bin/uim-toolbar-gtk3-systray ]; then uim-toolbar-gtk3-systray @@ -25,6 +19,12 @@ uim-toolbar-qt fi +fi + +if [ $IM_CONFIG_PHASE = 1 ]; then +# set variables for the plain XIM +XMODIFIERS=@im=uim + GTK_IM_MODULE=xim # use immodule only when available for both GTK 2.0 and 3.0 IM_CONFIG_MARKER2=0 diff -Nru --exclude po im-config-0.19/debian/changelog im-config-0.20/debian/changelog --- im-config-0.19/debian/changelog 2012-12-02 11:08:19.0 +0900 +++ im-config-0.20/debian/changelog 2012-12-15 11:25:30.0 +0900 @@ -1,3 +1,14 @@ +im-config (0.20) unstable; urgency=low + + * Fix regression on uim for #683950 caused by the 0.19~pre1 fixing +#694446. Closes: #695940 + * Adjust desktop file to match the gnome-shell 3.4.1-8 behavior +updated just around the wheezy freeze on 23 Jun 2012. + * Work around zenity bug for readable display under Japanese. +Closes: #695939 + + -- Osamu Aoki os...@debian.org Sat, 15 Dec 2012 11:25:11 +0900 + im-config (0.19) unstable; urgency=low * Uploading to unstable. diff -Nru --exclude po im-config-0.19/im-config im-config-0.20/im-config --- im-config-0.19/im-config 2012-05-15 23:06:29.0 +0900 +++ im-config-0.20/im-config 2012-12-15 11:16:45.0 +0900 @@ -201,7 +201,9 @@ fi IM_CONFIG_ACTIVE=missing IM_CONFIG_MSG=$(eval_gettext Removing the \$IM_CONFIG_XINPUTRC_TYPE \$IM_CONFIG_XINPUTRC.) -IM_CONFIG_RTFM=$(eval_gettext The \$IM_CONFIG_XINPUTRC_TYPE is modified by im-config. +IM_CONFIG_RTFM=$(eval_gettext +The \$IM_CONFIG_XINPUTRC_TYPE is modified by im-config. + Restart the X session to activate the new \$IM_CONFIG_XINPUTRC_TYPE. \$IM_CONFIG_RTFM) elif [ -z $IM_CONFIG_NAME ]; then @@ -218,7 +220,9 @@ fi IM_CONFIG_ACTIVE=$IM_CONFIG_NAME IM_CONFIG_MSG=$(eval_gettext Setting the \$IM_CONFIG_XINPUTRC_TYPE \$IM_CONFIG_XINPUTRC to \$IM_CONFIG_ACTIVE.) -IM_CONFIG_RTFM=$(eval_gettext The \$IM_CONFIG_XINPUTRC_TYPE is modified by im-config. +IM_CONFIG_RTFM=$(eval_gettext +The \$IM_CONFIG_XINPUTRC_TYPE is modified by im-config. + Restart the X session to activate the new \$IM_CONFIG_XINPUTRC_TYPE. \$IM_CONFIG_RTFM) fi diff -Nru --exclude po im-config-0.19/im-config.desktop im-config-0.20/im-config.desktop --- im-config-0.19/im-config.desktop 2012-05-14 23:35:47.0 +0900 +++ im-config-0.20/im-config.desktop 2012-12-15 10:18:58.0 +0900 @@ -19,4 +19,3 @@ Terminal=false Icon=input-keyboard Categories=Settings -NoDisplay=true signature.asc Description: Digital signature
Bug#695846: fixed mem overflow
tags 695846 fixed-upstream thanks See: http://refdb.svn.sourceforge.net/viewvc/refdb/refdb/trunk/src/risdb.c?r1=763r2=762pathrev=763 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695974: two missing manpages (adt-virt-schroot, adt-testreport-cronjob)
Package: autopkgtest Version: 2.2.3 Severity: minor seems to be the only ones... and even the cmdline name is suggestive -- $ adt-testreport-cronjob --help /usr/bin/adt-testreport-cronjob: line 9: cd: --: invalid option cd: usage: cd [-L|[-P [-e]]] [dir] since it is in public bin-space, might be nice if --help was informative -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages autopkgtest depends on: ii debhelper 9.20120608 ii python 2.7.3-3 Versions of packages autopkgtest recommends: ii apt-utils 0.9.7.2 ii pbuilder 0.211 Versions of packages autopkgtest suggests: pn autopkgtest-xenlvm none ii curl7.26.0-1 -- 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#684434: RFS: yamcha/0.33-1 [ITP] -- General purpose chunker annotator
Il 14/12/2012 19:36, Jakub Wilk ha scritto: * Giulio Paci giuliop...@gmail.com, 2012-12-13, 00:56: debian/patches/1002_manpages_fix.patch touches a file which starts with the following comment: .\ DO NOT MODIFY THIS FILE! It was generated by help2man 1.23. Fixed: now this patch does not alter man/yamcha.1 anymore. If it doesn't touch manpages anymore, perhaps it needs a better name? Name changed to 1002_documentation_fixes.patch Instead help2man is invoked at build time. I added: 1) helpman as build dependency; 2) a patch to fix update-man target in the man/Makefile.am; 3) code to invoke this target in debian/rules. Great. doc/yamcha.html looks like it was automatically generated from the manpage, although it's not up-to-date... Done the same as above for html. I added man2html as build dependency. Bests, Giulio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693197: RFS: mozilla-gnome-keyring/0.6.5-1
Hi again, On 15.12.2012 04:06, Michael Biebl wrote: Hi Ximin, I'm mostly interested in this change in 0.6.6-1: * Build separate libraries against both xulrunner-dev and icedove-dev. (Closes: #690324) So I can rebuild the extension for iceweasel/icedove 7. ^ 17, of course. I've just went ahead and tried that, by simply bumping the xulrunner-dev and icedove-dev b-deps to (= 17.0). The package built fine against those version and the resulting dependencies look ok also from a cursory glance: Depends: libc6 (= 2.4), libgcc1 (= 1:4.1.1), libglib2.0-0 (= 2.12.0), libgnome-keyring0 (= 3.2.2-2~), libnspr4 (= 2:4.9-2~) | libnspr4-0d (= 1.8.0.10), libstdc++6 (= 4.1.1), iceweasel (= 17.0) | icedove (= 17.0) Enhances: icedove, iceweasel Conflicts: iceape ( 2.0), iceweasel ( 3.0) Breaks: icedove ( 17.+), icedove ( 17.0), iceweasel ( 17.0) In Iceweasel 17 the (recompiled) plugin seems to work fine. When I restart Icedove, I get a dialog saying, that the gnome-keyring extension is not compatible with this version, though. Maybe my approach to bump the b-deps and recompile was too simple and no sufficient enough, but shouldn't the package rather fails to build in that case then to produce a binary which apparently doesn't work with Icedove 17. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695975: should have different release_pattern on wheezy
Package: devscripts Version: 2.12.6 Severity: normal File: /usr/bin/build-rdeps Tags: patch, wheezy build-rdeps is not useful out of the box on wheezy system since it would only provide a confusing message like: build-rdeps: unable to find sources files. Did you forget to run apt-get update (or add --update to this command)? that is because of $ grep release_pattern /usr/bin/build-rdeps my $release_pattern = '(.*_dists_(sid|unstable))_(?:In)*Release$'; which hard-coded the names. As a quick resolution geared toward wheezy it could be patched to become (wheezy|stable) (consider this a patch ;) ), but imho in the long run it should use lsb_release -rc output to determine possible choices for the default regexp expression. -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- DEBSIGN_KEYID=75C024C8 DEBUILD_ROOTCMD=fakeroot DEBUILD_DPKG_BUILDPACKAGE_OPTS=-i -ICVS -I.svn DEBUILD_LINTIAN=yes DSCVERIFY_KEYRINGS=~/.gnupg/pubring.gpg USCAN_SYMLINK=no USCAN_DESTDIR=~/deb/tarballs USCAN_SYMLINK=rename -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages devscripts depends on: ii dpkg-dev 1.16.9 ii libc6 2.13-33 ii perl 5.14.2-12 ii python2.7.3-3 Versions of packages devscripts recommends: ii at3.1.13-2 ii curl 7.26.0-1 ii dctrl-tools 2.22.2 ii debian-keyring2012.06.01 ii dput 0.9.6.3 ii dupload 2.7.0 ii equivs2.0.9 ii fakeroot 1.18.4-2 ii gnupg 1.4.12-4+b1 ii libcrypt-ssleay-perl 0.58-1 ii libdistro-info-perl 0.10 ii libjson-perl 2.53-1 ii libparse-debcontrol-perl 2.005-3 ii libsoap-lite-perl 0.714-1 ii liburi-perl 1.60-1 ii libwww-perl 6.04-1 ii lintian 2.5.10.3 ii man-db2.6.2-1 ii patch 2.6.1-3 ii patchutils0.3.2-1.1 ii python-debian 0.1.21 pn python-magic none ii sensible-utils0.0.7 ii strace4.5.20-2.3 ii unzip 6.0-7 ii wdiff 1.1.2-1 ii wget 1.13.4-3 ii xz-utils 5.1.1alpha+20120614-1 Versions of packages devscripts suggests: ii bsd-mailx [mailx]8.1.2-0.2006cvs-1 ii build-essential 11.5 pn cvs-buildpackage none pn devscripts-elnone ii gnuplot 4.6.0-8 ii libauthen-sasl-perl 2.1500-1 ii libfile-desktopentry-perl0.04-3 ii libnet-smtp-ssl-perl 1.01-3 ii libterm-size-perl0.207-1 ii libtimedate-perl 1.2000-1 ii libyaml-syck-perl1.20-1 ii mutt 1.5.21-6.2 ii openssh-client [ssh-client] 1:6.0p1-3 ii svn-buildpackage 0.8.5 ii w3m 0.5.3-8 -- 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#693197: RFS: mozilla-gnome-keyring/0.6.5-1
On 15.12.2012 04:06, Michael Biebl wrote: How does this exactly work? How does the iceweasel extension know that it should load libgnomekeyring.so whereas the icedove extension should load libgnomekeyring-icedove.so? nvm, found it in the mean time: the chrome.manifest maps the libraries to the corresponding apps by using the app-id. Just for fun, I've installed 0.6.6-1 and rm'ed libgnomekeyring-icedove.so, but icedove still started without errors and the extension seems to work without issues. What is this library then good for? Actually this a was a red herring. I still had the password in the icedove-internal keyring, that's why I still could login successfully. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#620748: [sisu-pdf] hyphenation problem building manual
Chals, * Ralph Amissah ralph.amis...@gmail.com [Tue, 05 Apr 2011 11:36:00 -0400], wrote: chals, thanks for the bug report (and sorry i missed you online yesterday) Line breaking and line-justification the smooth right text margin are determined by latex/texlive according to parameters it is given. The trick for us is to come up with a (generic) solution that works decently over as wide a body of documents as possible. To decide line-breaking, LaTeX uses: (a) the language setting; (b) a sloppy value; (c) additionally provided hyphenation points. There may be additional things, and I am not necessarily using the right LaTeX terminology. May I close this bug? (would mark done as of 3.1.0, I do not find that I tweaked the sloppy value though) Ralph signature.asc Description: Digital signature
Bug#695882: menu: su-to-root runs root applications using user's HOME, when SU_TO_ROOT_X=sux
On Fri, 14 Dec 2012 16:43:18 +0100, bill.allomb...@math.u-bordeaux1.fr wrote: Are you using systemd ? Nope, I'm using the good ol' sys-v init. I get this error when calling DISPLAY=:0 SU_TO_ROOT_X=sux su-to-root -X -c xterm and su-to-root -X will set SU_TO_ROOT_SU to sux by itself. I see that I should have DISPLAY=:0 along with the command SU_TO_ROOT_X=sux su- to-root -X -c. I always wondered why the terminal window that opens always indicate 'Using su...' instead of 'Using sux...' This is what I have observed prior to creating /etc/su-to-rootrc: ianp@sid:~$ SU_TO_ROOT_X=sux su-to-root -X -c xterm About to execute xterm. This command needs root privileges to be executed. Using su... Enter root password at prompt. Password: ianp@sid:~$ DISPLAY=:0 SU_TO_ROOT_X=sux su-to-root -X -c xterm About to execute xterm. This command needs root privileges to be executed. Using sux... Enter root password at prompt. Password: I paid little attention to the message, thinking that sux is a wrapper for su after all. So I have been running SU_TO_ROOT_X=sux su-to-root -X -c with su all this time. Learning as I move along. A quick question though: Why SU_TO_ROOT_X=gksu su-to-root -X -c runs with gksu, but SU_TO_ROOT_X=sux su-to-root -X -c runs with su instead of sux? I don't have /etc/su-to-rootrc. OK, I see what you report: by setting SU_TO_ROOT_SU=su, you force su-to-root to use su instead of sux, so you are actually using su, so you are bypassing the bug with su-to-root. Indeed I have been running su-to-root with su all this time, as I have only come to know just now. And we have found the bug with su-to-root using sux, but unfortunately not the bug I'm reporting about. Now to your report, it seems the su behaviour is correct, see the bug reports #246886 and #150314. Basically, if su reset $HOME, then X programs will fail to find the .Xauthority file. I have read through the bug reports you have indicated. These explain to me why su-to-root using su retains the user's $HOME. And this is where my bug report lies. Running root applications that is using the user's $HOME results in the creation of files/folders having root permissions. I encountered this undesired behavior with GSmartControl: ianp@sid:~$ cat /usr/share/applications/gsmartcontrol.desktop Exec=su-to-root -X -c gsmartcontrol Upon clicking on the GSmartControl menu entry, I am presented with a terminal window with the following messages: About to execute gsmartcontrol. This command needs root privileges to be executed. Using su... Enter root password at prompt. Password: This is prior to creating /etc/su-to-rootrc. Please remove SU_TO_ROOT_SU=su from your su-to-rootrc file and try the script in attachment which fix the bug with sux. I see that you made the following change to /usr/bin/su-to-root: - sux) suname=sux; pwuser=$PRIV; cmd='sux -p $PRIV -c $COMMAND';; + sux) suname=sux; pwuser=$PRIV; cmd='sux -p $PRIV $COMMAND';; And I can confirm that it fixes the bug with su-to-root using sux. Unfortunately and as expected, it is still the same undesired behavior as with su: root application is using user's $HOME. No /etc/su-to-rootrc. ianp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695965: gnome-shell crashes after restarting NetworkManager
On Fri, Dec 14, 2012 at 5:42 PM, Joel Diaz joeld...@earthlink.net wrote: Package: gnome-shell Version: 3.4.2-3 Severity: important Dear Maintainer, * What led up to the situation? Issued /etc/init.d/network-manager restart as root while logged into Gnome as a regular user. * What was the outcome of this action? gnome-shell process crashes then restarts. And of course NetworkManager restarts as well. * What outcome did you expect instead? I expect NetworkManager to restart without crashing gnome-shell. Looking at /var/log/messages while issuing '/etc/init.d/network-manager restart' shows: [ 100.511094] gnome-shell[3518]: segfault at 2bf9 ip 7f77c8c95132 sp 7fff17d07b20 error 4 in libgjs.so.0.0.0[7f77c8c75000+3b000] Retrying while attached to gnome-shell over gdb shows a failure at libgobject-2.0.so instead of libgjs.so above: (gdb) c Continuing. [New Thread 0x7f3a2e11b700 (LWP 4962)] [New Thread 0x7f3a2d711700 (LWP 4963)] [New Thread 0x7f3a2cd09700 (LWP 4964)] [New Thread 0x7f3a23ffe700 (LWP 4965)] [New Thread 0x7f3a21dff700 (LWP 4970)] [New Thread 0x7f3a163fc700 (LWP 4976)] [Thread 0x7f3a163fc700 (LWP 4976) exited] Program received signal SIGSEGV, Segmentation fault. 0x7f3a38af9ef0 in g_type_check_instance_cast () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 (gdb) bt #0 0x7f3a38af9ef0 in g_type_check_instance_cast () from /usr/lib/x86_64 -linux-gnu/libgobject-2.0.so.0 #1 0x7f3a41233ce6 in gjs_value_from_g_argument () from /usr/lib/libgjs.so.0 #2 0x7f3a41235159 in ?? () from /usr/lib/libgjs.so.0 #3 0x7f3a412341e5 in gjs_value_from_g_argument () from /usr/lib/libgjs.so.0 #4 0x7f3a4123a818 in ?? () from /usr/lib/libgjs.so.0 #5 0x7f3a4123abc0 in ?? () from /usr/lib/libgjs.so.0 #6 0x7f3a40d8a056 in ?? () from /usr/lib/libmozjs185.so.1.0 #7 0x7f3a40d73c0f in ?? () from /usr/lib/libmozjs185.so.1.0 #8 0x7f3a40d87f3f in ?? () from /usr/lib/libmozjs185.so.1.0 #9 0x7f3a40d89f3a in ?? () from /usr/lib/libmozjs185.so.1.0 #10 0x7f3a40d58bac in ?? () from /usr/lib/libmozjs185.so.1.0 #11 0x7f3a40d7de4e in ?? () from /usr/lib/libmozjs185.so.1.0 #12 0x7f3a40d87f3f in ?? () from /usr/lib/libmozjs185.so.1.0 #13 0x7f3a40d89f3a in ?? () from /usr/lib/libmozjs185.so.1.0 #14 0x7f3a40d58bac in ?? () from /usr/lib/libmozjs185.so.1.0 #15 0x7f3a40d7de4e in ?? () from /usr/lib/libmozjs185.so.1.0 #16 0x7f3a40d87f3f in ?? () from /usr/lib/libmozjs185.so.1.0 #17 0x7f3a40d89f3a in ?? () from /usr/lib/libmozjs185.so.1.0 #18 0x7f3a40d58bac in ?? () from /usr/lib/libmozjs185.so.1.0 #19 0x7f3a40d7de4e in ?? () from /usr/lib/libmozjs185.so.1.0 #20 0x7f3a40d87f3f in ?? () from /usr/lib/libmozjs185.so.1.0 #21 0x7f3a40d89f3a in ?? () from /usr/lib/libmozjs185.so.1.0 #22 0x7f3a40d583b4 in ?? () from /usr/lib/libmozjs185.so.1.0 #23 0x7f3a40d89cfb in ?? () from /usr/lib/libmozjs185.so.1.0 #24 0x7f3a40d8a414 in ?? () from /usr/lib/libmozjs185.so.1.0 #25 0x7f3a40cff8e4 in JS_CallFunctionValue () from /usr/lib/libmozjs185.so.1.0 #26 0x7f3a4122ce4c in gjs_call_function_value () from /usr/lib/libgjs.so.0 #27 0x7f3a41237cad in gjs_closure_invoke () from /usr/lib/libgjs.so.0 #28 0x7f3a412435f9 in ?? () from /usr/lib/libgjs.so.0 #29 0x7f3a38ad86e0 in g_closure_invoke () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #30 0x7f3a38ae9750 in ?? () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #31 0x7f3a38af16bc in g_signal_emit_valist () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #32 0x7f3a38af1852 in g_signal_emit () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #33 0x7f3a38add085 in ?? () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #34 0x7f3a38ade96b in g_object_notify () from /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #35 0x7f3a3dc466fb in ?? () from /usr/lib/libnm-glib.so.4 #36 0x7f3a38819355 in g_main_context_dispatch () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #37 0x7f3a38819688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #38 0x7f3a38819a82 in g_main_loop_run () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #39 0x7f3a414a9f27 in meta_run () from /usr/lib/libmutter.so.0 #40 0x00401e77 in main () -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii gconf-service3.2.5-1+build1 ii gir1.2-accountsservice-1.0 0.6.21-7 ii gir1.2-atk-1.0 2.4.0-2 ii gir1.2-caribou-1.0
Bug#695976: postgis: shp2pgsql segfault
Package: postgis
Version: 1.5.1-5
Severity: important
On running shp2pgsql on a particular data set, a segfault occurs.
$ ls
nsw.dbf nsw.shp nsw.shx
$ shp2pgsql nsw
Shapefile type: Polygon
Postgis type: MULTIPOLYGON[2]
SET CLIENT_ENCODING TO UTF8;
SET STANDARD_CONFORMING_STRINGS TO ON;
BEGIN;
CREATE TABLE nsw (gid serial PRIMARY KEY,
mb_code11 varchar(11),
mb_cat11 varchar(50),
sa1_main11 varchar(11),
sa1_7dig11 varchar(7),
sa2_main11 varchar(9),
sa2_5dig11 varchar(5),
sa2_name11 varchar(50),
sa3_code11 varchar(5),
sa3_name11 varchar(50),
sa4_code11 varchar(3),
sa4_name11 varchar(50),
gcc_code11 varchar(5),
gcc_name11 varchar(50),
ste_code11 varchar(1),
ste_name11 varchar(50),
albers_sqm numeric);
SELECT AddGeometryColumn('','nsw','the_geom','-1','MULTIPOLYGON',2);
INSERT INTO nsw
(mb_code11,mb_cat11,sa1_main11,sa1_7dig11,sa2_main11,sa2_5dig11,sa2_name11,sa3_code11,sa3_name11,sa4_code11,sa4_name11,gcc_code11,gcc_name11,ste_code11,ste_name11,albers_sqm,the_geom)
VALUES
('1009499','NOUSUALRESIDENCE','194','194','19499','19499','No
usual address (NSW)','1','Special Purpose Codes SA3
(NSW)','199','Special Purpose Codes SA4 (NSW)','19499','No usual address
(NSW)','1','New South Wales','0',NULLp�t ');
Segmentation fault
-- System Information:
Debian Release: 6.0.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.39.1-linode34 (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 postgis depends on:
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii libpq5 8.4.13-0squeeze1 PostgreSQL C client library
postgis recommends no packages.
Versions of packages postgis suggests:
pn postgresql-8.4-postgisnone (no description available)
-- no debconf information
nsw.dbf
Description: Binary data
nsw.shp
Description: Binary data
nsw.shx
Description: application/empty
Bug#695976: postgis: shp2pgsql segfault
Your attached shx file is empty as such, .shx file is unreadable, or corrupt. nsw: shape (.shp) or index files (.shx) can not be opened, will just import attribute data. which runs fine. signature.asc Description: OpenPGP digital signature
Bug#635131: systemd: Creates user-writable directory under /run, /run/user
On Sat, Dec 15, 2012 at 12:39:13AM +, Roger Leigh wrote: /run/user is created by systemd. This contains within it directories owned by logged in users e.g. /run/user/rleigh in my case, and the environment variable XDG_RUNTIME_DIR is set to this location. There are a few problems with this: 1) Any user can now trivially DoS the system by filling up /run. I think that is a valid problem and a possible solution would be to use a separate tmpfs for /run/user as long as we don't have quota support for tmpfs. mountall (upstart) goes this route and uses none /run/user tmpfs nodev,noexec,nosuid,size=104857600,mode=0755 0 0 in /lib/init/fstab. The only tricky part here is the size. We can either: a/ hard code it and ship a run-user.mount unit in /lib/systemd/system b/ generate it dynamically upon installation and store the mount unit in /etc/systemd/system If a/, the question is which size we chose, if b/ which percentage of the available RAM we use. As discussed on IRC last week, I still fail to see a valid reason for using the /run tmpfs for user data. While using yet another tmpfs mount somewhat mitigates the DoS issue, it doesn't address the question of why it really needs to be here in the first place. I would still prefer option c/ Use [/tmp] Steve, I don't know if you've seen this bug previously, but it would be useful to have your input from the upstart POV. While the tmpfs issue is important, for me I think that point (2) in my original mail has rather wider-reaching implications regarding session management. I do not wish to cripple the basic session management we have e.g. with PAM by inheriting the restrictions of GNOME session management system wide. It's fundamentally broken, and I really object to having this pushed onto the base system by systemd. Debian is not just for desktop environments. upstart itself is agnostic on this question. The mountall package mounts /run/user by default in support of the XDG runtime dir spec, which requires a per-user directory which is guaranteed to be: - local - shared across all sessions for the user on the system - cleaned at boot - secure, and only accessible to the owning user There is no existing path on the system that's guaranteed to have these characteristics. /home is not guaranteed to be local; /tmp is not guaranteed to be cleaned at boot, nor is there a guaranteed secure way to create a directory there that's discoverable by all possible unrelated sessions for the user. So the only way to fulfill the XDG requirements is by creating a new directory structure with new properties. If you think the XDG requirements are /wrong/, please take that up with the XDG folks... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#675175: some more systemd-196 notes, initramfs
For anyone who might be wanting to try systemd-196, there will also need to be some changes to the udev package contribution to the initramfs-tools. Without a few revisions, the first time the /boot/initrd.img-version file is regenerated, the system will not boot. Hopefully, you have an older version /boot/initrd.img-version file in the grub menu you can use to recover, if necessary. Once the root file system is mounted and systemd is started, from switch_root, then everything else will run, even if the /boot/initrd.img-version file being used was generated with older versions of systemd and udev. First, the udev files udevd and udevadm, originally in /sbin, must be linked to the new files, sudo ln -s /bin/udevadm /sbin/udevadm sudo ln -s /usr/lib/systemd/systemd-udevd /sbin/udevd And second, a symbolic link must be created in the initram file system generated - because the files /bin/udevadm and /usr/lib/systemd/systemd-udevd have been hard-coded to use /usr/lib instead of /lib. This can be done by adding some commands to the file /usr/share/initramfs-tools/hooks/udev, from the udev package, ... copy_exec /sbin/udevd /sbin copy_exec /sbin/udevadm/sbin + mkdir -p $DESTDIR/usr/lib + ln -s /lib/udev $DESTDIR/usr/lib/udev ... Then run update-initramfs -u. The initrd.img-... file generated seems to work now. Mind you, I have only done this on a non-encrypted, non-lvm, and local file system, but it works. James -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695977: unblock: fontconfig/2.9.0-7.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package fontconfig. The only change is a documentation one that fixes #684923 (RC). unblock fontconfig/2.9.0-7.1 diff -Nru fontconfig-2.9.0/debian/changelog fontconfig-2.9.0/debian/changelog --- fontconfig-2.9.0/debian/changelog 2012-07-25 17:52:32.0 +0200 +++ fontconfig-2.9.0/debian/changelog 2012-12-11 15:11:19.0 +0100 @@ -1,3 +1,14 @@ +fontconfig (2.9.0-7.1) unstable; urgency=low + + * Non-maintainer upload. + * Update README.Debian with respect to enabling bitmapped fonts: just +removing the no-bitmaps.conf symlink is not enough, the corresponding +symlink for yes-bitmaps.conf needs to be added too. +Thanks to Andreas Metzler ametz...@debian.org for the patch. +Closes: #684923. + + -- intrigeri intrig...@debian.org Tue, 11 Dec 2012 15:09:54 +0100 + fontconfig (2.9.0-7) unstable; urgency=low * Don't clean ancient cache files on new install. Closes: #636173. diff -Nru fontconfig-2.9.0/debian/README.Debian fontconfig-2.9.0/debian/README.Debian --- fontconfig-2.9.0/debian/README.Debian 2012-04-16 20:35:08.0 +0200 +++ fontconfig-2.9.0/debian/README.Debian 2012-12-11 22:49:29.0 +0100 @@ -3,9 +3,14 @@ Recently, fontconfig changed to not include bitmapped fonts in the default font set. There is now a Debconf question about this. -If you wish to enable bitmapped fonts manually, either reconfigure this -package (with dpkg-reconfigure fontconfig-config), or remove the -symbolic link /etc/fonts/conf.d/30-debconf-no-bitmaps.conf +If you wish to enable bitmapped fonts manually, either reconfigure +fontconfig-config (with dpkg-reconfigure fontconfig-config), or remove the +/etc/fonts/conf.d/70-no-bitmaps.conf symbolic link and add a symlink named +70-yes-bitmaps.conf pointing to ../conf.avail/70-yes-bitmaps.conf: + + cd /etc/fonts/conf.d \ +rm -f 70-no-bitmaps.conf \ +ln -s ../conf.avail/70-yes-bitmaps.conf *
Bug#691115: unblock libdvdread/4.2.0+20120521-3
Hi, Dmitry Smirnov wrote (12 Dec 2012 22:40:05 GMT) : On Wed, 12 Dec 2012 21:30:14 intrigeri wrote: Dmitry Smirnov wrote (12 Dec 2012 01:16:15 GMT) : There were no reply from maintainer in #688574 so perhaps it would be better to set Daniel as owner of this bug... Please do it if you feel it's useful. Waht would you do? If there was a bug I really wanted to see fixed in Wheezy, I would 1. talk to the maintainer and possibly 2. prepare an upload for t-p-u. Given the crash fixed by 4.2.0+20120521-3 has severity normal, I'm unsure it's worth the effort. I'm not sure if normal is an adequate severity for crash. I've no idea how far the implications go, so I have no opinion on this matter. I'd like to hear the maintainer's opinion. Daniel, what do you think? (You might want to read #691115 first, to get some context.) For example handbrake (not in testing) was unusable (crashing on DVD open) with libdvdread prior to 4.2.0+20120521-3. The effects of this bug on a package that is not in testing is hardly relevant to the requested unblock. Please find a more relevant example to illustrate the case :) Dmitry, you filed the unblock request that is now outdated, what do you think? We can close it if you think that's the right thing to do. What else we can do? If it's worth it, going through t-p-u might be an option. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695979: reports Py_ENABLE_SHARED as 0
Package: python2.7-minimal
Version: 2.7.3~rc2-2.1
Severity: normal
python -c import distutils.sysconfig;
print(distutils.sysconfig.get_config_var('Py_ENABLE_SHARED'))
prints 0, but should print 1, because a shared library is built.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695980: please use signed git tags in the packaging repo
Package: unburden-home-dir Version: 0.3.1.2 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Axel, could you please use signed git tags in the packaging repo? I wanted to build from your git repo and have no other mean to verify the authenticity of what I cloned. Thank you! Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQzBnWAAoJEAf8SJEEK6Za1Q4QAJWImUaJg0P9a6XEC8b9fk6K tUSPOGDO7JSHM1ubFOWa0X5OtEi4TeTVrjn6KCBqsSYTgUcqQgmDRqc0sfFVlEgP OXmPSzJ7s8PPjb5iFcifFUXY7SppHJ0X0f9ntHQC7fhnZgxQfzonh+fMN/6MxWca HX8spBVyNJwirqqmo4y8Q2Sr94P5+FA1smL9rU4eHb2G3wu0RImIUGxdvg/p1Vl1 iEYnPW69meYqvrxb8aKgm9IWnmMtySd5ugKFBTVAPNcAOn5p7pV+2gm20gpENn7H vFEPIX4TbcLxdqxx2OsECd11BMHFn2zfJ6jaVZeD4n9/57UIlpjCd5z0xbACDA1b PZ7UVf5zbMD3NZPYPvWwTDMyLz88+qPXVlVOnPRenMiQa3lctO97zVB9VCOmBwEG 1ngTGI4LsWwguzBeeaII4SKtnaOi+jso8YHnhpiSRY3eG4WQv+dt8trdV7FLU9Qn Fg+g3ZPNZmmj5lzJuRBLdEle7oRmBtTRnKIpOdmx4NOETymgRjvCERhmaj5H11do VcmZBQ764RDb7MRUMwp/hxZYsx9ZKgcm1n7OOibUMst09Swuey76/KIH+l+vNdmT fsHAoWxNM58TmfD4nEzaqxlarkN5J6FTrL4LnPG9Q5NeIHv+VS8SkVXtuIWXSn+h yEPRBMPQD+/OxRGouDQW =tmLU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695981: again reserved work when upgrading to wheeze openshot
Package: openshot Version: 1.4.2-1.1 Severity: important when upgrading from squeeze to wheeze i have this error due (stupid again and again) python undecided api: /usr/lib/pymodules/python2.5/openshot/uploads/vimeo/convenience.py:84: Warning: 'with' will become a reserved keyword in Python 2.6 Compiling /usr/lib/pymodules/python2.5/openshot/uploads/vimeo/convenience.py ... File /usr/lib/pymodules/python2.5/openshot/uploads/vimeo/convenience.py, line 84 with open(file_path) as video: due wheeze are freeze now, searching i note that the problem are historically easy to fix, but currently the X python version i dont know how to setup due python 2.6 to 2.7 transition must be early for that! see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614174#39 due -- System Information: Debian Release: squeeze APT prefers stable APT policy: (500, 'stable') Architecture: i386 Kernel: Linux 3.3.6 (SMP w/2 CPU cores) Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openshot depends on: ii fontconfig 2.8.0-3 ii gtk2-engines-pixbuf 2.24.10-1 ii librsvg2-common 2.26.3-1 ii melt 1:0.6.2-1 ii python 2.6.6-3+squeeze3 ii python-gtk2 2.17.0-3 ii python-httplib2 0.6.0-4 ii python-imaging 1.1.7-2 ii python-mlt3 1:0.6.2-1 ii python-support 1.0.10 ii python-xdg 0.19-2 Versions of packages openshot recommends: ii frei0r-plugins 1.1.22git20091109-1.2 ii openshot-doc1.4.2-1 Versions of packages openshot suggests: pn blender 2.63-1 pn inkscape none -- no debconf information -- Lenz McKAY Gerardo (PICCORO) http://qglochekone.blogspot.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695976: postgis: shp2pgsql segfault
On Sat, Dec 15, 2012 at 4:37 PM, Andrew Harvey andrew.harv...@gmail.com wrote: Your attached shx file is empty as such, That empty shx file is part of the setup. It does not segfault if the file does not exist. Could you confirm that you tried it with all three files as attached? I was trying to create a minimal example, and found that an empty shx file still reproduced the problem. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695976: postgis: shp2pgsql segfault
On 15/12/12 17:34, Thomas Chung wrote:
On Sat, Dec 15, 2012 at 4:37 PM, Andrew Harvey andrew.harv...@gmail.com
wrote:
Your attached shx file is empty as such,
That empty shx file is part of the setup. It does not segfault if the
file does not exist. Could you confirm that you tried it with all
three files as attached?
I was trying to create a minimal example, and found that an empty shx
file still reproduced the problem.
Thomas
Yep. Used,
those files with md5sums of
60c1d5f7a6a36728b88db947359757ba nsw.dbf
4b7c97864fdf18acd2bbe0af0d897f7c nsw.shp
d41d8cd98f00b204e9800998ecf8427e nsw.shx
and running
shp2pgsql nsw
gives attached results.
Using postgis package 1.5.3-2 (unstable)
.shx file is unreadable, or corrupt.
nsw: shape (.shp) or index files (.shx) can not be opened, will just import
attribute data.
SET CLIENT_ENCODING TO UTF8;
SET STANDARD_CONFORMING_STRINGS TO ON;
BEGIN;
CREATE TABLE nsw (gid serial PRIMARY KEY,
mb_code11 varchar(11),
mb_cat11 varchar(50),
sa1_main11 varchar(11),
sa1_7dig11 varchar(7),
sa2_main11 varchar(9),
sa2_5dig11 varchar(5),
sa2_name11 varchar(50),
sa3_code11 varchar(5),
sa3_name11 varchar(50),
sa4_code11 varchar(3),
sa4_name11 varchar(50),
gcc_code11 varchar(5),
gcc_name11 varchar(50),
ste_code11 varchar(1),
ste_name11 varchar(50),
albers_sqm numeric);
INSERT INTO nsw
(mb_code11,mb_cat11,sa1_main11,sa1_7dig11,sa2_main11,sa2_5dig11,sa2_name11,sa3_code11,sa3_name11,sa4_code11,sa4_name11,gcc_code11,gcc_name11,ste_code11,ste_name11,albers_sqm)
VALUES
('1009499','NOUSUALRESIDENCE','194','194','19499','19499','No
usual address (NSW)','1','Special Purpose Codes SA3 (NSW)','199','Special
Purpose Codes SA4 (NSW)','19499','No usual address (NSW)','1','New South
Wales',NULL);
COMMIT;
signature.asc
Description: OpenPGP digital signature
Bug#694518: [BTS#694518] templates://sheepdog/{sheepdog.templates} : Final update for English review
Dear Debian maintainer,
On Saturday, December 01, 2012, I notified you of the beginning of a review
process
concerning debconf templates for sheepdog.
The debian-l10n-english contributors have now reviewed these templates,
and the final proposed changes are attached to this update to the
original bug report.
Please review the suggested changes, and if you have any
objections, let me know in the next 3 days.
However, please try to avoid uploading sheepdog with these changes
right now.
The second phase of this process will begin on Tuesday, December 18, 2012, when
I will
coordinate updates to translations of debconf templates.
The existing translators will be notified of the changes: they will
receive an updated PO file for their language.
Simultaneously, a general call for new translations will be sent to
the debian-i18n mailing list.
Both these calls for translations will request updates to be sent as
individual bug reports. That will probably trigger a lot of bug
reports against your package, but these should be easier to deal with.
The call for translation updates and new translations will run until
about Tuesday, January 08, 2013. Please avoid uploading a package with fixed or
changed
debconf templates and/or translation updates in the meantime. Of
course, other changes are safe.
Please note that this is an approximative delay, which depends on my
own availability to process this work and is influenced by the fact
that I simultaneously work on many packages.
Around Wednesday, January 09, 2013, I will contact you again and will send a
final patch
summarizing all the updates (changes to debconf templates,
updates to debconf translations and new debconf translations).
Again, thanks for your attention and cooperation.
--
# These templates have been reviewed by the debian-l10n-english
# team
#
# If modifications/additions/rewording are needed, please ask
# debian-l10n-engl...@lists.debian.org for advice.
#
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.
Template: sheepdog/start
Type: boolean
Default: true
_Description: Automatically start the sheepdog service?
Please choose whether the sheepdog service should start automatically
when the system is booted.
Template: sheepdog/daemon_args
Type: string
Default:
_Description: Arguments for the sheepdog daemon:
Please choose the command line arguments that should be passed to the
sheepdog daemon. If no argument is given, the default behavior is to
start on port 7000, using the corosync driver.
.
Available options include:
-p, --port specify the TCP port to listen to
-l, --loglevel specify the level of logging detail
-d, --debug include debug messages in the log
-D, --directio use direct I/O when accessing the object store
-z, --zone specify the zone ID
-c, --cluster specify the cluster driver
More information can be found in the sheep(8) manual page.
Source: sheepdog
Section: admin
Priority: optional
Maintainer: PKG OpenStack openstack-de...@lists.alioth.debian.org
Uploaders: YunQiang Su wzss...@gmail.com, Guido Guenther a...@debian.org
Build-Depends: debhelper (= 7.0.50~),
dh-autoreconf,
bash-completion,
pkg-config,
libcorosync-dev,
liburcu-dev,
libzookeeper-mt-dev [linux-any],
po-debconf
Standards-Version: 3.9.4.0
Homepage: http://www.osrg.net/sheepdog/
Vcs-Browser: http://git.debian.org/?p=openstack/sheepdog.git
Vcs-Git: git://git.debian.org/openstack/sheepdog.git
Package: sheepdog
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Recommends: corosync
Description: distributed storage system for KVM/QEMU
Sheepdog provides highly available block level storage volumes that can be
attached to KVM/QEMU virtual machines. Sheepdog scales to several hundred
nodes, and supports advanced volume management features such as snapshots,
cloning, and thin provisioning.
--- sheepdog.old/debian/sheepdog.templates 2012-11-27 06:58:04.783934869
+0100
+++ sheepdog/debian/sheepdog.templates 2012-12-15 08:10:05.581694814 +0100
@@ -1,22 +1,32 @@
+# These templates have been reviewed by the debian-l10n-english
+# team
+#
+# If modifications/additions/rewording are needed, please ask
+# debian-l10n-engl...@lists.debian.org for advice.
+#
+# Even minor modifications require translation updates and such
+# changes should be coordinated with translators and reviewers.
+
Template: sheepdog/start
Type: boolean
Default: true
-_Description: Automatic start sheepdog service?
- You can set this to false to make sheepdog service doesn't
- start automaticly if you need.
+_Description: Automatically start the sheepdog service?
+ Please choose whether the sheepdog service should start automatically
+ when the system is booted.
Template: sheepdog/daemon_args
Type: string
Default:
-_Description: The arguments passed when start service:
- The default behavior with no
Bug#506861: python-debian: support data.tar.xz member
Hi! On Fri, 2012-06-29 at 00:57:03 +0100, Stuart Prescott wrote: For python 3.3, the unxz utility from the xz-utils package is used to decompress the member which is then fed into the python tarfile module as would be done for gz or bz2 members. This is crude but works fine. Perhaps python- debian and python3-debian (until python 3.3 at least) should Recommend xz- utils as a result. Perhaps better error handling around the subprocess would be advisable for the absence of unxz(1) on the system. I think this should really be fixed for wheezy, as there's an increasing number of .xz compressed binary packages in the archive already, not doing so will mean python-debian is not usable there. diff --git a/lib/debian/debfile.py b/lib/debian/debfile.py index a728a77..84b88aa 100644 --- a/lib/debian/debfile.py +++ b/lib/debian/debfile.py @@ -27,7 +28,7 @@ from debian.deb822 import Deb822 DATA_PART = 'data.tar' # w/o extension CTRL_PART = 'control.tar' -PART_EXTS = ['gz', 'bz2'] # possible extensions +PART_EXTS = ['gz', 'bz2', 'xz'] # possible extensions I guess it would make sense to handle .lzma compressed members too, as dpkg-deb has supported generating those up to now, they might be found in the wild, although creating new such .debs has been deprecated, but that still does not make existing packages disappear, so at least dpkg-deb will continue supporting extraction for the forseeable future. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688772: gnome Depends network-manager-gnome
]] Steve Langasek And by the way, if you're going to treat it as a serious bug, you'd better get filing other bugs for consistency. Just off the top of my head, base-passwd has had the same handling of /etc/passwd for *years* without anyone objecting. To me, this is very clearly a matter of moving the goal posts. I file those bugs whenever I see them and has been doing this for a while. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558784 for another example. It's not ok to replace a config file just because it has a syntax error in it, is it? Also, see below. Replace, no. Repair, maybe. I don't think it should do that, it should notify the admin. Trying to guess the intentions of admins is not particularly easy. When ifupdown recreates the file, it populates it only with a config for lo. I don't think it's reasonable to claim that it's valid and intentional to configure a system in such a way that it will fail to bring up the loopback interface on boot. In fact, booting the system without lo breaks so many assumptions that Ubuntu, for example, *unconditionally* brings up lo on boot, whether or not it's configured in /etc/network/interfaces. I consider restoring a stock /e/n/i on package upgrade to be in the same category. Putting «iface lo» into /etc/network/interfaces is not only a way to ensure there is a loopback interface on boot. It's also a way for ifupdown to claim to handle that interface (this is a natural consequence of the CTTE ruling; that ifupdown is special and has precedence and other tools should stay away from interfaces where there is a ifupdown configuration for the interface), so if ifupdown does add that configuration, there is no way for me to have ifupdown installed so I can read the man page at the same time as letting other tools manage lo. I don't see where the previous TC ruling says that ifupdown is special. Rather, it says that upgrading gnome-core shouldn't cause network-manager to clobber the user's network preferences on upgrade, /whichever/ tool they were using to manage those. I did explicitly say it was a natural consequence of the ruling, not that the ruling itself said so. The alternative is for the relation to be symmetrical, so ifupdown should stay away from managing interfaces where there exists a NM config for the interface without there existing an explicit configuration for the ifupdown interface? It's easy enough to generate such a configuration by using mappings, for instance. This becomes a nightmare once you drag wicd into this and all tools need to know about what other tools might want to manage an interface. I think it's important that we end up with something that's actually supportable, rather than something which might be formally better, but in practice so complex it becomes brittle beyond repair. That should be trivially easy in the case of lo. If the /e/n/i entry for lo is missing, or matches this: iface lo inet loopback ... it's fair game. If it's something else, then /against all reason/, the user has configured lo in a non-standard way, and NM should respect that. So I don't think this bug in ifupdown in any way blocks NM from being able to do the right thing. If you disagree, let's explore this further. I don't think I've said it blocks NM from doing the right thing. I've said it's a bug in ifupdown. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695904: unblock: mediawiki/1:1.19.3-1
Control: tags -1 moreinfo On 2012-12-14 09:18, Dominik George wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package mediawiki. The unblock would fix security-relevant RC bug #694998 . The unblock has been discussed and approved by Niels Thykier on d-r@l.d.o beforehand. unblock mediawiki/1:1.19.3-1 [...] Hi, I noticed a couple of changes I don't remember seeing in the diff sent to the list. Namely, * debian/patches/bz29635.patch * debian/patches/fix_invalid_xhtml.patch * debian/control (dependency update) Nor are these mentionen in the changelog. If they were extra bugs you fixed just prior to the upload, then please mention that you did additional changes since we approved it (and why). If they were unintended for Wheezy, please undo them. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695145:
reported upstream. Patch there as well https://sourceforge.net/tracker/?func=detailaid=3596229group_id=269812atid=1147701 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
