Bug#704883: [gtk2-engines-oxygen] KDE: emacs hangs on git repositories (vc-git)
Package: gtk2-engines-oxygen Version: 1.2.4-1 Severity: normal In KDE if oxygen-gtk chosen as GTK2 Theme in systemsettings -- Gtk Configuration -- GTK themes (with kde-config-gtk-style=3:2.1.1-1 installed) then `emacs` hangs on opening any file under git repository. I've noticed that on emacs23 or emacs24 (with git and git-core packages). To reproduce I start `emacs` from CWD (current working directory) in git repository tree with file name as command line argument: `emacs` just opens blank window with Loading vc-git...done in status line and hangs (i.e. don't respond to clicks or key presses). I tried upstream release gtk2-engines-oxygen_1.3.2.1 but it does not fix the problem. Regards, Dmitry. --- System information. --- Architecture: amd64 Kernel: Linux 3.8-trunk-amd64 --- Package information. --- Depends(Version) | Installed -+-== libc6 (= 2.4) | 2.17-0experimental2 libcairo2(= 1.10.0) | 1.12.2-3 libgcc1 (= 1:4.1.1) | 1:4.7.2-5 libgdk-pixbuf2.0-0 (= 2.22.0) | 2.26.1-1 libglib2.0-0 (= 2.26.0) | 2.36.0-2 libgtk2.0-0(= 2.24.5-4) | 2.24.10-2 libpango1.0-0(= 1.18.0) | 1.30.0-1 libstdc++6 (= 4.6) | 4.7.2-5 libx11-6 | 2:1.5.0-1 Package's Recommends field is empty. Suggests (Version) | Installed ===-+-=== kde-config-gtk-style| 3:2.1.1-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669726: release-notes: Please document tmpfs filesystem changes for wheezy
On Vi, 05 apr 13, 14:48:44, Julien Cristau wrote: On Mon, Apr 1, 2013 at 08:38:30 +0900, Charles Plessy wrote: + Applications which create excessively large temporary files always + only in filename class='directory'/tmp/filename while not + honoring literalTMPDIR/literal may cause + filename class='directory'/tmp/filename to run out of free space. + Such applications should not force to use + filename class='directory'/tmp/filename, and require fixing. + Please consider filing a bug report against the application in + question if you experience such an occurrence. Two comments: - I don't think the last two sentences are particularly helpful in the RN, so I'd drop them - I'm confused by the bit about TMPDIR, since we don't say anything about setting that variable anywhere, so even if an app obeys TMPDIR if it's set, it'll still fill up /tmp by default. I'd reword it slightly: Applications which create excessively large temporary files may cause /tmp to run out of free space. It should possible to configure a different location for those files by setting the TMPDIR environment variable. Applications that don't honour TMPDIR and don't have any other means to configure the destination of temporary files require fixing. Please consider filing a bug report against the application in question if you experience such an occurrence. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Bug#704884: alot: doesn't properly instantiate GPGProblem
Package: alot
Version: 0.3.4-1
Severity: normal
tag: patch
Dear Maintainer,
There was a bug in gpg signing part of alot which was failing when
gpg-agent is either not running or password is not present in agent
(mostly due to the improper configuration of gpg-agent). Here alot was
not properly doing error handling and was not displaying proper error
message display.
I discussed this with upstream author and he provided a fix which is
already on upstream Git but I'm attaching same patch with this mail.
Please consider applying this patch to the alot package till upstream
releases new tarball with this fix.
[1] https://github.com/pazz/alot/issues/590
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armel
Kernel: Linux 3.7-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages alot depends on:
ii python2.7.3-4
ii python-configobj 4.7.2+ds-4
ii python-gpgme 0.2-3
ii python-magic 1:5.11-3
ii python-notmuch0.15.2-1
ii python-twisted12.3.0-1
ii python-urwid 1.1.0-1
Versions of packages alot recommends:
ii notmuch 0.15.2-1
Versions of packages alot suggests:
ii alot-doc 0.3.4-1
-- no debconf information
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
From a1fc6b97b9d3975a3d0239f5e66ea2b78c53a43d Mon Sep 17 00:00:00 2001
From: Patrick Totzke patricktot...@gmail.com
Date: Sat, 6 Apr 2013 13:25:51 +0100
Subject: fix incorrect instanciations of GPGProblem
with missing 'code' parameter.
cf issue #590
---
alot/db/envelope.py | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/alot/db/envelope.py b/alot/db/envelope.py
index f0c94de..0f8c195 100644
--- a/alot/db/envelope.py
+++ b/alot/db/envelope.py
@@ -18,7 +18,7 @@ import alot.helper as helper
import alot.crypto as crypto
import gpgme
from alot.settings import settings
-from alot.errors import GPGProblem
+from alot.errors import GPGProblem, GPGCode
from attachment import Attachment
from utils import encode_header
@@ -192,8 +192,9 @@ class Envelope(object):
signatures, signature_str = crypto.detached_signature_for(
plaintext, self.sign_key)
if len(signatures) != 1:
-raise GPGProblem((Could not sign message
- (GPGME did not return a signature)))
+raise GPGProblem(Could not sign message (GPGME
+ did not return a signature),
+ code=GPGCode.KEY_CANNOT_SIGN)
except gpgme.GpgmeError as e:
if e.code == gpgme.ERR_BAD_PASSPHRASE:
# If GPG_AGENT_INFO is unset or empty, the user just does
@@ -201,11 +202,12 @@ class Envelope(object):
if os.environ.get('GPG_AGENT_INFO', '').strip() == '':
msg = Got invalid passphrase and GPG_AGENT_INFO\
not set. Please set up gpg-agent.
-raise GPGProblem(msg)
+raise GPGProblem(msg, code=GPGCode.BAD_PASSPHRASE)
else:
-raise GPGProblem((Bad passphrase. Is
- gpg-agent running?))
-raise GPGProblem(str(e))
+raise GPGProblem(Bad passphrase. Is gpg-agent
+ running?,
+ code=GPGCode.BAD_PASSPHRASE)
+raise GPGProblem(str(e), code=GPGCode.KEY_CANNOT_SIGN)
micalg = crypto.RFC3156_micalg_from_algo(signatures[0].hash_algo)
unencrypted_msg = MIMEMultipart('signed', micalg=micalg,
@@ -235,7 +237,7 @@ class Envelope(object):
encrypted_str = crypto.encrypt(plaintext,
self.encrypt_keys.values())
except gpgme.GpgmeError as e:
-raise GPGProblem(str(e))
+raise GPGProblem(str(e), code=GPGCode.KEY_CANNOT_ENCRYPT)
outer_msg = MIMEMultipart('encrypted',
protocol='application/pgp-encrypted')
--
1.7.10.4
signature.asc
Description: Digital signature
Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
On Vi, 29 mar 13, 09:45:11, Chris Knadle wrote: You will also need to recreate /etc/resolv.conf, as the contents of this file is replaced by NetworkManager. Isn't this done by wicd-daemon (maybe by restarting it)? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
On Sat, Apr 06, 2013 at 10:54:32AM -0400, Chris Knadle wrote: Okay... updated patches attached. Thanks. Won't have time to work on this for next 24 hours. Hope to get to it later, unless somebody else picks this one up (hint). Bye, Joost - leaving for loadays.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#386791:
I am sorry to report that this seems to be happening again. Package: bind9 State: partially configured Automatically installed: no Version: 1:9.7.3.dfsg-1~squeeze10 Priority: optional Section: net Maintainer: LaMont Jones lam...@debian.org Chowning rndc.key to root:bind means I can start up the service again, but the next attempt to install this package re-runs the post-install script, which chowns it back to bind:bind, which means the service can't start, leaving the package partially configured. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540287: Duplicate bug
This is a duplicate of bug #531532. Is anybody working on this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704886: Build failure on i386 and others
Package: src:webkitgtk Version: 1.11.91-1 Severity: normal Hi, the build failed on all architectures that weren't uploaded directly: At least on i386 this looks like an outdated symbols file: https://buildd.debian.org/status/fetch.php?pkg=webkitgtkarch=i386ver=1.11.91-1stamp=1363812260 other architectures look worse but I'd be great to have i386 built since this blocks empathy among others. Cheers, -- Guido -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704887: bmon crashes on launch
Package: bmon
Version: 3.0+git20110323-1
Severity: important
Dear Maintainer,
An update on Debian sid broke bmon. I don't exactly know what dependency broke
bmon, but when launched it now displays the following error message
BUG: element.c:348
bmon: element.c:348: element_set_key_attr: Assertion `0'
failed.
Aborted
The return code is SIGABRT :
$ echo $?
134
Using strace I didn't find any useful information, only that it stops after
reading /proc/net/dev :
5799 open(/proc/net/dev, O_RDONLY) = 3
5799 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
5799 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7ffdc4736000
5799 read(3, Inter-| Receive
| Transmit\n face |bytespackets errs drop fifo frame compressed
multicast|bytespackets errs drop fifo colls carrier compressed\nlo:
22259560 17251000 0 0 0 22259560 172510
00 0 0 0\n eth0: 0 0000 0
0 00 ..., 1024) = 695
5799 write(2, BUG: element.c:348\n, 19) = 19
5799 write(2, bmon: element.c:348: element_set_key_attr: Assertion `0'
failed.\n, 65) = 65
5799 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
5799 tgkill(5799, 5799, SIGABRT) = 0
5799 --- SIGABRT (Aborted) @ 0 (0) ---
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-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 bmon depends on:
ii libc62.13-38
ii libconfuse0 2.7-4
ii libncurses5 5.9-10
ii librrd4 1.4.7-2
ii libtinfo55.9-10
bmon recommends no packages.
bmon 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#704880: reportbug urwid interface crash with Debian Bug 611298
reassign 704880 python-urwid thanks Hello Nils, On Sun, Apr 7, 2013 at 6:09 AM, Nils Dagsson Moskopp nils+debian-report...@dieweltistgarnichtso.net wrote: ... Traceback (most recent call last): File /usr/bin/reportbug, line 2206, in module main() File /usr/bin/reportbug, line 1080, in main return iface.user_interface() File /usr/bin/reportbug, line 1859, in user_interface 'Please provide a subject for your response.', default=Re: %s % exinfo.subject, force_prompt=True) File /usr/lib/pymodules/python2.7/reportbug/ui/urwid_ui.py, line 359, in get_string code, text = box.main(ui) File /usr/lib/pymodules/python2.7/reportbug/ui/urwid_ui.py, line 200, in main return self.ui.run_wrapper(self.run) File /usr/lib/python2.7/dist-packages/urwid/raw_display.py, line 237, in run_wrapper return fn() File /usr/lib/pymodules/python2.7/reportbug/ui/urwid_ui.py, line 151, in run canvas = self.view.render( size, focus=True ) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/decoration.py, line 219, in render canv = self._original_widget.render(size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/decoration.py, line 727, in render canv = self._original_widget.render((maxcol,maxrow-top-bottom),focus) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/decoration.py, line 535, in render canv = self._original_widget.render((maxcol,)+size[1:], focus) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/container.py, line 596, in render focus and self.focus_part == 'body') File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/container.py, line 1228, in render focus = focus and self.focus_col == i) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/container.py, line 596, in render focus and self.focus_part == 'body') File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/decoration.py, line 219, in render canv = self._original_widget.render(size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/decoration.py, line 727, in render canv = self._original_widget.render((maxcol,maxrow-top-bottom),focus) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/decoration.py, line 535, in render canv = self._original_widget.render((maxcol,)+size[1:], focus) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/container.py, line 596, in render focus and self.focus_part == 'body') File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/decoration.py, line 725, in render canv = self._original_widget.render((maxcol,), focus) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/container.py, line 864, in render focus=focus and item_focus) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 132, in cached_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/decoration.py, line 219, in render canv = self._original_widget.render(size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/widget.py, line 170, in finalize_render canv = fn(self, size, focus=focus) File /usr/lib/python2.7/dist-packages/urwid/listbox.py, line 378, in render assert rows = maxrow, Listbox contents too long! Probably urwid's fault (please report): %r % ((top,middle,bottom),) AssertionError: Listbox contents too long! Probably urwid's fault (please report): ((0, []), (-1, Edit selectable flow widget 'Re: texlive-latex-extra: In pax: pdfannotextractor requires
Bug#696994: debian-reference: Proposed changes - round 3
Hi Osamu, Osamu Aoki os...@debian.org wrote: Hi, Thanks for detailed proof-reading. Great work! I have some question on your patch as below. Your thought is most appreciated. http://bugs.debian.org/696994 But you know most of them are stylistic changes. Changing them at this moment before the release will cause major breakage to translations. It has been more than several month under freeze for Debian. I have not been changing SVN at this moment. But maybe we can start doing it. (Released version is not exactly ones on public svn-repo). Strategy is to make all typo/plural/article related fixes first. These do not require translation updates. Then work on content fixes. That's perfectly fine for me. I did not expected my proposals to be merged in before the release of Wheezy! And as you may have seen, there are even more proposed changes to come. As I get further and further with my translation, I do proofreading slowly over the english text. This means, that proofreading the whole document will take months, or most probably more than a year. Be prepared to receive more and more proposals ;-) Implement them whenever you want. On Sat, Apr 06, 2013 at 11:41:13PM +0200, Holger Wansing wrote: this is round 3 of my proposals for the DR. Yes I see them at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696994 You may want to fix at least one point before the next upload: see line 189 of attached diff. FYI: I need to merge all these changes manually to the source files with resideing under the asciidoc directory as *.txt. Diff to that source is easier for me to integrate. Ok, sorry for this. I will make diffs for the txt files in the future. @@ -9352,16 +9352,18 @@ citerefentryrefentrytitleaptitude/refentrytitlemanvolnum8/ manvolnum/citerefentry for an interactive text interface to manage the installed packages and to search the available packages. msgstr #. type: Content of: bookchapteritemizedlistlistitempara +### HW: update-manager works basically under other desktop environments, too. msgid citerefentryrefentrytitleupdate-manager/refentrytitlemanvolnum8/ -manvolnum/citerefentry for keeping your system up-to-date if you're -running the default GNOME desktop. +manvolnum/citerefentry for keeping your system up-to-date; it is mainly +aimed for being used in the default GNOME desktop, but basically works under +other desktop environments as well. msgstr True. But question is how pedantic we should be. I want to keep it short. Now we have update-manager-gnome ... Just a proposal, do as you like. #. type: Content of: bookchaptertabletgrouptbodyrowentry -msgid graphical package manager (GNOME front-end for APT) +### HW: my proposal for update-manager also applies here: synaptic is also +### HW: working fine under Xfce for example. +msgid graphical package manager (graphical front-end for APT) msgstr I think we need some generic solution than making every text longer. [...] #. type: Content of: bookchaptersectionsectionorderedlistlistitempara msgid Type \literall/literal\ to enter the package display limit as \literal~i/literal\ and type \literalm/literal\ over -\literalTasks/literal\ as manual installed. +\literalTasks/literal\, to mark that packages as manual installed. msgstr YES. sounds better! But unsynmetric use of ,. Should I add ; before and for these to make it clearer? Now: Type \literall/literal\ to enter the package display limit as \literal~i/literal\ and type \literalm/literal\ over \literalTasks/literal\, to mark that packages as manual installed. How about use , and ;: V V Type \literall/literal\, to enter the package display limit as \literal~i/literal\; and type \literalm/literal\ over \literalTasks/literal\, to mark that packages as manual installed. Yes. Or even use then instead of and (in German it is a rule, to not use and after a comma or semicolon. Don't know how about this in English). cheers Holger -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Created with Sylpheed 3.0.2 under D e b i a n G N U / L I N U X 6.0 ( S q u e e z e ) Registered LinuxUser #311290 - http://linuxcounter.net/ = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704861: torsocks: documentation with sources references obsolete file, and omits prerequisites
Control: tag -1 + upstream Control: forwarded -1 https://trac.torproject.org/projects/tor/ticket/8659 Control: severity -1 minor Hi, Anonymous wrote (30 Mar 2013 21:44:44 GMT) : In the git version of the INSTALL document, there is a reference to Makefile.cvs, which has been obsoleted. Thanks for noticing. I forwarded this report upstream: https://trac.torproject.org/projects/tor/ticket/8659 Care to submit a patch? In the debian version, there was no mention of packages that are required for building, and it takes some investigation to discover what's missing. The build process fails if the user does not have automake and libtool. Perhaps there should be an INSTALL.debian file if these packages are particular to debian. Debian is a binary distribution: we don't ship instructions about building packages in the packages themselves. However, Debian distributes its source, and source packages have build-dependencies (see the debian/control file), that you can easily install this way: # apt-get build-dep torsocks So, I'm calling that one not-a-bug. In the future, please try to file separate bug reports for separate problems, as it makes it much easier to deal with on our side. Thanks! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704888: gpodder: Causes 100% cpu load for several minutes
Package: gpodder Version: 2.20.1-1 Severity: normal Recently, feed updates and downloads of episodes have started causing 100% for several minutes, during which the programme becomes unresponsive. I first observed this behaviour on gpodder 3.5 from sid. Therefore I downgraded to the version from Wheezy, deleted the entire configuration and re-synced with gpodder.net, but to no avail. This makes the programme unusable for any practical purpose. Please let me know what specific debug information is needed and how it can be extracted. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-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 gpodder depends on: ii python 2.7.3-4 ii python-dbus 1.1.1-1 ii python-feedparser 5.1.2-1 ii python-gtk2 2.24.0-3+b1 ii python-mygpoclient 1.4-1 ii python-support 1.0.15 Versions of packages gpodder recommends: ii dbus-x11 1.6.8-1 ii python-gpod0.8.2-7 ii python-gst0.10 0.10.22-3 ii python-pymtp 0.0.4-4 ii python-simplejson 2.5.2-1 ii python-webkit 1.1.8-2 Versions of packages gpodder suggests: ii gnome-bluetooth 3.4.2-1 ii mplayer 3:1.1-dmo9 ii python-eyed3 0.6.18-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#704768: debian-installer: no neo2 keymap
Am 07.04.2013 03:14, schrieb Samuel Thibault: Control: forcemerge 630575 -1 Simon Reinhardt, le Sat 06 Apr 2013 10:32:53 +0200, a écrit : One problem is, that the neo2 layout is completely different to the qwertz. Sure, like other dvorak layouts. And it is not so uncommon. At least not among Debian users :-). You still probably have a physical qwertz keyboard, don't you? not quite: http://www.keinstein.org/neo2.JPG Please read the backlog of bug 630575 for more rationale. Samuel signature.asc Description: OpenPGP digital signature
Bug#704889: php-sabredav: breaks caldav-synchronisation
Package: php-sabredav Version: 1.7.5+dfsg-1 Severity: important Dear Maintainer, since upgrading to 1.7.5+dfsg-1 (with installing php-sabre-vobject) my CalDavSync Application shows me this error: Fatal error: Class 'Sabre\VObject\DateTimeParser' not found in /usr/share/php/Sabre/CalDAV/CalendarQueryParser.php on line 246 Even though the file /usr/share/php/Sabre/VObject/DateTimeParser.php is existent (with the php-sabre-vobject package) it seems to be not found. I had to switch back to php-sabredav 1.6.3-1 -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (998, 'testing'), (998, 'stable'), (101, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages php-sabredav depends on: ii php5 5.4.4-14 ii php5-cli 5.4.4-14 php-sabredav recommends no packages. php-sabredav 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#704890: gvfs-backends and thunar
Package: gvfs-backends Version: 1.12.3-4 When you want to open Thunar in Xfce 4.8 on Debian Wheezy takes a very long time. Then he opens Thunar and window with the message: Did not receive a reply. Possible Causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken . Open Thunar takes more than 20 seconds. When the package gvfs-backends is not installed it is all good. Thunar opens quickly. I installed version 4.10 of Siduction xfce http://news.siduction.org/2012/10/xfce-4-10-for-siduction/ and here it all works fine. Thunar works well with the installed package gvfs-backends. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704891: Wishlist: feature present in countrycodes, deleted in isoquery
Package: isoquery Version: 1.4-1 Severity: wishlist Dear maintenance/Devel team, while we can enter countrycodes be or belgi or Belg in countrycodes and the program was searching/finding and showing the correct info, this feature is totally deleted in isoquery; this is a major problem when you doesn't exactly know how to write some countynames in English since that's not my motherlanguage: please do implement this feature again in the replacement program for countrycodes, isoquery. Thank you. OLR -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages isoquery depends on: ii python 2.6.6-3+squeeze7 interactive high-level object-orie ii python-lxml 2.2.8-2 pythonic binding for the libxml2 a ii python-support 1.0.10 automated rebuilding support for P Versions of packages isoquery recommends: ii iso-codes 3.23-1 ISO language, territory, currency, isoquery 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#704892: new upstream (2.5.0)
Package: python-colorama Severity: wishlist Please upgrade to 2.5.0. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704893: build python3 package
Package: python-colorama Please build a module package for python3. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704894: yatm: does not honour -e parameter
Package: yatm Version: 0.6-1+b2 Severity: normal yatm fails to honour the -e paramenter which determines that decoding should stop after a certain amount of time. yatm -v -b '0:00:04' -e '0:00:07' -t 0.6 /home/data/music/Barzaz/Echonder/01\ Gavotenn\ Bro\ Pourlet.ogg should start 4 seconds into the track (which works) and exit after 7 seconds (which does not work. It just keeps on playing). -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-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 yatm depends on: ii libao4 1.1.0-2 ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 ii libmad0 0.15.1b-7 ii libogg0 1.3.0-4 ii libslang2 2.2.4-15 ii libsndfile1 1.0.25-5 ii libsoundtouch0 1.6.0-3 ii libspeex1 1.2~rc1-7 ii libstdc++6 4.7.2-5 ii libvorbisfile3 1.3.2-1.3 yatm recommends no packages. yatm 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#704787: manpages: units should use an actual µ
tags 704787 fixed-upstream thanks On Fri, Apr 5, 2013 at 11:24 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Package: manpages Version: 3.44-1 Severity: minor File: /usr/share/man/man7/units.7.gz Tags: patch The units(7) man page uses an ASCII u in place of the actual Greek letter mu. Since we're in the twenty-first century, with UTF-8-compatible terminals and terminal emulators, we should use the actual letter µ instead of an ASCII approximation. Attached is a patch to do that. It's against the current master of the Vcs-Git repository. Seems reasonable to me. Applied. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699021: src:sigx: FTBFS against newer GLib: invalid conversion from 'const volatile void*' to 'volatile void*'
retitle 699021 src:sigx: FTBFS against glib2.0/wheezy: invalid conversion from 'const volatile void*' to 'volatile void*' tags 699021 + sid thanks On Sat, 26 Jan 2013 at 16:34:36 +, Simon McVittie wrote: Using g_atomic_pointer_get ((volatile void *) (blah blah)) would probably resolve this for now. I'll open a GLib bug suggesting that it should take a const volatile void * parameter. I fixed this in GLib for 2.36[1] so this can be closed when glib2.0/experimental reaches unstable after the wheezy release. S [1] https://bugzilla.gnome.org/show_bug.cgi?id=692583 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704882: xen-create-image doesn't clean up on interrupt
Hi Mike, Mike wrote: Control-C interrupt at the terminal leaves the domU LV mounted: I think that's already fixed in Git as a lot of code changed around the clean up on aborting, but I've to explicitly test it. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, 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#704895: transmission: doesn't open magnet links when clicked in iceweasel
Package: transmission Version: 2.52-3 Severity: normal Dear Maintainer, when I click on magnet links in iceweasel, they don't get opened in transmission; iceweasel says there's no protocol associated with that kind of link. I checked transmission's trac, and it says that since version 1.80 it should set the appropriate gnome preferences [1]. I checked my preferences with gconf -R /desktop/gnome/url-hanlders/magnet and nothing was set. I set them by hand and now it works. I suppose debian's transmission doesn't do the right thing when it gets launched. [1] https://trac.transmissionbt.com/wiki/MagnetLinks -- 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-2-amd64 (SMP w/1 CPU core) 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 transmission depends on: ii transmission-common 2.52-3 ii transmission-gtk 2.52-3 transmission recommends no packages. transmission suggests no packages. -- no debconf information -- CONTACTS http://tracciabi.li/~bruno/contacts.html 2nd email br...@tracciabi.li GNU/Linux registered user #121507 http://linuxcounter.net signature.asc Description: This is a digitally signed message part
Bug#704896: [gourmet] Missing dependency to python-elib.intl
Package: gourmet Version: 0.16.0-1 Severity: normal --- Please enter the report below this line. --- Hi, To be able to see the actual translated strings, gourmet needs to load elib.intl. After installing it, I'm able to see translated menus that were in English before. --- System information. --- Architecture: i386 Kernel: Linux 3.2.0-4-686-pae Debian Release: 7.0 500 unstable ftp.fr.debian.org 1 experimental ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed =-+- python (= 2.7) | 2.7.3-4 python ( 2.8) | 2.7.3-4 python-imaging | 1.1.7-4 python-glade2 | 2.24.0-3+b1 python-gtk2 (= 2.3.92) | 2.24.0-3+b1 python-reportlab | 2.5-1.1 python-sqlalchemy | 0.7.9-1 python-poppler | 0.12.1-8+b1 Recommends (Version) | Installed ==-+-=== python-gnome2 | python-gtkspell | 2.25.3-12 Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704897: [gourmet] Missing dependency to python-elib.intl
Package: gourmet Version: 0.16.0-1 Severity: normal --- Please enter the report below this line. --- Hi, To be able to see the actual translated strings, gourmet needs to load elib.intl. After installing it, I'm able to see translated menus that were in English before. --- System information. --- Architecture: i386 Kernel: Linux 3.2.0-4-686-pae Debian Release: 7.0 500 unstable ftp.fr.debian.org 1 experimental ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed =-+- python (= 2.7) | 2.7.3-4 python ( 2.8) | 2.7.3-4 python-imaging | 1.1.7-4 python-glade2 | 2.24.0-3+b1 python-gtk2 (= 2.3.92) | 2.24.0-3+b1 python-reportlab | 2.5-1.1 python-sqlalchemy | 0.7.9-1 python-poppler | 0.12.1-8+b1 Recommends (Version) | Installed ==-+-=== python-gnome2 | python-gtkspell | 2.25.3-12 Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667904: RFS: mitlm/0.4-1 [ITP] -- MIT Language Modeling
Il 06/04/2013 23:47, Jakub Wilk ha scritto: * Giulio Paci giuliop...@gmail.com, 2013-03-27, 12:18: - there is no need to run autotools anymore Please do run them anyway. Done. - a very basic test suite is run Use LC_ALL instead of LANG. LANG, unlike LC_ALL, can be overriden by various LC_* variables. Thank you again for this advice. Now the script is using LC_ALL. I hope this is the last time I am doing this error. :-) Bests, Giulio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704457: gd extension broken due new embedded libgd functions not added to gd_compat layer
I also had this problem, so I was happy to see it was already fixed. Though i noticed on php.net that another php beta release should be available in a few days, I was hoping that this an interim version (5.5.0~beta2-2 perhaps?) could be uploaded already, because the owncloud 5.0.3 package was uploaded yesterday and it seems to require gd to work. So this is no longer a matter of merely having persistent error notifications. If this is not possible, I will just have to wait a little while longer (it's all from experimental anyway, so it's to be expected). It might still be useful to communicate this to the owncloud maintainers though.
Bug#704668: RFS: woff-tools/0:2009.10.04-1 [ITP]
Hi Jakub, On Fri, 5 Apr 2013 16:26:01 +0200, Jakub Wilk wrote: * Dmitry Shachnev mity...@gmail.com, 2013-04-04, 14:36: http://mentors.debian.net/debian/pool/main/w/woff-tools/woff-tools_2009.10.04-1.dsc FTBFS: woff.c:43:18: fatal error: zlib.h: No such file or directory Fixed in SVN, thanks! -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704898: ITP: libnet-idn-nameprep-perl -- stringprep profile for Internationalized Domain Names (RFC 3491)
Package: wnpp Owner: gregor herrmann gre...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libnet-idn-nameprep-perl Version : 1.101+dfsg Upstream Author : Claus F�rber cfaer...@cpan.org * URL : https://metacpan.org/release/Net-IDN-Nameprep/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : stringprep profile for Internationalized Domain Names (RFC 3491) Net::IDN::Nameprep implements the nameprep specification, which describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. Nameprep is a profile of the stringprep protocol and is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704899: ITP: libhash-storediterator-perl -- Functions for accessing a hashes internal iterator
Package: wnpp Severity: wishlist Owner: Xavier Guimard x.guim...@free.fr * Package name: libhash-storediterator-perl Version : 0.003 Upstream Author : Chad Granum exodi...@gmail.com * URL : https://metacpan.org/release/Hash-StoredIterator * License : Artistic or GPL-1+ Programming Lang: Perl Description : Functions for accessing a hashes internal iterator In perl all hashes have an internal iterator. This iterator is used by the each() function, as well as by keys() and values(). Because these all share use of the same iterator, they tend to interact badly with eachother when nested. Hash::StoredIterator gives you access to get, set, and init the iterator inside a hash. This allows you to store the current iterator, use each/keys/values/etc, and then restore the iterator, this helps you to ensure you do not interact badly with other users of the iterator. Along with low-level get/set/init functions, there are also 2 variations of each() which let you act upon each key/value pair in a safer way than vanilla each() This module can also export new implementations of keys() and values() which stash and restore the iterator so that they are safe to use within each(). This module is required to update libperl5i-perl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616980: pyrex: deprecation of dh_pycentral, please use dh_python2
Control: tags -1 +patch Here is a patch applied by Matthias in Ubuntu: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/pyrex/raring/revision/17 Do you welcome NMUs? -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695224: Locale::Maketext versioning in perl package
On 2013-04-02 21:15, Niko Tyni wrote: On Sun, Mar 31, 2013 at 05:46:12PM +0100, Dominic Hargreaves wrote: There is a problem with the perl package, as discussed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695224#55 onwards, whereby the application of the security fix in that ticket now causes double-escaping problems where people workaround the problem by escaping themselves, when they detect an earlier Locale::Maketext by version number. I am slightly wary about importing the new (1.23) version of Locale::Maketext as I mentioned in that bug already, but my fears may be unfounded. Could you comment about whether you would accept such a change in wheezy at this time? (I can't really decide whether it's RC or not). FWIW, it looks clear to me that the only functional changes in the patch are the $VERSION increments in the .pm files. The rest is documentation and test cases, and the only important $VERSION is most probably the main one in Locale/Maketext.pm. Indeed. While that change itself is trivial, it has action-at-distance effects - otherwise this wouldn't be an issue at all. I think the risk potential is mostly in breaking something that's trusting Module::CoreList (dh-make-perl and lintian come to mind, CPAN.pm and CPANPLUS.pm might be affected somehow too?), and that it's not a very big risk but still a real one. Lintian uses a precomputed static list. It would at worst lead to false-negatives for package-superseded-by-perl (i.e. no tag when one should have been there). I suspect dh-make-perl will have a similar case with using the cpan variant instead of the core variant in dependencies (though I only gave it a quick scan). I would suspect that any application code using Module::CoreList would still have to account for the cpan version being present? [...] In this specific case, upgrading Locale::Maketext fully to 1.23 in wheezy would probably have been the right thing to do if we had anticipated these issues. But we didn't, and it seems very late in the release process to do it now. Also, I can't really see us applying anything but the targeted fix for squeeze. I am tempted to take this fix for Wheezy and be done with it. Can (one of) you please check up on CPAN.pm/CPANPLUS.pm ? I see Fedora/RedHat also upgraded their Locale::Maketext modules without incrementing $VERSION (I checked the patches in RHEL 6 / Perl 5.10.1 and Fedora Core 16 17 / Perl 5.14.3). So it looks like even if we do try to fix this for wheezy, applications still have to check for features rather than versions to stay on the safe side. Okay, sounds like it will be fine with leaving Squeeze as is then. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704668: RFS: woff-tools/0:2009.10.04-1 [ITP]
* Dmitry Shachnev mity...@gmail.com, 2013-04-07, 15:28: http://mentors.debian.net/debian/pool/main/w/woff-tools/woff-tools_2009.10.04-1.dsc FTBFS: woff.c:43:18: fatal error: zlib.h: No such file or directory Fixed in SVN, thanks! FTR, the repository is here: svn://anonscm.debian.org/pkg-fonts/packages/woff-tools/trunk Please fix the Vcs-Svn field. :) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704900: nmu: librevisa_0.0.20130404-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu librevisa_0.0.20130404-2 . amd64 . -m Rebuild in a clean sid environment. Package: libvisa0 Source: librevisa Version: 0.0.20130404-2 Architecture: amd64 Depends: ..., libc6 (= 2.15), ... Once again a package was built in experimental or Ubuntu and uploaded to sid. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687563: RFS: opengrm-ngram/1.0.3-1 [ITP] -- opengrm n-gram, library
Il 06/04/2013 21:03, Jakub Wilk ha scritto: I see this in the build log: dpkg-shlibdeps: warning: symbol FLAGS_fst_default_cache_gc_limit used by debian/libngram0/usr/lib/libngram.so.0.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol FLAGS_fst_default_cache_gc used by debian/libngram0/usr/lib/libngram.so.0.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol FLAGS_fst_verify_properties used by debian/libngram0/usr/lib/libngram.so.0.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol FLAGS_v used by debian/libngram0/usr/lib/libngram.so.0.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol FLAGS_fst_error_fatal used by debian/libngram0/usr/lib/libngram.so.0.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol _ZN3fst13PropertyNamesE used by debian/libngram0/usr/lib/libngram.so.0.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol FLAGS_fst_compat_symbols used by debian/libngram0/usr/lib/libngram.so.0.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol _ZN3fst17ComposePropertiesEyy used by debian/libngram0/usr/lib/libngram.so.0.0.0 found in none of the libraries It looks like a violation of Policy §10.2: “shared libraries must be linked against all libraries that they use symbols from”. Indeed it was. I added a patch to fix this. Now autotools are run at build time, in order to use this patch. Bests, Giulio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677795: Bug#704520: RM: midgard2-core/10.05.7.1-1 php5-midgard2/10.05.7-1
user release.debian@packages.debian.org usertags 677795 + wheezy-will-remove thanks On 2013-04-02 13:13, Didier Raboud wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hi dear Release Team, hi dear midgard2-core and php5-midgard2 maintainers, as explained in http://bugs.debian.org/677795#67 , I think midgard2-core (and it's only build-rdep, php5-midgard2) should get removed from testing: As I read it, the package had several packaging-related issues summing up to that serious bug, filed two weeks before the freeze. Since then, in September, a package supposedly fixing these issues has been uploaded and queued in NEW [0]; it hasn't been liberated from NEW yet. From here, I see three ways forward: a) a new package enters unstable, and then Wheezy, but that seems unlikely; b) midgard2-core and php5-midgard2 are removed from Wheezy, thereby removing the RC bug. c) that bug either gets downgraded to non-RC severity, or tagged wheezy-ignore by the release team. As I think the concerns originally leading to the severity of that bug are correct, I would rather be of the opinion to drop the two packages. As you see, I think that as this point, b) is the only reasonable choice. Cheers, OdyX [...] We have not accepted new (binary) packages in Wheezy for quite a while. So option a) is indeed very unlikely. As it is, I am inclined to agree with OdyX's observations, so I am tagging the bug as will-remove for now. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704668: RFS: woff-tools/0:2009.10.04-1 [ITP]
On Sun, Apr 7, 2013 at 4:31 PM, Jakub Wilk jw...@debian.org wrote: FTR, the repository is here: svn://anonscm.debian.org/pkg-fonts/packages/woff-tools/trunk Please fix the Vcs-Svn field. :) Done, thanks! I should probably have mentioned it when I was filing the bug… -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704901: [imagemagick] Null deference during creation of tempory file
Package: imagemagick
Version: 8:6.7.7.10-5
Severity: minor
Tags: patch security upsteam fixed-upstream
Forwarded:
http://www.imagemagick.org/discourse-server/viewtopic.php?f=3t=23117p=96934#p96934
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
If MAGICK_TMPDIR point to non existant file, imagemagick will crash during
retrieving a file by url.
= local dos at least.
Security team please assess the security risk and open a candidate CVE if
needed. Will send a mail to oss-security list.
Patch available here.
Bastien
From e5eb27d112e0a7181df44fb70c42633c2d1c9c74 Mon Sep 17 00:00:00 2001
From: cristy cristy@aa41f4f7-0bf4-0310-aa73-e5a19afd5a74
Date: Fri, 5 Apr 2013 11:49:29 +
Subject: [PATCH] git-svn-id:
https://www.imagemagick.org/subversion/ImageMagick/trunk@11698
aa41f4f7-0bf4-0310-aa73-e5a19afd5a74
---
coders/url.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/coders/url.c b/coders/url.c
index 19dbd73..abab351 100644
--- a/coders/url.c
+++ b/coders/url.c
@@ -153,12 +153,9 @@ static Image *ReadURLImage(const ImageInfo *image_info,ExceptionInfo *exception)
file=fdopen(unique_file,wb);
if ((unique_file == -1) || (file == (FILE *) NULL))
{
- read_info=DestroyImageInfo(read_info);
- (void) CopyMagickString(image-filename,read_info-filename,
-MaxTextExtent);
ThrowFileException(exception,FileOpenError,UnableToCreateTemporaryFile,
-image-filename);
- image=DestroyImageList(image);
+read_info-filename);
+ read_info=DestroyImageInfo(read_info);
return((Image *) NULL);
}
(void) CopyMagickString(filename,image_info-magick,MaxTextExtent);
--
1.7.10.4
Bug#704902: ITP: uc-echo - error correction algorithm designed for short-reads from NGS
Package: wnpp Severity: wishlist * Package name: uc-echo Version : 1.12 Upstream Author : Yun S. Song * URL : http://uc-echo.sourceforge.net/ * License : BSD Programming Lang: C++, Python Description : error correction algorithm designed for short-reads from NGS ECHO is an error correction algorithm designed for short-reads from next-generation sequencing platforms such as Illumina's Genome Analyzer II. The algorithm uses a Bayesian framework to improve the quality of the reads in a given data set by employing maximum a posteriori estimation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704435: [Pkg-varnish-devel] Bug#704435: varnish: Pushing vcls failed:#012CLI communication error (hdr)
I get the same error starting varnish with the default command line (contained in /etc/default/varnish), like so: varnishd -a :6081 -T localhost:6082 -f ../../etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m where ../../etc/varnish/default.vcl contains the vcl file of a freshly extracted varnish deb (retieved with aptitude). Upon further research, I've found that this bug disappears when the package is built with debug symbols, and in diagnostics mode like so: --enable-debugging-symbols --enable-diagnostics /Rune On Wed, Apr 3, 2013 at 4:17 PM, Stig Sandbeck Mathisen s...@debian.org wrote: Hello, Thanks for reporting an issue with varnish. Does varnish start with the default vcl, or the default configuration? -- Stig Sandbeck Mathisen s...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704889: [Pkg-owncloud-maintainers] Bug#704889: php-sabredav: breaks caldav-synchronisation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Albert, Thanks for your report. Le 07/04/2013 05:22, Albert Zangerl a écrit : since upgrading to 1.7.5+dfsg-1 (with installing php-sabre-vobject) my CalDavSync Application shows me this error: Fatal error: Class 'Sabre\VObject\DateTimeParser' not found in /usr/share/php/Sabre/CalDAV/CalendarQueryParser.php on line 246 Can you please document how CalendarQueryParser is called? Is it via owncloud (if so, which version)? Even though the file /usr/share/php/Sabre/VObject/DateTimeParser.php is existent (with the php-sabre-vobject package) it seems to be not found. I had to switch back to php-sabredav 1.6.3-1 Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRYXHVAAoJELgqIXr9/gnycN4QAJ0N7G2A+LimzC1+K1voZGnI Hahl5N565sls20vuDk0m/dIiDs8zwWmsyaycKnhIL/zJh7larzZF9DX6WPagwRZz 4SkV6bu4LZ2M87cGLk4cHNWX3sFJ+67EFWlTvw0Vjs0y+/XtZelwV90TyJAohdvW sNOIySLLeoJM36WVqNSUtGFU43AyKxBUV5LdPI5w+glHAkMNg5UrlZCtc0KzTqRJ aSBSI42scX8AO41iARg2FpKfWCWjIreR51aKRAbKT1dfSaeQMH5pgCaSV1kOf2jC Cs19nezrnd9CQ8m8852QTsHxsaqT+xWz+yLmTld4cO1rAqqPGy6tjo82ZahaKutV Q4YT9tiX3rYAIUa/gL2PstrrABlrl+3hdyA+2V7EqHc8ruWWhlOEZAhZI8bA/aI5 emPgrpgWcj6KwJFRBJMXT2kmVbTjuWkk/R5uyo9yIHZijWgIvOkde+HKBlbBJFUg wNbno8qQG31mP/VzgkdR/NCgUEdsbYhq2Tu0iJD+sDyd/VlF7EXZ6BXaGmRogXwm UpvrMaKAnvfNtz8R5rOai1tpO6gxISJzQDnl2ipYJ7ri/eKF0MuTNfMBB+I8OXYY 6zOkbOnr4+iXO7/QGgt8XpRYSeVtSiaa6xgWEPVGaAbShtRElDLwcm3zaSSDn2rN 4VqNDf5tyYrXawhmhxfY =8dDr -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#704903: php5: Bug #60723 error_log error time has changed to UTC ignoring default timezone
Package: php5 Version: 5.4.4-14 Severity: minor Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Logs don't print local time, but UTC. * What exactly did you do (or not do) that was effective (or ineffective)? Looked for bug report upstream. Bug is aparently solved, but not in Debian. https://bugs.php.net/bug.php?id=60723 As the PHP bug report says, my version of PHP should have this solved, but it doesn't. * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (40, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages php5 depends on: ii libapache2-mod-php5 5.4.4-14 ii php5-cgi 5.4.4-14 ii php5-common 5.4.4-14 php5 recommends no packages. php5 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#704904: release-notes: mention lightdm as gdm3 replacement
Package: release-notes Severity: normal Tags: patch Hi, gdm was installed as default display manager at least for Xfce task. Other people might have it and not want gdm3 as replacement (since it requires quite some more gnome stuff like gnome-session. Xfce task switchted to lightdm but it won't be automatically pulled, so it might be interesting to mention it in the release notes. Attached patch is a proposed phrasing. Regards, -- Yves-AlexisA -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-grsec-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 Index: en/upgrading.dbk === --- en/upgrading.dbk (revision 9717) +++ en/upgrading.dbk (working copy) @@ -2053,7 +2053,9 @@ listitem para systemitem role=packagegdm/systemitem, successor is - systemitem role=packagegdm3/systemitem. + systemitem role=packagegdm3/systemitem; people using Xfce, LXDE or + other lightweight desktop environment might want to use systemitem + role=packagelightdm/systemitem instead. /para /listitem listitem
Bug#684128: SI units (was Re: failure to communicate)
On 05/04/13 14:06, Ian Jackson wrote: Daniel Pocock writes (SI units (was Re: failure to communicate)): It may actually be useful for the technical committee to review what is on the wiki and make some general statement about Debian's position (if they haven't done so in the past), and that can guide the way similar bugs are classified for jessie and beyond. 1. http://lists.debian.org/debian-devel/2007/06/thrd2.html#00700 2. http://wiki.debian.org/ConsistentUnitPrefixes You should try to address this through the policy process. If and when we have competing policy proposals the TC might want to arbitrate. Hi Ian (and thanks Ian), Your issue is now on the radar and this is a clear way forward - even if it has been missed for wheezy, I too would like to see this progress in Debian, not just for the installer Here is the link to the policy team: http://wiki.debian.org/Teams/Policy and this is the existing wiki on units, which doesn't appear to be formal policy just yet: http://wiki.debian.org/ConsistentUnitPrefixes In the short term, the installer team really appear to have a lot of competing demands, there are a range of bugs listed for D-I related packages. In the long term, to keep Debian at the forefront, things like installing onto bootable btrfs RAID1 works fine[1] but needs changes to the installer to make it easy, and that appears to require strategic changes to the installer architecture[2]. There is a clear opportunity here for more people to be involved in the installer project (both collaborating on the more urgent bugs and doing strategic work), and approaching these issues as a whole would certainly give you a chance of influencing its future direction. Regards, Daniel 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686130 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686097 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704889: [Pkg-owncloud-maintainers] Bug#704889: php-sabredav: breaks caldav-synchronisation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-04-07 15:17, schrieb David Prévot: Hi Albert, Hi David, Thanks for your report. you're welcome. Can you please document how CalendarQueryParser is called? Is it via owncloud (if so, which version)? The error message shows on my Android-Phone in the app CalDavSync beta (https://play.google.com/store/apps/details?id=org.dmfs.caldav.lib ) On the server owncloud (4.0.8debian-1.6) is running. Thanks, Albert - -- The only excuse for God is that he doesn't exist. - -- Stendhal -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFhdUcACgkQ/06RcDHO2YiY/gCglSJKbH07YKLQLxw+cvovASTM yvAAn3xkhKL9Ro45CJLipaMFreAmZz/9 =pQ0G -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#704905: please ship contrib/ scripts in the Debian package
Package: ledger Version: 3.0.0~20130313+b608ed2-1 Severity: wishlist Heya, as per subject. Ledger's contrib https://github.com/ledger/ledger/tree/next/contrib contains quite a bit of useful scripts, for instance some useful to non-profits for generating reports in ODS format, and much more. Can you please update the package to ship the contrib/ dir under /usr/share/doc/ledger ? Thanks for considering ... and for maintaining ledger in Debian! Cheers. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 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 ledger depends on: ii dpkg 1.16.10 ii install-info 4.13a.dfsg.1-10 ii libboost-filesystem1.49.0 1.49.0-3.2 ii libboost-iostreams1.49.0 1.49.0-3.2 ii libboost-regex1.49.0 1.49.0-3.2 ii libboost-system1.49.0 1.49.0-3.2 ii libc6 2.13-38 ii libgcc11:4.7.2-5 ii libgmp10 2:5.0.5+dfsg-2 ii libicu48 4.8.1.1-12 ii libmpfr4 3.1.1-1 ii libstdc++6 4.7.2-5 ledger recommends no packages. ledger 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#704870: opus: cve-2013-0899
On Sat, 06 Apr 2013 20:00:56 -0400, Michael Gilbert wrote: CVE-2013-0899[0]: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0899 http://security-tracker.debian.org/tracker/CVE-2013-0899 Clicking through the links in https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0899 I came upon https://code.google.com/p/chromium/issues/detail?id=160480 which points to a commit http://git.xiph.org/?p=opus.git;a=commitdiff;h=9345aaa5ca1c2fb7d62981b2a538e0ce20612c38 Same in https://codereview.chromium.org/11575026 which points to https://codereview.chromium.org/download/issue11575026_5001_6001.diff (Please note that I haven't checked if this applies to the opus version in Debian.) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Tom Waits: Poncho's Lament signature.asc Description: Digital signature
Bug#703376: javahelper: Remove Maven support from jh_makepkg
Control: tags -1 confirmed On 2013-03-18 23:04, Hilko Bengen wrote: Package: javahelper Version: 0.43 Severity: normal Tags: patch jh_makepkg's template for Maven projects produces a debian/rules file that uses /usr/bin/mvn-debian whose maintainer does not support production use. The comment at the top of /usr/bin/mvn-debian is correct: The template produced by jh_makepkg cannot even determine in a robust way if the build attempt by mvn-debian has been successful or not. Yet, production use is exactly what is implied by templates for building Debian packages that are output by a script. In its current form, this template does more harm and frustration than good for unsuspecting users (DDs such as myself who just want to package some Maven-built software). On the other hand, supporting Maven seems to be a bigger, more complicated, task that is better served by mh_make from the maven-debian-helper package. I suggest removing maven support from jh_makepkg altogether; see my patch below. Cheers, -Hilko [...] I will probably have jh_makepkg recommend mh_make for this instead instead of just removing the options. But definitely seconded. I am planning on a rewrite of jh_makepkg and have therefore not applied your patch as-is. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704853: Wheezy RC1 i386 on Dell Precision M65 laptop
On Sun 07 Apr 2013 at 06:07:37 +0200, Christian PERRIER wrote: Quoting Cyril Brulebois (k...@debian.org): 1) The WLAN password is displayed on screen. User account passwords are not displayed on screen, so presumably it is a bug for WLAN passwords to be displayed. Bonus points for a Display password button to toggle display of the password. I can't find a pointer right now, but that was discussed on this list already, and yes, it would indeed by nice to have. That would mean implementing some bits on the debconf side, too. Yes, there is something somewhere else. Can't find it either, though. #700834 may be what you are looking for. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704906: ITP: emscripten -- An LLVM-to-JavaScript Compiler
Package: wnpp Severity: wishlist Owner: Sylvestre Ledru sylves...@debian.org * Package name: emscripten Version : git Upstream Author : Alon Zakai alonza...@gmail.com * URL : http://emscripten.org * License : MIT license and the University of Illinois/NCSA Open Source License Programming Lang: JS co Description : An LLVM-to-JavaScript Compiler Emscripten is an LLVM to JavaScript compiler. It takes LLVM bitcode (which can be generated from C/C++ using Clang, or any other language that can be converted into LLVM bitcode) and compiles that into JavaScript, which can be run on the web (or anywhere else JavaScript can run). Using Emscripten, you can * Compile C and C++ code into JavaScript and run that on the web * Run code in languages like Python as well, by compiling CPython from C to JavaScript and interpreting code in that on the web -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704844: [wiki.debian.org] French interface: broken links for edit help (HelpOnEditing, HelpOnMoinWikiSyntax)
On 2013-04-06 19:11, Paul Wise wrote: Control: reassign -1 python-moinmoin Control: affects -1 wiki.debian.org Control: tags -1 + upstream On Sun, Apr 7, 2013 at 12:57 AM, Filipus Klutiero wrote: When editing a page, information to help editing is shown at the bottom. At the very bottom a paragraph links to more information. ... In French, one sees: Pour plus d'informations, reportez-vous à l'[AideDeL'Édition|AideDeL'Édition] ou au AideDeLaSyntaxeWikiDeMoinMoin. Although the second link shows, it is broken. This appears to be an issue with moinmoin upstream: http://moinmo.in/AideDeLaSyntaxeWikiDeMoinMoin Please contribute a translation for this page to upstream and once that reaches Debian we can backport the package to wheezy to fix this issue. A translation would be ideal, but the problem I'm reporting isn't a lack of translation, it's broken links. I simply expect the links to be fixed or removed. Anyway, the pages are already translated as you can see in /usr/share/moin/underlay/pages/LanguageSetup/attachments/French--all_help_pages.zip (36 and 39). But I have to agree that this seems to be an upstream bug, as I can reproduce on http://moinmo.in/action/edit/WikiSandBox?action=editeditor=text which runs 1.9.7! http://master19.moinmo.in/ has the pages ( http://master19.moinmo.in/AideDeL%27%C3%89dition ) and is also on 1.9.7 (but none of its pages can be edited). This suggests the main problem could be one of setup (only English help pages on some installs). wiki.debian.org runs 1.9.4. The problem with the first link may be a different issue. Don't links need 2 brackets at each extremity (now?)? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696899: can anybody sponsor an ITP for premake4 ?
in-line :- On Sun, Apr 7, 2013 at 9:32 AM, Cameron Hart cameron.h...@gmail.com wrote: Please use the premake4_4.3-1 version. After feedback from Jonathan that the version number shouldn't be incremented until it's actually uploaded to unstable I switched the version back to 4.3-1. The url is http://mentors.debian.net/debian/pool/main/p/premake4/premake4_4.3-1.dsc. I don't know if I can delete the 4.3-2 upload from mentors unfortunately. would do. If you don't already have a pbuilder environment set up it might be easier to use debuild. The following should hopefully build and install the package for you: sudo apt-get install dget devscripts debhelper cdbs liblua5.1-0-dev AFAIK dget is part of devscripts there is no binary by the name of dget or did you mean something else ? $ which dget /usr/bin/dget $ dpkg -S /usr/bin/dget devscripts: /usr/bin/dget Can anybody tell why lua 5.1-dev is being used instead of lua5.2-dev ? AFAIK I have both of them installed :- $ apt-show-versions -a liblua5.1-0-dev liblua5.1-0-dev 5.1.5-4 install ok installed liblua5.1-0-dev 5.1.4-5 stable ftp.debian.org liblua5.1-0-dev 5.1.5-4 wheezy ftp.debian.org liblua5.1-0-dev 5.1.5-4 unstable ftp.debian.org No experimental version liblua5.1-0-dev/wheezy uptodate 5.1.5-4 $ apt-show-versions -a liblua5.2-dev liblua5.2-dev 5.2.1-3 install ok installed No stable version liblua5.2-dev 5.2.1-3 wheezy ftp.debian.org liblua5.2-dev 5.2.1-3 unstable ftp.debian.org No experimental version $ lua -v Lua 5.2.1 Copyright (C) 1994-2012 Lua.org, PUC-Rio The default is lua5.2 at my end. dget -ux http://mentors.debian.net/debian/pool/main/p/premake4/premake4_4.3-1.dsc cd premake4-4.3/ debuild -us -uc cd .. dpkg -i premake4_4.3-1_i386.deb (assuming i386) There may be an easier way, I'm no expert :) I used cdbs and was able to install it in the end :- ~/games/premake4$ dget -ux http://mentors.debian.net/debian/pool/main/p/premake4/premake4_4.3-1.dscdget: retrieving http://mentors.debian.net/debian/pool/main/p/premake4/premake4_4.3-1.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1389 100 13890 0974 0 0:00:01 0:00:01 --:--:-- 7937 dget: retrieving http://mentors.debian.net/debian/pool/main/p/premake4/premake4_4.3.orig.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 392k 100 392k0 0 68189 0 0:00:05 0:00:05 --:--:-- 70756 dget: retrieving http://mentors.debian.net/debian/pool/main/p/premake4/premake4_4.3-1.debian.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 7881 100 78810 0 15061 0 --:--:-- --:--:-- --:--:-- 22013 dpkg-source: info: extracting premake4 in premake4-4.3 dpkg-source: info: unpacking premake4_4.3.orig.tar.gz dpkg-source: info: unpacking premake4_4.3-1.debian.tar.gz dpkg-source: info: applying generated-makefile.diff dpkg-source: info: applying fix-readme.diff dpkg-source: info: applying kfreebsd-fix.diff dpkg-source: info: applying fix-findlib.diff Just cdbs was absent so installed that too :- ~/games/premake4$ sudo aptitude install cdbs The following NEW packages will be installed: cdbs 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 78.1 kB of archives. After unpacking 226 kB will be used. Get: 1 http://ftp.debian.org/debian/ wheezy/main cdbs all 0.4.115+deb7u1 [78.1 kB] Fetched 78.1 kB in 7s (10.9 kB/s) Retrieving bug reports... Done Parsing Found/Fixed information... Done Selecting previously unselected package cdbs. (Reading database ... 540149 files and directories currently installed.) Unpacking cdbs (from .../cdbs_0.4.115+deb7u1_all.deb) ... D01: process_archive oldversionstatus=not installed D01: process_archive updating info directory D01: generating infodb hashfile Processing triggers for man-db ... Setting up cdbs (0.4.115+deb7u1) ... D01: deferred_configure updating conffiles ~/games/premake4$ cd premake4-4.3/ ~/games/premake4/premake4-4.3$ debuild -us -uc dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: source package premake4 dpkg-buildpackage: source version 4.3-1 dpkg-buildpackage: source changed by Cameron Hart c...@bitshifter.net.nz dpkg-source --before-build premake4-4.3 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean test -x debian/rules dh_testroot rm -f debian/stamp-makefile-build debian/stamp-makefile-install /usr/bin/make -C . CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro -k
Bug#698732: dspam external map does not work with TLS enabled
Le samedi 2 mars 2013 09:34:32, Jason a écrit :
I think we've already figured it out. The problem is that DSPAM currently
only supports TLS via STARTTLS but I'm using ldaps which is a different
protocol. I would have submitted a patch already but I currently don't
have a Linux dev environment to do the build on (only a server which, for
security reasons I don't want things like compilers on).
I think *you* had already figured it out ;)
All that needs to happen is the field where you specify ldap or
database needs to also accept ldaps and put what ever is in that field
as the schema. Then the ldap library will do the right thing.
So here's the patch. I'll open a bug upstream to ask them to integrate it.
Don't expect miracles though: the last commit in the upstream git repository
was in august 2012. If nobody answer within 2 months, I might consider to
include it in Debian anyway given the small size of the patch (most of the
diff is just increasing the indentation).
Any testing on your side would be appreciated. I can provide you deb packages
in my personal repository if you need.
Best regards,
Thomas
diff --git a/src/external_lookup.c b/src/external_lookup.c
index 4f8e10e..eaf48e0 100644
--- a/src/external_lookup.c
+++ b/src/external_lookup.c
@@ -164,7 +164,7 @@ ldap_lookup(config_t agent_config, const char *username, char *external_uid)
struct timeval ldaptimeout = {.tv_sec = BIND_TIMEOUT, .tv_usec = 0};
int i, rc=0, num_entries=0;
char *transcoded_query = NULL;
- char *ldap_uri = NULL;
+ char *ldap_uris[2] = {NULL, NULL}; // 0 = ldap, 1 = ldaps
char *end_ptr;
char *ldap_host = _ds_read_attribute(agent_config, ExtLookupServer);
char *port = _ds_read_attribute(agent_config, ExtLookupPort);
@@ -249,30 +249,43 @@ ldap_lookup(config_t agent_config, const char *username, char *external_uid)
url.lud_port = ldap_port;
url.lud_scope = LDAP_SCOPE_SUBTREE;
- ldap_uri = ldap_url_desc2str( url );
- }
+ ldap_uris[0] = ldap_url_desc2str( url );
- rc = ldap_initialize( ld, ldap_uri );
- if( rc != LDAP_SUCCESS ) {
- LOG(LOG_ERR, External Lookup: Could not create LDAP session handle for URI=%s (%d): %s\n, ldap_uri, rc, ldap_err2string(rc));
- return NULL;
- }
+ url.lud_scheme = ldaps;
+ url.lud_host = ldap_host;
+ url.lud_port = ldap_port;
+ url.lud_scope = LDAP_SCOPE_SUBTREE;
- if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, ldap_version ) != LDAP_OPT_SUCCESS ) {
- LOG(LOG_ERR, External Lookup: Could not set LDAP_OPT_PROTOCOL_VERSION %d\n, ldap_version );
- return NULL;
+ ldap_uris[1] = ldap_url_desc2str( url );
}
- /* use TLS if configured */
- if ( _ds_match_attribute(agent_config, ExtLookupCrypto, tls )) {
- if (ldap_version != 3) {
- LOG(LOG_ERR, External Lookup: TLS only supported with LDAP protocol version 3);
+ /* Try ldap then ldaps */
+ for (i = 0; i 2; i++) {
+ rc = ldap_initialize( ld, ldap_uris[i] );
+ if( rc != LDAP_SUCCESS ) {
+ LOG(LOG_ERR, External Lookup: Could not create LDAP session handle for URI=%s (%d): %s\n, ldap_uris[i], rc, ldap_err2string(rc));
return NULL;
}
- if ( ldap_start_tls_s( ld, NULL, NULL ) != LDAP_SUCCESS ) {
- LOG(LOG_ERR, External Lookup: %s: %s (%d), ERR_EXT_LOOKUP_INIT_FAIL, strerror(errno), errno);
+
+ if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, ldap_version ) != LDAP_OPT_SUCCESS ) {
+ LOG(LOG_ERR, External Lookup: Could not set LDAP_OPT_PROTOCOL_VERSION %d\n, ldap_version );
return NULL;
}
+
+ /* use TLS if configured */
+ if ( _ds_match_attribute(agent_config, ExtLookupCrypto, tls )) {
+ if (ldap_version != 3) {
+LOG(LOG_ERR, External Lookup: TLS only supported with LDAP protocol version 3);
+return NULL;
+ }
+ if ( ldap_start_tls_s( ld, NULL, NULL ) != LDAP_SUCCESS ) {
+if (!i)
+ continue;
+LOG(LOG_ERR, External Lookup: %s: %s (%d), ERR_EXT_LOOKUP_INIT_FAIL, strerror(errno), errno);
+return NULL;
+ }
+ }
+ break;
}
/* schedules alarm */
signature.asc
Description: This is a digitally signed message part.
Bug#704482: #704482 general: file copy over kde gui or cp to an usb devices (tried fat/ext3) is showen as finshed while it's still copying
Hey, I think it would be nice to have a progress bar that would show the actual data transfer. There is, if you are using KDE and plasma. I think it's trough dbus, so maybe it works in Gnome too. Thats the point there is and its fine but its wrong for fat usb devices, i tested it now for cp because its easier to stop the time but its at this progress bar from kde the same So i copied a file with 1,5GB and the copy progress is finished in 55sec (command prompt comes back) but it isn't, you see that they device is still working for another 30sec (i have gkrellm where you see the datarate to devices) and in this time you can not unmount the device you get the error i posted in my last message. So kde and cp are showing a wrong state of coping file to fat usb devices. But if it is at those both are not showing the correct state, doesn't that mean that this will be at any data copying over usb?. So it's something more generall then konquer? (which i do not use, i use Dolphin) The correct state is being shown, so I don't see a problem here. you tried it? for fat usb devices? thanks best regards
Bug#704889: [Pkg-owncloud-maintainers] Bug#704889: php-sabredav: breaks caldav-synchronisation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 07/04/2013 09:21, Albert Zangerl a écrit : On the server owncloud (4.0.8debian-1.6) is running. Please note that owncloud 5.0.3+dfsg-1 is available in experimental. Since it seems to do more harm than good, I’ll drop the php-sabredav dummy binary, thus allowing people sticking to owncloud 4.0.8 to keep it working before we push owncloud 5.0 to Sid. Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRYX7JAAoJELgqIXr9/gnyn/wQAKbYuYvyNbt24/2qIdqPhU+4 4ZgTIDCA56RLooucoAm/MtGX2VwcfeS03YFG/+pB8EYhWpU7xf0xa4d0AnJ2bGcu +NdwEjamvMSxrATCSKtH9H/m8B973LACOr4zmdtcc5yCth+fHxgSvcLCXpXmd5PU 3PSgtTI/r58bx4hn5VgBOTstkq0VrEh6+BZJOHR7kldNpz9l0aJaSEvUEG+PJGcg Vlh3HZIwI/fQLuPIcRXe7KcBiAMqZEQvDM5p1rSo9O0G9HSJGXaPKeDZZQPpnjVp 66sD0iGVDrMT5nJapMlE7rAK06iV8F9FmZ+wFE8KSfvDw0DuKPg0F8jMaKofVvTA GJpQz3b35q1l0ZDutVgyBb0JAGEkXmJngqiiBe/QpeoHh4OLAyzbIUJVlG3aFsOP G+pFVqgSDGA3q6UEp6JzRfsGfqYg9zs3iGGEjj+uYzIo+5vqrUPSSy3fVEdEfoK1 gdGgT8867DZVEJVxm2JwP/HPbfkqWVirB4tsNdChp4rMyl12n/X5+b5nO81eefN2 E5Fkm9echbxwglI8G4tMkBW0elf/48+TzctMFhcijsnS2pj+IXiMujwJssKuaFbT Um1HrIWLuWEQVElGt4M+BnhWMDlll/dNe1v1s9yG/E7JVcNQ3Cu1IdTnD35/c/Q4 b6u3ivoeZQYcm2iPSNoy =UcYK -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#704587: ITP: libtcod -- an API for roguelike developpers
* Oohara Yuuma ooh...@libra.interq.or.jp [130405 08:38]: The library packaging guide [5] may help: | It is quite important that Debian does not lose binary compatibility | with other distributions, so changing the SONAME specifically | for Debian is generally a bad idea. Thanks. I might update the upstream guide with these links. I had an answer from upstream ; they're aware of the problems it caused in the past and now want to keep compatibility. As a matter of fact, 1.5.2 was just added to UT and does not break API: http://upstream-tracker.org/versions/libtcod.html I'll prepare a patch for upstream setting the SONAME to 1 (same as the major version). -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704907: thawab: The .bok files are not converting, it stops at converting..
Package: thawab Version: 3.0.13-1 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) 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 thawab depends on: ii mdbtools 0.7-1 ii python 2.7.3-4 ii python-gtk22.24.0-3+b1 ii python-okasha 0.2.4-1 ii python-othman 0.2.7-1 ii python-paste 1.7.5.1-4.1 ii python-webkit 1.1.8-2 ii python-whoosh 2.3.2-2 Versions of packages thawab recommends: pn islamic-menus none thawab 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#704908: bup: Version in experimental not in Vcs.
Package: bup Version: 0.25~git20130303-1 Severity: minor The packaging of the latest version of bup in experimental is not in the repository pointed by the Vcs-git -header. Please either update the repo, or the headers to point to the correct place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704909: ITP: libcmime - libcmime is a lightweight mime library, written in C
Package: wnpp Severity: wishlist Owner: Werner Detter wer...@aloah-from-hell.de * Package name: libcmime Version : 0.1.6 Upstream Author : Axel Steiner, a...@treibsand.com Werner Detter, wer...@aloah-from-hell.de Robin Doer, r...@space.net * URL : http://www.libcmime.org * License : LGPL3 Programming Lang: C Description : libcmime is a lightweight mime library, written in C libcmime is a lightweight mime library, written in C. It attempts to be a general library for parsing and creating mime email messages and is designed to provide an easy to use and easy to integrate interface for developers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704889: [Pkg-owncloud-maintainers] Bug#704889: php-sabredav: breaks caldav-synchronisation
On Sun, 07 Apr 2013 10:12:26 -0400, David Prévot wrote: On the server owncloud (4.0.8debian-1.6) is running. Please note that owncloud 5.0.3+dfsg-1 is available in experimental. Since it seems to do more harm than good, I’ll drop the php-sabredav dummy binary, thus allowing people sticking to owncloud 4.0.8 to keep it working before we push owncloud 5.0 to Sid. Or maybe add a Breaks: owncloud ( 5) to the new dummy php-sabredav package to avoid premature/asynchronous upgrades? Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Nguyên Lê: Kithâra signature.asc Description: Digital signature
Bug#704910: bup: Work around pandoc absence also in mips.
Package: bup Version: 0.25~git20130303-1 Severity: normal Tags: patch As pandoc never seems to be in a buildable state in mips, it would be better to have the already built docs (man, html) included in the source package. The attached patch makes is possible to build the bup package from the upstream git repo, with the debian-dir from the package from experimental copied in. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: mips Kernel: Linux 3.3.8 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bup depends on: ii git [git-core] 1:1.7.10.4-1+wheezy1 ii libc6 2.13-38 ii python 2.7.3-4 ii python-fuse 2:0.2.1-7 ii python-tornado 2.3-2 ii python2.7 2.7.3-8 Versions of packages bup recommends: pn par2 none bup suggests no packages. -- no debconf information From fb01050166bff00571a8782a31cb83405bab03fe Mon Sep 17 00:00:00 2001 From: Teemu Ikonen tpiko...@gmail.com Date: Sat, 6 Apr 2013 22:41:51 +0200 Subject: [PATCH] Do not build-dep on pandoc also on mips. --- debian/control |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 92a1dc6..1de7109 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Section: admin Priority: extra Maintainer: Robert S. Edmonds edmo...@debian.org Build-Depends: debhelper (= 7.0.50~), - pandoc [!ia64 !mipsel !s390 !hurd-i386], + pandoc [!ia64 !mips !mipsel !s390 !hurd-i386], python-dev (= 2.6.6-3~), python-pyxattr, python-pylibacl, git (= 1:1.7.0.4-2) | git-core, -- 1.7.10.4
Bug#704889: [Pkg-owncloud-maintainers] Bug#704889: Bug#704889: php-sabredav: breaks caldav-synchronisation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Gregor, Le 07/04/2013 10:30, gregor herrmann a écrit : On Sun, 07 Apr 2013 10:12:26 -0400, David Prévot wrote: Since it seems to do more harm than good, I’ll drop the php-sabredav dummy binary Or maybe add a Breaks: owncloud ( 5) to the new dummy php-sabredav package to avoid premature/asynchronous upgrades? That’s a lot better thanks, but I haven’t been quick enough with “dcut rm”… I’ll upload a -3 version with the proposed fix, but that will have to go through NEW again. Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRYYehAAoJELgqIXr9/gnyb7IP/A3W2hm0UBlxMVYB3wEib5j1 VEWWfHftG9hUxdNkESHqF7qP62Zb5SP+mUVcYBgiLiDYc8M6ZYmFq5Q1q2trB5bH 8Com4iZ6bZsHq2+u+2Zz2QvJHfuGyuxbF1E059t6puduJiLf0aDCJqi9cufqcLBX l8e475wa15Wz/Y1t+ZIK/wMn3+RaV2uh+/KUQ1jN1OZRyy7VHwp4t244KJe2RFsL thFmYw6iWA+UmALs61ZSps/c+4O73C0Yged1CIoCKQMbh17w4rptX2D/wC+qPkPw bCfRsKZHEnLjqkbxsts7viEPmGIeGJLOuhzxwDIsuIl8toTLDB5QVmoVbaHUvo0B W0P4lfmlzSUmjLvrlgWfYS+nukaA7J3KXdNBXqoVMzHVwOuG5LLbQkyDCltjj8X9 IuCSlg8+Tha6+esIM/2VWHbNk1T6NgOgqfR0LC8rA4cSmwwL4QTdmxbHCmAbB+cf FnUp5h+LXPVngV/cQvHPEC7S0kecCpIn2x+wU5uiyWWpg91ZDb6VBLDy++k6vXgI gYpbyNJ4qwf3rFe6j79OU5a5szZpcn0XoKahKB8hppqAt7Jiu/KKijVChrOtcRyW 7Ux6mJC4n0iedm8yT5Uku+VwZI0tXH7XMlT3Gke7dHISZLlK5W/dItlGyYevHf51 v8gy+E7+i1GYhPsoLQoT =s5yu -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#704912: base: VirtualBox Guest Additions installation with Kernel 3.2.0-4-486 failed
Package: base Severity: normal Dear Maintainer, the installation of VirtualBox 4.2.10 Guest Additions with Kernel 3.2.0-4-486 failed. I have no 3D-grafik and Gnome 3 will not work. Verifying archive integrity... All good. Uncompressing VirtualBox 4.2.10 Guest Additions for Linux.. VirtualBox Guest Additions installer Removing installed version 4.2.10 of VirtualBox Guest Additions... Removing existing VirtualBox DKMS kernel modules ...done. Removing existing VirtualBox non-DKMS kernel modules ...done. Building the VirtualBox Guest Additions kernel modules The headers for the current running kernel were not found. If the following module compilation fails then this could be the reason. Building the main Guest Additions module ...done. Building the shared folder support module ...done. Building the OpenGL support module ...fail! (Look at /var/log/vboxadd-install.log to find out what went wrong) Doing non-kernel setup of the Guest Additions ...done. Installing the Window System drivers Installing X.Org Server 1.12 modules ...done. Setting up the Window System to use the Guest Additions ...done. You may need to restart the hal service and the Window System (or just restart the guest system) to enable the Guest Additions. Installing graphics libraries and desktop services components ...done. Press Return to close this window... /var/log/vboxadd-install.log here: http://pastebin.com/pTNLRjWY Please have a look to debianform thead Gast Erweiterungen mit fehlerhafter Installation http://debianforum.de/forum/viewtopic.php?f=29t=141447p=927206#p927206 With Kernel 3.2.0-4-486 (Subversion 3.2.35-2) and VirtualBox 4.1.24 the Guest Additions installation woks fine. Please give me a answer to ch-hani...@t-online.de regards Ch. Hanisch -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-486 Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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#704889: [Pkg-owncloud-maintainers] Bug#704889: Bug#704889: php-sabredav: breaks caldav-synchronisation
On Sun, 07 Apr 2013 10:50:10 -0400, David Prévot wrote: Hi Gregor, Salut David ! Since it seems to do more harm than good, I’ll drop the php-sabredav dummy binary Or maybe add a Breaks: owncloud ( 5) to the new dummy php-sabredav package to avoid premature/asynchronous upgrades? That’s a lot better thanks, but I haven’t been quick enough with “dcut rm”… I’ll upload a -3 version with the proposed fix, but that will have to go through NEW again. Hm, let's see how quick dak is about forgetting packages :) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Nguyên Lê: Kithâra signature.asc Description: Digital signature
Bug#704913: git-bzr fails to properly clone bzr::http://bzr.savannah.gnu.org/r/grub/trunk/grub
Package: git-bzr
Version: 1:1.8.2-1
Severity: important
I tried to look at grub's bzr repository with git-bzr (version
1:1.8.2-1) as well as with bzr (version 2.6.0~bzr6526-1).
i did two checkouts:
git clone bzr::http://bzr.savannah.gnu.org/r/grub/trunk/grub grub.git
bzr branch http://bzr.savannah.gnu.org/r/grub/trunk/grub grub.bzr
They produced very different source trees:
0 dkg@reason:~/src/grub$ diff -ruN grub.{bzr,git}/grub-core | diffstat -p0
grub.git/grub-core/boot/i386/pc/pxeboot.S | 42
grub.git/grub-core/commands/efi/acpi.c| 59
grub.git/grub-core/efiemu/loadcore32.c| 22
grub.git/grub-core/efiemu/loadcore64.c| 22
grub.git/grub-core/efiemu/prepare32.c | 22
grub.git/grub-core/efiemu/prepare64.c | 22
grub.git/grub-core/efiemu/runtime/config.h| 34
grub.git/grub-core/efiemu/runtime/efiemu.S| 159 -
grub.git/grub-core/fs/tar.c |2
grub.git/grub-core/fs/ufs2.c |3
grub.git/grub-core/gfxmenu/gui_box.c | 412 ---
grub.git/grub-core/gfxmenu/gui_canvas.c | 267 --
grub.git/grub-core/gfxmenu/gui_util.c | 101
grub.git/grub-core/gnulib/argp-ba.c | 34
grub.git/grub-core/gnulib/argp-eexst.c| 30
grub.git/grub-core/gnulib/argp-fs-xinl.c | 42
grub.git/grub-core/gnulib/argp-namefrob.h | 157 -
grub.git/grub-core/gnulib/argp-pin.c | 27
grub.git/grub-core/gnulib/argp-pv.c | 34
grub.git/grub-core/gnulib/argp-pvh.c | 31
grub.git/grub-core/gnulib/argp-xinl.c | 42
grub.git/grub-core/gnulib/argp.h | 645 -
grub.git/grub-core/gnulib/error.h | 65
grub.git/grub-core/gnulib/getopt1.c | 170 -
grub.git/grub-core/gnulib/progname.c | 92
grub.git/grub-core/gnulib/progname.h | 62
grub.git/grub-core/kern/emu/time.c| 46
grub.git/grub-core/kern/generic/millisleep.c | 39
grub.git/grub-core/kern/sparc64/cache.S | 41
grub.git/grub-core/kern/sparc64/ieee1275/ieee1275.c | 91
grub.git/grub-core/kern/time.c| 37
grub.git/grub-core/lib/LzmaDec.c | 1035
grub.git/grub-core/lib/envblk.c | 296 --
grub.git/grub-core/lib/hexdump.c | 85
grub.git/grub-core/lib/libgcrypt/cipher/arcfour.c | 156 -
grub.git/grub-core/lib/libgcrypt/cipher/bithelp.h | 54
grub.git/grub-core/lib/libgcrypt/cipher/blowfish.c| 605 -
grub.git/grub-core/lib/libgcrypt/cipher/camellia-glue.c | 253 --
grub.git/grub-core/lib/libgcrypt/cipher/camellia.c| 1461
grub.git/grub-core/lib/libgcrypt/cipher/camellia.h| 81
grub.git/grub-core/lib/libgcrypt/cipher/cast5.c | 620 -
grub.git/grub-core/lib/libgcrypt/cipher/elgamal.c | 846 ---
grub.git/grub-core/lib/libgcrypt/cipher/hash-common.c | 94
grub.git/grub-core/lib/libgcrypt/cipher/hash-common.h | 33
grub.git/grub-core/lib/libgcrypt/cipher/hmac-tests.c | 732 --
grub.git/grub-core/lib/libgcrypt/cipher/rijndael-tables.h | 1687 --
grub.git/grub-core/lib/libgcrypt/cipher/rijndael.c| 1253 --
grub.git/grub-core/lib/libgcrypt/cipher/rmd.h | 37
grub.git/grub-core/lib/libgcrypt/cipher/seed.c| 478 ---
grub.git/grub-core/lib/posix_wrap/errno.h | 28
grub.git/grub-core/lib/posix_wrap/stdint.h|1
grub.git/grub-core/loader/i386/bsd32.c|6
grub.git/grub-core/loader/i386/bsd64.c|6
grub.git/grub-core/video/sm712_init.c | 14
54 files changed, 12713 deletions(-)
0 dkg@reason:~/src/grub$
This is despite them both appearing to claim to be at the same revision:
0 dkg@reason:~/src/grub$ (cd grub.bzr bzr log -r-1)
revno: 4810
author: Andrey Borzenkov arvidj...@gmail.com
committer: Vladimir 'phcoder' Serbinenko phco...@gmail.com
branch nick: grub
timestamp: Sat 2013-04-06 20:49:02 +0200
message:
* conf/Makefile.extra-dist (EXTRA_DIST): Add
grub-core/lib/libgcrypt/src/gcrypt.h.in and util/import_gcrypth.sed.
0 dkg@reason:~/src/grub$ (cd grub.git git log -n1)
commit 17b15326c633a9e2fb179ab0867f2d34fe213aa6
Author: Vladimir 'phcoder' Serbinenko phco...@gmail.com
Date: Sat Apr 6 20:49:02 2013 +0200
* conf/Makefile.extra-dist (EXTRA_DIST): Add
Bug#704889: [Pkg-owncloud-maintainers] Bug#704889: Bug#704889: php-sabredav: breaks caldav-synchronisation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Gregor, Le 07/04/2013 10:57, gregor herrmann a écrit : On Sun, 07 Apr 2013 10:50:10 -0400, David Prévot wrote: I’ll upload a -3 version with the proposed fix, but that will have to go through NEW again. Hm, let's see how quick dak is about forgetting packages :) Good call (again): not as quick as I thought ;). Thanks again for shimming in. Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRYZAHAAoJELgqIXr9/gnyOfwQAIJqPXpFLgjEungYXLnJ0Q2o UUFTMUWcIhoCgWO1o928boCb++QAFDILhpRYh/0KhP9TJ7zD0pk6Eyx40g/kvYNe 20d8sxroJvPeQjrIv4PHFOL7hSyzozZSazd5j1L9tHupZRc1dihdJ361VXSP/41M fagCUFVDtWw2oe6Vkf43taEpvh11keaWNH50RGhCCcSt7XEihOWsQZNXvDD5DdF/ I8SowIP+UQEtjcpcAHESPVqQTesgASG6S7KnznOhJzZjz+kkpcYzaMTfWGQnRCFd AZSig734bR6AqRmeVCNWqkcoK8hSp2LWEZB7v7Z4z8PQYHdo+HyIY3fkSBR+S0jG 8HWfKt8n6tx8aZJKJMN3K4xw71/EOYcuwFN0p8BYYMLX11Sw+4euWeXJEMd8XsTC cDP9AhzyDX8iL5cOqZD9rnYUZJESUAQl5sECUWfXybIvaghToytiBCnsMd1vDKOA DbvxpM3NCsjNUzXVONtqUpgcaX8YUInxnkgzNC8rBYfl9bmGcCzrG7MUZKLJyQA0 ai5Qm6LGsGVbgOc2bc3gL1oSdmBHMeDdcFhIlTU5wQt8Hw/TLp/o3Fjg4M3dAJWo OpGFpdBVGUDhJw/RnAx3bYjYpXHlR0GYqg8wqD96yKRIxGSSwfC48dOpNe/8gf1y TlUl7IBtwRqK0HRVx7DW =FrW6 -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#704914: glx-alternatives: The libGL diversion does not work
Source: glx-alternatives Version: 0.2.90 Severity: grave Justification: renders package unusable There is a severe problem with the libGL diversion strategy as exists at present. The desktop is rendered inoperable after any change in the packaging, due to the diversion in glx-diversions being replaced by the actual lib from libgl1-mesa-glx. This is because gnome- session-bin and other current parts of the gnome desktop have a hardcoded dependency on libgl1-mesa-glx (or the virtual libgl1). This means the gnome desktop in 3.8 is NOT co-installable with nvidia graphics drivers, a situation this diversion was meant to prevent. The only fix is to re-run update-alternatives --configure glx, which re- replaces the symlink diversion however, if gnome is about to progress beyond experimental, it is likely this is about to become a critical pain point. I read bug 389971, on the reasons the nvidia-glx* packages don't directly provide libgl1, but it may be that unless the gnome team changes their libgl deps, this might be the only solution (or, alternatively, making the glx-alternatives packages provide libgl1?) It should be noted, that the nvidia alternative clearly *works*, however, making it so is pretty challenging. Info on my system as it stands at present: # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1 diversion by glx-diversions from: /usr/lib/x86_64-linux-gnu/libGL.so.1 diversion by glx-diversions to: /usr/lib/mesa-diverted/x86_64-linux- gnu/libGL.so.1 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1 # dpkg --remove libgl1-mesa-glx:amd64 dpkg: dependency problems prevent removal of libgl1-mesa-glx:amd64: gnome-session-bin depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. libvisual-0.4-plugins:amd64 depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. libglew1.7:amd64 depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. enblend depends on libgl1-mesa-glx | libgl1; however: Package libgl1-mesa-glx:amd64 is to be removed. Package libgl1 is not installed. Package libgl1-mesa-glx:amd64 which provides libgl1 is to be removed. mplayer depends on libgl1-mesa-glx | libgl1; however: Package libgl1-me dpkg: error processing libgl1-mesa-glx:amd64 (--remove): dependency problems - not removing Errors were encountered while processing: libgl1-mesa-glx:amd64 Thanks Christian -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (501, 'unstable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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#704915: auctex: Fails to install
Package: auctex Version: 11.85-1 Severity: grave Justification: renders package unusable Debian Squeeze AMD64. The package in subject fails to install (fresh install). This is the output from terminal: # LC_ALL=C aptitude install auctex The following NEW packages will be installed: auctex 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/1305 kB of archives. After unpacking 4678 kB will be used. Preconfiguring packages ... Selecting previously deselected package auctex. (Reading database ... 254909 files and directories currently installed.) Unpacking auctex (from .../auctex_11.85-1_all.deb) ... Processing triggers for install-info ... Processing triggers for man-db ... Processing triggers for doc-base ... Processing 2 added doc-base file(s)... Registering documents with scrollkeeper... Setting up auctex (11.85-1) ... install/auctex: Setting up for emacs23 (log file: /usr/share/emacs23/site- lisp/auctex//CompilationLog)... emacs-package-install: /usr/lib/emacsen- common/packages/install/auctex emacs23 emacs23 failed at /usr/lib/emacsen- common/emacs-package-install line 30, TSORT line 1. dpkg: error processing auctex (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: auctex E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up auctex (11.85-1) ... install/auctex: Setting up for emacs23 (log file: /usr/share/emacs23/site- lisp/auctex//CompilationLog)... emacs-package-install: /usr/lib/emacsen- common/packages/install/auctex emacs23 emacs23 failed at /usr/lib/emacsen- common/emacs-package-install line 30, TSORT line 1. dpkg: error processing auctex (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: auctex Thank you very much in advance, Domenico -- Package-specific info: Content of '/usr/share/emacs/site-lisp/auctex/' 4445a5aa5b0c6dd4eeb5d6a7b214b9a7 /usr/share/emacs/site-lisp/auctex/ChangeLog 7a5ac7b2ea13114a7237cad95ce9e127 /usr/share/emacs/site-lisp/auctex/Makefile 94b8353848c014c5aad9e29b149ff931 /usr/share/emacs/site-lisp/auctex/Makefile.in f86b3412ef7d2947d5ab37ab13f2200d /usr/share/emacs/site-lisp/auctex/aclocal.m4 c515b501a8d5009537edfb0348d3f14e /usr/share/emacs/site-lisp/auctex/auctex.el e23e60e9de6051db5156aecaaaea11e7 /usr/share/emacs/site-lisp/auctex/auctex.el.in 3366a99dd44e27fa57e0bcc130c4fa1c /usr/share/emacs/site-lisp/auctex/bib-cite.el 542b9f88e6d102b497e17c104de7568a /usr/share/emacs/site-lisp/auctex/confdefs.h 683dbf2998518f1d182da52f12bd1d63 /usr/share/emacs/site-lisp/auctex/config.log dbb7f49fb883815b70b880b1c047d6b7 /usr/share/emacs/site-lisp/auctex/config.status 8f868ec2c03618542b54b36547f83afd /usr/share/emacs/site-lisp/auctex/configure 9ad8e6370c812d9a54f4b76b7b6ccfcd /usr/share/emacs/site-lisp/auctex/configure.ac bc74f7b5fa3e81249059523bda2af187 /usr/share/emacs/site-lisp/auctex/context-en.el 7e5fea718848deb6b66d2f2050c4c4d9 /usr/share/emacs/site-lisp/auctex/context-nl.el 66cdeaf725eadcbd25f55cefa4fdce88 /usr/share/emacs/site-lisp/auctex/context.el 2b11f4f8c3a4189bf7cc8fec5a51e8c0 /usr/share/emacs/site-lisp/auctex/doc/Makefile 2b11f4f8c3a4189bf7cc8fec5a51e8c0 /usr/share/emacs/site-lisp/auctex/doc/Makefile.in 6f9d9372928534a7b6549aca174f026e /usr/share/emacs/site-lisp/auctex/font-latex.el f176261b5a5511cbe1401ee72ffb8947 /usr/share/emacs/site-lisp/auctex/images/amstex.xpm d33121019448617a3ad3bcafdeb8db40 /usr/share/emacs/site-lisp/auctex/images/bibtex.xpm 1a43d6438010bceb374ab0a5f2bd05a8 /usr/share/emacs/site-lisp/auctex/images/dropdown.xpm 41f1ae0341ae2e307d92a7b8b815f868 /usr/share/emacs/site-lisp/auctex/images/dvipdf.xpm 2e4b8669b0168f32247411be3f999437 /usr/share/emacs/site-lisp/auctex/images/dvips.xpm 55f7600cadc3a209e94bacf6bbc42a7c /usr/share/emacs/site-lisp/auctex/images/error.xpm c29ad797273fd27201a40bd939a95fe0 /usr/share/emacs/site-lisp/auctex/images/exec.xpm 79b958849511c67d6b13ef9f5b3673e8 /usr/share/emacs/site-lisp/auctex/images/execbibtex.xpm a8570e26e9f96b6f527cdbe218d6c55f /usr/share/emacs/site-lisp/auctex/images/execdvips.xpm e647bc601aef2dc71b134a989df1adff /usr/share/emacs/site-lisp/auctex/images/execerror.xpm 4610ec6133f89ceb441c43dfee077361 /usr/share/emacs/site-lisp/auctex/images/execpdftex.xpm c9cd1fc9fe4fd122cbf900fae654a67b /usr/share/emacs/site-lisp/auctex/images/exectex.xpm 6a6b9af945d4735f048ea8e475f8d9b8 /usr/share/emacs/site-lisp/auctex/images/execviewdvi.xpm 466466f6d1867510b058a9c184ffce5d /usr/share/emacs/site-lisp/auctex/images/execviewpdf.xpm 39d8ccaffb40b0c118e000f45272db05
Bug#704889: [Pkg-owncloud-maintainers] Bug#704889: Bug#704889: php-sabredav: breaks caldav-synchronisation
On Sun, 07 Apr 2013 11:25:59 -0400, David Prévot wrote: I’ll upload a -3 version with the proposed fix, but that will have to go through NEW again. Hm, let's see how quick dak is about forgetting packages :) Good call (again): not as quick as I thought ;). Thanks again for shimming in. Thanks to you for all your work on owncloud friends! Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Nguyên Lê: Kithâra signature.asc Description: Digital signature
Bug#323790: cdebootstrap: Description is very, very short
The current description (sid, version 0.5.9) is a bit longer: cdebootstrap generates systems from scratch for Debian and derivates. This is implementation is different from debootstrap. It features a different package selection. The package selection is done according to the flavour. Assuming the part This is should be replaced by This, the text doesn't make things more clear. What's a flavour, and how is the package selection different? -- Herwin Weststrate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704916: Xorg-server or evdev detects Saitek Eclipse keyboard as mouse and block mouse buttons
Package: xserver-xorg Version: 1:7.7+2 Since Debian 7 installer have this bug, Pressing the button to change the keyboard light the buttons on mouse freezes and I have to restart to work again. This is part relevant of Xorg.0.log [19.974] (II) config/udev: Adding input device Power Button (/dev/input/event4) [19.974] (**) Power Button: Applying InputClass evdev keyboard catchall [19.974] (**) Power Button: Applying InputClass keyboard-all [19.974] (II) LoadModule: evdev [19.974] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [19.978] (II) Module evdev: vendor=X.Org Foundation [19.978]compiled for 1.12.3, module version = 2.7.1 [19.979]Module class: X.Org XInput Driver [19.979]ABI class: X.Org XInput driver, version 16.0 [19.979] (II) Using input driver 'evdev' for 'Power Button' [19.979] (**) Power Button: always reports core events [19.979] (**) evdev: Power Button: Device: /dev/input/event4 [19.979] (--) evdev: Power Button: Vendor 0 Product 0x1 [19.979] (--) evdev: Power Button: Found keys [19.979] (II) evdev: Power Button: Configuring as keyboard [19.979] (**) Option config_info udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event4 [19.979] (II) XINPUT: Adding extended input device Power Button (type: KEYBOARD, id 6) [19.979] (**) Option xkb_rules evdev [19.979] (**) Option xkb_model pc105 [19.979] (**) Option xkb_layout es [19.979] (**) Option xkb_options lv3:ralt_switch,terminate:ctrl_alt_bksp [20.018] (II) config/udev: Adding input device Power Button (/dev/input/event3) [20.018] (**) Power Button: Applying InputClass evdev keyboard catchall [20.018] (**) Power Button: Applying InputClass keyboard-all [20.018] (II) Using input driver 'evdev' for 'Power Button' [20.018] (**) Power Button: always reports core events [20.018] (**) evdev: Power Button: Device: /dev/input/event3 [20.018] (--) evdev: Power Button: Vendor 0 Product 0x1 [20.018] (--) evdev: Power Button: Found keys [20.018] (II) evdev: Power Button: Configuring as keyboard [20.018] (**) Option config_info udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input3/event3 [20.018] (II) XINPUT: Adding extended input device Power Button (type: KEYBOARD, id 7) [20.018] (**) Option xkb_rules evdev [20.018] (**) Option xkb_model pc105 [20.018] (**) Option xkb_layout es [20.018] (**) Option xkb_options lv3:ralt_switch,terminate:ctrl_alt_bksp [20.019] (II) config/udev: Adding input device Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) (/dev/input/event0) [20.019] (**) Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Applying InputClass evdev pointer catchall [20.019] (II) Using input driver 'evdev' for 'Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)' [20.019] (**) Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): always reports core events [20.019] (**) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Device: /dev/input/event0 [20.019] (--) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Vendor 0x45e Product 0x40 [20.019] (--) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Found 3 mouse buttons [20.019] (--) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Found scroll wheel(s) [20.019] (--) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Found relative axes [20.020] (--) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Found x and y relative axes [20.020] (II) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Configuring as mouse [20.020] (II) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): Adding scrollwheel support [20.020] (**) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): YAxisMapping: buttons 4 and 5 [20.020] (**) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [20.020] (**) Option config_info udev:/sys/devices/pci:00/:00:02.0/usb2/2-1/2-1:1.0/input/input0/event0 [20.020] (II) XINPUT: Adding extended input device Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) (type: MOUSE, id 8) [20.020] (II) evdev: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): initialized for relative axes. [20.020] (**) Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): (accel) keeping acceleration scheme 1 [20.020] (**) Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): (accel) acceleration profile 0 [20.020] (**) Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): (accel) acceleration factor: 2.000 [20.020] (**) Microsoft Microsoft 3-Button Mouse with IntelliEye(TM): (accel) acceleration threshold: 4 [20.021] (II) config/udev: Adding input device Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) (/dev/input/mouse0) [
Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
On Sunday, April 07, 2013 02:22:17, Andrei POPESCU wrote: On Vi, 29 mar 13, 09:45:11, Chris Knadle wrote: You will also need to recreate /etc/resolv.conf, as the contents of this file is replaced by NetworkManager. Isn't this done by wicd-daemon (maybe by restarting it)? It doesn't. Also keep in mind that wicd can be set for all kinds of configurations, such that it may not touch this file even making a connection. [I have what appear to be default settings, and this is the behavior I see on my home network, for instance.] /By default/ NM seems to replace /etc/resolv.conf on the first connection attempt. This entry in the release-notes is aimed for Gnome users that /didn't/ previously have network-manager installed, thus may be using wicd. The first thing these users are likely to do is try wicd and find it broken due to the conflict, then try NM and find it broken too -- and the connection attempt with NM replaces the /etc/resolv.conf file, where wicd may not. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#612402: upgraded systems won't boot from UUID volumes
On Sun, 2013-04-07 at 16:19 +0200, Daniel Pocock wrote: On 07/04/13 15:47, Neil Williams wrote: On Sun, 07 Apr 2013 15:25:43 +0200 Daniel Pocock dan...@pocock.com.au wrote: I notice this bug was downgraded below the RC threshold and appears to have been missed so far: It was only pushed to RC status by your request and then almost immediately moved back to original severity of Important by one of the maintainers. It is up to the maintainers to assign severity of bugs. Why have you not asked the maintainers of their opinion of the severity? Because they already downgraded below the RC status, so I'm curious if other people have reason to believe there is a problem. I have only come across a few systems with UUID in fstab, If you *don't* use LVM this is normal, as device names are not stable. but if somebody else is aware of widespread use of this, now is probably the time to comment. I just did some install and upgrade tests: 1. I installed squeeze and selected guided partitioning using LVM. The installer put /dev/mapper/* names in /etc/fstab (and also created a non-LVM /boot formatted as ext2!). Upgrading to wheezy worked fine. 2. I installed squeeze and selected 'manual partitioning' and created a pure LVM layout with root and swap LVs. This also resulted in /dev/mapper/* names in /etc/fstab. 3. Running 'dpkg-reconfigure linux-base' did not change these device names, as expected (it should only touch IDE and SCSI device names). So it seems that this is only going to be an issue if users take the unusual step of changing /etc/fstab to refer to LVs by UUID. But maybe there are management tools that do that as a matter of course? Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
Bug#704914: glx-alternatives: The libGL diversion does not work
Control: reassign -1 glx-diversions 0.2.90 Control: tag -1 moreinfo On 2013-04-07 17:43, Christian Weeks wrote: There is a severe problem with the libGL diversion strategy as exists at present. The desktop is rendered inoperable after any change in the packaging, due to the diversion in glx-diversions being replaced by the actual lib from libgl1-mesa-glx. This is because gnome- session-bin and other current parts of the gnome desktop have a hardcoded dependency on libgl1-mesa-glx (or the virtual libgl1). I'm sorry, but what exactly is the problem you experienced? The only fix is to re-run update-alternatives --configure glx, which re- replaces the symlink diversion however, if gnome is about to progress beyond experimental, it is likely this is about to become a critical pain point. So what is broken before this command and fixed afterwards? # dpkg --remove libgl1-mesa-glx:amd64 and why would you want to do that? Unfortunately you reported this against the source package, so no scripts were run that could collect additional information. I've reassigned this bug to the glx-diversions package, please run reportbug -N 704914 on the *broken* system, that should collect some helpful information. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697890: tasksel arch any? (Re: Bug#697890: iwconfig not in /sbin)
On Sat, Mar 16, 2013 at 15:40:12 +0900, Charles Plessy wrote:
diff --git a/netcfg-static.c b/netcfg-static.c
index 4e9ca29..1987bec 100644
--- a/netcfg-static.c
+++ b/netcfg-static.c
@@ -83,7 +83,7 @@ int main(int argc, char** argv)
case WCONFIG:
if (requested_wireless_tools == 0) {
requested_wireless_tools = 1;
-di_exec_shell(apt-install wireless-tools);
+di_exec_shell(apt-install iw wireless-tools);
}
state = WCONFIG_ESSID;
break;
diff --git a/netcfg.c b/netcfg.c
index 06c1dcf..d0c46e5 100644
--- a/netcfg.c
+++ b/netcfg.c
@@ -280,7 +280,7 @@ int main(int argc, char *argv[])
case WCONFIG:
if (requested_wireless_tools == 0) {
-di_exec_shell_log(apt-install wireless-tools);
+di_exec_shell_log(apt-install iw wireless-tools);
requested_wireless_tools = 1;
}
state = WCONFIG_ESSID;
Those two hunks seem reasonable.
diff --git a/write_interface.c b/write_interface.c
index 1aa331a..2a42d48 100644
--- a/write_interface.c
+++ b/write_interface.c
@@ -55,7 +55,7 @@ static int nc_wi_wireless_options(const struct
netcfg_interface *interface, FILE
fprintf(fd, \twpa-ssid %s\n, interface-essid);
fprintf(fd, \twpa-psk %s\n, interface-passphrase);
} else {
- fprintf(fd, \t# wireless-* options are implemented by the
wireless-tools package\n);
+ fprintf(fd, \t# wireless-* options are implemented by the iw
and wireless-tools packages\n);
fprintf(fd, \twireless-mode %s\n,
(interface-mode == MANAGED) ? managed : ad-hoc);
fprintf(fd, \twireless-essid %s\n,
This one doesn't, because it's not true as far as I can tell.
Cheers,
Julien
signature.asc
Description: Digital signature
Bug#704917: missleading documentation for dkms add
Package: dkms Version: 2.2.0.3-1.2 Severity: minor Hi, man dkms says about dkms add: add [module/module-version] [/path/to/source-tree] [/path/to/tarball.tar] Adds a module/module-version combination to the tree for builds and installs. If module/module-version, -m module/module-version, or -m module -v version are passed as options, this command requires source in /usr/src/module-module-version/ as well as a properly formatted dkms.conf file. If /path/to/source-tree is passed as an option, and source-tree contains a dkms.conf file, it will copy /path/to/source-tree to /usr/src/module-module-version. If /path/to/tarball.tar is passed, this command behaves like the ldtarball command. With that formating, I would expect to call it like this: dkms add module/0.123 /tmp/here/I/downloaded But actually, you have to call dkms add /tmp/here/I/downloaded And dkms will read the name and version from the dkms.conf. I think the manpage should read: add [module/module-version | /path/to/source-tree | /path/to/tarball.tar] instead. Regards Evgeni -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.7-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dkms depends on: ii build-essential11.6 ii coreutils 8.20-3 ii dpkg-dev 1.16.10 ii gcc4:4.7.2-1 ii make 3.81-8.2 ii module-init-tools 9-2 ii patch 2.6.1-3 Versions of packages dkms recommends: ii fakeroot 1.18.4-2 ii linux-headers-3.1.0-1-amd64 [linux-headers]3.1.8-2 ii linux-headers-3.2.0-1-amd64 [linux-headers]3.2.7-1 ii linux-headers-3.2.0-2-amd64 [linux-headers]3.2.20-1 ii linux-headers-3.2.0-3-amd64 [linux-headers]3.2.23-1 ii linux-headers-3.2.0-4-amd64 [linux-headers]3.2.41-2 ii linux-headers-3.7-trunk-amd64 [linux-headers] 3.7.1-1~experimental.2 ii linux-headers-amd64 [linux-headers]3.2+46 ii linux-image-3.1.0-1-amd64 [linux-image]3.1.8-2 ii linux-image-3.2.0-1-amd64 [linux-image]3.2.7-1 ii linux-image-3.2.0-2-amd64 [linux-image]3.2.20-1 ii linux-image-3.2.0-3-amd64 [linux-image]3.2.23-1 ii linux-image-3.2.0-4-amd64 [linux-image]3.2.41-2 ii linux-image-3.7-trunk-amd64 [linux-image] 3.7.1-1~experimental.1 ii menu 2.1.46 ii sudo 1.8.5p2-1+nmu1 dkms 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#689226: spectrwm: please package the latest version
Package: spectrwm Followup-For: Bug #689226 Is there any news on the repackaging? I'm running spectrwm 2.2.0 (hand-build) and there are *many* fixed issues that I couldn't work with. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
On 07/04/13 12:17 PM, Andreas Beckmann wrote: Control: reassign -1 glx-diversions 0.2.90 Control: tag -1 moreinfo On 2013-04-07 17:43, Christian Weeks wrote: There is a severe problem with the libGL diversion strategy as exists at present. The desktop is rendered inoperable after any change in the packaging, due to the diversion in glx-diversions being replaced by the actual lib from libgl1-mesa-glx. This is because gnome- session-bin and other current parts of the gnome desktop have a hardcoded dependency on libgl1-mesa-glx (or the virtual libgl1). I'm sorry, but what exactly is the problem you experienced? libGL is brokenly referring to the libgl from mesa whereas it should be referring to the libGL from the nvidia packages. This breaks the gnome desktop. Gnome shell fails to start with an error, or any gnome application fails to launch, as the link is gone, replaced by the actual lib from that libgl-mesa-glx package. This affects almost all desktop applications that are linked against gnome. This is with the current gnome 3.8 environment in experimental. The only fix is to re-run update-alternatives --configure glx, which re- replaces the symlink diversion however, if gnome is about to progress beyond experimental, it is likely this is about to become a critical pain point. So what is broken before this command and fixed afterwards? Before: (This is reset after almost any packaging change on the system): The link to libGL isn't a link to the diversions anymore. It is a link to somewhere else: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 14 Apr 7 11:36 /usr/lib/x86_64-linux-gnu/libGL.so.1 - libGL.so.1.2.0 # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 Running the command: # update-alternatives --config glx There is only one alternative in link group glx (providing /usr/lib/glx): /usr/lib/nvidia Nothing to configure. update-alternatives: warning: forcing reinstallation of alternative /usr/lib/nvidia because link group glx is broken After: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 50 Apr 7 12:23 /usr/lib/x86_64-linux-gnu/libGL.so.1 - /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu If I do not run this command, after any package installation or update, Gnome is completely broken, because mesa isn't functional on this system, because it is using the NVIDIA libraries. # dpkg --remove libgl1-mesa-glx:amd64 and why would you want to do that? Because it's the wrong thing for this system? It keeps replacing the nvidia GL with it's own? But I added it here because it shows how the libgl1 virtual dependency has crept from the base packages into the gnome packages. Unfortunately you reported this against the source package, so no scripts were run that could collect additional information. I've reassigned this bug to the glx-diversions package, please run reportbug -N 704914 on the *broken* system, that should collect some helpful information. Acknowledged. That'll be run forthwith. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633968: cups: seg.fault
tags 633968 moreinfo thanks Hello Pol, Thank you for you report. On Fri 15 Jul 2011 at 15:25:58 +0200, Pol Hallen wrote: Jul 15 09:56:58 tweet kernel: [ 3746.453029] cupsd[5280]: segfault at 74 ip b759da6b sp bfc9a680 error 4 in libdbus-1.so.3.5.7[b7577000+48000] There have been a number of changes made in cups since you wrote which have fixed crashes. For example, in 1.4.6-10 and 1.5.0-9. Hopefully, after upgrading to the present testing/unstable, you will be able to report your problem has gone away. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704918: libjson0: Upstream homepage has been updated
Package: libjson0 Version: 0.10-1.2 Severity: minor Dear Maintainer, The information of the package contains the following: Homepage: http://oss.metaparadigm.com/json-c/ This site states it's obsolete, https://github.com/json-c/json-c/wiki should be used instead. I think this should be updated in the package description as well. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-4-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/bash Versions of packages libjson0 depends on: ii libc6 2.13-38 ii multiarch-support 2.13-38 libjson0 recommends no packages. libjson0 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#704914: glx-diversions: More system information
Package: glx-diversions Version: 0.2.90 Followup-For: Bug #704914 Data from reportbug -- Package-specific info: Diversions: diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib32/libGL.so to /usr/lib32/nvidia/diversions/libGL.so by libgl1-nvidia-alternatives-ia32 diversion of /usr/lib32/libGL.so.1 to /usr/lib32/nvidia/diversions/libGL.so.1 by libgl1-nvidia-alternatives-ia32 diversion of /usr/lib32/libGL.so.1.2 to /usr/lib32/nvidia/diversions/libGL.so.1.2 by libgl1-nvidia-alternatives-ia32 /usr/lib/mesa-diverted: total 64 drwxr-xr-x 4 root root 4096 Oct 1 2012 . drwxr-xr-x 236 root root 49152 Apr 7 11:36 .. drwxr-xr-x 2 root root 4096 Mar 18 12:30 i386-linux-gnu drwxr-xr-x 2 root root 4096 Mar 18 12:31 x86_64-linux-gnu /usr/lib/mesa-diverted/i386-linux-gnu/: total 8 drwxr-xr-x 2 root root 4096 Mar 18 12:30 . drwxr-xr-x 4 root root 4096 Oct 1 2012 .. lrwxrwxrwx 1 root root 14 Dec 29 23:03 libGL.so.1 - libGL.so.1.2.0 /usr/lib/mesa-diverted/x86_64-linux-gnu/: total 8 drwxr-xr-x 2 root root 4096 Mar 18 12:31 . drwxr-xr-x 4 root root 4096 Oct 1 2012 .. lrwxrwxrwx 1 root root 14 Dec 29 22:24 libGL.so - libGL.so.1.6.0 lrwxrwxrwx 1 root root 14 Dec 29 22:24 libGL.so.1 - libGL.so.1.2.0 Alternative 'glx': glx - auto mode link currently points to /usr/lib/nvidia /usr/lib/nvidia - priority 100 slave glx--libGL.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 slave glx--libGL.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 slave glx--libnvidia-cfg.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 slave glx--libnvidia-cfg.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 slave glx--linux-libglx.so: /usr/lib/nvidia/libglx.so slave glx--nvidia-blacklists-nouveau.conf: /etc/nvidia/nvidia-blacklists-nouveau.conf slave glx--nvidia-bug-report.sh: /usr/lib/nvidia/nvidia-bug-report.sh slave glx--nvidia_drv.so: /usr/lib/nvidia/nvidia_drv.so Current 'best' version is '/usr/lib/nvidia'. lrwxrwxrwx 1 root root 15 Apr 7 12:23 /etc/alternatives/glx - /usr/lib/nvidia lrwxrwxrwx 1 root root 41 Apr 7 12:23 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Apr 7 12:23 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 49 Apr 7 12:23 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 51 Apr 7 12:23 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Apr 7 12:23 /etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Apr 7 12:23 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf - /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Apr 7 12:23 /etc/alternatives/glx--nvidia-bug-report.sh - /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 29 Apr 7 12:23 /etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so File System: lrwxrwxrwx 1 root root 21 Apr 7 09:54 /usr/lib/glx - /etc/alternatives/glx lrwxrwxrwx 1 root root 48 Apr 7 12:23 /usr/lib/i386-linux-gnu/libGL.so.1 - /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -rw-r--r-- 1 root root 387532 Dec 29 23:03 /usr/lib/i386-linux-gnu/libGL.so.1.2.0 lrwxrwxrwx 1 root root 50 Apr 7 12:23 /usr/lib/x86_64-linux-gnu/libGL.so.1 - /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 431600 Feb 23 09:57 /usr/lib/xorg/modules/extensions/libglx.so -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (501, 'unstable'), (499, 'testing'), (399, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores) Locale:
Bug#697890: tasksel arch any? (Re: Bug#697890: iwconfig not in /sbin)
On Sun, 2013-04-07 at 18:26 +0200, Julien Cristau wrote:
On Sat, Mar 16, 2013 at 15:40:12 +0900, Charles Plessy wrote:
[...]
diff --git a/write_interface.c b/write_interface.c
index 1aa331a..2a42d48 100644
--- a/write_interface.c
+++ b/write_interface.c
@@ -55,7 +55,7 @@ static int nc_wi_wireless_options(const struct
netcfg_interface *interface, FILE
fprintf(fd, \twpa-ssid %s\n, interface-essid);
fprintf(fd, \twpa-psk %s\n, interface-passphrase);
} else {
- fprintf(fd, \t# wireless-* options are implemented by the
wireless-tools package\n);
+ fprintf(fd, \t# wireless-* options are implemented by the iw
and wireless-tools packages\n);
fprintf(fd, \twireless-mode %s\n,
(interface-mode == MANAGED) ? managed : ad-hoc);
fprintf(fd, \twireless-essid %s\n,
This one doesn't, because it's not true as far as I can tell.
Correct, this is just as old-school as the rest of /e/n/i.
Ben.
--
Ben Hutchings
I'm not a reverse psychological virus. Please don't copy me into your sig.
signature.asc
Description: This is a digitally signed message part
Bug#704647: krb5: rdns=false does not work
It looks like this patch is redundant with what's actually pending. I think all I need to do is upload the tip of master. If I missed anything let me know. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634937: /usr/sbin/cupsd: segfault in libavahi-common
tags 634937 moreinfo thanks Hello Daniel, Thank you for your report. On Wed 20 Jul 2011 at 22:54:26 -0400, Daniel Dickinson wrote: Unplugging the printer (HP OfficeJet J4580 All-in-One) results in segault in libavahi (see logs below) In addition (not sure if related), attempting to print from Iceweasel or Evince results in part of a page being printed then timeout and the following messages after the segfault syslogs below. Segfault Syslog --- Jul 20 22:36:25 daniloth kernel: [ 689.475096] cupsd[3864]: segfault at d0 ip 7fe0d98e3ff6 sp 7fffdc201e58 error 4 in libavahi-common.so.3.5.3[7fe0d98df000+c000] A cups-avahi patch is included in Debian cups and this was updated in 1.5.0-2 and 1.5.0-9. It is possible one or the other of them fixed your problem. It would be good if you would report whether or not the crashes still happen with an up-to-date testing/unstable. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
On Du, 07 apr 13, 12:10:28, Chris Knadle wrote: On Sunday, April 07, 2013 02:22:17, Andrei POPESCU wrote: On Vi, 29 mar 13, 09:45:11, Chris Knadle wrote: You will also need to recreate /etc/resolv.conf, as the contents of this file is replaced by NetworkManager. Isn't this done by wicd-daemon (maybe by restarting it)? It doesn't. Also keep in mind that wicd can be set for all kinds of configurations, such that it may not touch this file even making a connection. [I have what appear to be default settings, and this is the behavior I see on my home network, for instance.] This doesn't sound right. Wicd has got to have some resolv.conf handling, otherwise it wouldn't be very useful. Maybe the maintainer can help out here? /By default/ NM seems to replace /etc/resolv.conf on the first connection attempt. This entry in the release-notes is aimed for Gnome users that /didn't/ previously have network-manager installed, thus may be using wicd. The first thing these users are likely to do is try wicd and find it broken due to the conflict, then try NM and find it broken too -- and the connection attempt with NM replaces the /etc/resolv.conf file, where wicd may not. Kept for a little bit more context. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Bug#704876: hothasktags: FTBFS: cabal: Command not found
Hi Joey, Am Samstag, den 06.04.2013, 21:55 -0400 schrieb Aaron M. Ucko: Builds of hothasktags in minimal environments, as on the autobuilders, have been failing: cabal clean make[1]: cabal: Command not found make[1]: *** [override_dh_auto_clean] Error 127 Could you please declare a build dependency on cabal-install and confirm with pbuilder or the like that no others were missing? it seems you are trying to build a cabal package without haskell-devscripts. I know you are the author of debhelper, but is there any other reason? In the next version of haskell-devscripts even supports the installation of cabal-built binaries in a declarative way, i.e. without modifying debian/rules. I can upload 0.8.14 if you want to use it for hothasktags. If you want to avoid cdbs, I’d be happy to see dh support Haskell, but it should use the same building steps as haskell-devscripts now, I’d think. Also, I don’t think we should ever use cabal in the packaging scripts, it would be similar to using aptitude instead of dpkg when building packages. Just use the Setup.lhs in every package. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#704914: glx-alternatives: The libGL diversion does not work
Control: severity -1 wishlist Control: retitle -1 does not divert libGL.so.1.2.0 from mesa 9.0.1-1 On 2013-04-07 18:26, Christian Weeks wrote: Before: (This is reset after almost any packaging change on the system): The link to libGL isn't a link to the diversions anymore. It is a link to somewhere else: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 14 Apr 7 11:36 /usr/lib/x86_64-linux-gnu/libGL.so.1 - libGL.so.1.2.0 # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 This is not the Debian libgl1-mesa-glx. That would contain /usr/lib/x86_64-linux-gnu/libGL.so.1.2 which is properly diverted. On 2013-04-07 18:30, Christian Weeks wrote: Versions of packages glx-diversions is related to: ii libgl1-mesa-glx [libgl1] 9.0.1-1 Exactly :-) $ rmadison --arch amd64 libgl1-mesa-glx libgl1-mesa-glx | 7.7.1-5 | squeeze | amd64 libgl1-mesa-glx | 7.10.3-4~bpo60+1 | squeeze-backports | amd64 libgl1-mesa-glx | 8.0.5-4 | wheezy| amd64 libgl1-mesa-glx | 8.0.5-4 | sid | amd64 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
On 07/04/13 12:52 PM, Andreas Beckmann wrote: Control: severity -1 wishlist Control: retitle -1 does not divert libGL.so.1.2.0 from mesa 9.0.1-1 On 2013-04-07 18:26, Christian Weeks wrote: Before: (This is reset after almost any packaging change on the system): The link to libGL isn't a link to the diversions anymore. It is a link to somewhere else: # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 14 Apr 7 11:36 /usr/lib/x86_64-linux-gnu/libGL.so.1 - libGL.so.1.2.0 # ls -l /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 -rw-r--r-- 1 root root 414328 Dec 29 22:24 /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 # dpkg --search /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 libgl1-mesa-glx:amd64: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 This is not the Debian libgl1-mesa-glx. That would contain /usr/lib/x86_64-linux-gnu/libGL.so.1.2 which is properly diverted. On 2013-04-07 18:30, Christian Weeks wrote: Versions of packages glx-diversions is related to: ii libgl1-mesa-glx [libgl1] 9.0.1-1 Exactly :-) $ rmadison --arch amd64 libgl1-mesa-glx libgl1-mesa-glx | 7.7.1-5 | squeeze | amd64 libgl1-mesa-glx | 7.10.3-4~bpo60+1 | squeeze-backports | amd64 libgl1-mesa-glx | 8.0.5-4 | wheezy| amd64 libgl1-mesa-glx | 8.0.5-4 | sid | amd64 Andreas OK. That's interesting. This is just the update from xorg, built a couple of months ago to get multiarch gnome working (because of the wayland dep added in gnome 3.6 - the version of wayland you list is not multiarch). It's a straight copy of pkg-mesa from the subversion, built in a pbuilder. I would assume this will affect all future versions from there too, including the one that will (inevitably) finally hit experimental/unstable. Thanks for that info. I guess I'll have to look into why this linking was lost in their subversion. *sigh*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639156: [cups] cups crashes
tags 639156 moreinfo thanks Hello Marco, Thank you for you report. On Wed 24 Aug 2011 at 18:44:37 +0200, Marco Righi wrote: Hi, after one of the last upgrades cups initiated to crash after a certain time (the time is not constant). Please write me if I can execute some instruction or send some log in order to help you. There have been a number of changes made in cups since you wrote which have fixed crashes. For example, in 1.5.0-9. Please consider reporting, after upgrading to the present testing/unstable, whether your problem has gone away. Daniel - your problem may not be the same as Marco's. Please submit a new bug report if present the testing/unstable does not fix it. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704914: glx-alternatives: The libGL diversion does not work
On 2013-04-07 18:58, Christian Weeks wrote: OK. That's interesting. This is just the update from xorg, built a couple of months ago to get multiarch gnome working (because of the wayland dep added in gnome 3.6 - the version of wayland you list is not multiarch). It's a straight copy of pkg-mesa from the subversion, built in a pbuilder. and having a bad version number that looks like an official Debian package I would assume this will affect all future versions from there too, including the one that will (inevitably) finally hit experimental/unstable. Thanks for that info. I guess I'll have to look into why this linking was lost in their subversion. *sigh*. probably an intentional library rename done by upstream you'll have to divert libGL.so.1.2.0 to move it away from /usr/lib/triplet, otherwise ldconfig (which is run from many maintainer scripts - so nearly every packaging operation breaks the setup) will always recreate (and overwrite) the libGL.so.1 link Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704828: nsis: CWD taken from symlink target, not symlink itself
If you build your .nsi script in the /home/user/project folder then it is going to fail as well. makensis follows symbolic links. So if you put your .nsi file in the parent folder then you would need to adapt the file references to this new base (/home/user/project). In your example this means the following adaption: --- !insertmacro MUI_PAGE_LICENSE folder/COPYING -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628996: apt-listbugs: please use debconf
On Sun, 24 Mar 2013 01:09:43 +0100 Serafeim Zanikolas wrote: Hi guys, Hi Serafeim (and sorry for the very late follow-up), Attached a proof-of-concept for the advanced use case (in which the user actually wants to review which buggy packages to pin or upgrade). Consider this as a basis for further discussion, rather than something anywhere near a working patch. [...] I tested it by running it a few times. I understand that it's just a proof-of-concept script, but, well, it feels a little limited in its user interaction: I mean, can we present a multiple-action choice to the user (via debconf)? The current apt-listbugs text user interface displays the bugs that affect the installation/upgrade and then offers the user the following possible choices: * go on * go on and permanently mark the bugs as ignored * stop everything * display one bug log * pin some or all the packages * mark a bug as ignored * open a browser to display one bug log How can we do something similar via debconf without forcing the user to go through a tree of multiple successive screens (that would feel like a horrible call center menu system: dial 1 to learn about our fantastic promotional offers, dial 2 to receive commercial assistance, ...)? Going forward from here, one possibility would be for the apt-listbugs ruby script to invoke the debconf script (passing on the package/bug num/bug title info and getting back the user reply, via a tempfile or something along those lines). To be frank, I am not too enthusiastic about the idea to let a Ruby program invoke a POSIX shell script in order to get a user interface... If we have to implement a debconf interface for apt-listbugs, I would strongly prefer that it be done directly in Ruby. One issue with the debconf approach is that you can't fire up a browser to lookup a bug report before making the pin/upgrade decision (something that's possible with the current non-debconf based interaction). You also can't ^Z the debconf screen to do so manually. Any ideas about working around this? This looks like a severe limitation, if confirmed... Another issue that should be straightforward: use debconf in postinst to ask the user to choose between newbie and advance use (ie. whether one should go through the above dialog on every invocation, or let apt-listbugs upgrade only non-rc-buggy packages without asking) -- defaulting to newbie mode? This is much more similar to what is usually done with debconf, and should not be hard in itself, I think... What puzzles me is all the rest, as I explained above. Unfortunately I cannot dedicate time to the issue, for the time being. Maybe after the release of wheezy? Hopefully, not *too* long after? Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpiJbyTnqMFI.pgp Description: PGP signature
Bug#699437: Addition: No successful boot when using 2 TB disks and/or ext4 file system
After fixing bug #704635 I tested a new Debian Wheezy setup today. To exclude any partition layout specific issues, I allowed Debian to use the whole disk with the automatic partitioning layout including ext4. Result: Setup (using mini.iso, FTP source=mirror.switch.ch) completely runs fine but startup of the installed system fails after OS selection in GRUB: http://beilagen.dreael.ch/Diverses/dmraid_Wheezy_Bugs/Boot_failure_20130407.jpg Difference to the earlier tests with the small disks: It always fails (I repeated booting several times). More details: http://beilagen.dreael.ch/Diverses/dmraid_Wheezy_Bugs/Kernel_panic_after_exit_20130407.jpg http://beilagen.dreael.ch/Diverses/dmraid_Wheezy_Bugs/Promise_BIOS_details_20130407.jpg http://beilagen.dreael.ch/Diverses/dmraid_Wheezy_Bugs/dmesg_20130407.txt http://beilagen.dreael.ch/Diverses/dmraid_Wheezy_Bugs/proc_partitions_20130407.txt http://beilagen.dreael.ch/Diverses/dmraid_Wheezy_Bugs/ls_dev_mapper_20130407.txt http://beilagen.dreael.ch/Diverses/dmraid_Wheezy_Bugs/proc_bus_pci_devices_20130407.txt Hardware is a IBM NetVista A40 (model 6840-QDG) equipped with a Promise Fastrak TX2300 PCI RAID controller and two Western Digital 2 TB Caviar Red NAS SATA hard drives configured as RAID-1. I hope this hint better helps to reproduce this bug. Also worth to note: On the CD boot, using dmraid=yes always works fine, this bug occurs only when booting from hard drive. Andreas -- meile.biz IT solutions, Hauptstrasse 63, CH-8242 Hofen SH PC/Netzwerk-Support, Web-Entwicklung und -Hosting, IT Security Tel. +41 52 640 04 72 * Fax +41 52 640 04 73 * Mobile +41 79 334 05 67 Postfach 169, CH-8240 Thayngen * i...@meile.biz * http://www.meile.biz smime.p7s Description: S/MIME cryptographic signature
Bug#681819: iwlwifi: rfkill stuck on Soft blocked: yes with Centrino 6205
Hi Yaroslav, On 2012-07-16 21:58, Yaroslav Halchenko wrote: This was a freshly dual-booted Debian squeeze on Thinkpad T420s. Centrino 6205 seemd to be not supported on 2.6.32 at all so we dist-upgraded to current testing/wheezy to get WiFi working. Now soft mode of rfkill remains in enabled regardless what I do: root@brain:/var/log# rfkill list all 2: phy2: Wireless LAN Soft blocked: yes Hard blocked: no I had the same problem with another Thinkpad model, and looking for the cause was driving me nuts. Then I stumbled over #662183, where Thomas mentions the exact same problem and a solution: resetting the BIOS. And indeed, that also worked for me -- the issue is now resolved. How about giving that a try? Cheers, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704853: Wheezy RC1 i386 on Dell Precision M65 laptop
sön 2013-04-07 klockan 14:54 +0100 skrev Brian Potkin: On Sun 07 Apr 2013 at 06:07:37 +0200, Christian PERRIER wrote: Quoting Cyril Brulebois (k...@debian.org): 1) The WLAN password is displayed on screen. User account passwords are not displayed on screen, so presumably it is a bug for WLAN passwords to be displayed. Bonus points for a Display password button to toggle display of the password. I can't find a pointer right now, but that was discussed on this list already, and yes, it would indeed by nice to have. That would mean implementing some bits on the debconf side, too. Yes, there is something somewhere else. Can't find it either, though. #700834 may be what you are looking for. Yes, thanks for the pointer. Se let's keep this bug (#704853) open to track auto-detection of WEP vs PSK. Btw, #700924 is about my bonus point idea of having a display password toggle. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700834: +1 to hide passwords by default
Hi. I recently reported a similar issue in #704853. I would prefer if the default was to mask out WLAN passwords displayed on screen. A toggle to display/hide password would be nice, but pending that I believe it is safer to hide the password instead of displaying it. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704876: hothasktags: FTBFS: cabal: Command not found
Joachim Breitner wrote: If you want to avoid cdbs, I’d be happy to see dh support Haskell, but it should use the same building steps as haskell-devscripts now, I’d think. I don't know if it's worth putting in the time to make debhelper support haskell library packages, but it certianly makes sense for it to automatically handle packages that simply build binaries from a cabal file. I hope to see an increasing number of such packages in Debian. -- see shy jo signature.asc Description: Digital signature
Bug#704914: glx-alternatives: The libGL diversion does not work
On 07/04/13 01:11 PM, Andreas Beckmann wrote: On 2013-04-07 18:58, Christian Weeks wrote: OK. That's interesting. This is just the update from xorg, built a couple of months ago to get multiarch gnome working (because of the wayland dep added in gnome 3.6 - the version of wayland you list is not multiarch). It's a straight copy of pkg-mesa from the subversion, built in a pbuilder. and having a bad version number that looks like an official Debian package Sorry about that. It's because I try and pbuild exactly what's in the git. (Not subversion like I said before- this is all from the pkg-xorg sub projects- wayland and mesa and, with the recent updates, now libdrm too *sigh*). I would assume this will affect all future versions from there too, including the one that will (inevitably) finally hit experimental/unstable. Thanks for that info. I guess I'll have to look into why this linking was lost in their subversion. *sigh*. probably an intentional library rename done by upstream you'll have to divert libGL.so.1.2.0 to move it away from /usr/lib/triplet, otherwise ldconfig (which is run from many maintainer scripts - so nearly every packaging operation breaks the setup) will always recreate (and overwrite) the libGL.so.1 link Ah, yes, OK, that's the guilty party here then I guess. I'll see what I can come up with and share it here. No doubt others are or will soon be in the same boat. Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704853: Wheezy RC1 i386 on Dell Precision M65 laptop
Brian Potkin claremont...@gmail.com (07/04/2013): On Sun 07 Apr 2013 at 06:07:37 +0200, Christian PERRIER wrote: Quoting Cyril Brulebois (k...@debian.org): 1) The WLAN password is displayed on screen. User account passwords are not displayed on screen, so presumably it is a bug for WLAN passwords to be displayed. Bonus points for a Display password button to toggle display of the password. I can't find a pointer right now, but that was discussed on this list already, and yes, it would indeed by nice to have. That would mean implementing some bits on the debconf side, too. Yes, there is something somewhere else. Can't find it either, though. #700834 may be what you are looking for. I had that one in mind: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698322#47 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698322#52 Mraw, KiBi. signature.asc Description: Digital signature
