Bug#688603: mlterm: diff for NMU version 3.1.2-1.2
On 2012-09-28 08:25 +0200, أحمد المحمودي wrote: > On Fri, Sep 28, 2012 at 08:54:30AM +0900, Kenshi Muto wrote: >> mlterm is mostly maintained by Ahmed. >> Ahmed, could you tell me what you think about? > > Well, it is the same fix that was done in 3.1.2-1.1 for mlterm & > mlterm.tiny > > Yet I think it is better to do the fix in .preinst instead of > .postinst as the file attached. > > Note that I didn't test that fix yet. I am afraid that your proposed fix will not work correctly. > #!/bin/sh > set -e > > case "$1" in > install|upgrade) > if dpkg --compare-versions "$2" lt "3.0.9" ; then People who had already upgraded from earlier versions will still have an empty directory, so the version should be adjusted. > rmdir /usr/share/doc/mlterm The directory is not guaranteed to be empty at this time. Also, you want to protect this with "|| true" to make the script idempotent (see Policy §6.2). Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688580: xonix: Crash with double freeing memory
On 2012-09-24 00:56, Tim wrote: | Package: xonix | Version: 1.4-26 | Severity: important | | When a game was ended, xonix is crashed on double freeing memory. | I am not sure, but it seems this behaviour can be related with fail of a | reading the scores file. | | This is an output: | tim@station:~$ xonix | xonix: cannot reopen high score file | *** glibc detected *** xonix: double free or corruption (fasttop): 0x09750168 Hi Tim, Would you test with this version and let me know if the bug still exists: # Select one for your arch wget http://cante.net/~jaalto/tmp/debian/xonix/xonix_1.4-30_amd64.deb wget http://cante.net/~jaalto/tmp/debian/xonix/xonix_1.4-30_i386.deb dpkg -i xonix*.deb thanks, Jari -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542258: enblend-enfuse: embeds the VIGRA library
On 2012-09-29 Andreas Metzler wrote: > OTOH libvigraimpex has been orphaned in Debian (#587063). There is some good news, though: An updated version (1.8.0+dfsg-0ubuntu2) has been uploaded to Ubuntu a couple of days ago. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689101: etckeeper confused by GIT_DIR and GIT_WORK_TREE environment variables
Package: etckeeper Version: 0.48 If etckeeper is using git as its VCS, setting the GIT_DIR or GIT_WORK_TREE environment variables can lead to etckeeper using a repository other than /etc/.git or a working directory other than /etc. This should be easily fixed by sanitizing those variables before calling git. Here's an example where I set GIT_DIR to point to the nagios-plugins git repository: root@host:~/git# git clone git:// github.com/nagios-plugins/nagios-plugins.git Cloning into nagios-plugins... [...clone completes...] Resolving deltas: 100% (10894/10894), done. root@host:~/git# etckeeper vcs log | head -5# correct result commit d2aed14f26b083aa9a29b741365776e16eabdb6f Author: root Date: Fri Sep 28 22:40:27 2012 -0700 Initial commit root@host:~/git# export GIT_DIR=/root/git/nagios-plugins/.git root@host:~/git# etckeeper vcs log | head -5 # wrong commit 05c4c9bfc649ba8f66e470667824200c2cda5314 Merge: c5583ab 2672e95 Author: Sven Nierlein Date: Tue Sep 25 07:48:14 2012 -0700 This can really create a mess if, say, I've set GIT_DIR during some development work unrelated to /etc and happen to use apt-get to install a package: root@host:~/git# apt-get install linuxlogo [linuxlogo installs, then etckeeper makes commits to /root/git/nagios-plugins/.git which replace the nagios-plugins files with the contents of /etc] root@host:~/git# git log | head -20 commit 493cf79c6e7726d974e468a9fcada45755de6b3e Author: root Date: Fri Sep 28 23:10:15 2012 -0700 committing changes in /etc after apt run Package changes: commit 0fd04d9aec990189180ed421344a551238bc49ba Author: root Date: Fri Sep 28 23:10:13 2012 -0700 saving uncommitted changes in /etc prior to apt run commit 05c4c9bfc649ba8f66e470667824200c2cda5314 Merge: c5583ab 2672e95 Author: Sven Nierlein Date: Tue Sep 25 07:48:14 2012 -0700 Merge pull request #19 from gvarisco/patch-1 Here's a less dramatic example with GIT_WORK_TREE set: root@host:~/git# unset GIT_DIR root@host:~/git# etckeeper vcs log | head -5 # back to normal commit d2aed14f26b083aa9a29b741365776e16eabdb6f Author: root Date: Fri Sep 28 22:40:27 2012 -0700 Initial commit root@host:~/git# export GIT_WORK_TREE=/root/git/nagios-plugins root@host:~/git# etckeeper commit fatal: pathspec '.etckeeper' did not match any files root@host:~/git# unset GIT_WORK_TREE root@host:~/git# etckeeper commit [master acd2dca] [... commit succeeds] (The hostname has been anonymized in the above examples.) Regards, Alex Bradley
Bug#542258: enblend-enfuse: embeds the VIGRA library
block 542258 with 587063
thanks
On 2009-08-18 Jakub Wilk wrote:
> Package: enblend-enfuse
> Version: 3.2+dfsg-2
> Severity: normal
> Enblend embeds a modified version of the VIGRA 1.4 library. However,
> this library is already packaged for Debian[1]. It would be great if
> the necessary changes were pushed to VIGRA's upstream and Enblend
> started to use system version of the library, rather than an
> embedded copy.
[...]
> [1] http://packages.qa.debian.org/libvigraimpex
Hello,
looking at enblend upstream HG repsitory this seems to have been fixed
upstream.
http://enblend.hg.sourceforge.net/hgweb/enblend/enblend/file/74011c6d5427/NEWS
| * Version 4.1 ("touble in paradise")
| Unreleased. Current line of development.
[...]
| - Enblend and Enfuse no longer rely on their own versions of the Vigra
| imaging library. Vigra version 1.8 or later is now required to
| build.
OTOH libvigraimpex has been orphaned in Debian (#587063).
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689100: bugs.debian.org doesn't identify itself in Resent-From: (RFC 5322)
Package: bugs.debian.org As per RFC 5322 §3.6.6, the Resent-From: header field should be set to the user who has “reintroduced [the message] into the transport system”: --cut: urn:ietf:rfc:5322 -- Resent fields are used to identify a message as having been reintroduced into the transport system by a user. […] […] The resent originator fields indicate the mailbox of the person(s) or system(s) that resent the message. […] --cut: urn:ietf:rfc:5322 -- Thus, I'd expect the messages passed via bugs.debian.org to bear Resent-From: ow...@bugs.debian.org. On the contrary, the service duplicates From: as Resent-From: instead, like: --cut: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689099;msg=2;mbox=yes -- Resent-From: Joey Hess … Date: Sat, 29 Sep 2012 01:13:21 -0400 From: Joey Hess To: Debian Bug Tracking System Message-ID: <20120929051321.ga11...@gnu.kitenet.net> --cut: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689099;msg=2;mbox=yes -- -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688611: automake1.7: Add ${misc:Depends} depends since package uses debhelper
tags 688611 + wontfix
thanks
* Benjamin Kerensa (bkere...@ubuntu.com) wrote:
> Package: automake1.7
> Version: 1.7.9-9.1
> Severity: wishlist
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu quantal ubuntu-patch
>
> Dear Maintainer,
>
> I have attached a patch which adds ${misc:Depends} depends since this package
> uses debhelper
> hopefully this can be included in your next update to this package.
Thanks but automake1.7 has been removed from unstable and won't be
part of the next release of Debian.
> -- System Information:
> Debian Release: wheezy/sid
> APT prefers quantal-updates
> APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
> 'quantal-proposed'), (500, 'quantal'), (100, 'quantal-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.5.0-15-generic (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
> === modified file 'Makefile.in'
> --- Makefile.in 2004-04-20 23:47:54 +
> +++ Makefile.in 2012-09-24 07:12:42 +
> @@ -472,7 +472,8 @@
> $(MAKE) $(AM_MAKEFLAGS) \
> top_distdir="$(top_distdir)" distdir="$(distdir)" \
> dist-info
> - -find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
> + -find "$(distdir)" -type d ! -perm -755 \
> + -exec chmod u+rwx,go+rx {} \; -o \
> ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
> ! -type d ! -perm -400 -exec chmod a+r {} \; -o \
> ! -type d ! -perm -444 -exec $(SHELL) $(install_sh) -c -m a+r {} {}
> \; \
>
> === modified file 'debian/changelog'
>
> === modified file 'debian/control'
> --- debian/control2006-06-15 21:33:50 +
> +++ debian/control2012-09-24 07:13:14 +
> @@ -9,7 +9,7 @@
> Package: automake1.7
> Architecture: all
> Provides: automaken
> -Depends: autoconf (>= 2.54), autotools-dev (>= 20020320.1)
> +Depends: ${misc:Depends}, autoconf (>= 2.54), autotools-dev (>= 20020320.1)
> Conflicts: automake1.6 (<< 1.6.1-4), automake (<< 1:1.4-p5-1), automake1.5
> (<< 1.5-2)
> Description: A tool for generating GNU Standards-compliant Makefiles
> Automake is a tool for automatically generating `Makefile.in's from
>
> === modified file 'lib/am/distdir.am'
> --- lib/am/distdir.am 2004-04-20 23:47:54 +
> +++ lib/am/distdir.am 2012-09-24 07:12:42 +
> @@ -181,11 +181,7 @@
> endif %?DIST-TARGETS%
> ##
> ## This complex find command will try to avoid changing the modes of
> -## links into the source tree, in case they're hard-linked. It will
> -## also make directories writable by everybody, because some
> -## brain-dead tar implementations change ownership and permissions of
> -## a directory before extracting the files, thus becoming unable to
> -## extract them.
> +## links into the source tree, in case they're hard-linked.
> ##
> ## Ignore return result from chmod, because it might give an error
> ## if we chmod a symlink.
> @@ -198,7 +194,8 @@
> ## the file in place in the source tree.
> ##
> if %?TOPDIR_P%
> - -find $(distdir) -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
> + -find "$(distdir)" -type d ! -perm -755 \
> + -exec chmod u+rwx,go+rx {} \; -o \
> ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
> ! -type d ! -perm -400 -exec chmod a+r {} \; -o \
> ! -type d ! -perm -444 -exec $(SHELL) $(install_sh) -c -m a+r {} {}
> \; \
>
--
Eric Dorland
ICQ: #61138586, Jabber: ho...@jabber.com
signature.asc
Description: Digital signature
Bug#688603: mlterm: diff for NMU version 3.1.2-1.2
Hey Ahmed and Kenshi On Fri, Sep 28, 2012 at 08:25:28AM +0200, أحمد المحمودي wrote: > On Fri, Sep 28, 2012 at 08:54:30AM +0900, Kenshi Muto wrote: > > mlterm is mostly maintained by Ahmed. > > Ahmed, could you tell me what you think about? > ---end quoted text--- > > Well, it is the same fix that was done in 3.1.2-1.1 for mlterm & > mlterm.tiny > > Yet I think it is better to do the fix in .preinst instead of > .postinst as the file attached. > > Note that I didn't test that fix yet. Thanks for your reply Ahmed. Yes I think you are correct and your solution should works too correctly (untested your solution). Only thinking aloud: Would it be safer to check in addition against current version in wheezy, for the already happened updates for people who did Squeeze -> current Testing, and if we still have empty directories where should be symlinks to mlterm-common replace them? Thanks for your work! Regards, Salvatore signature.asc Description: Digital signature
Bug#638839: please add multi-arch support for libhal1
tags 638839 + wontfix thanks On 29.09.2012 02:14, Francois Gouget wrote: > Package: libhal1 > Version: 0.5.14-8 > Followup-For: Bug #638839 > > Dear Maintainer, > > This breaks HAL support in Wine for multi-arch configurations. > libhal1-dev will need the same treatment so Wine can be built with HAL > support. > HAL is dead. No software should use it anymore. Please fix wine to not use HAL anymore. If wine is really still depending on HAL, please talk to the Wine maintainers. Marking this bug as wontfix. 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#688932: g_get_user_*_dir () fails to conform to basedir-spec-0.8 (re. ${HOME})
> Bernhard R Link writes:
> * Simon McVittie [120926 18:50]:
[Cc: 688...@bugs.debian.org.]
>> ... but I don't think this is the right way to make it happen.
>> Please research previous discussion to check that you're not missing
>> arguments that have happened in the past, then if you still think
>> your proposal is the best option, take it upstream.
> This was already taken upstream
Could you please provide an URI of the prior discussion? TIA.
> and upstream's opinion was "if we do this as the unix guys expect
> then users complain that changing $HOME changes the home directory.".
The point is that the home directory is exactly “the directory
pointed to by the HOME environment variable.” At least on the
Unix-like systems.
It's just like the user's shell is the one pointed to by
${SHELL}, and the user's executables' search path is the
directories listed in ${PATH}. Never an “ordinary” program is
expected to use a system-wide configuration, or a hard-coded
value, for these.
[…]
> The documentation for g_get_home_dir [1] also documents what a proper
> program can do, it's a simple:
> const char *homedir = g_getenv ("HOME");
>if (!homedir)
> homedir = g_get_home_dir ();
> instead of using get_get_home_dir directly.
Actually, as pointed out in [2], a conforming application should
use g_get_user_cache_dir (), g_get_user_data_dir (), and
g_get_user_config_dir () instead.
Alas, the GLib implementation of these functions relies on
g_get_home_dir (), and thus itself fails to conform to the
specification [3], which explicitly requires that the HOME
variable's value is used. (FWIW, it doesn't even mention
getpwuid () or passwd(5).)
[2] news:506480fe.4060...@gnome.org
http://permalink.gmane.org/gmane.comp.gnome.gtk+.devel.general/22728
[3] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.8.html
> (And tip of the day: If you are working with multiple home
> directories regulariy and get tired of badly written programs
> confusing the initial home directory with the current one, setting
> the initial home directory to the empty string can help in many cases
> (though you lose having a default one for programs not getting one
> set)).
The question is, where Bash will get its ~/.bash_profile from,
then?
A “proper” hack (for a certain definition thereof) would be to
use an LD_PRELOAD module, redefining either g_get_home_dir (),
or, perhaps, getpwuid () (to catch the cases getpwuid () ends up
being used for no good reason at all.).
> [1] For example
> http://developer.gnome.org/glib/2.33/glib-Miscellaneous-Utility-Functions.html#g-get-home-dir
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
* Aaron M. Ucko wrote: > Jon Bernard writes: > > > Is there an easier way of doing this without searching through the source to > > find all liburcu calls and then pinning them to a specific version in the > > symbols file? - or is that how it's done? > > You can run dpkg-gensymbols on a build tree of 0.6.6, copy the resulting > symbols file over to a build tree of 0.7.4, and repeat. That said, > that approach may well be overkill here. > > >> or simply insisting on a versioned dependency in its .shlibs file (e.g., by > >> running dh_makeshlibs -V). > > > > This will yield a file containing: "liblttng-ctl 0 liblttng-ctl0 (>= > > 2.1.0~rc4)" > > But that will not help me with the liburcu dependency, which should likely > > be > > 0.7.4. It's not clear to me how to get dh_makeshlibs to do the right thing. > > I meant that *liburcu*'s rules should run dh_makeshlibs -V; sorry if that > was unclear. (That said, it would probably be wise for ltt-control to > do the same for the sake of its libraries' own reverse dependencies.) > > > My first thought was that "Build-Depends: .. liburcu-dev (>= 0.6.6)" is too > > lenient, and that version should be bumped. I could then release ltt-control > > version 2.1.0-2 with this change, and avoid the binNMUs, no? What am I > > missing? > > That would only work if liburcu1 shipped a symbols file with a magic > Build-Depends-Package line. > > > Also, which of these in your opinion is the best/most-proper solution? > > I might just go for having liburcu1 run dh_makeshlibs -V for simplicity; > although that approach can result in overly tight dependencies, that > shouldn't be a big deal here. Ok, this makes sense. So just to be clear, here are the steps I plan to follow: 1. In liburcu source, add "-V" to dh_makeshlibs to set strict symbol version dependencies on this particular version 2. Rebuild ltt-control against the new liburcu, which will pull in liburcu's shlibs and cause ltt-control to depend on that specific version of liburcu. 3. Request binNMU for ltt-control. Is step 3 necessary, will the updated ltt-control not sort this out? That's the only piece I don't quite follow. Thanks again! -- Jon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689099: capture.log should never be world-readable
Package: arbtt Version: 0.6.2-1 Severity: normal Tags: security Window titles can contain sensative information, but are logged to capture.log with file permissions that honor umask. I suggest making either all log files or the .arbtt directory only readable by the owner. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (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 arbtt depends on: ii libc6 2.13-35 ii libffi5 3.0.10-3 ii libgmp10 2:5.0.5+dfsg-2 ii libpcre3 1:8.31-1 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxinerama1 2:1.1.2-1 ii libxss1 1:1.2.2-1 arbtt recommends no packages. arbtt suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#98825: Votre quota WEBMAIL
Votre boîte aux lettres a dépassé Il Limite de stockage tel que défini par votre administrateur et vous ne serez pas capable de recevoir de nouveaux courriels jusqu'à ce que vous re-valider. Cliquez ici: http://njalaj.phpforms.net/view_forms/view/85e8a0a8e7#top Administrateur système -- Este mensaje ha sido analizado por el Sistema de Antivirus y Antispam de SPSE en busca de virus y otros contenidos peligrosos, y se considera que esta limpio. Gerencia de Tecnologia de la Informacion y Comunicaciones. Div Seguridad Informatica. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668645: Acknowledgement (libgl1-mesa-dri: Add a recommendation for a libtxc-dxtn implementation)
Hi, Just wanted to report that Ubuntu's corresponding bug has been fixed recently (see https://bugs.launchpad.net/ubuntu/+source/s2tc/+bug/1053065 ) Cheers Thibaut 2012/5/15 Julien Cristau : > On Tue, May 15, 2012 at 14:26:00 +0200, Lennart Weller wrote: > >> Is this under consideration or did I just file it against the wrong package? > > It's filed against the right package. There's many bugs though, and > only so much free time. > > Cheers, > Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688970: patch-smime-self breaks gpg on my install
Package: mutt Followup-For: Bug #688970 unfortunatly, I spoke too soon. the patch-smime-self breaks the gpg-decrypting and gpg-encrypting on my install. I can encrypt (wont find any key to encrypt although they are all here) and it wont decrypt my gpg-encrypted mail. sigh... -- 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#689098: RFP: cdesktopenv -- CDE, the classic unix desktop
Package: wnpp Severity: wishlist As some may have heard, CDE (the desktop that was once standard on Unix systems) has been open-sourced under the LGPL, version 2.0. The website is http://sourceforge.net/projects/cdesktopenv/ and source is available from http://sourceforge.net/projects/cdesktopenv/files/src/ git://git.code.sf.net/p/cdesktopenv/code There are several potential issues to watch when packaging: -It requires OpenMotif; this means it has to stay in contrib/ for now, but according to the developers, relicensing OpenMotif to LGPL2.0 is well underway. -All patches should be MIT if possible; they hope to relicense at some point. -It is hard-coded to install in /usr/dt; this might be fixed with a simple find/replace? -The install script does not respect DESTDIR; you must patch it to package properly (the Arch PKGBUILD does this) -Needs (preferably) ksh93 (or mksh), tcl, rpcbind/portmapper, g++, libxp (!) for full build. -There's a patch to use libtirpc authentication; without this, rpcbind must be run in insecure mode. -the install script (admin/IntegTools/dbTools/installCDE) recognizes 20+ packages; if you don't use these, it still needs to be split into at least 5-6 packages: libDt*: CDE libraries libTt*: ToolTalk libraries tt*: Tooltalk executables dt*: CDE binaries; may need splitting up (make dtterm provide x-terminal-emulator; make dtwm provide a windowmanager; make dtlogin provide a display manager) Data: cde-config: including themes, icons (may require patches to put in the standard place!), configfiles cde-help: helpfiles (& perhaps manpages, if those don't go with the binaries) Data should at least be split in 2 packages, due to its large size. A full tar.xz of the install runs 120+ MB. Thank you, Isaac Dunham -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689042: iucode-tool: Microcode no more loaded on self build kernel, with microcode updating firmware build-in
tag 689042 + wontfix severity 689042 wishlist retitle 689042 requires modular microcode driver for autoload on boot On Fri, 28 Sep 2012, Eric Valette wrote: > he old microcode.ctl package did at least provide an init script to perform > it. Why > not iucode-tool? Why should it? It is the kernel's job. An initscript would just slow the boot. And the wheezy kernel does its job better when the microcode driver is a module. For more details, please install the intel-microcode package, and read the package documentation in /usr/share/doc/intel-microcode. Basically, make sure /lib/firmware is in the root filesystem (duh), make sure the microcode driver is a _module_, and make sure it auto-loads (or add it to /etc/modules to force it to load manually). That's it. If you don't want to use the intel-microcode package, tell iucode-tool to install the microcode you need (iucode-tool -S -K) for the kernel. You are advised to rm /lib/firmware/intel-ucode/* before you run iucode-tool -S -K otherwise you may use microcode Intel decided to recall. And no, I have absolutely no idea why it happens. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687657: vlc: copyright file missing after squeeze->wheezy upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: tags -1 pending patch Hi, Le 26/09/2012 20:19, Andreas Beckmann a écrit : > On 2012-09-27 00:09, David Prévot wrote: >> I haven't yet been able to reproduce this >> specific issue. > > you should be able to test with debsums, currently this reports after > an upgrade squeeze > wheezy 2.0.3-2 > > debsums: missing file /usr/share/doc/vlc-nox/AUTHORS.gz (from vlc-nox > package) > debsums: missing file /usr/share/doc/vlc-nox/NEWS.Debian.gz (from vlc-nox > package) > debsums: missing file /usr/share/doc/vlc-nox/NEWS.gz (from vlc-nox package) > debsums: missing file /usr/share/doc/vlc-nox/README (from vlc-nox package) > debsums: missing file /usr/share/doc/vlc-nox/changelog.Debian.gz (from > vlc-nox package) > debsums: missing file /usr/share/doc/vlc-nox/changelog.gz (from vlc-nox > package) > debsums: missing file /usr/share/doc/vlc-nox/copyright (from vlc-nox > package) OK, thanks, I was looking in the wrong place (well in the vlc package, not the vlc-nox one ;). The proposed patch indeed fixes the issue (it took me some time to setup a test environment to dist-upgrade from squeeze to wheezy including my package), so I'm in the process of uploading it to DELAYED/2 (it will take some time with my bandwidth), please let me know if I should delay it any longer. I'll take care of the unblock request. I guess the debian/vlc-nox.preinst can also be removed, but I didn't rebuilt the package just to test it. Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQZlgWAAoJELgqIXr9/gnyl7QP/jgPo3j9znN/nw0iHQlL9+4v dp//cSPv2+aAgR/LbAzpJXXVnKfH6RpNrSl1/UnYugU0Ch+velr2Smh0wl1bIUY4 RxjAITqEqTllaKiaidD+XAqbBqV9ttnh8IJx2m7UrZgbIOvkjaS8UZ9gOWF02IOz P8Jt+4bysgEfsvaOngGhe0YuWTZni0qrsMn5pFQO/7jBGmMEV2QTVc6zKDRgraqQ 9WgloP+a23HvqugiP1uuZMiVpXxLeJQDuVarXdVLsBsEpin2596XMkmYoiG0TYCz xA0uPSz7uOeMl+Dp75uUXhS7GkQ2iopoRMcfZHFI0IZ5Z6utzcSHKPGq5F2zE4tZ eu373e71dBSOksE5LI0RhQ1Vg+AozC2hJZapzfIriqoHPKQPQcqd47doupY5g45R LslEluesdZpsmPwGdmjwciaDqPF5hCtSrJQmJIMu4xGUm1ucAfr53enyLMmTUzyn jlZIOx2a1CUdScAIyg+IxyrDi6OAFBzMIKChocWLBHNVaNtx1Ig9OrwRulMz1dQJ eoABc5cD0It3MFgBEcd/RfeD+c5QhBz4wAvC9WixdHYQPzjkFbd9Z5TRASd8u5s5 j635+cUYEoQPtaoB4Pa1DtCSisRPNSQd91Mqy9sCnVNB5wLRN2cuWXasUPrmkz/a BDHN8SMmrXOdzywlZDA4 =a6vl -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#689097: libgtk2.0-dev is not Multi-Arch compatible
Package: libgtk2.0-dev Version: 2.24.10-2 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgtk2.0-dev depends on: ii libatk1.0-dev 2.4.0-2 ii libcairo2-dev 1.12.2-2 ii libgdk-pixbuf2.0-dev 2.26.1-1 ii libglib2.0-dev2.32.3-1 ii libgtk2.0-0 2.24.10-2 ii libgtk2.0-common 2.24.10-2 ii libpango1.0-dev 1.30.0-1 ii libx11-dev2:1.5.0-1 ii libxcomposite-dev 1:0.4.3-2 ii libxcursor-dev1:1.1.13-1 ii libxdamage-dev1:1.1.3-2 ii libxext-dev 2:1.3.1-2 ii libxfixes-dev 1:5.0-4 ii libxi-dev 2:1.6.1-1 ii libxinerama-dev 2:1.1.2-1 ii libxml2-utils 2.8.0+dfsg1-5 ii libxrandr-dev 2:1.3.2-2 ii pkg-config0.26-1 Versions of packages libgtk2.0-dev recommends: ii debhelper 9.20120830 ii python 2.7.3~rc2-1 Versions of packages libgtk2.0-dev suggests: pn libgtk2.0-doc -- 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#689096: linux-image-3.2.0-3-686-pae: ipw2200 crashes on wakeup
Package: src:linux Version: 3.2.23-1 Severity: normal Dear Maintainer, Ever since I upgraded to wheezy I get occasional crashes in the ipw2200 driver when my laptop wakes up from suspend. It does't always happen and it used to work flawlessly with squeeze. Here's what dmesg has to say about this: [59928.488934] wlan: Coming out of suspend... [59928.488943] ipw2200 :04:02.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 [59928.490888] [ cut here ] [59928.490899] WARNING: at /build/buildd-linux_3.2.23-1-i386-qhsd1M/linux-3.2.23/drivers/base/firmware_class.c:537 _request_firmware+0xad/0x2f9() [59928.490922] Hardware name: 25256NG [59928.490925] Modules linked in: ipw2200 msr tg3 libphy cryptd aes_i586 aes_generic lib80211_crypt_ccmp cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave fuse ext3 jbd mbcache hidp hid rfcomm bluetooth crc16 dm_crypt dm_mod snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss thinkpad_acpi snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer pcmcia libipw snd_seq_device iTCO_wdt cfg80211 rfkill iTCO_vendor_support snd lib80211 nvram soundcore yenta_socket pcmcia_rsrc pcmcia_core psmouse rng_core snd_page_alloc serio_raw i2c_i801 pcspkr battery acpi_cpufreq ac power_supply mperf evdev processor xfs sg sd_mod crc_t10dif ata_generic ata_piix ahci libahci libata i915 scsi_mod sdhci_pci sdhci mmc_core i2c_algo_bit drm_kms_helper drm uhci_hcd ehci_hcd usbcore thermal video i2c_core thermal_sys usb_common button [last unloaded: ipw2200] [59928.491047] Pid: 19479, comm: kworker/0:0 Tainted: GW 3.2.0-3-686-pae #1 [59928.491050] Call Trace: [59928.491059] [] ? warn_slowpath_common+0x68/0x79 [59928.491063] [] ? _request_firmware+0xad/0x2f9 [59928.491068] [] ? warn_slowpath_null+0xd/0x10 [59928.491073] [] ? _request_firmware+0xad/0x2f9 [59928.491077] [] ? request_firmware+0x9/0xc [59928.491088] [] ? ipw_up+0xdd/0x1165 [ipw2200] [59928.491094] [] ? finish_task_switch+0x6d/0x94 [59928.491109] [] ? scsi_request_fn+0x303/0x3c3 [scsi_mod] [59928.491116] [] ? _raw_spin_lock_irqsave+0x8/0x21 [59928.491121] [] ? should_resched+0x5/0x1e [59928.491128] [] ? ipw_bg_up+0x1c/0x25 [ipw2200] [59928.491134] [] ? process_one_work+0x112/0x1fa [59928.491141] [] ? ipw_net_init+0x32/0x32 [ipw2200] [59928.491146] [] ? worker_thread+0xa9/0x122 [59928.491150] [] ? manage_workers.isra.23+0x13d/0x13d [59928.491155] [] ? kthread+0x63/0x68 [59928.491160] [] ? kthread_worker_fn+0x101/0x101 [59928.491167] [] ? kernel_thread_helper+0x6/0x10 [59928.491170] ---[ end trace 489947a6c8cb68b7 ]--- [59928.491174] ipw2200 :04:02.0: firmware: ipw2200-bss.fw will not be loaded [59928.491178] ipw2200: ipw2200-bss.fw request_firmware failed: Reason -16 [59928.491182] ipw2200: Unable to load firmware: -16 -- Package-specific info: ** Version: Linux version 3.2.0-3-686-pae (Debian 3.2.23-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP Mon Jul 23 03:50:34 UTC 2012 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-3-686-pae root=UUID=88262002-52a8-49fa-ab66-637759ec0159 ro acpi_sleep=s3_bios splash quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [124138.880450] snd_intel8x0 :00:1e.2: restoring config space at offset 0x1 (was 0x297, writing 0x293) [124138.880608] tg3 :02:00.0: restoring config space at offset 0xc (was 0x0, writing 0xac00) [124138.880638] tg3 :02:00.0: restoring config space at offset 0x1 (was 0x100102, writing 0x100106) [124138.896067] sdhci-pci :04:00.1: BAR 0: set to [mem 0xa0201000-0xa02010ff] (PCI address [0xa0201000-0xa02010ff]) [124138.896105] sdhci-pci :04:00.1: restoring config space at offset 0x3 (was 0x80, writing 0x804000) [124138.896115] sdhci-pci :04:00.1: restoring config space at offset 0x1 (was 0x210, writing 0x2100106) [124138.896376] PM: early resume of devices complete after 56.287 msecs [124138.896531] i915 :00:02.0: power state changed by ACPI to D0 [124138.896536] i915 :00:02.0: power state changed by ACPI to D0 [124138.896545] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [124138.896550] i915 :00:02.0: setting latency timer to 64 [124138.952450] uhci_hcd :00:1d.0: power state changed by ACPI to D0 [124138.952454] uhci_hcd :00:1d.0: power state changed by ACPI to D0 [124138.952461] uhci_hcd :00:1d.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [124138.952469] uhci_hcd :00:1d.0: setting latency timer to 64 [124138.952496] usb usb2: root hub lost power or was reset [124138.952509] uhci_hcd :00:1d.1: power state changed by ACPI to D0 [124138.952513] uhci_hcd :00:1d.1: power state changed by ACPI to D0 [124138.952519] uhci_hcd :00:1d.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [124138.952527] uhci_hcd :00:1d.1: setting latency timer to 64 [124138.952552] usb usb3: root hub lost power or was reset [124138.952566] uhci_hcd :
Bug#688794: PANIC: Circular dependancy after reboot when installing 1.20120606.6
On Fri, 28 Sep 2012, Lionel Gamay wrote: > I followed you advice but I still get a similar error message, without > any reference to udev: > > "Loading, please wait... > /init: eval: line 1: array_intel_microcode=: not found > /init: eval: line 1: array_intel_microcode=: not found > PANIC: Circular dependancy. Exiting." I still wonder WTF is it thinking a variable assignment is a command name? Can you give me the output of "dpkg -s busybox", please? And maybe, just in case, you should "apt-get --reinstall install busybox"... Anyway, please boot the kernel with the broken initramfs with the "debug" command line parameter. You'll need to set it in the boot loader, add "debug" to the end of the line with the kernel parameters. The nasty thing will be to get the debug file out of the broken system :-( it is supposed to end up in /run/initramfs/* If you're good with shell scripts, maybe you'll find the error right away :-) Otherwise, try to copy the last 30 or so lines before the PANIC error message and send it to the bug report. Maybe I can figure it out from there. Otherwise, if you can get the bug to happen with the _Wheezy kernel_, please send me the broken initramfs for the wheezy kernel. I should be able to run that in a VM... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689095: Forces user to agree to terms of usage before running
Package: transmission-gtk Version: 2.52-3 Severity: normal Transmission has started popping up a modal dialog on startup containing some terms of usage, with buttons for "Quit" and "I Agree". Software in Debian main should not include click-through licenses or terms of usage. Please remove this dialog. Thanks, Josh Triplett -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages transmission-gtk depends on: ii libc62.13-35 ii libcurl3-gnutls 7.27.0-1 ii libevent-2.0-5 2.0.19-stable-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-1 ii libgtk-3-0 3.4.2-4 ii libminiupnpc51.5-2 ii libnatpmp1 20110808-3 ii libpango1.0-01.30.0-1 ii libssl1.0.0 1.0.1c-4 ii transmission-common 2.52-3 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages transmission-gtk recommends: ii xdg-utils 1.1.0~rc1+git20111210-6 transmission-gtk 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#689094: libwebkitgtk-3.0-0 constant segfaults on mipsel
Package: libwebkitgtk-3.0-0 Version: 1.8.1-3.3 libwebkitgtk crashes segfaults constantly on mipsel(Debian wheezy, Loongson 2F) with the output "Segmentation fault.", making it unusable on this platform. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689079: screen: Focus up no longer does the exact opposite of focus [down].
On Fri, Sep 28, 2012 at 07:25:23PM -0500, Eric Pruitt wrote: > That it does, and I can actually use that as work around in the mean time: I > can use a bash script that does a layout dump, counts the number of regions > and > calls "screen -X focus" N-1 times. > > Eric I think I will end up downgrading since I am running into what I believe are TERMCAP related problems when resizing the terminal, but I have attached the script I used to circumvent the issue while using screen 4.1.0. counter-clockwise-focus.sh Description: Bourne shell script
Bug#408666: #408666 uxterm: bold attribute causes some glyphs to fail rendering
this is fixed by the same change as that made for #359006 (in xterm #282) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#683942: #683942 xterm: alternate screen scrolling
I made the indicated changes in #282 (current version). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#359006: #359006 xterm: unicode glyph rendering glitch
I made the indicated fix in patch #282 -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#689093: libssl-dev is not Multi-Arch compatible
Package: libssl-dev Version: 1.0.1c-4 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libssl.so and libcrypto.so symbolic links are missing so that developping 32bit applications (e.g. Wine) using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libssl-dev depends on: ii libssl1.0.0 1.0.1c-4 ii zlib1g-dev 1:1.2.7.dfsg-13 Versions of packages libssl-dev recommends: ii libssl-doc 1.0.1c-4 libssl-dev 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#689092: libpng12-dev is not Multi-Arch compatible
Package: libpng12-dev Version: 1.2.49-1 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libpng12.so symbolic link is missing so that developping 32bit applications (e.g. Wine) using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. The /usr/bin/libpng12-config binary is going to cause trouble though :-( -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpng12-dev depends on: ii libpng12-0 1.2.49-1 ii zlib1g-dev 1:1.2.7.dfsg-13 libpng12-dev recommends no packages. libpng12-dev 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#689091: libxslt1-dev is not Multi-Arch compatible
Package: libxslt1-dev Version: 1.1.26-13 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libxslt.so symbolic link is missing so that developping 32bit applications (e.g. Wine) using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxslt1-dev depends on: ii libxml2-dev 2.8.0+dfsg1-5 ii libxslt1.1 1.1.26-13 libxslt1-dev recommends no packages. libxslt1-dev 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#689090: libgstreamer0.10-dev is not Multi-Arch compatible
Package: libgstreamer0.10-dev Version: 0.10.36-1 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libgstreamer-0.10.so symbolic link is missing so that developping 32bit applications (e.g. Wine) using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgstreamer0.10-dev depends on: ii gir1.2-gstreamer-0.10 0.10.36-1 ii libc6 2.13-35 ii libc6-dev [libc-dev] 2.13-35 ii libglib2.0-0 2.32.3-1 ii libglib2.0-dev 2.32.3-1 ii libgstreamer0.10-0 0.10.36-1 ii libxml2-dev2.8.0+dfsg1-5 ii pkg-config 0.26-1 Versions of packages libgstreamer0.10-dev recommends: ii debhelper 9.20120830 Versions of packages libgstreamer0.10-dev suggests: pn gstreamer0.10-doc -- 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#689087: ITP: sweethome3d-furnitures -- Interior 2D design application with 3D preview (additional furnitures)
Gabriele Giacone <1o5g4...@gmail.com> writes: > Programming Lang: no code, zip archives containing OBJ + MTL > (Wavefront) format files. Great, it's about time we have a proper kitchen sink in Debian ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689025: slapd: chokes on unresponsive syslogd
Quanah Gibson-Mount writes: >n...@naturalnet.de wrote: >> Although this is possibly an rsyslog bug, Yes. Syslog is supposed to be lossy when it can't keep up. It should log problems, not create them without logging them. Imagine you had a lossy syslog but a "non-lossy" openlog() option: "If the log disk is full or the log port/program is not receiving, syslog(3) will block until the problem is fixed". Who'd ever use such an option? Anyway: >> slapd should not run into a >> freeze due to that. It didn't even come back up after syslog >> functionality had been re-established. > > A full GDB backtrace of all threads would be useful for examining this > issue any further. That is, a backtrace when syslog has unclogged but slapd is still hanging - to see if all threads are waiting for each other. -- Hallvard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689012: chrony: Refuses to start: Fatal error : Cannot read information from uname, sorry
I patched it, but probably not right:
...
diff -Naur chrony-1.24-3.1-build.orig/chrony-1.24/sys_linux.c
chrony-1.24-3.1-build.new/chrony-1.24/sys_linux.c
--- chrony-1.24-3.1-build.orig/chrony-1.24/sys_linux.c 2012-09-28
19:42:44.0 -0500
+++ chrony-1.24-3.1-build.new/chrony-1.24/sys_linux.c 2012-09-28
19:21:24.0 -0500
@@ -736,7 +736,12 @@
LOG_FATAL(LOGF_SysLinux, "Cannot uname(2) to get kernel version,
sorry.");
}
if (sscanf(uts.release, "%d.%d.%d", &major, &minor, &patch) != 3) {
-LOG_FATAL(LOGF_SysLinux, "Cannot read information from uname, sorry");
+ patch = 0;
+ }
+ else {
+if (sscanf(uts.release, "%d.%d.%d", &major, &minor) != 2) {
+ LOG_FATAL(LOGF_SysLinux, "Cannot read information from uname,
sorry");
+}
}
LOG(LOGS_INFO, LOGF_SysLinux, "Linux kernel major=%d minor=%d patch=%d",
major, minor, patch);
...
The amd64 .deb with the patch is here:
https://docs.google.com/open?id=0BwcitGMmYn5-N253a1VZb24yMVk
Hugo Vanwoerkom
Bug#689087: ITP: sweethome3d-furnitures -- Interior 2D design application with 3D preview (additional furnitures)
Package: wnpp Severity: wishlist Owner: Gabriele Giacone <1o5g4...@gmail.com> * Package name: sweethome3d-furnitures Version : 1.2 Upstream Author : Various SweetHome3D contributors * URL : http://www.sweethome3d.com/importModels.jsp * License : CC-BY-3.0 Unported, CC-BY-3.0 USA, Free Art License 1.3 Programming Lang: no code, zip archives containing OBJ + MTL (Wavefront) format files. Description : Interior 2D design application with 3D preview (additional furnitures) Furnitures released under CC-BY-3.0 in sweethome3d-furnitures package in main. Free Art License ones in sweethome3d-furnitures-nonfree in non-free. Sweet Home 3D is an interior design Java application for quickly choosing and placing furniture on a house 2D plan drawn by the end-user, with a 3D preview. . This package contains additional furniture libraries created by SweetHome3D contributors. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689086: libmpg123-dev is not Multi-Arch compatible
Package: libmpg123-dev Version: 1.14.2+svn20120622-1 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libmpg123.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libmpg123-dev depends on: ii libmpg123-0 1.14.2+svn20120622-1 libmpg123-dev recommends no packages. libmpg123-dev 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#689085: libtiff4-dev is not Multi-Arch compatible
Package: libtiff4-dev Version: 3.9.6-7 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libtiff.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libtiff4-dev depends on: ii libc6-dev [libc-dev]2.13-35 ii libjbig-dev 2.0-2 ii libjpeg8-dev [libjpeg-dev] 8d-1 ii libtiff43.9.6-7 ii libtiffxx0c23.9.6-7 ii zlib1g-dev 1:1.2.7.dfsg-13 libtiff4-dev recommends no packages. libtiff4-dev 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#689084: libcups2-dev is not Multi-Arch compatible
Package: libcups2-dev Version: 1.5.3-1 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libcups.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcups2-dev depends on: ii libcups2 1.5.3-1 ii libgnutls-dev 2.12.20-1 ii libkrb5-dev1.10.1+dfsg-2 libcups2-dev recommends no packages. libcups2-dev 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#689079: screen: Focus up no longer does the exact opposite of focus [down].
On Sat, Sep 29, 2012 at 02:14:08AM +0200, Axel Beckert wrote: > > In screen 4.0.3, when my focus was in the top right quadrant, executing > > "focus > > up" would move the focus to the pane on the left > > That sounds like a quite strange and unexpected behaviour to me. > > > but in screen 4.1.0, this no longer works as expected and the foucs > > simply remains in the top right quadrant. > > That's the behaviour I'd expect. I admit the naming convention could use some work in that "focus down" and "focus up" would be more aptly named "focus clockwise" and "focus counterclockwise" (or anti-clockwise), but it was perfectly documented and quite useful for changing focus without having to worry about cardinality. > C-a Tab (i.e. "focus" without subcommand) though still cycles through > all regions. That it does, and I can actually use that as work around in the mean time: I can use a bash script that does a layout dump, counts the number of regions and calls "screen -X focus" N-1 times. Eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#621409: vnc4: FTBFS on armel: macro 'in' not recognized -- ignoring
hw/xfree86/common/compiler.h in the current Xserver has some pre-processor conditional logic for __arm__, which needs ported over to vnc4's older copy of this file. More details: https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/945368/comments/2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689083: libgphoto2-2-dev is not Multi-Arch compatible
Package: libgphoto2-2-dev Version: 2.4.14-2 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libgphoto2.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgphoto2-2-dev depends on: ii libc6-dev [libc-dev] 2.13-35 ii libexif-dev 0.6.20-3 ii libgphoto2-2 2.4.14-2 ii libusb-dev2:0.1.12-20 ii pkg-config0.26-1 libgphoto2-2-dev recommends no packages. libgphoto2-2-dev 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#689079: screen: Focus up no longer does the exact opposite of focus [down].
Hi Eric, Eric Pruitt wrote: > I often use the following screen layout: > > ~% screen -X layout dump > ~% cat layout-dump > split -v > focus > split > focus > focus > > In ASCII diagram form: > ___ ___ >| | | >| |---| >|___|___| > > In screen 4.0.3, when my focus was in the top right quadrant, executing "focus > up" would move the focus to the pane on the left That sounds like a quite strange and unexpected behaviour to me. > but in screen 4.1.0, this no longer works as expected and the foucs > simply remains in the top right quadrant. That's the behaviour I'd expect. > The documentation still reads below in both versions of screen: > > This is done in a cyclic way so that the top region is selected after > the bottom one. If no subcommand is given it defaults to `down'. `up' > cycles in the opposite order [...] That sounds out of sync, yes. C-a Tab (i.e. "focus" without subcommand) though still cycles through all regions. > So this is an unexpected (and personally undesirable) change in behavior. I'd still call it more consistent and expectable than before, so I guess that change has been made on purpose by upstream. I though haven't found the according upstream commit on a first glance to back that assumption. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687057: ITP: androidsdk-tools -- A subset of the android sdk tools
Hi Jakub, thanks for the interest in this package. I do have a local git repository for the packaging and have just requested access to alioth to upload it directly to the debian packaging repository (pkg-java). As soon as I get access, I will upload the packaging repository such that others can easily contribute. Best regards, Stefan Am Freitag, den 28.09.2012, 20:30 +0200 schrieb Jakub Adam: > Hi Stefan, > > I looked at your package and see that the java libraries you create will be > required by ADT Eclipse plugin once it is packaged. To make those JARs usable > in Eclipse, there are some OSGi metadata that must be added to their > manifests. > > In a preparation for ADT packaging (no work have been done yet AFAIK), I'd > like > to update the manifests. Do you have any source code repository where you > store > your work? If not, could you please import the package into a git repository > of pkg-java team so that others can collaborate? > > Regards, > > Jakub signature.asc Description: This is a digitally signed message part
Bug#638839: please add multi-arch support for libhal1
Package: libhal1 Version: 0.5.14-8 Followup-For: Bug #638839 Dear Maintainer, This breaks HAL support in Wine for multi-arch configurations. libhal1-dev will need the same treatment so Wine can be built with HAL support. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libhal1 depends on: ii libc62.13-35 ii libdbus-1-3 1.6.0-1 libhal1 recommends no packages. libhal1 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#672495: libsane: please make libsane multiarch
Package: libsane-dev Followup-For: Bug #672495 Dear Maintainer, libsane 1.0.22-7.4 is Multi-Arch aware and indeed I have both the amd64 and the i386 version installed. So I think this bug can be closed. libsane-dev is not Multi-Arch aware however but that's bug #689073. If this bug was meant to cover both packages then I apologize for the duplicate bug. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libsane-dev depends on: ii libavahi-client-dev 0.6.31-1 ii libgphoto2-2-dev2.4.14-2 ii libieee1284-3-dev 0.2.11-10 ii libjpeg8-dev [libjpeg-dev] 8d-1 ii libsane 1.0.22-7.4 ii libtiff4-dev3.9.6-7 ii libusb-dev 2:0.1.12-20 ii libv4l-dev 0.8.8-3 ii pkg-config 0.26-1 Versions of packages libsane-dev recommends: ii libsane-extras-dev 1.0.22.2 libsane-dev 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#689082: libxcomposite-dev is not Multi-Arch compatible
Package: libxcomposite-dev Version: 1:0.4.3-2 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libXcomposite.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxcomposite-dev depends on: ii libx11-dev 2:1.5.0-1 ii libxcomposite1 1:0.4.3-2 ii libxext-dev 2:1.3.1-2 ii libxfixes-dev 1:5.0-4 ii x11proto-composite-dev 1:0.4.2-2 ii x11proto-core-dev 7.0.23-1 libxcomposite-dev recommends no packages. libxcomposite-dev 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#689012: chrony: Refuses to start: Fatal error : Cannot read information from uname, sorry
The problem is in the kernel release: hugo@HDBF:~$ uname -r + uname -r 3.5-trunk-amd64 he expects 3.5.-trunk-amd64 in sys_linux.c #738. Hugo Vanwoerkom
Bug#689080: ITP: ktouchpadenabler -- kded daemon to enable/disable touchpad
Package: wnpp Severity: wishlist Owner: Daniel Skinner * Package name: ktouchpadenabler Version : 0.1.0 Upstream Author : Unknown * URL : http://download.kde.org/stable/extragear/ * License : GPL Programming Lang: C++ Description : kded daemon to enable/disable touchpad ktouchpadenabler is a kded daemon to enable and disable the system's touchpad. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689078: schroot: CHROOT_ALIAS/SCHROOT_ALIAS_NAME doesn't refer to alias
On Fri, Sep 28, 2012 at 03:59:55PM -0700, Vagrant Cascadian wrote: > Package: schroot > Version: 1.6.3-1 > Severity: normal > > CHROOT_ALIAS and SCHROOT_ALIAS_NAME does not refer to the alias, but to the > actual chroot name. > > I would have expected SCHROOT_ALIAS_NAME=default or chroot:default. > > The same holds true for the CHROOT_ALIAS variable used in the > /etc/schroot/setup.d hooks. > > This means I end up cutting and pasting chroot configurations for > squeeze-backports, experimental, etc. rather than just setting them up as > aliases with setup.d hooks to configure the small differences from squeeze or > sid. Just checked the code to remind myself how this is set, and it does certainly /look/ like it's being set with the alias name rather than the chroot name. Possibly it's not being passed the correct name in chroot_facet_session_clonable::clone_session_setup (which has an alias argument which is used for the above env vars). I'll have to investigate that in more detail. One possible cause might be if the alias->chroot mappings in sbuild::chroot_config are not being used correctly, or we pass the wrong value in sbuild::session. I'll have to double check that. One other consideration might be if the chroot is capable of session cloning, since these are set during setting cloning. Chroots like "plain", which are not, might not have this capability--I can't remember offhand how they are handled, so I'll again have to check. 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#689079: screen: Focus up no longer does the exact opposite of focus [down].
Package: screen Version: 4.1.0~20120320gitdb59704-5 Severity: important I often use the following screen layout: ~% screen -X layout dump ~% cat layout-dump split -v focus split focus focus In ASCII diagram form: ___ ___ | | | | |---| |___|___| In screen 4.0.3, when my focus was in the top right quadrant, executing "focus up" would move the focus to the pane on the left, but in screen 4.1.0, this no longer works as expected and the foucs simply remains in the top right quadrant. The documentation still reads below in both versions of screen: This is done in a cyclic way so that the top region is selected after the bottom one. If no subcommand is given it defaults to `down'. `up' cycles in the opposite order [...] So this is an unexpected (and personally undesirable) change in behavior. Eric -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (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/dash Versions of packages screen depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii dpkg 1.15.8.12 Debian package management system ii install-info 4.13a.dfsg.1-6 Manage installed documentation in ii libc6 2.13-35Embedded GNU C Library: Shared lib ii libpam0g 1.1.1-6.1+squeeze1 Pluggable Authentication Modules l ii libtinfo5 5.9-10 shared low-level terminfo library screen recommends no packages. Versions of packages screen suggests: pn iselect | screenie | byobu (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687149: Again new patch...
Marco Gaiarin wrote: > Bob Proulx wrote: > > Please, one thread for each bug. This is a different problem and it > > should have a different bug ticket. > > I consider the ''bug'' as: «squeeze /etc/cron.daily/spamassassin is a > bit more verbose/annoying then lenny one», and sa-exim only a ''side > effect'' of that. Okay. I have filed Bug#689076 to hold discussion about the mirror problem. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689076 > Probably i've understimated this, but i think that cronjobs have (to > try) to be as quiter as possible, because are mostly unreadable and > confusing. I can agree that the errors are terrible to understand. The original authors could have made them nicer. But redirecting all errors to /dev/null does not solve the problem. It just ignores it. In this case one of the mirrors is having a problem. Let's say that there were two mirrors. The other mirror would handle the load and everything will continue to work. But then what happens if that other mirror has an error? We don't want to fail and ignore that error. > AFAI've understood the script, it try insted to ''pass over'' to catch > errors, and if an error occur, restart the update with ''--lint'' to > make a better informative ''log''. Most of the time that is reasonable. However some of the time I will have problems behave differently the second time around. When there is a network dependent error for example. In those cases it will lead to the confusing case of a report of a failure but the detail listing showing a success. Therefore I believe it is always better to save the full output and if there is an error then report it without running anything a second time. This way the real details are reported and it is less confusing. It is more trouble to write it that way though. > All my ''example patch'' say that, other than error, there's also some > warnings (or not so understood errors ;). I looked at your patch and here are the changes from it: -sa-compile --quiet +sa-compile --quiet > /dev/null 2>&1 - invoke-rc.d spamassassin reload > /dev/null + invoke-rc.d spamassassin reload > /dev/null 2>&1 - /etc/init.d/spamassassin reload > /dev/null + /etc/init.d/spamassassin reload > /dev/null 2>&1 -spamassassin --lint || die_with_lint +spamassassin --lint > /dev/null 2>&1 || die_with_lint What I see there is that in every case all of the output is redirected to /dev/null ignoring all output include any errors that are produced. > I don't know very well SA, so i don't know if the error handling are > excellent or poor, and so, if the warning can be safely ignored (as > i've done in my patch) or taken into account. Okay. But I do not believe it is appropriate to ignore those errors. > For me, give to the users the choice to ignore warnings or send them, > eg, redirecting all output of scripts to a file, check if it was empty > and eventually send to the user (better, filtering with a regexp). I would not be opposed to an *option* to ignore all errors. But it should not be the default. I am not proposing this next but if you want the script to stop producing any output then at the top of the script you could install this one single line and it would in one place redirect all of the output for the entire rest of the script without needing to change many individual lines. exec >/dev/null 2>&1 Put that near the top of the script such as immediately after the "#!/bin/sh" line and it will redirect output for the rest of the file. Bob signature.asc Description: Digital signature
Bug#689004: Bug#689047: digikam: Maintainer deliberately uploaded a package in experimental that will not be installable for months
merge 689047 689004 retitle 689004 digikam/3.0 conficts with kdegraphics/4.8 found 689047 4:3.0.0~beta1a-1 notfound 689047 3.0.0~beta1a-1 thanks On Sat, 29 Sep 2012 02:53:51 Eric Valette wrote: > Package: digikam > Version: 3.0.0~beta1a-1 > Severity: grave > Justification: renders package unusable > > See the changelog and bug 689004. > Eric, I seem to be unable to email you directly, all email returns with a 550 error, so I will continue to utilise the BTS. digikam/experimental is installable now (see below), but it does conflict with kdegraphics/unstable. It installs fine and is a fully usable package (contary to your assertions), and some users wish to utilise the latest upstream release, which is why I have uploaded to experimental. However, you are correct that this is not an acceptable long terms solution and is a release critical bug and should not be brought into unstable, hence why it is uploaded to experimental. Upstream has a peculiar approach where they start utilising newer components of kdegraphics. Again you are correct this is not the debian way and is not a sensible approach to packaging. We also had exactly the same issue with the release of digikam/2.0 which was using unreleased features from kdegraphics/4.7. The workaround we used then, and are using now is to make the bleeding edge package available via experimenal, whilst maintaining the fully compatible package via unstable. So debian users have a number of choices: 1. Bleeding edge digikam/3.0. In which case they can install via experimental but cannot utilise kdegraphics/4.8. 2. Integrated digikam/2.6 kdegraphics/4.8. In which case they can install from unstable/ testing and shortly stable.. Once stable is released I will likley release digikam/2.9 to unstable/testing. 3. Roll their own. I think this is a perfectly reasonable approach, which I understand you are not happy with. However I would refer you to the headline for experimental packages: http://packages.debian.org/experimental/digikam Package: digikam (4:3.0.0~beta1a-1) Warning: This package is from the experimental distribution. That means it is likely unstable or buggy, and it may even cause data loss. Please be sure to consult the changelog and other possible documentation before using it. Mark # apt-get -t experimental install digikam Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: digikam-data kipi-plugins kipi-plugins-common Suggested packages: gallery gimp The following packages will be REMOVED: gwenview kdegraphics kdegraphics-thumbnailers ksnapshot libkdcraw-data libkdcraw20 libkexiv2-10 libkexiv2-data libkipi-data libkipi8 The following NEW packages will be installed: digikam digikam-data kipi-plugins kipi-plugins-common 0 upgraded, 4 newly installed, 10 to remove and 398 not upgraded. Need to get 0 B/36.5 MB of archives. After this operation, 89.4 MB of additional disk space will be used. Do you want to continue [Y/n]? Retrieving bug reports... Done Parsing Found/Fixed information... Done grave bugs of digikam (-> 4:3.0.0~beta1a-1) #689047 - digikam: Maintainer deliberately uploaded a package in experimental that will not be installable for months #689004 - digikam again not installable Summary: digikam(2 bugs) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] (Reading database ... 329290 files and directories currently installed.) Removing kdegraphics ... Removing gwenview ... Removing kdegraphics-thumbnailers ... Removing ksnapshot ... Removing libkdcraw20 ... Removing libkdcraw-data ... Removing libkexiv2-10 ... Removing libkexiv2-data ... Removing libkipi8 ... Removing libkipi-data ... Processing triggers for hicolor-icon-theme ... Processing triggers for desktop-file-utils ... Processing triggers for gnome-menus ... Selecting previously unselected package kipi-plugins-common. (Reading database ... 329159 files and directories currently installed.) Unpacking kipi-plugins-common (from .../kipi-plugins- common_4%3a3.0.0~beta1a-1_all.deb) ... Selecting previously unselected package kipi-plugins. Unpacking kipi-plugins (from .../kipi-plugins_4%3a3.0.0~beta1a-1_amd64.deb) ... Selecting previously unselected package digikam-data. Unpacking digikam-data (from .../digikam-data_4%3a3.0.0~beta1a-1_all.deb) ... Selecting previously unselected package digikam. Unpacking digikam (from .../digikam_4%3a3.0.0~beta1a-1_amd64.deb) ... Processing triggers for hicolor-icon-theme ... Processing triggers for desktop-file-utils ... Processing triggers for gnome-menus ... Processing triggers for menu ... Processing triggers for man-db ... Setting up kipi-plugins-common (4:3.0.0~beta1a-1) ... Setting up digikam-data (4:3.0.0~beta1a-1) ... Setting up digikam (4:3.0.0~beta1a-1) ... Setting up kipi-plugins (4:3.0.0~beta1a-1) ... Processing triggers for
Bug#689078: schroot: CHROOT_ALIAS/SCHROOT_ALIAS_NAME doesn't refer to alias
Package: schroot Version: 1.6.3-1 Severity: normal CHROOT_ALIAS and SCHROOT_ALIAS_NAME does not refer to the alias, but to the actual chroot name. vagrant@prl:~$ schroot -c default (sid-aufs)vagrant@prl:~$ (sid-aufs)vagrant@prl:~$ echo $SCHROOT_ALIAS_NAME chroot:sid-aufs (sid-aufs)vagrant@prl:~$ echo $SCHROOT_CHROOT_NAME sid-aufs default is listed as an alias of sid-aufs in my configuration. I would have expected SCHROOT_ALIAS_NAME=default or chroot:default. The same holds true for the CHROOT_ALIAS variable used in the /etc/schroot/setup.d hooks. This means I end up cutting and pasting chroot configurations for squeeze-backports, experimental, etc. rather than just setting them up as aliases with setup.d hooks to configure the small differences from squeeze or sid. Thanks for your work on schroot! live well, vagrant -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (120, 'unstable'), (110, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (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/dash Versions of packages schroot depends on: ii libboost-filesystem1.49.0 1.49.0-3.1 ii libboost-iostreams1.49.01.49.0-3.1 ii libboost-program-options1.49.0 1.49.0-3.1 ii libboost-regex1.49.01.49.0-3.1 ii libboost-system1.49.0 1.49.0-3.1 ii libc6 2.13-35 ii libgcc1 1:4.7.1-7 ii liblockdev1 1.0.3-1.5 ii libpam0g1.1.3-7.1 ii libstdc++6 4.7.1-7 ii libuuid12.20.1-5.2 ii schroot-common 1.6.3-1 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-modules | unionfs-modules ii btrfs-tools 0.19+20120328-7 ii debootstrap 1.0.42 ii lvm22.02.95-4 ii qemu-user-static1.1.0+dfsg-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#688682: dma: modifies conffiles (policy 10.7.3): /etc/dma/dma.conf
Hello, I've looked at this issue. Peter, you are modifying dma.conf it postinst to include configuration settings grabbed through debconf, e.g.: 16 db_get dma/relayhost 17 if [ -n "$RET" ]; then 18 sed -i -re 's@^[[:space:]]*(#+[[:space:]]*)?SMARTHOST([[:space:]]+.*)?$@SMARTHOST '"$RET@" /etc/dma/dma.conf 19 else 20 sed -i -re 's@^[[:space:]]*(#+[[:space:]]*)?SMARTHOST([[:space:]]+.*)?$@#SMARTHOST@' /etc/dma/dma.conf 21 fi As Andreas pointed out this is a policy violation. Maintainer scripts must not modify conffiles (note conffiles and configuration files mean different things, in a Debian context). The alternative way to work around this, is *not* to ship the configuration file as a conffile and complying with the policy by other means. I suggest: * not to mark /etc/dma/dma.conf as conffile (i.e. override dh_installdeb's standard behavior by using a package.conffiles file) or do not ship it at all, but generate it at postinst time. * depend on ucf, do a policy compliant preservation of user changes through it, continue to prompt using debconf * You may need to use of dpkg-maintscript-helper's conffile removal assistant, but please make sure to preserve user changes. Otherwise dpkg will ignore newer versions of the file, if it is not present in the newer version. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#689077: Header path not matching llvm-config include-dir
Package: llvm-3.1-dev Version: 3.1-3~exp4 Severity: grave Tags: patch Hi, I got into some troubles with experimental llvm-3.1... Current header files are installed in: /usr/lib/llvm-3.1/include/llvm/llvm /usr/lib/llvm-3.1/include/llvm-c/llvm-c while `llvm-config --includedir` reports /usr/lib/llvm-3.1/include (ie. a directory up) I suspect that header links in llvm-3.1-dev should be diverted as in the following patch: --- debian/llvm-3.1-dev.links~ 2012-09-14 19:47:31.0 +0200 +++ debian/llvm-3.1-dev.links 2012-09-29 00:30:50.086131015 +0200 @@ -1,3 +1,3 @@ usr/lib/x86_64-linux-gnu/libLLVM-3.1.so.1 usr/lib/x86_64-linux- gnu/libLLVM-3.1.so -usr/include/llvm-c-3.1/ usr/lib/llvm-3.1/include/llvm-c -usr/include/llvm-3.1/ usr/lib/llvm-3.1/include/llvm +usr/include/llvm-c-3.1/llvm-c usr/lib/llvm-3.1/include/ +usr/include/llvm-3.1/llvm usr/lib/llvm-3.1/include/ I raised the severity as it is currently breaking everything which uses `llvm- config --includedir`. Ciao, Luca -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages llvm-3.1-dev depends on: ii libc6 2.13-35 ii libffi-dev 3.0.10-3 ii libffi5 3.0.10-3 ii libgcc1 1:4.7.1-8 ii libstdc++6 4.7.1-8 ii llvm-3.13.1-3~exp4 llvm-3.1-dev recommends no packages. llvm-3.1-dev 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#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
On Fri, 2012-09-28 at 22:50:10 +0100, Nicholas Bamber wrote: > On 28/09/12 21:55, Guillem Jover wrote: > > As such, I'm going to be closing this request if there's no additional > > feedback proposing a workable and elegant solution to this. > Thanks for responing. I think I can come up with a proposed mechanism. > I'd be grateful if you'd allow me some time as it does not need to be in > Debian before Wheezy is released. Sure thing, no hurry, it was more to do to with keeping the bts under control and clean than anything related to the wheezy release. regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689076: spamassassin: GET http://daryl.dostech.ca/sa-update/asf/1389758.tar.gz request failed
Package: spamassassin Version: 3.3.2-4 Severity: normal Tags: upstream wontfix I am reporting this so that others who search for this problem in Debian will have a reference point for it. The daily spamassassin crontab will sporadically emit this error: From: CronDaemon To: root Subject: Cron test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) /etc/cron.daily/spamassassin: http: GET http://daryl.dostech.ca/sa-update/asf/1389758.tar.gz request failed: 404 Not Found: 404 Not Found Not Found The requested URL /sa-update/asf/1389758.tar.gz was not found on this server. Apache/2.2.6 (Fedora) Server at daryl.dostech.ca Port 80 This is one of those deja-bugs that has appeared before and will appear again. See these upstream bug reports for a history and current status: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6511 2010-11-06 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6761 2012-02-20 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6838 2012-09-23 Summary: daryl.dostech.ca is a mirror hosted by one of the SA developers. It is broken and needs to be removed from the MIRRORED.BY file until it is fixed. Supposedly this was removed on 2012-09-26 14:45:21 UTC (two days ago) according to this comment: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6838#c15 But at this time (2012-09-28 16:05:34 -0600) it is still in the list. This means that sa-update may randomly select it and if so it will report the error. The sa-update script itself will retry a different server and will succeed but only after printing the above error. Even though the error is emitted the process will have succeeded from a different mirror from the MIRRORED.BY list. This is an upstream mirror problem. Bob -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689075: CVE-2011-1005: safe level bypass
Package: ruby1.9.1
Version: 1.9.3.194-1
Severity: grave
Tags: patch security
Justification: user security hole
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch
Dear Maintainer,
While running some regression tests I discovered that 1.9.3.194-1 is
vulnerable to CVE-2011-1005, despite the Ruby advisory stating
otherwise:
http://www.ruby-lang.org/en/news/2011/02/18/exception-methods-can-bypass-safe/
You can use the reproducer in the advisory for verification. Just do a
'puts $secret_path' rather than the 'open($secret_path)' block.
In Ubuntu, the attached patch was applied to achieve the following:
* SECURITY UPDATE: Safe level bypass
- debian/patches/20120927-cve_2011_1005.patch: Remove incorrect string
taint in exception handling methods. Based on upstream patch.
- CVE-2011-1005
Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-15-generic (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
diff -Nru ruby1.9.1-1.9.3.194/debian/changelog ruby1.9.1-1.9.3.194/debian/changelog
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/20120927-cve_2011_1005.patch ruby1.9.1-1.9.3.194/debian/patches/20120927-cve_2011_1005.patch
--- ruby1.9.1-1.9.3.194/debian/patches/20120927-cve_2011_1005.patch 1969-12-31 16:00:00.0 -0800
+++ ruby1.9.1-1.9.3.194/debian/patches/20120927-cve_2011_1005.patch 2012-09-28 00:09:06.0 -0700
@@ -0,0 +1,60 @@
+Description: Prevent untainted strings from being incorrectly tainted
+ This flaw allowed untainted strings to be tainted and modified, even in
+ safe level 4.
+Origin: backport, http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?revision=30903&view=revision
+Index: ruby1.9.1-1.9.3.194/error.c
+===
+--- ruby1.9.1-1.9.3.194.orig/error.c 2012-02-25 04:32:19.0 -0800
ruby1.9.1-1.9.3.194/error.c 2012-09-26 10:10:15.164576749 -0700
+@@ -569,7 +569,6 @@
+
+ if (NIL_P(mesg)) return rb_class_name(CLASS_OF(exc));
+ r = rb_String(mesg);
+-OBJ_INFECT(r, exc);
+ return r;
+ }
+
+@@ -854,10 +853,9 @@
+ if (NIL_P(mesg)) return rb_class_name(CLASS_OF(exc));
+ StringValue(str);
+ if (str != mesg) {
+- rb_iv_set(exc, "mesg", mesg = str);
++ OBJ_INFECT(str, mesg);
+ }
+-OBJ_INFECT(mesg, exc);
+-return mesg;
++return str;
+ }
+
+ /*
+Index: ruby1.9.1-1.9.3.194/test/ruby/test_exception.rb
+===
+--- ruby1.9.1-1.9.3.194.orig/test/ruby/test_exception.rb 2012-02-07 16:44:05.0 -0800
ruby1.9.1-1.9.3.194/test/ruby/test_exception.rb 2012-09-26 10:10:15.164576749 -0700
+@@ -333,4 +333,26 @@
+ load(t.path)
+ end
+ end
++
++ def test_to_s_taintness_propagation
++for exc in [Exception, NameError]
++ m = "abcdefg"
++ e = exc.new(m)
++ e.taint
++ s = e.to_s
++ assert_equal(false, m.tainted?,
++ "#{exc}#to_s should not propagate taintness")
++ assert_equal(false, s.tainted?,
++ "#{exc}#to_s should not propagate taintness")
++end
++
++o = Object.new
++def o.to_str
++ "foo"
++end
++o.taint
++e = NameError.new(o)
++s = e.to_s
++assert_equal(true, s.tainted?)
++ end
+ end
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/series ruby1.9.1-1.9.3.194/debian/patches/series
--- ruby1.9.1-1.9.3.194/debian/patches/series 2012-05-27 15:46:34.0 -0700
+++ ruby1.9.1-1.9.3.194/debian/patches/series 2012-09-28 00:32:14.0 -0700
@@ -16,3 +16,4 @@
110829-hurd_dirent_usage.patch
hurd-path-max.diff
20120517-r35434.patch
+20120927-cve_2011_1005.patch
Bug#687574: Multiple security issues
On 13/09/2012 23:27, Moritz Muehlenhoff wrote: > Package: libv8 > Severity: grave > Tags: security > > Hi, > please check the status of these security issues in libv8. > They were all fixed in Chrome, but it's not clearly from > which Chrome release the libv8 package in Wheezy was cut: > > http://security-tracker.debian.org/tracker/CVE-2011-3111 > http://security-tracker.debian.org/tracker/CVE-2011-3057 > http://security-tracker.debian.org/tracker/CVE-2011-2881 > http://security-tracker.debian.org/tracker/CVE-2011-3115 > http://security-tracker.debian.org/tracker/CVE-2011-3103 > http://security-tracker.debian.org/tracker/CVE-2011-3092 > http://security-tracker.debian.org/tracker/CVE-2011-2875 Hi, the current status of these CVE in libv8 3.8.9.20-1 is : CVE-2011-3111 Fixed in upstream version libv8 3.8.9.23. Those CVE are fixed or not applicable in libv8 3.8.9.20 : CVE-2011-3057 fixed CVE-2011-2881 fixed CVE-2011-3115 affects libv8 >= 3.9 CVE-2011-3103 affects libv8 >= 3.9 CVE-2011-3092 affects libv8 >= 3.9 CVE-2011-2875 fixed I'm preparing a libv8 3.8.9.20-2 package fixing CVE-2011-3111 (and few other bugs). Regards, Jérémy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689074: ruby1.9.1: RubyGems should use ca-certificates for SSL verification
Package: ruby1.9.1
Version: 1.9.3.194-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch
Dear Maintainer,
While I was preparing an Ubuntu ruby1.9.1 update for CVE-2012-2126, I
noticed that ruby1.9.1-1.9.3.194-1 included its own trusted CA
certificate bundle, rather than using the bundle from ca-certificates,
to do server certificate verification in the gem fetcher.
In Ubuntu, the attached patch was applied to achieve the following:
* Make the RubyGems fetcher use distro-provided ca-certificates
(LP: #1057926)
- debian/control: Add ca-certificates to libruby1.9.1 depends so that
rubygems can perform certificate verification
- debian/rules: Don't install SSL certificates from upstream sources
- debian/patches/20120927-rubygems_disable_upstream_certs.patch: Use
/etc/ssl/certs/ca-certificates.crt for the trusted CA certificates.
Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-15-generic (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
diff -Nru ruby1.9.1-1.9.3.194/debian/changelog ruby1.9.1-1.9.3.194/debian/changelog
diff -Nru ruby1.9.1-1.9.3.194/debian/control ruby1.9.1-1.9.3.194/debian/control
--- ruby1.9.1-1.9.3.194/debian/control 2012-05-27 15:47:25.0 -0700
+++ ruby1.9.1-1.9.3.194/debian/control 2012-09-28 14:29:00.0 -0700
@@ -29,7 +29,7 @@
Package: libruby1.9.1
Section: libs
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ca-certificates, ${shlibs:Depends}, ${misc:Depends}
Conflicts: libdbm-ruby1.9.1, libgdbm-ruby1.9.1, libreadline-ruby1.9.1, libopenssl-ruby1.9.1, irb1.8 (<< 1.9.1.378-2~), rdoc1.8 (<< 1.9.1.378-2~)
Replaces: libdbm-ruby1.9.1, libgdbm-ruby1.9.1, libreadline-ruby1.9.1, libopenssl-ruby1.9.1, irb1.8, rdoc1.8
Provides: libdbm-ruby1.9.1, libgdbm-ruby1.9.1, libreadline-ruby1.9.1, libopenssl-ruby1.9.1
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/20120927-rubygems_disable_upstream_certs.patch ruby1.9.1-1.9.3.194/debian/patches/20120927-rubygems_disable_upstream_certs.patch
--- ruby1.9.1-1.9.3.194/debian/patches/20120927-rubygems_disable_upstream_certs.patch 1969-12-31 16:00:00.0 -0800
+++ ruby1.9.1-1.9.3.194/debian/patches/20120927-rubygems_disable_upstream_certs.patch 2012-09-28 00:09:07.0 -0700
@@ -0,0 +1,30 @@
+Description: Use the certificates maintained by the distro
+ Rather than using the certificates packaged in the upstream sources to verify
+ server SSL certificates, use the certificates provided by the ca-certificates
+ package.
+Author: Tyler Hicks
+Forwarded: not-needed
+Index: ruby1.9.1-1.9.3.194/lib/rubygems/remote_fetcher.rb
+===
+--- ruby1.9.1-1.9.3.194.orig/lib/rubygems/remote_fetcher.rb 2012-09-27 10:48:23.046684546 -0700
ruby1.9.1-1.9.3.194/lib/rubygems/remote_fetcher.rb 2012-09-27 10:48:42.590685014 -0700
+@@ -8,7 +8,7 @@
+
+ class Gem::RemoteFetcher
+
+- BuiltinSSLCerts = File.expand_path("./ssl_certs/*.pem", File.dirname(__FILE__))
++ BuiltinSSLCerts = "/etc/ssl/certs/ca-certificates.crt"
+
+ include Gem::UserInteraction
+
+@@ -354,8 +354,8 @@
+ end
+
+ def add_rubygems_trusted_certs(store)
+-Dir.glob(BuiltinSSLCerts).each do |ssl_cert_file|
+- store.add_file ssl_cert_file
++if File.file? BuiltinSSLCerts
++ store.add_file BuiltinSSLCerts
+ end
+ end
+
diff -Nru ruby1.9.1-1.9.3.194/debian/patches/series ruby1.9.1-1.9.3.194/debian/patches/series
--- ruby1.9.1-1.9.3.194/debian/patches/series 2012-05-27 15:46:34.0 -0700
+++ ruby1.9.1-1.9.3.194/debian/patches/series 2012-09-28 00:32:14.0 -0700
@@ -16,3 +16,5 @@
110829-hurd_dirent_usage.patch
hurd-path-max.diff
20120517-r35434.patch
+20120927-rubygems_disable_upstream_certs.patch
diff -Nru ruby1.9.1-1.9.3.194/debian/rules ruby1.9.1-1.9.3.194/debian/rules
--- ruby1.9.1-1.9.3.194/debian/rules 2012-06-02 03:35:36.0 -0700
+++ ruby1.9.1-1.9.3.194/debian/rules 2012-09-28 00:09:07.0 -0700
@@ -170,7 +170,8 @@
for f in libruby-$(ruby_ver).so.$(ruby_ver) libruby-$(ruby_ver).so.$(ruby_ver_major); do \
echo usr/lib/$$f; \
done) | xargs dh_movefiles -p$(cdbs_curpkg)
- dh_movefiles -p$(cdbs_curpkg) $(ruby_libdir)
+ # Do not install the SSL certs bundled in the upstream source
+ dh_movefiles -p$(cdbs_curpkg) -Xssl_certs $(ruby_libdir)
cd $(DEB_SRCDIR)/ext && \
for dir in \
Bug#689073: libsane-dev is not Multi-Arch compatible
Package: libsane-dev Version: 1.0.22-7.4 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libsane.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no architecture-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libsane-dev depends on: ii libavahi-client-dev 0.6.31-1 ii libgphoto2-2-dev2.4.14-2 ii libieee1284-3-dev 0.2.11-10 ii libjpeg8-dev [libjpeg-dev] 8d-1 ii libsane 1.0.22-7.4 ii libtiff4-dev3.9.6-7 ii libusb-dev 2:0.1.12-20 ii libv4l-dev 0.8.8-3 ii pkg-config 0.26-1 Versions of packages libsane-dev recommends: ii libsane-extras-dev 1.0.22.2 libsane-dev 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#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
On 28/09/12 21:55, Guillem Jover wrote: > Control: severity -1 wishlist > > Hi! > > On Fri, 2012-09-28 at 20:58:13 +0100, Nicholas Bamber wrote: >> Package: dpkg-dev >> Version: 1.16.8 >> Severity: normal >> >> Debian Policy version 3.9.4 adds support for the Built-Using field. >> This field can be different on each build run and so is analagous to >> the shlibs fields added via dpkg-shlibdeps. > > Even if it might seem so, it's really not like those substvars, > because the values to put into Built-Using cannot be easily computed > automatically (if at all). See previous discussion in #653575. > >> The differences are: >> 1.) we are talking about static libraries rather than shared libraries > > Which cannot be reliably inferred from stripped binaries, in contrast > to shared libraries. > >> 2.) we need the source package rather than the binary package. > > Which can already be easily retrieved through the dpkg-query > source:Package and source:Version virtual fields. > > As such, I'm going to be closing this request if there's no additional > feedback proposing a workable and elegant solution to this. > > thanks, > guillem Guillem, Thanks for responing. I think I can come up with a proposed mechanism. I'd be grateful if you'd allow me some time as it does not need to be in Debian before Wheezy is released. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689072: renameutils: imv should be able to take more than one file as argument
Package: renameutils Version: 0.12.0-1 Severity: wishlist Tags: upstream Forwarded: https://savannah.nongnu.org/bugs/?37459 Dear Maintainer, I see myself doing this nearly everytime I use imv: $ imv * imv: too many arguments $ for i in *; do imv $i; done > file1 > file2 > file3 [...] It would be helpful if imv iterates through all files given on the commandline when called with more than one parameter. -- 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/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 renameutils depends on: ii libc6 2.13-35 ii libreadline6 6.2-8 renameutils recommends no packages. renameutils 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#689071: libdbus-1-dev is not Multi-Arch compatible
Package: libdbus-1-dev Version: 1.6.0-1 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libdbus-1.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no hardware-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libdbus-1-dev depends on: ii libdbus-1-3 1.6.0-1 ii pkg-config 0.26-1 libdbus-1-dev recommends no packages. libdbus-1-dev 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#689070: Please take upstream D-Bus patches for CVE-2012-3524
Package: dbus Severity: serious Justification: local privilege escalation Tags: security Hi, CVE-2012-3524 is about setuid binaries linking libdbus being easily trickable to do bad things via a malicious PATH (for finding dbus-launch), or through a DBUS_* address variable using the unixexec address type. Initially the D-Bus developers thought that this should be fixed on the application side (hence the comment in the security-tracker), but decided that it would be better to have a defense-in-depth approach, and change _dbus_getenv to not succeed if the current program is setuid or similar, since that's faster than patching every relevant program. There's a patch in the D-Bus 1.6.6 release that implements this. Many other distros, including RHEL/Fedora, SUSE, and Ubuntu have taken this patch already. There are some other hardening things in the 1.6.6 release that broke gnome-keyring, prompting a 1.6.8 release a few hours later to revert those; you should either take 1.6.8, or just backport the four patches that weren't reverted in 1.6.8: http://cgit.freedesktop.org/dbus/dbus/commit/?id=23fe78ceefb6cefcd58a49c77d1154b68478c8d2 http://cgit.freedesktop.org/dbus/dbus/commit/?id=4b351918b9f70eaedbdb3ab39208bc1f131efae0 http://cgit.freedesktop.org/dbus/dbus/commit/?id=57ae3670508bbf4ec57049de47c9cae727a64802 http://cgit.freedesktop.org/dbus/dbus/commit/?id=f68dbdc3e6f895012ce33939fb524accf31bcca5 I think these are all easily backportable, but I'm happy to supply a debdiff if that'd make it easier for you. More discussion of the issue can be found at https://bugs.freedesktop.org/show_bug.cgi?id=52202 https://bugzilla.novell.com/show_bug.cgi?id=697105 https://bugzilla.redhat.com/show_bug.cgi?id=847402 http://seclists.org/oss-sec/2012/q3/29 -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689069: rubygems: RubyGems should use ca-certificates for SSL verification
Package: rubygems
Version: 1.8.24-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch
Dear Maintainer,
While I was preparing an Ubuntu rubygems update for CVE-2012-2126, I
noticed that rubygems-1.8.24-1 included its own trusted CA certificate
bundle, rather than using the bundle from ca-certificates, to do server
certificate verification in the gem fetcher.
In Ubuntu, the attached patch was applied to achieve the following:
* Make the RubyGems fetcher use distro-provided ca-certificates
(LP: #1057926)
- debian/control: Add ca-certificates to rubygems depends so that
rubygems can perform certificate verification
- debian/rules: Don't install SSL certificates from upstream sources
- debian/patches/20120927-disable_upstream_certs.patch: Use
/etc/ssl/certs/ca-certificates.crt for the trusted CA certificates.
Thanks for considering the patch.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-15-generic (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
diff -Nru rubygems-1.8.24/debian/changelog rubygems-1.8.24/debian/changelog
diff -Nru rubygems-1.8.24/debian/control rubygems-1.8.24/debian/control
--- rubygems-1.8.24/debian/control 2012-06-09 06:44:27.0 -0700
+++ rubygems-1.8.24/debian/control 2012-09-28 14:18:32.0 -0700
@@ -14,7 +14,7 @@
Package: rubygems
Architecture: all
XB-Ruby-Versions: ${ruby:Versions}
-Depends: ${misc:Depends}, ruby1.8
+Depends: ca-certificates, ${misc:Depends}, ruby1.8
Recommends: ruby1.8-dev, build-essential
Replaces: rubygems1.8 (<< 1.7.2-1~), rubygems-doc (<< 1.7.2-1~)
Conflicts: rubygems1.8 (<< 1.7.2-1~), rubygems-doc (<< 1.7.2-1~)
diff -Nru rubygems-1.8.24/debian/patches/20120927-disable_upstream_certs.patch rubygems-1.8.24/debian/patches/20120927-disable_upstream_certs.patch
--- rubygems-1.8.24/debian/patches/20120927-disable_upstream_certs.patch 1969-12-31 16:00:00.0 -0800
+++ rubygems-1.8.24/debian/patches/20120927-disable_upstream_certs.patch 2012-09-27 12:12:57.0 -0700
@@ -0,0 +1,30 @@
+Description: Use the certificates maintained by the distro
+ Rather than using the certificates packaged in the upstream sources to verify
+ server SSL certificates, use the certificates provided by the ca-certificates
+ package.
+Author: Tyler Hicks
+Forwarded: not-needed
+Index: rubygems-1.8.24/lib/rubygems/remote_fetcher.rb
+===
+--- rubygems-1.8.24.orig/lib/rubygems/remote_fetcher.rb 2012-04-27 16:15:17.0 -0700
rubygems-1.8.24/lib/rubygems/remote_fetcher.rb 2012-09-27 12:12:53.970805064 -0700
+@@ -8,7 +8,7 @@
+
+ class Gem::RemoteFetcher
+
+- BuiltinSSLCerts = File.expand_path("./ssl_certs/*.pem", File.dirname(__FILE__))
++ BuiltinSSLCerts = "/etc/ssl/certs/ca-certificates.crt"
+
+ include Gem::UserInteraction
+
+@@ -365,8 +365,8 @@
+ end
+
+ def add_rubygems_trusted_certs(store)
+-Dir.glob(BuiltinSSLCerts).each do |ssl_cert_file|
+- store.add_file ssl_cert_file
++if File.file? BuiltinSSLCerts
++ store.add_file BuiltinSSLCerts
+ end
+ end
+
diff -Nru rubygems-1.8.24/debian/patches/series rubygems-1.8.24/debian/patches/series
--- rubygems-1.8.24/debian/patches/series 2012-06-09 06:44:27.0 -0700
+++ rubygems-1.8.24/debian/patches/series 2012-09-27 12:23:22.0 -0700
@@ -5,3 +5,4 @@
fix-shebang.diff
20120608-fix-test_gem_platform.rb.diff
20120608-fix-assert_match.diff
+20120927-disable_upstream_certs.patch
diff -Nru rubygems-1.8.24/debian/rules rubygems-1.8.24/debian/rules
--- rubygems-1.8.24/debian/rules 2012-06-09 06:44:27.0 -0700
+++ rubygems-1.8.24/debian/rules 2012-09-27 20:37:45.0 -0700
@@ -25,6 +25,8 @@
override_dh_auto_install:
dh_auto_install
+ # Do not install the SSL certs bundled in the upstream source
+ rm -rf debian/rubygems/usr/lib/ruby/vendor_ruby/rubygems/ssl_certs
mv debian/rubygems/usr/bin/gem debian/rubygems/usr/bin/gem1.8
rm debian/rubygems/usr/bin/update_rubygems # not needed
# we don't want to share rubygems with 1.9.
Bug#689068: libxi-dev is not Multi-Arch compatible
Package: libxi-dev Version: 2:1.6.1-1 Severity: normal Dear Maintainer, The amd64 version conflicts with the i386 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libXi.so symbolic link is missing so that developping 32bit applications using this library is impossible on a 64bit system. Furthermore this development package does not seem to be multiarch aware as there is no Multi-Arch field. My understanding is that as long as there are no hardware-dependent headers there is no obstacle (i.e. no toolchain issue) to tagging the development package as 'Multi-Arch: same'. The symbolic link (and any static libraries) should be no issue as they are already in the architecture-qualified folders. A good model for this appears to be the libx11-dev package. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxi-dev depends on: ii libx11-dev 2:1.5.0-1 ii libxext-dev 2:1.3.1-2 ii libxi6 2:1.6.1-1 ii x11proto-input-dev 2.2-1 ii xorg-sgml-doctools 1:1.10-1 libxi-dev recommends no packages. libxi-dev 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#679978: base: fails to shutdown, hard reset required
Package: base Followup-For: Bug #679978 Dear Maintainer, * What led up to the situation? Every time I shutdown the system I can read a similar message regardless the kind of power supply (battery or AC). * What exactly did you do (or not do) that was effective (or ineffective)? I reviewed all the logs in the user folder and in /var/log/ to get more information, I haven't seen the message anywhere else though. I did nothing because the system seems to work properly. From my point of view it is an annoying message. I am replying to provide more information. I hope it will help. Let me know if I can do anything else. robert -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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#689067: unblock: dasher/4.11-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock dasher for a small but useful dependency change (the
dependency on at-spi seems to confuse APT).
dasher (4.11-2) unstable; urgency=low
* Update repository URL.
* Replace at-spi dependency with libatk-adaptor.
unblock dasher/4.11-2
Thanks,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
diff -u dasher-4.11/debian/changelog dasher-4.11/debian/changelog
--- dasher-4.11/debian/changelog
+++ dasher-4.11/debian/changelog
@@ -1,3 +1,10 @@
+dasher (4.11-2) unstable; urgency=low
+
+ * Update repository URL.
+ * Replace at-spi dependency with libatk-adaptor.
+
+ -- Josselin Mouette Fri, 28 Sep 2012 23:05:10 +0200
+
dasher (4.11-1.2) unstable; urgency=low
* Non-maintainer upload.
diff -u dasher-4.11/debian/control.in dasher-4.11/debian/control.in
--- dasher-4.11/debian/control.in
+++ dasher-4.11/debian/control.in
@@ -4,8 +4,8 @@
Maintainer: Debian GNOME Maintainers
Uploaders: Alan Baghumian ,
@GNOME_TEAM@
-Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/dasher
-Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/dasher
+Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/attic/dasher
+Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/attic/dasher
Build-Depends: debhelper (>= 5.0.0),
cdbs,
gnome-pkg-tools (>= 0.6),
@@ -31,7 +31,7 @@
Architecture: any
Depends: ${misc:Depends},
${shlibs:Depends},
- at-spi,
+ libatk-adaptor,
dasher-data (= ${source:Version})
Description: A graphical predictive text input system
Dasher is an information-efficient text-entry interface, driven by natural
Bug#689066: RM: gok/2.30.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hi, please remove gok from testing. It has been replaced by caribou and has no reverse dependencies. Specifically for wheezy, it causes upgrade trouble by still depending on at-spi. RM request for sid has already been filed as #689065. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
Control: severity -1 wishlist Hi! On Fri, 2012-09-28 at 20:58:13 +0100, Nicholas Bamber wrote: > Package: dpkg-dev > Version: 1.16.8 > Severity: normal > > Debian Policy version 3.9.4 adds support for the Built-Using field. > This field can be different on each build run and so is analagous to > the shlibs fields added via dpkg-shlibdeps. Even if it might seem so, it's really not like those substvars, because the values to put into Built-Using cannot be easily computed automatically (if at all). See previous discussion in #653575. > The differences are: > 1.) we are talking about static libraries rather than shared libraries Which cannot be reliably inferred from stripped binaries, in contrast to shared libraries. > 2.) we need the source package rather than the binary package. Which can already be easily retrieved through the dpkg-query source:Package and source:Version virtual fields. As such, I'm going to be closing this request if there's no additional feedback proposing a workable and elegant solution to this. 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#622863: make -j fails with strace (wait: No child processes)
Package: make Version: 3.81-8.2 Followup-For: Bug #622863 I managed to reproduce this once as well, by running "make -j5" in a Linux kernel tree and hitting Ctrl-C: ~/src/linux$ make -j5 scripts/kconfig/conf --silentoldconfig Kconfig SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_32.h SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_64.h SYSTBL arch/x86/syscalls/../include/generated/asm/syscalls_32.h SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_x32.h SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_32_ia32.h HOSTCC arch/x86/tools/relocs SYSHDR arch/x86/syscalls/../include/generated/asm/unistd_64_x32.h SYSTBL arch/x86/syscalls/../include/generated/asm/syscalls_64.h CHK include/linux/version.h UPD include/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h ^Cmake[1]: *** Deleting file `arch/x86/syscalls/../include/generated/asm/syscalls_64.h' make[1]: *** Deleting file `arch/x86/syscalls/../include/generated/asm/syscalls_32.h' make[1]: *** [block/partitions] Interrupt make: *** [block/modules.builtin] Interrupt make[1]: *** [arch/x86/syscalls/../include/generated/asm/syscalls_32.h] Interrupt make[1]: *** [arch/x86/syscalls/../include/generated/asm/syscalls_64.h] Interrupt make: *** [archheaders] Interrupt make: *** wait: No child processes. Stop. make: INTERNAL: Exiting with 6 jobserver tokens available; should be 5! - Josh Triplett -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages make depends on: ii libc6 2.13-35 make recommends no packages. Versions of packages make suggests: pn make-doc -- 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#689065: RM: gok -- ROM; Deprecated, replaced by caribou
Package: ftp.debian.org Severity: normal Hi, please remove gok from the archive. It has been replaced by caribou and has no reverse dependencies. Thanks, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689064: fwknop: FTBFS on mips* ("relocation R_MIPS_26 against `getenv' can not be used when making a shared object")
Source: fwknop
Version: 2.0.3-1
Severity: serious
Hi,
fwknop fails to build on mips{,el}. From the mips build log:
libtool: link: gcc -g -O2 -Wformat -Werror=format-security -Wall -g -O2 -Wl,-z
-Wl,relro -Wl,-z -Wl,now -Wall -fstack-protector-all -fstack-protector -fPIE
-pie -D_FORTIFY_SOURCE=2 -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/fwknop
fwknop-fwknop.o fwknop-config_init.o fwknop-spa_comm.o fwknop-utils.o
fwknop-http_resolve_host.o fwknop-getpasswd.o ../lib/.libs/libfko.so
/usr/bin/ld: fwknop-fwknop.o: relocation R_MIPS_26 against `getenv' can not be
used when making a shared object; recompile with -fPIC
fwknop-fwknop.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [fwknop] Error 1
make[4]: Leaving directory
`/build/buildd2-fwknop_2.0.3-1-mips-MZ2TL7/fwknop-2.0.3/client'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/build/buildd2-fwknop_2.0.3-1-mips-MZ2TL7/fwknop-2.0.3'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/build/buildd2-fwknop_2.0.3-1-mips-MZ2TL7/fwknop-2.0.3'
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory
`/build/buildd2-fwknop_2.0.3-1-mips-MZ2TL7/fwknop-2.0.3'
make: *** [build-arch] Error 2
Full logs available via
https://buildd.debian.org/status/package.php?p=fwknop
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689025: slapd: chokes on unresponsive syslogd
> A full GDB backtrace of all threads would be useful for examining this issue > any further. kI will have to build a test case for that. Obviously, I cannot break production deliberately for that ;). -nik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689025: slapd: chokes on unresponsive syslogd
--On Friday, September 28, 2012 2:19 PM +0200 Dominik George wrote: Package: slapd Version: 2.4.31-1 Severity: important The slapd process hangs when sending log data to an unresponsive syslogd. In out site setup, all servers log to a central MySQL database through rsyslog. rsyslog becomes unresponsive when having too much data queued, which happened when the line to the log server came down for a loner time period several times last week. rsyslog then refuses to accept any new logs before commiting all queued messages to MySQL. Although this is possibly an rsyslog bug, slapd should not run into a freeze due to that. It didn't even come back up after syslog functionality had been re-established. A full GDB backtrace of all threads would be useful for examining this issue any further. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681830: gdm3: spawns X continuously when gnome-session dies
Package: gdm3 Version: 3.4.1-3 Followup-For: Bug #681830 Just tried again ... no display connected and gdm3 goes spawning $ ls -la /var/log/Xorg.*.log | wc -l 450 Andreas -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gdm3 depends on: ii accountsservice 0.6.21-6 ii adduser 3.113+nmu3 ii dconf-gsettings-backend 0.12.1-2 ii dconf-tools 0.12.1-2 ii debconf [debconf-2.0] 1.5.46 ii dpkg1.16.8 ii gir1.2-freedesktop 1.32.1-1 ii gir1.2-glib-2.0 1.32.1-1 ii gnome-session [x-session-manager] 3.4.2.1-2 ii gnome-session-bin 3.4.2.1-2 ii gnome-session-fallback [x-session-manager] 3.4.2.1-2 ii gnome-settings-daemon 3.4.2-5 ii gnome-terminal [x-terminal-emulator]3.4.1.1-1+build1 ii gsettings-desktop-schemas 3.4.2-1 ii kde-window-manager [x-window-manager] 4:4.8.4-3 ii konsole [x-terminal-emulator] 4:4.8.4-1 ii libaccountsservice0 0.6.21-6 ii libatk1.0-0 2.4.0-2 ii libattr11:2.4.46-8 ii libaudit0 1:1.7.18-1.1 ii libc6 2.13-35 ii libcairo-gobject2 1.12.2-2 ii libcairo2 1.12.2-2 ii libcanberra-gtk3-0 0.28-4 ii libcanberra00.28-4 ii libdbus-1-3 1.6.0-1 ii libdbus-glib-1-20.100-1 ii libfontconfig1 2.9.0-7 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libglib2.0-bin 2.32.3-1 ii libgtk-3-0 3.4.2-3 ii libpam-modules 1.1.3-7.1 ii libpam-runtime 1.1.3-7.1 ii libpam0g1.1.3-7.1 ii libpango1.0-0 1.30.0-1 ii librsvg2-common 2.36.1-1 ii libselinux1 2.1.9-5 ii libupower-glib1 0.9.17-1 ii libwrap07.6.q-24 ii libx11-62:1.5.0-1 ii libxau6 1:1.0.7-1 ii libxdmcp6 1:1.1.1-1 ii libxklavier16 5.2.1-1 ii libxrandr2 2:1.3.2-2 ii lsb-base4.1+Debian7 ii metacity [x-window-manager] 1:2.34.3-3 ii policykit-1-gnome 0.105-2 ii twm [x-window-manager] 1:1.0.6-1 ii upower 0.9.17-1 ii x11-common 1:7.7+1 ii x11-xserver-utils 7.7~3 ii xfce4-session [x-session-manager] 4.8.3-2+b1 ii xfce4-terminal [x-terminal-emulator]0.4.8-1+b1 ii xfwm4 [x-window-manager]4.8.3-2 ii xterm [x-terminal-emulator] 278-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.5.3-1 ii desktop-base 7.0.3 ii gnome-icon-theme 3.4.0-2 ii gnome-icon-theme-symbolic 3.4.0-2 ii x11-xkb-utils 7.7~1 ii xserver-xephyr 2:1.12.3.902-1 ii xserver-xorg 1:7.7+1 ii zenity 3.4.0-2 Versions of packages gdm3 suggests: ii gnome-orca3.4.2-2 ii gnome-shell 3.4.2-1 pn gok ii libpam-gnome-keyring 3.4.1-5 -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680577: (no subject)
I'll add the requested skip in 1:6.0.12-1, but I can't test it as I don't have emacs21 installed and it's not available in Wheezy. At least the skip doesn't seem to break installation on emacs23 :). signature.asc Description: PGP signature
Bug#689063: dhelp: updated german debconf translation
Package: dhelp Severity: wishlist Tags: patch,l10n Hi, attached you get the updated german debconf translation for dhelp, version 0.6.22. Please include it in your package. Thanks for your i18n efforts. So long Holger -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Created with Sylpheed 3.0.2 under DEBIAN GNU/LINUX 6.0 - S q u e e z e Registered LinuxUser #311290 - http://counter.li.org/ = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = dhelp-0.6.22_de.po.gz Description: Binary data
Bug#689062: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool
Package: dpkg-dev Version: 1.16.8 Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Debian Policy version 3.9.4 adds support for the Built-Using field. This field can be different on each build run and so is analagous to the shlibs fields added via dpkg-shlibdeps. The differences are: 1.) we are talking about static libraries rather than shared libraries 2.) we need the source package rather than the binary package. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (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 dpkg-dev depends on: ii base-files6.11 ii binutils 2.22-7.1 ii bzip2 1.0.6-4 ii libdpkg-perl 1.16.8 ii make 3.81-8.2 ii patch 2.6.1-3 ii xz-utils 5.1.1alpha+20120614-1 Versions of packages dpkg-dev recommends: ii build-essential 11.5 ii clang [c-compiler] 3.1-8 ii fakeroot 1.18.4-2 ii gcc [c-compiler] 4:4.7.2-1 ii gcc-4.4 [c-compiler] 4.4.7-3 ii gcc-4.5 [c-compiler] 4.5.4-1 ii gcc-4.6 [c-compiler] 4.6.3-10 ii gcc-4.7 [c-compiler] 4.7.2-2 ii gnupg1.4.12-4+b1 ii gpgv 1.4.12-4+b1 ii libalgorithm-merge-perl 0.08-2 Versions of packages dpkg-dev suggests: ii debian-keyring 2012.06.01 -- 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#689061: Percona Toolkit version (2.1.4) released, please consider packaging it
Package: percona-toolkit Version: 2.1.4 Severity: wishlist Hi. Mostly following the instructions left here: https://bugs.launchpad.net/percona-toolkit/+bug/932883 by Dario; Thanks for your time! Here's the release announcement: The Percona Toolkit team is happy to announce the release of Percona Toolkit version 2.1.4. This is the fifth stable release in the 2.1 series, and primarily a bug-fix release; We suggest that users upgrade to the latest version of the tools. The complete list of changes is on the Launchpad milestone for 2.1.4, but here are some highlights the release: pt-table-checksum now works with Percona XtraDB Cluster The “Version Check” feature, explained at length here: http://www.mysqlperformanceblog.com/2012/09/10/introducing-the-version-check-feature-in-percona-toolkit/. –defaults-file is now used when connecting to discovered slaves in pt-table-checksum All in all, a solid bug-fix release, with the addition of some new features too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689060: base: Mac keyboard layout is incorrect on MacBook Pros
Package: base Severity: normal On my late 2011 MacBook Pro, the keys to the left of the z and above shift give the incorrect characters. The key to the left of z is marked with ` and ~ whereas it prnts < and > The key above shift is marked with § and § whereas it prints ` and ~ -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688964: qemu-kvm: Fedora 17 guest hangs on boot with soft lockup in udevd
On 09/27/2012 11:06 PM, Michael Tokarev wrote: Easiest way to get a backtrace is to add a serial console to guest (I used -serial file:out), set it up in grub (console=ttyS0), AND remove "quiet" parameter from kernel command line, together with "rhgb". The "quiet" thing is the most frequently forgotten parameter. Thanks. I suspected there was something like that. I used the serial console in virt-manager, but obviously it didn't help. Shall be removing both of these parameters from all my VMs. Thank you very much for fixing it this fast :)! It was really easy to find the stuff in between the 13 commits :) And Jan noted the right place as well, it is more his work than mine. Well, still, nothing was preventing you from putting it off ;) Now, it isn't really clear when this fix will hit the debian archive (ie, will be released to debian). I understand it is annoying to have bugs like this, but I'm afraid to push even more work to the release team. Current freeze policy is to allow fixing only bugs with severity "serious" and up, and your does not qualify :) Sure, I agree with the policy. It's not a big deal for me to live with a self-built package - it's only needed for a single laptop. However, someone else might find this cumbersome. Could you please tag your last two dfsg releases, so it is easier to check them out next time? I tagged it the time when I uploaded them, but forgot to push. I forget to push the tags quite often myself. Note I changed the tag format to include package name too, since else the tags in qemu and qemu-kvm packages/repositories clashes with each other. Sure, the important thing is that they're there. Thank you :) Sincerely, Nick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688512: unblock or tpu: glib2.0/2.33.12+really2.32.4-1
Le vendredi 28 septembre 2012 à 12:56 +0200, Niels Thykier a écrit :
> The diff looks mostly reasonable, though I have one case where it seems
> to me that the new version introduces a leak (see attached glib.leak).
Thanks for the thorough review.
I have committed a fix for the leak in our SVN and reported it upstream.
Note that it has a small impact since it only affects
glib-compile-resources, not the library itself.
Changes currently sitting in our svn are attached (since they also
target wheezy).
> Other than that, I think it may have to wait until the next d-i beta is
> out. Personally I do not mind the extra couple of days in unstable as
> the diff is rather large and I could quite possibly have missed something.
Sure.
> Also, on the part of (re-)uploading it as 2.32.{4,5}-1 via t-p-u. I am
> not sure it is an acceptable use of t-p-u, so my default would be "no"
> on this.
As you wish. It is mostly a cosmetic issue.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Index: debian/libglib2.0-doc.links
===
--- debian/libglib2.0-doc.links (révision 35787)
+++ debian/libglib2.0-doc.links (copie de travail)
@@ -2,4 +2,3 @@
usr/share/doc/libglib2.0-doc/gio usr/share/gtk-doc/html/gio
usr/share/doc/libglib2.0-doc/glib usr/share/gtk-doc/html/glib
usr/share/doc/libglib2.0-doc/gobject usr/share/gtk-doc/html/gobject
-usr/share/doc/libglib2.0-doc/gdbus-object-manager-example usr/share/gtk-doc/html/gdbus-object-manager-example
Index: debian/patches/20_glib-compile-resources_leak.patch
===
--- debian/patches/20_glib-compile-resources_leak.patch (révision 0)
+++ debian/patches/20_glib-compile-resources_leak.patch (révision 35834)
@@ -0,0 +1,36 @@
+Index: glib2.0-2.33.12+really2.32.4/gio/glib-compile-resources.c
+===
+--- glib2.0-2.33.12+really2.32.4.orig/gio/glib-compile-resources.c 2012-07-14 22:33:11.0 +0200
glib2.0-2.33.12+really2.32.4/gio/glib-compile-resources.c 2012-09-28 21:32:32.168548276 +0200
+@@ -272,7 +272,6 @@ end_element (GMarkupParseContext *conte
+ if (state->preproc_options)
+ {
+ gchar **options;
+- gchar *stderr_child = NULL;
+ guint i;
+ gboolean xml_stripblanks = FALSE;
+ gboolean to_pixdata = FALSE;
+@@ -298,6 +297,7 @@ end_element (GMarkupParseContext *conte
+ if (xml_stripblanks && xmllint != NULL)
+ {
+ gchar *argv[8];
++ gchar *stderr_child = NULL;
+ int status, fd, argc;
+
+ tmp_file = g_strdup ("resource-");
+@@ -336,6 +336,7 @@ end_element (GMarkupParseContext *conte
+ {
+ g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
+_("Error processing input file with xmllint:\n%s"), stderr_child);
++ g_free (stderr_child);
+ goto cleanup;
+ }
+ #endif
+@@ -392,6 +393,7 @@ end_element (GMarkupParseContext *conte
+ {
+ g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
+ _("Error processing input file with to-pixdata:\n%s"), stderr_child);
++ g_free (stderr_child);
+ goto cleanup;
+ }
+ #endif
Index: debian/patches/series
===
--- debian/patches/series (révision 35787)
+++ debian/patches/series (copie de travail)
@@ -4,6 +4,7 @@
04_homedir_env.patch
05_run-gio-tests-with-a-dbus-session.patch
10_gdbus_race.patch
+20_glib-compile-resources_leak.patch
61_glib-compile-binaries-path.patch
90_gio-modules-multiarch-compat.patch
91_revert_schema_path_warning.patch
Index: debian/changelog
===
--- debian/changelog (révision 35787)
+++ debian/changelog (copie de travail)
@@ -1,3 +1,13 @@
+glib2.0 (2.33.12+really2.32.4-2) UNRELEASED; urgency=low
+
+ * Revert link adding for gdbus-object-manager-example. While it is
+useful to have in /usr/share/doc as an example, it must not be
+shipped with the system documentation.
+ * 20_glib-compile-resources_leak.patch: new patch. Fix a leak
+introduced in version 2.32.4. Thanks Niels Thykier!
+
+ -- Josselin Mouette Sun, 23 Sep 2012 13:26:33 +0200
+
glib2.0 (2.33.12+really2.32.4-1) unstable; urgency=low
* New upstream bugfix release.
Bug#689059: Bad use of perl: qw(...) as parentheses is deprecated
Package: vcftools Version: 0.1.9-1 /usr/bin/vcf-validator /dev/null Use of qw(...) as parentheses is deprecated at /usr/share/perl5/Vcf.pm line 1622. ... -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689058: Bad description
Package: vcftools Version: 0.1.9-1 This is a bad description: | Description: designed for working with VCF files Maybe something like "Collection of tools to work with VCF files". -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689057: errors in help & manpage
Package: scanmem Version: 0.12-2 Severity: minor --- Please enter the report below this line. --- $ scanmem 0> help [...] != match all variables that have not changed since last scan = match all variables that have not changed since last scan First line is wrong, it should read: != match all variables that have changed since last scan Besides that, man page scanmem.1 lacks a number of features descriptions compared to output of scanmem interactive help, e.g. !=, +, -, " etc --- System information. --- Architecture: amd64 Kernel: Linux 3.2.0-1-amd64 Debian Release: wheezy/sid --- Package information. --- Depends (Version) | Installed -+- libc6 (>= 2.3) | 2.13-33 libncurses5 (>= 5.5-5~) | 5.9-10 libreadline6 (>= 6.0) | 6.2-8 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== gameconqueror (>= 0.12) | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689055: luarocks: Please add support for parallel 5.1 & 5.2 trees
Package: luarocks Severity: wishlist luarocks now works nicely with Lua 5.2 (it can also be run by Lua 5.2, which is convenient for using it with Lua 5.2, though not of course essential). Please could you add support to the package for parallel 5.1 & 5.2 rocks trees. Support to ease this has recently been added to git upstream. The system I use is to have rock trees installed under PREFIX/lib/luarocks/5.[12]/rocks/ (via setting rocks_dir in the configuration file) and to have separate luarocks5.[12] and luarocks-admin5.[12] executables (this second step has to be done with manual renaming or by patching the build system at present). Finally, different configuration files need to be used, and again this requires patching (I use environment variables, and LUAROCKS_CONFIG_5_2 is now supported, but that of course only helps users, not system-wide installation). See https://github.com/keplerproject/luarocks/issues/99 -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-29-generic (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 luarocks depends on: ii liblua5.1-dev ii lua5.1 ii wget 1.13.4-2ubuntu1 ii zip3.0-4 luarocks recommends no packages. luarocks suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688204: jackd2: modifies conffiles (policy 10.7.3): /etc/security/limits.d/audio.conf
Control: tags -1 + patch pending
Dear Maintainers,
Andreas Beckmann writes:
> debsums reports modification of the following files,
> from the attached log (scroll to the bottom...):
>
> debsums: missing file /etc/security/limits.d/audio.conf (from jackd2
> package)
>
>
> Looking at the maintainer scripts, they already DTRT: initially get the
> file from /usr/share and delete it in postrm purge (trying both possible
> names). So just stop shipping the conffile, too.
I have uploaded to DELAYED/5 an NMU fixing this bug, implementing the
suggestion by Andreas. The debdiff is attached. Feel free to tell me if
I should delay it longer.
Regards,
diff -Nru jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/changelog jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/changelog
--- jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/changelog 2012-08-29 21:26:03.0 +0200
+++ jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/changelog 2012-09-28 20:26:15.0 +0200
@@ -1,3 +1,11 @@
+jackd2 (1.9.8~dfsg.4+20120529git007cdc37-4.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * No longer ship /etc/security/limits.d/audio.conf as a conffile
+(Closes: #688204)
+
+ -- Sébastien Villemot Fri, 28 Sep 2012 20:25:20 +0200
+
jackd2 (1.9.8~dfsg.4+20120529git007cdc37-4) unstable; urgency=low
* Only include DBUS files on Linux (Closes: #685776)
diff -Nru jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/jackd2.install jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/jackd2.install
--- jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/jackd2.install 2012-08-29 21:21:36.0 +0200
+++ jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/jackd2.install 2012-09-28 20:24:57.0 +0200
@@ -9,5 +9,4 @@
debian/tmp/usr/lib/*/jack/netadapter.so
debian/tmp/usr/lib/*/jack/jack_dummy.so
debian/bash_completion.d etc
-debian/audio.conf etc/security/limits.d
debian/audio.conf usr/share/jackd
diff -Nru jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/jackd2.postinst jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/jackd2.postinst
--- jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/jackd2.postinst 2012-08-11 12:11:56.0 +0200
+++ jackd2-1.9.8~dfsg.4+20120529git007cdc37/debian/jackd2.postinst 2012-09-28 20:25:15.0 +0200
@@ -5,8 +5,8 @@
CONFIG_FILE=/etc/security/limits.d/audio.conf
-# if neither $CONFIG_FILE nor ${CONFIG_FILE}.disabled exists, the file
-# somehow got lost. Let's copy it over from /usr/share/
+# if neither $CONFIG_FILE nor ${CONFIG_FILE}.disabled exists,
+# let's copy it over from /usr/share/
if [ ! -s ${CONFIG_FILE} -a ! -s ${CONFIG_FILE}.disabled ]; then
cp /usr/share/jackd/audio.conf ${CONFIG_FILE}.disabled
fi
--
.''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
`- GPG Key: 4096R/381A7594
pgpfY75DgnUti.pgp
Description: PGP signature
Bug#689054: libgpod-cil: Wrong architecture field value in libgpod-cil package definition
Package: libgpod-cil
Version: 0.8.2-6
Severity: important
Tags: patch
Dear Maintainer,
libgpod-cil package of the libgpod project has a wrong architecture entry:
- Normally -cil packages are arch-independent but,
- This one isn't because the library contains interoperability/marshalling
(unsafe) code.
- Package should be compiled differently, then, in each arch.
- Proof of this is the file configure.ac of upstream:
http://gtkpod.git.sourceforge.net/git/gitweb.cgi?p=gtkpod/libgpod;a=blob;f=configure.ac;h=669d433a47536ed5504eed12766f4876b476efa6;hb=HEAD
(Line 318, with different GMCS_FLAGS determined by ac_cv_alignof_double)
- The upstram bug is: https://bugzilla.gnome.org/show_bug.cgi?id=684876
Patch to fix this upstream in debian git is simple:
diff --git a/debian/control b/debian/control
index 145766c..50ae277 100644
--- a/debian/control
+++ b/debian/control
@@ -138,7 +138,7 @@ Description: Python bindings for libgpod
Package: libgpod-cil
Section: cli-mono
-Architecture: all
+Architecture: any
Depends: ${cli:Depends}, ${misc:Depends}
Description: CLI bindings for libgpod
libgpod is a library meant to abstract access to an iPod's content. It
Thanks very much.
Andres G. Aragoneses (Banshee developer)
-- System Information:
Debian Release: wheezy/sid
APT prefers precise-updates
APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500,
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-31-generic (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 libgpod-cil depends on:
ii libglib2.0-cil 2.12.10-2ubuntu4
ii libgpod40.8.2-6~hyper1+precise
ii libgtk2.0-cil 2.12.10-2ubuntu4
ii libmono-corlib4.0-cil 2.10.8.1-5~dhx1~precise1
ii libmono-system-core4.0-cil 2.10.8.1-5~dhx1~precise1
libgpod-cil recommends no packages.
libgpod-cil suggests no packages.
Bug#687569: gdm3 displays "Oh No! Something has gone wrong"
Le vendredi 28 septembre 2012 à 09:12 +0200, Andreas Beckmann a écrit : > There is 304.51 in experimental and everything < 304.48 in snapshots. > Please try these and if it's not working in .51 find the first broken > one. If it still seems related to nvidia, report a new bug against > nvidia-glx (using the experimental version) with reportbug to collect > system information and logfiles. This may also be done from the console > after you got the error from gdm. Then I'll give you instructions how to > forward this to Nvidia, they have become more responsive recently :-) Felix, can you try these versions? > What I see in many bug reports against nvidia, is that gdm3 tends to go > havoc and spawns hundreds of X servers if something goes wrong. Leaving > you many many Xorg.*.log[.old]. I experienced this myself by e.g. just > not having a display connected. Filed/commented, but I'm too lazy to > look up the bug numbers right now. Worked around by s/gdm3/kdm/, sorry. This bug should have been fixed in GDM 3.4. Are you still seeing it? (Anyway this is unrelated: the thing that crashes here is gnome-shell, not Xorg.) -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689053: rsyslog: slow or dead omysql backend can hang rsyslog
Package: rsyslog Version: 5.8.11-1+b1 Severity: important We recently added the omysql backend to rsyslog to centralize all logging to a MySQL database. The link to the database was a bit flakey lately and a syslog client, slapd, was producing tons of log lines for debugging purposes. This lead to rsyslog staying behind with logging for nearly 30 minutes and apparently filling up all its buffers. That prevented rsyslog from accepting more logs, which even froze slapd (which is a bug in slapd as well, see #689025). rsyslog should rather drop messages to a certain backend if it is not available and keep on logging to available backends or at least make this behaviour configurable so a broken logging backend can not freeze rsyslog. -- 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/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages rsyslog depends on: ii initscripts 2.88dsf-32 ii libc62.13-35 ii lsb-base 4.1+Debian7 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages rsyslog recommends: ii logrotate 3.8.1-4 Versions of packages rsyslog suggests: pn rsyslog-doc pn rsyslog-gnutls pn rsyslog-gssapi ii rsyslog-mysql 5.8.11-1+b1 pn rsyslog-relp -- 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#680578: (no subject)
Is XEmacs even still available in Wheezy? % aptitude search xemacs % sudo apt-get install xemacs21 Reading package lists... Done Building dependency tree Reading state information... Done Package xemacs21 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'xemacs21' has no installation candidate % lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux testing (wheezy) Release:testing Codename: wheezy signature.asc Description: PGP signature
Bug#689052: git-annex: .desktop files missing from package
Package: git-annex Version: 3.20120924 Severity: minor The upstream-supplied .desktop files for automatic startup of the assistant with the session and the webapp menu entry are missing from the Debian package. It would be great to have them added! -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git-annex depends on: ii git 1:1.7.10.4-1 ii libc6 2.13-35 ii libffi5 3.0.10-3 ii libgmp102:5.0.5+dfsg-2 ii libpcre31:8.30-5 ii libxml2 2.8.0+dfsg1-5 ii libyaml-0-2 0.1.4-2 ii openssh-client 1:6.0p1-3 ii rsync 3.0.9-3 ii uuid1.6.2-1.3 ii wget1.13.4-3 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages git-annex recommends: ii gnupg1.4.12-4+b1 ii libnss-mdns 0.10-3.2 ii lsof 4.86+dfsg-1 Versions of packages git-annex suggests: pn bup pn graphviz -- 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#688997: Needs update to newer version to fix youtube downloading
On Fri, Sep 28, 2012 at 06:11:02PM +0200, Sven Joachim wrote: > severity 688997 grave > found 688997 2012.02.27-1 > thanks > > On 2012-09-28 04:36 +0200, Josh Triplett wrote: > > > Package: youtube-dl > > Version: 2012.02.27+gita171dbf-3 > > Severity: normal > > > > Youtube downloading no longer works with the current version; > > This seems to warrant a higher severity than normal. Agreed; I realized that shortly after filing it, and just hadn't changed the severity because I saw that an upload fixing it had already occurred. But... > > youtube-dl upstream has fixed this as of today. > > Already uploaded by the Debian maintainer (thanks!), but this bug needs > to be dealt with in wheezy as well, or the package removed from wheezy. ...good catch, this definitely needs to go into wheezy. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#329234: (no subject)
In python-mode.el, when I crash the sub-interpreter, I see this:
-snip snip-
Python 2.7.3rc2 (default, Apr 22 2012, 22:30:17)
[GCC 4.6.3] on linux2
>>> import ctypes
>>> i = ctypes.c_char('a')
>>> j = ctypes.pointer(i)
>>> c = 0
>>> while True:
... j[c] = 'a'
... c += 1
...
Process python segmentation fault (core dumped)
-snip snip-
which seems good enough to me.
signature.asc
Description: PGP signature
Bug#328894: (no subject)
I cannot reproduce this with python-mode 6.0.12 (soon to be uploaded). Is this still a problem for you? signature.asc Description: PGP signature
Bug#689051: connect-proxy: debian/patches/01-connect-proxy-make.diff contains garbage/unused c-code
Package: connect-proxy Version: 1.101-1 Severity: normal Please have a look at the debian/patches/01-connect-proxy-make.diff which seesm to be some king of mongoloid: $ lsdiff 01* connect-proxy-1.100/Makefile But if you look at the file, it contains full source code of: --- connect-proxy-1.100.orig/Makefile +++ connect-proxy-1.100/Makefile @@ -0,0 +1,29 @@ +#!/usr/bin/make -f + [... snip ...] +LICENCE: /usr/share/apps/LICENSES/GPL_V2 + ln -fs $^ $@ + +#eof "$Id: connect-proxy/Makefile -- r...@users.sf.net $" connect-proxy-1.100/ * connect.c -- Make socket connection using SOCKS4/5 and HTTP tunnel. * * Copyright (c) 2000-2006 Shun-ichi Goto * Copyright (c) 2002, J. Grant (English Corrections) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * [... snip: 2000+ lines of code ...] Perhaps the patch should be cleaned up to only list the changes done. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages connect-proxy depends on: ii libc6 2.13-35 connect-proxy recommends no packages. connect-proxy 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#681502: (no subject)
Submitted to upstream at https://bugs.launchpad.net/debian/+source/python-mode/+bug/1058261 As mentioned in the upstream bug, when testing my soon-to-be-uploaded 6.0.12 package on unstable with `emacs -q`, I see the following differences: * Jumping to the end of the file shows me proper syntax highlighting. * While scrolling up does stall, emacs eventually responds to C-g signature.asc Description: PGP signature
Bug#688986: init script of Debian package of dkimproxy do not parse/read /etc/dkimproxy/dkimproxy_out.conf
On 09/28/2012 03:18 PM, Raif Tolga Korkunçkaya wrote: I did not notice that the bug is because of a typo in the init script as you have mentioned, it was not in the debian bug list. This bug makes the package unusable for the ones that did not notice this bug in terms of successful signing of mails, *but i agree, the package is usable if you change cert paths*. No, the package is usable also without the change in the init script, it will then just use it's default ports. Anyway, this is fixed in Wheezy. And if you feel like you have time to fix it in stable proposed-updates, please go ahead and make an upload happen there. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
