Bug#1064307: Work-around / patches for Python 3.12 compatibility
tags 1064307 patch thanks Hi, for $REASONS I need to use awscli on Ubuntu, but the package was removed from Ubuntu Noble (supposedly due to this bug). Here is how I managed to get things to work on Noble. The problem that is reported in this bug comes from an old version of "six" that is bundled in "botocore" which is bundled in "awscli". To fix this, I simple updated (= overwrote) botocore's six.py with a newer version from git: wget https://github.com/benjaminp/six/raw/c1b416f24de52ebd8eaed3e379ab85ec9c3e935b/six.py -O /usr/lib/python3/dist-packages/awscli/botocore/vendored/six.py Then, I ran into a problem with urllib3 (which might or might not be unrelated to this bug - sorry). Newer versions no longer provide urllib3.util.ssl_.DEFAULT_CIPHERS (and the "_" in "ssl_" makes me believe that this module is not considered to be public API). This problem is also already fixed in newer botocore versions. You need the following two patches. https://github.com/boto/botocore/commit/0a6d8e3c6325da395a04227599cfa292190d6841.patch https://github.com/boto/botocore/commit/7b4c26e721936b185681cb10010ded4026295bd4.patch The resulting awscli seems to work fine for me on Ubuntu Noble, but so far I only tested it lightly. Cheers, Uli
Bug#1059148: Fixed upstream
Hi, this issue was now fixed upstream and thus should be solved in an upcoming release: http://cvs.schmorp.de/rxvt-unicode/src/command.C?r1=1.603=1.604=date Cheers, Uli
Bug#1059148: rxvt-unicode: Incorrect mouse motion reporting before first mouse click
Package: rxvt-unicode Version: 9.31-1 Severity: normal Tags: patch upstream X-Debbugs-Cc: tobespam...@web.de Hi, I was recently experimenting with a terminal UI library and had some contact with terminal mouse reporting [0]. Specifically, SGR pixel mode (enabled via ESC[?1006h) and the any mouse event mode (ESC[?1003h). In this combination of modes, moving the mouse around in urxvt's window generates input for the TTY indicating these mouse moves. See [1] for the urxvt documentation about these features. For example, ESC[<33;67;40M is reported when moving the mouse to x=67, y=40. 33 indicates the button state. It is a bit mask. Since bit 5 is set (32), this is a mouse move without a click. The last button that was pressed is button 2 (32 + 1). I noticed that right after starting a new urxvt instance without ever pressing a mouse button in its window, urxvt reports 31 as the first value of the event. According to the docs [1], this would be a press of button 3 with Shift, Meta, and Control modifiers active, even though this was just a simple mouse move without any modifiers. To reproduced, I used a shell script so that I can run this in a fresh urxvt window without having to type the exact commands or using the middle mouse button for paste. It only later occurred to me that I could have used Shift+Insert instead. The shell script is (yes, this enables more than just mode 1006 and 1003; I was experimenting): #!/bin/bash printf "\x1b[?1000h\x1b[?1003h\x1b[?1015h\x1b[?1006h" xxd printf "\x1b[?1000l\x1b[?1003l\x1b[?1015l\x1b[?1006l" Open a new urxvt window, run this script without clicking in the window, press Ctrl+D twice to make it exit and clean up again. Next, I looked at the source code of urxvt. During startup, MEvent.button is initialised to AnyButton (which has value 0) in rxvt_term::init_vars(). The code that does the actual mouse event reporting is rxvt_term::mouse_report(). It calculates the button number as "MEvent.button - Button1". Since "Button1" has the value 1, this ends up with 0 - 1 = -1 if no button was ever pressed. I would propose to e.g. pick button 1 instead if no mouse button ever happened before: diff --git a/src/command.C b/src/command.C index 14e6c24..0b16b9b 100644 --- a/src/command.C +++ b/src/command.C @@ -1297,6 +1297,10 @@ rxvt_term::mouse_report (XButtonEvent ) } button_number = MEvent.button - Button1; + /* Make sure we do not end up with button_number = -1 */ + if (MEvent.button == AnyButton) +button_number = 0; + /* add 0x3D for wheel events, like xterm does */ if (button_number >= 3) button_number += 64 - 3; However, I have to admit that I only read the source code and did the above mentioned experiment. I never actually build urxvt with my patch. I hope this information suffices to reproduce the problem and helps fixing it. Now, why am I reporting this to the Debian BTS? Because I failed at contacting upstream. The IRC channel had no activity since I wrote there and my mail to Marc Lehmann didn't produce any reaction yet (but the mail is only four days old, so that might still happen). Besides, there doesn't seem to be any bug tracker available upstream. I hope that rak, the current Debian urxvt maintainer, has better information about how to deal with upstream. Sorry for dumping this task upon you. Thanks & Cheers, Uli [0]: https://github.com/ArthurSonzogni/FTXUI/issues/791 [1]: http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#Mouse_Reporting -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages rxvt-unicode depends on: ii base-passwd 3.6.3 ii libc6 2.37-12 ii libfontconfig12.14.2-6 ii libgcc-s1 13.2.0-7 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3 ii libglib2.0-0 2.78.3-1 ii libperl5.36 5.36.0-10 ii libptytty02.0-1+b1 ii libstartup-notification0 0.12-6+b1 ii libx11-6 2:1.8.7-1 ii libxext6 2:1.3.4-1+b1 ii libxft2 2.3.6-1 ii libxmu6 2:1.1.3-3 ii libxrender1 1:0.9.10-1.1 ii ncurses-base 6.4+20231209-1 ii ncurses-term 6.4+20231209-1 Versions of packages rxvt-unicode recommends: ii fonts-dejavu2.37-8 pn fonts-vlgothic | fonts-japanese-gothic Versions of packages rxvt-unicode suggests: ii sensible-utils 0.0.20 -- no debconf information
Bug#1025409: libxcb-cursor0: Causes X11 errors for non-existing cursors / please update to a newer upstream release
Package: libxcb-cursor0 Version: 0.1.1-4 Severity: normal X-Debbugs-Cc: tobespam...@web.de Hi, for $REASONS [0] I tested today what happens when loading a non-existing cursor through libxcb-cursor. To my surprise, I got X11 errors instead of the existing "cannot load cursor"-message. After some debugging, I figured out that this is a bug that was fixed upstream 7 years ago [1]. Please update the package to a version that contains this fix. The first such version is version 0.1.2. Thanks! Cheers, Uli P.S.: Hi Michael. :-) [0]: https://github.com/awesomeWM/awesome/pull/3745 [1]: https://gitlab.freedesktop.org/xorg/lib/libxcb-cursor/-/commit/cf26479ece9ab9e04616bc10ba674d88a284e5b0 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libxcb-cursor0 depends on: ii libc62.36-5 ii libxcb-image00.4.0-2 ii libxcb-render-util0 0.3.9-1+b1 ii libxcb-render0 1.15-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 libxcb-cursor0 recommends no packages. libxcb-cursor0 suggests no packages. -- no debconf information
Bug#1017828: cargo: Fails to update the crates index after the index was squashed
Package: cargo Version: 0.57.0-7+b1 Severity: important Tags: upstream X-Debbugs-Cc: psyc...@znc.in Hi, recently I tried to update some dependencies of a crate and cargo e.g. claimed that libc 0.2.126 is the newest version, even though 0.2.127 was released on August 3rd. I reported [#11009] about this. Someone from upstream then suggested that this is related to the update from libgit2 1.1 to libgit 1.3 [#9976] and that this issue was already fixed upstream a while ago [#9979]. If I understand GitHub's UI correctly, the fix is part of cargo 1.59. Apparently, somewhere between libgit2 and cargo, something with forced pushes... happens? I did not really understand the details. Cheers, Uli [#11009]: https://github.com/rust-lang/cargo/issues/11009 [#9976]: https://github.com/rust-lang/cargo/issues/9976 [#9979]: https://github.com/rust-lang/cargo/pull/9979 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages cargo depends on: ii binutils 2.38.90.20220713-2 ii clang 1:14.0-55.1 ii clang-13 [c-compiler] 1:13.0.1-7 ii clang-14 [c-compiler] 1:14.0.6-2 ii gcc [c-compiler] 4:12.1.0-3 ii gcc-10 [c-compiler]10.4.0-4 ii gcc-11 [c-compiler]11.3.0-5 ii gcc-12 [c-compiler]12.1.0-8 ii gcc-8 [c-compiler] 8.4.0-7 ii gcc-9 [c-compiler] 9.4.0-2 ii libc6 2.34-3 ii libcurl3-gnutls7.84.0-2 ii libgcc-s1 12.1.0-8 ii libgit2-1.31.3.0+dfsg.1-3 ii libssh2-1 1.10.0-3+b1 ii libssl33.0.5-2 ii rustc 1.59.0+dfsg1-2 ii zlib1g 1:1.2.11.dfsg-4 cargo recommends no packages. Versions of packages cargo suggests: pn cargo-doc ii python33.10.5-3 -- no debconf information -- I'd be delighted to offer any advice I can. When I have some, I'll let you know.
Bug#992908: awesome: autopkgtest regression between 20 and 23 August 2021: Could not resolve keysym
Hi, can anyone tell me what the actual error here is? I took a look at run.sh (the script that integration.sh actually runs) and as far as I can tell, this script exited successfully. The end of [0] is: autopkgtest [19:16:07]: summary integration.sh FAIL stderr: The XKEYBOARD keymap compiler (xkbcomp) reports: So... is the autopkgtest failing because xkbcomp prints something on stderr...? Not because something actually failed...? If so, I wonder how this test ever passed. I don't think I ever xkbcomp being quiet and not complaining about something. As Reiner wrote, the debdiff says that only some symlinks changed, but restoring these symlinks does not fix the problem, so the error is caused by nothing? I am confused. Would "just pipe the output of xkbcomp to /dev/null" be a valid fix then? Cheers, Uli [0]: https://ci.debian.net/data/autopkgtest/testing/amd64/a/awesome/15268186/log.gz -- - He wants the impossible...! - That's the short definition of 'captain'.
Bug#925270: znc unwisely advertises exact Debian version
Hi, On 22.03.19 00:53, T. Joseph Carter wrote: > <-- nick (~u@h) has quit (Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in) > <-- nick (~u@h) has quit (Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in) > <-- nick (~u@h) has quit (Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in) > > And one counter-example of how changing the default might be a good idea: > > <-- nick (~u@h has quit (Quit: ZNC - https://znc.in) This behaviour goes back to [1], I think. Before that, ZNC would do the second kind of quit message. Commit [1] introduced an option called "HideVersion", which defaults to "false". If this option is "false", the function CZNC::GetTag() *always* includes version information. When set to "true", CZNC::GetTag() only includes version information when told so by its caller (seems to be: only the web interface for logged-in users). When I proposed to restore the old behaviour and instead to make "HideVersion" also not include the version when explicitly told otherwise, I was told that this is the way it is supposed to work. Anyway: Set "HideVersion = true" in your znc to get rid of the version information. Webadmin can modify this setting, but controlpanel can not. If wanted, Debian could patch src/znc.cpp to change the default for m_bHideVersion to true (the line looks like "m_bHideVersion(false)"). Cheers, Uli [1]: https://github.com/znc/znc/commit/f9a45076690990f75a14315db4f456e750073723 -- "Are you preparing for another war, Plutarch?" I ask. "Oh, not now. Now we're in that sweet period where everyone agrees that our recent horrors should never be repeated," he says.
Bug#915243: awesome: systray icons don't redraw transparent parts
Hi, On 02.12.18 02:30, Roland Hieber wrote: > since a recent apt-get upgrade, followed by a restart of X, the systray > icons in my awesome with default configuration look strange and it seems > like the transparent parts are no longer redrawn with the background > color, but previously drawn items stay there, and only the opaque parts > of the icons are drawn over them. I don't know if this is awesome's > fault, it could also be a problem in an underlying library, so feel free > to assign to some other package. GTK+ broke their systray icons (perhaps only in non-composited environments; I'm not entirely sure). As far as I know, version 3.24 is affected. This bug was introduced in https://gitlab.gnome.org/GNOME/gtk/commit/01d1bc3c75fd0eff5665f5b9c690c5e1e6c65f13. Links to a couple of upstream bugs (and patches): https://github.com/awesomeWM/awesome/issues/1720 (Ignore the people talking about Qt for this; Qt also broke their icons ages ago) https://github.com/awesomeWM/awesome/issues/2449 (This talks about GTK 3.24 being affected) https://github.com/i3/i3/issues/3335 https://github.com/TomaszGasior/gtk3-mushrooms/issues/12 https://gitlab.gnome.org/GNOME/gtk/issues/1280 https://gitlab.gnome.org/GNOME/gtk/merge_requests/391/diffs (Sadly this merge request is inactive for about a month now...) > I have attached a screenshot with systray icons from nm-applet, nm-applet is definitely GTK+. > variety, I do not know this, but it depends on gir1.2-gtk-3.0, so likely also GTK+. > pasystray, Also do not know, but depends on libgtk-3-0. > hexchat, Uhm... definitely GTK+, but it depends on libgtk2.0-0, so this should not be affected by the breakage in GTK+3...? > and xfce4-power-manager. Definitely GTK+ and depends on libgtk-3-0. > You can see that under the > nm-applet WLAN indicator, there are leftovers of a previous nm-applet > icon when it hadn't had any connection. Then, under the variety icon, > some leftover text from awesome's keyboard indicator widget (which got > pushed to the left when the systray was filled up with icons). The > Pulseaudio systray icon is showing some weird superimposed state of > muted and non-muted, and the XFCE4 Power Manager is showing one and a > half batteries, the result of a "running on battery" icon drawn over a > previous "charging battery" icon. In X11, a background of "ParentRelative" means that the window inherits the background of its parent window. So, systray implementations can set a background on the systray window and the individual systray icons then inherit this background. GTK+ switched all its windows to a background of "None". This means that no background at all is drawn and whatever was visible here before stays visible when a background should be drawn. This is the behaviour that GTK+ is getting. (Qt has (had?) a different problem; they simply grabbed a screenshot and used that as the background. So, if e.g. the screensaver was active at the time the systray icon became visible... well, you now get your screensaver as background. Sometimes it would also screenshot old systray icons etc.) Cheers, Uli -- Sent from my Game Boy.
Bug#893053: awesome: (re)Starting is very slow due to enumerating icons for the main menu
Hi,
On 15.03.2018 22:58, Hans van den Bogert wrote:
> It is arguable if this patch truly fixes a bug, [...]
Since the gist of the patch seemed to have been lost in the noise, I'll
repeat it here explicitly:
> +diff --git a/lib/menubar/menu_gen.lua b/lib/menubar/menu_gen.lua
> +index 519629c7d4..0be0b6967f 100644
> +--- a/lib/menubar/menu_gen.lua
> b/lib/menubar/menu_gen.lua
> +@@ -59,7 +58,7 @@ menu_gen.all_categories = {
> + --- Find icons for category entries.
> + function menu_gen.lookup_category_icons()
> + for _, v in pairs(menu_gen.all_categories) do
> +-v.icon = icon_theme():find_icon_path(v.icon_name)
> ++v.icon = utils.lookup_icon(v.icon_name)
> + end
> + end
> +
> +
Hans, you can work around this problem in your rc.lua with:
menubar.menu_gen.lookup_category_icons = function() end
The downside of this would be that you loose category icons. However,
most people do not have category icons and this is exactly the worst
case for the code in question since it tries very, very hard to find
some icons anyway.
Hm, I guess another work around would be to actually install some
category icons... (No, I do not have details on how to do that).
Cheers,
Uli
--
A normal person is just someone you don't know well enough yet.
- Nettie Wiebe
Bug#886393: doesn't clean up inherited children
Hi, On 05.01.2018 11:45, Wouter Verhelst wrote: > If you need further information, do ask. How would you fix this? Awesome uses glib. Your favorite search engine can provide you with lots of information on the problems here (e.g. [1,2]), but it boils down to: This is not possible with glib. GLib only reaps children that it starts itself and does not provide an API to take over SIGCHLD handling. Cheers, Uli [1]: https://bugzilla.xamarin.com/show_bug.cgi?id=21818 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=981580
Bug#879956: Patch available
tags 879956 + patch fixed-upstream
thanks
Hi,
a patch for this can be found [here] (git commit attached). Thanks to
Mattia Rizzolo for sponsoring me so that I could access a s390x
porterbox and debug this myself.
Cheers,
Uli
[here]: https://github.com/pavouk/lgi/pull/178
--
A learning experience is one of those things that say,
'You know that thing you just did? Don't do that.'
-- Douglas Adams
>From f8350780e77ed68922493c8397615abbd6908cb8 Mon Sep 17 00:00:00 2001
From: Uli Schlachter <psyc...@znc.in>
Date: Mon, 30 Oct 2017 21:14:11 +0100
Subject: [PATCH] callable: Fix enum return from C functions
According to [1], return values smaller than sizeof(long) are returned
as ffi_arg or ffi_sarg. Thus, the code here needs to use ffi_sarg
instead of int to work correctly.
This fixes a test failure on s390x that boils down to
cairo_pattern_get_type() returning 2, but the C code here turns that
into a value of 0.
A big "thank" you to Debian and specifically to Mattia Rizzolo for
giving me access to a porterbox so that I could debug this myself.
[1]: https://linux.die.net/man/3/ffi_call
Signed-off-by: Uli Schlachter <psyc...@znc.in>
---
lgi/callable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lgi/callable.c b/lgi/callable.c
index 62387ed..86b7ed3 100644
--- a/lgi/callable.c
+++ b/lgi/callable.c
@@ -769,7 +769,7 @@ callable_param_2lua (lua_State *L, Param *param, GIArgument *arg,
args + callable->has_self);
else
{
- union { GIArgument arg; int i; } *u = (gpointer) arg;
+ union { GIArgument arg; ffi_sarg i; } *u = (gpointer) arg;
lua_pushnumber (L, u->i);
}
}
--
2.14.2
Bug#870834: Bug is due to an API break in GLib
Hi, FYI, the bug was already reported upstream: https://github.com/pavouk/lgi/issues/167 The reason seems to be a (GObject-introspection) API break in GLib. Previously g_object_newv was [rename-to g_object_new], but now this annotation is on g_object_new_with_properties(). If you ask me, this is a regression in GLib, but I guess only breaking the C API is considered an API break and the introspection API has no stable guarantees, right? Cheers, Uli -- Sent from my Game Boy.
Bug#857661: awesome: systray frequently messed up
Hi, could you try if starting awesome with the --no-argb flag fixes this? First: "Why I think that this is not a bug in awesome" The systray is implemented as windows. The systray provider (awesome in this case) only places these windows, but it does not draw them. Since in X11 a window cannot be at multiple places at once, awesome cannot actually cause this. Second: "Why I suggest --no-argb" I do this for all bugs involving rendering issues. If you want, you can check if the fix for [1], which seems to be [2], makes your issue go away. [1]: https://bugs.freedesktop.org/show_bug.cgi?id=99220 [2]: https://patchwork.freedesktop.org/patch/137290/ Cheers, Uli -- Sent from my Game Boy.
Bug#852969: Wrong version for lua-gi dependency
On 28.01.2017 16:37, Goedson Teixeira Paixao wrote: > Package: awesome > Version: 4.0-1 > > When trying to show the menubar (shortcut is Super+p in the default > configuration) I get the following error message: > > /usr/share/awesome/menubar/utils.lua:289: attempt to index field > 'Async' (a nil value) > > I found that upgrading lua-lgi to 0.8.0 fixes it. Same problem upstream (NixOS users ran into): https://github.com/awesomeWM/awesome/issues/1348 Upstream fix is to depend on at least LGI 0.8.0: https://github.com/awesomeWM/awesome/commit/1078a9f395a8e84ce8f31bbe21e5a37fdf2fef79 Cheers, Uli
Bug#847659: #847659: [dma] postinst maintainer script fails
On 19.12.2016 00:04, Christian Hofstaedtler wrote: > Control: tags -1 + moreinfo > > Dear Submitter, > > I've quickly tried to reproduce your bug report, but failed to do > so. Please provide more info. I'm happy to do so, I just didn't have any good ideas on which information. :-) > Were you upgrading from a previous version? If so, which? Yes. This started to happen during the upgrade from 0.11-1 to 0.11-1+b1. Also, in the mean time the problem fixed itself for whatever reason. According to dpkg.loa, configuring the package failed 11 times [1] and the twelth attempt was successful. I have no idea what caused this problem and I can no longer reproduce. Feel free to close this report. Cheers, Uli [1]: $ grep 'configure dma:amd64 0.11-1+b1' /var/log/dpkg.log | wc -l 12 -- Homophobia - The fear that another man will treat you the way you treat women.
Bug#834414: apt-daily.service fails permanently and quietly as it runs before network is up
On 09.12.2016 08:59, Philipp Ittershagen wrote: [...] > On Sun, Dec 04 2016, Uli Schlachter wrote: >> I had the same problem and I can confirm that creating the following >> file fixed this issue for me: >> >> $ cat /etc/systemd/system/apt-daily.timer.d/10-depend-on-network.conf >> [Unit] >> After=network-online.target > > I tried adding the dependency (and to the service as well), but it does > not work. The `network-online.target` is not deactivated on my setup > when suspending. It rather stays active across suspend/resume cycles > and the requirement for the apt-daily unit(s) is always met. Did you > change anything on that regard? No, I did not, but I don't use suspend/resume. I had this problem only right after booting. Cheers, Uli -- Happiness can't be found -- it finds you. - Majic
Bug#847659: [dma] postinst maintainer script fails
Package: dma Version: 0.11-1+b1 Severity: serious --- Please enter the report below this line. --- Hi, I don't know really what is going on, but the symptom is: dpkg: Fehler beim Bearbeiten des Paketes dma (--configure): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 128 zurück So the postinst script is failing with code 128. I added "set -x" to it and the result was: $ LC_ALL=C sudo dpkg --configure dma Setting up dma (0.11-1+b1) ... + dpkg-maintscript-helper rm_conffile /etc/dma/dma.conf 0.0.2010.06.17-14.1~ dma -- configure 0.11-1 + . /usr/share/debconf/confmodule + [ ! ] + PERL_DL_NONLAZY=1 + export PERL_DL_NONLAZY + [ ] + exec /usr/share/debconf/frontend /var/lib/dpkg/info/dma.postinst configure 0.11-1 dpkg: error processing package dma (--configure): subprocess installed post-installation script returned error exit status 128 Errors were encountered while processing: dma Next Google gave me DEBCONF_DEBUG=developer as an environment var: $ sudo sh -c 'DEBCONF_DEBUG=developer LC_ALL=C dpkg --configure dma' Setting up dma (0.11-1+b1) ... + dpkg-maintscript-helper rm_conffile /etc/dma/dma.conf 0.0.2010.06.17-14.1~ dma -- configure 0.11-1 + . /usr/share/debconf/confmodule + [ ! ] + PERL_DL_NONLAZY=1 + export PERL_DL_NONLAZY + [ ] + exec /usr/share/debconf/frontend /var/lib/dpkg/info/dma.postinst configure 0.11-1 debconf (developer): frontend started debconf (developer): frontend running, package name is dma debconf (developer): starting /var/lib/dpkg/info/dma.config configure 0.11-1 debconf (developer): <-- VERSION 2.0 debconf (developer): --> 0 2.0 debconf (developer): <-- CAPB backup debconf (developer): --> 0 multiselect escape backup debconf (developer): <-- SET dma/mailname ZweiLED debconf (developer): --> 0 value set debconf (developer): <-- SET dma/relayhost debconf (developer): --> 0 value set debconf (developer): <-- smtp.uni-oldenburg.de debconf (developer): <-- INPUT high dma/mailname debconf (developer): --> 30 question skipped debconf (developer): <-- GO debconf (developer): --> 0 ok debconf (developer): <-- STOP dpkg: error processing package dma (--configure): subprocess installed post-installation script returned error exit status 128 Errors were encountered while processing: dma At this point I am a bit lost. I don't know what more information to provide. I hope this already helps. Cheers, Uli --- System information. --- Architecture: Kernel: Linux 4.8.0-1-amd64 Debian Release: stretch/sid 990 testing ftp.de.debian.org 500 stable dl.google.com50 unstablehttp.debian.net --- Package information. --- Depends (Version) | Installed ==-+-=== ucf (>= 0.28) | 3.0036 debconf (>= 0.5) | 1.5.59 OR debconf-2.0| libc6(>= 2.14) | libssl1.1 (>= 1.1.0) | Package's Recommends field is empty. Package's Suggests field is empty. -- Happiness can't be found -- it finds you. - Majic
Bug#834414: apt-daily.service fails permanently and quietly as it runs before network is up
Hi, I had the same problem and I can confirm that creating the following file fixed this issue for me: $ cat /etc/systemd/system/apt-daily.timer.d/10-depend-on-network.conf [Unit] After=network-online.target (However, I wonder if the timer or the service should depend on network-online.target, but that's a question for someone with more of a clue.) Cheers, Uli -- 99 little bugs in the code 99 little bugs in the code Take one down, patch it around 117 little bugs in the code -- @irqed
Bug#842478: [gettext] Contains copy of parts of libglib and exports it
On 29.10.2016 17:53, Santiago Vila wrote: > On Sat, Oct 29, 2016 at 05:03:55PM +0200, Uli Schlachter wrote: [...] >> while investigating [1], I noticed that this package contains a copy of >> parts of glib and exports its symbols. [...] > As you have rightly pointed out here: > > https://github.com/pavouk/lgi/issues/145#issuecomment-257097298 > > there is no point in loading libgettextlib at all, because that's an > internal gettext library which is *not* intented to be used by other > packages. > > This is somewhat documented by the lintian overrides: > > http://sources.debian.net/src/gettext/0.19.8.1-1/debian/gettext.lintian-overrides/ In my opinion that's quite a weak documentation, but ok. I didn't manage to find this when trying to figure out what this library is supposed to do. > So: How those "quite generic names" are a problem at all considering > that this is not supposed to be used by any other program in Debian? Let's ignore the "export symbols" part then. This report was more meant to be about "contains a convenience copy of parts of libglib" and policy 4.13. This is quite a stripped-down version with some generous use of "#if 0", but I guess it still is a convenience copy, isn't it? Uli -- “Some people are worth melting for.” - Olaf
Bug#842478: [gettext] Contains copy of parts of libglib and exports it
Package: gettext Version: 0.19.8.1-1 Severity: serious Justification: Policy 4.13 --- Please enter the report below this line. --- Hi, while investigating [1], I noticed that this package contains a copy of parts of glib and exports its symbols. For example, the following says that libgettextlib exports g_hash_table_new $ nm --dynamic /usr/lib/libgettextlib-0.19.8.1.so | grep g_hash_table_new 0002be50 T g_hash_table_new 0002bde0 T g_hash_table_new_full Attached is the full list of exported symbols, generated with $ nm --dynamic /usr/lib/libgettextlib-0.19.8.1.so | grep -vE ' U | w ' This list contains many symbols with quite generic names (e.g. quote, gcd, xmalloc, ...) Please do something about this. Cheers, Uli [1]: https://github.com/pavouk/lgi/issues/145 --- System information. --- Architecture: amd64 Kernel: Linux 4.7.0-1-amd64 Debian Release: stretch/sid 500 testing ftp.de.debian.org 500 stable dl.google.com --- Package information. --- Depends (Version) | Installed ==-+-= libc6(>= 2.17) | 2.24-5 libcroco3 (>= 0.6.2) | 0.6.11-2 libglib2.0-0 (>= 2.12.0) | 2.50.1-1 libgomp1 (>= 4.9) | 6.2.0-9 libncurses5 (>= 6) | 6.0+20160917-1 libtinfo5 (>= 6) | 6.0+20160917-1 libunistring0 | 0.9.6+really0.9.3-0.1 libxml2 (>= 2.9.1) | 2.9.4+dfsg1-2 gettext-base | 0.19.8.1-1 dpkg (>= 1.15.4) | 1.18.10 OR install-info | 6.3.0.dfsg.1-1+b1 Recommends (Version) | Installed =-+-=== curl | 7.50.1-1 OR wget | 1.18-4 OR lynx-cur | Suggests (Version) | Installed ===-+-=== gettext-doc | autopoint | 0.19.8.1-1 libasprintf-dev | libgettextpo-dev| -- “Some people are worth melting for.” - Olaf acb0 T acl_errno_valid be30 T addext ad70 T areadlink adb0 T argmatch 002cd9e8 D argmatch_die aee0 T argmatch_invalid b0e0 T argmatch_to_argument af60 T argmatch_valid 000291b0 T asnprintf 00010a10 T at_fatal_signal 00010bc0 T block_fatal_signals 002cdb30 B __bss_start cb30 T careadlinkat ad00 T chmod_or_fchmod bf20 T c_isalnum bf50 T c_isalpha bf80 T c_isascii bf90 T c_isblank bfa0 T c_iscntrl bfc0 T c_isdigit bfd0 T c_isgraph bfe0 T c_islower bff0 T c_isprint c000 T c_ispunct c030 T c_isspace c060 T c_isupper c070 T c_isxdigit daf0 T cleanup_temp_dir d8d0 T cleanup_temp_dir_contents d850 T cleanup_temp_file d8a0 T cleanup_temp_subdir 0001e580 T clone_quoting_options de50 T close_stdout dcf0 T close_temp f7a0 T compile_csharp_class 00014210 T compile_java_class df10 T concatenated_filename abd0 T copy_acl e280 T copy_file_preserving 0001f4e0 T create_pipe_bidi 0001f520 T create_pipe_in 0001f590 T create_pipe_out d3f0 T create_temp_dir c0c0 T c_strcasecmp c720 T c_strcasestr c110 T c_strncasecmp cb20 T c_strstr c0a0 T c_tolower c0b0 T c_toupper de40 T dup_cloexec 00027c80 T dup_safer 00011090 T dup_safer_flag 002cdb30 D _edata 002d1908 B _end v _environ 002cd9f8 D error_with_progname 00010500 T execute 00010390 T execute_csharp_program 00016bc0 T execute_java_class 002cd9fc D exit_failure dd40 T fclose_temp 00010fc0 T fd_ostream_create 002cc730 D fd_ostream_typeinfo 002cc700 D fd_ostream_vtable 00027c90 T fd_safer 00011050 T fd_safer_flag 00011100 T file_ostream_create 002cc770 D file_ostream_typeinfo 002cc740 D file_ostream_vtable bb90 T find_backup_file_name 00011120 T find_in_path 0002d0cc T _fini dc90 T fopen_temp 00019590 T freea ace0 T free_permission_context 00011790 T fstrcmp_bounded 00011b60 T full_write 00011d20 T fwriteerror 00011d30 T fwriteerror_no_ebadf dd90 T fwriteerror_temp 0002c820 T g_ascii_strup 002ccae8 D g_ascii_table 0002c800 T g_ascii_toupper 00011d40 T gcd 00022280 T gen_tempname 0001ef20 T get_handler acf0 T get_permissions 0001e5c0 T get_quoting_style bdb0 T
Bug#830491: Please package new upstream release 1.12
Hi, the arch issues seemed to be GCC6, -O2 (and x86?) specific [1,2] and was fixed in Arch by compiling libxcb with -O1 [3]. Also, the code where this crash occurred was not changed since the last release. I would suggest to just ignore that one report. Cheers, Uli [1]: https://lists.freedesktop.org/archives/xcb/2016-June/010818.html [2]: https://lists.freedesktop.org/archives/xcb/2016-June/010819.html [3]: https://bugs.archlinux.org/task/49560 -- A normal person is just someone you don't know well enough yet. - Nettie Wiebe
Bug#826197: discount: FTBFS on many architectures: 1 test failed
tags 826197 + fixed-upstream patch thanks This issue was fixed upstream (and the bug is actually on those arches where the tests did NOT fail...): https://github.com/Orc/discount/commit/0d71ce77859c44aad7379d70c9024d5047577100 https://github.com/Orc/discount/commit/aa9a54bddb3211204625c1eb6a2656e0f4b4e59c It would be nice to have these fixes included in Debian. It does not look like upstream is planing to have a new release just for this. Cheers, Uli
Bug#823164: Fixed upstream
Hi, this issue was fixed upstream 26 days ago and a new release with this fix was published. Are you planning to backport this fix or to upload the new version? What is blocking this from being fixed in Debian? How can I help? Two weeks left until auto-removal and lua-lgi seems to have ended up in a libffi transition. Cheers, Uli -- “I’m Olaf and I like warm hugs.”
Bug#817071: Backup fails if sync_first is used and some files are modified while rsync runs
Package: rsnapshot
Version: 1.4.1-1
Severity: grave
Tags: upstream patch
Hi,
I just noticed that my backups are broken since a while. rsnapshot happily makes
backups of an old state of its .sync directory. Symptoms on stderr are:
[snip]
rsnapshot encountered an error! The program was invoked with these options:
/usr/bin/rsnapshot sync
ERROR: /usr/bin/rsync returned 0.09375 while processing /
WARNING: Rolling back "hdd/"
[/snip]
(Notice that it says it's Rolling back, thus I get lots of disk activity and
think that it does a backup. Also, the mtimes in the backup directory suggest as
well that everything works. Oh and I had this error in the past, too, without
any problems. Hence the severity.)
Google found the following upstream report on this bug:
https://github.com/rsnapshot/sourceforge-issues/issues/8
And indeed I see in /usr/bin/rsnapshot that first in line 3921, result is set
via
$result = $? >> 8;
and then line 3929 does (where the function get_retval() just divides by its
argument by 256). As you see in the output above, this results in $retval being
set to 0.09375.
my $retval = get_retval($result);
The fix should be the following chunk of an otherwise weirdly wrong commit
upstream:
https://github.com/rsnapshot/rsnapshot/commit/778ab47d8eb4891f464677a0e26c38b186a376c8#diff-70276296f2bdcc3adb72b3d823d07361L3922
Cheers,
Uli
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (50,
'experimental'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-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
Init: systemd (via /run/systemd/system)
Versions of packages rsnapshot depends on:
ii liblchown-perl 1.01-3+b1
ii logrotate 3.8.7-2
ii perl5.22.1-8
ii rsync 3.1.1-3
Versions of packages rsnapshot recommends:
ii openssh-client [ssh-client] 1:7.1p2-2
rsnapshot suggests no packages.
-- Configuration Files:
/etc/logrotate.d/rsnapshot changed:
/var/log/rsnapshot.log /var/log/rsnapshot {
rotate 6
monthly
compress
missingok
}
/etc/rsnapshot.conf changed:
config_version 1.2
snapshot_root /media/backup/
no_create_root 1
cmd_cp /bin/cp
cmd_rm /bin/rm
cmd_rsync /usr/bin/rsync
cmd_logger /usr/bin/logger
cmd_du /usr/bin/du
cmd_rsnapshot_diff /usr/bin/rsnapshot-diff
retain daily 8
retain weekly 5
retain monthly 12
verbose 2
loglevel3
logfile /var/log/rsnapshot.log
lockfile/var/run/rsnapshot.pid
exclude kuja.in_home
exclude /proc
exclude /sys
exclude /tmp
exclude /var/tmp
exclude .ccache
exclude /dev/.udev
exclude /dev/pts
exclude /dev/shm
exclude /var/cache
link_dest 1
sync_first 1
backup / hdd/
-- no debconf information
Bug#801170: Similar bugs
Hi, just wanted to mention: The following bugs sound like previous reports of this problem which were fixed by depending on shared-mime-info, however the dependency was added to the wrong package each time (libgdk-pixbuf2.0-dev, libgtk2.0-0): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758813 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518090 Cheers, Uli -- "In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move."
Bug#801170: awesome fails to recognize image file format for png
reassign 801170 libgdk-pixbuf2.0-0 thanks Hi, I tried a slight variation of your instruction: host$ fallocate -l 10G testimg host$ /sbin/mkfs.ext4 testimg host$ mkdir /tmp/mount host$ mount testimg /tmp/mount host$ sudo /usr/sbin/debootstrap --variant=minbase unstable /tmp/mount host$ echo 'APT::Install-Recommends "0";' | sudo tee "/tmp/mount/etc/apt/apt.conf.d/99no-install-recommends" > /dev/null host$ Xephyr -listen tcp :1 & host$ sudo chroot /tmp/mount chroot# apt-get install awesome chroot# DISPLAY=127.0.0.1:1 awesome Via this, I can reproduce the problem (same error message). Looking at this via strace, I noticed this tries to load mime information. Thus, I had the following idea: host$ sudo cp /usr/share//mime/mime.cache /tmp/mount/usr/share/mime/mime.cache The above command makes everything work here. Looking at gdk-pixbuf's source, I can see that it has its own, internal mime information implementation, but it defaults to using the mime information available. Apparently something is wrong here. Hence I reassign this to libgdk-pibxuf. The file /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache says the following about PNG files: "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so" "png" 5 "gdk-pixbuf" "PNG" "LGPL" "image/png" "" "png" "" "\211PNG\r\n\032\n" "" 100 The background.png file that this issue is about begins with: \211PNG\r\n\32\n\0\0\0\rIHDR\0\0\10\0\0\0\6\0\10\2\0\0\0m I don't really understand the loaders.cache's file format, but to me this looks like it should match. Cheers, Uli -- - Buck, when, exactly, did you lose your mind? - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her.
Bug#802248: awesome: FTBFS: ldoc: Error: no suitable Lua interpreter found
reassign 802248 lua-ldoc 1.4.3-4 retitle 802248 lua-ldoc does not work with lua5.1 tag 802248 patch thanks Hi, lua-ldoc clearly uses lua-any, but claims to only work with lua5.2: $ grep Lua-Versions /usr/bin/ldoc -- Lua-Versions: 5.2 After uninstalling lua5.2 I thus get: $ ldoc Error: no suitable Lua interpreter found Error: supported versions are: 5.2 A sudoedit later I get: $ grep Lua-Versions /usr/bin/ldoc -- Lua-Versions: 5.1 5.2 $ ldoc ldoc: missing required parameter: file [...] So I'll (try to...) reassign this bug to lua-ldoc. Also, it should be obvious how to fix this. :-) Cheers, Uli -- "In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move."
Bug#802248: awesome: FTBFS: ldoc: Error: no suitable Lua interpreter found
Hi everyone, isn't this a bug in ldoc? If I understand the dependencies correctly, awesome depends on lua 5.1 and lua-ldoc depends on lua5.1 | lua5.2, so only lua 5.1 is installed. However, looking at [0], ldoc contains "Lua-Versions: 5.2", so lua-any doesn't consider lua 5.1 a valid option. Thus, either lua-ldoc should depend on lua 5.2 or allow to be used with lua 5.1. Anyone disagrees? Cheers, Uli [0]: https://anonscm.debian.org/cgit/pkg-lua/lua-ldoc.git/commit/?id=ed6a8e46ce29e2a31eccc685c162e7b704539808 -- Sent from my Game Boy.
Bug#744712: znc: ZNC can be crashed by any user if webadmin is loaded
Hi, the bug was introduced in the following commit: https://github.com/znc/znc/commit/997023ea9de8fcc4ab68f0139015e1b7dba3b8a9 This is from 2005. Or put differently, everything this release is affected: $ git describe --contains 997023ea9de8fcc4ab68f0139015e1b7dba3b8a9 znc-0.043~72 Yay, Uli -- “I’m Olaf and I like warm hugs.” -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735047: [Xcb] Bug#735047: fglrx-driver: openGL applications segfaults on igpu configuration
Hi,
On 02.02.2014 17:41, Julien Cristau wrote:
[...]
On 2014-02-01 23:18, Alexander V. Kudrevatykh wrote:
В Чтв, 30/01/2014 в 01:05 +0100, Andreas Beckmann пишет:
First step of debugging would be to run glxinfo inside gdb and get a
backtrace
after the crash. And maybe running it under strace, too.
In attachment you can find gdb and strace output for glxinfo
Program received signal SIGSEGV, Segmentation fault.
xcb_glx_query_server_string_string_length (R=R@entry=0x0) at glx.c:2460
Null-pointer dereference in libxcb-glx0.
The caller seems to be
http://sources.debian.net/src/mesa/9.2.2-1/src/glx/glx_query.c?hl=55#L55
(but this is code from sid, codesearch.d.n does not have wheezy)
Reassigning to libxcb since I don't know how to debug further.
There is no bug in xcb-glx here. Mesa doesn't do the necessary error checking
for this request (as evident by the reply = 0x0 in gdb output).
The GLX QueryServerString request failed, the error for this was ignored (NULL
argument to xcb_glx_query_server_string_reply()) and the caller then tried to
extract data from the NULL pointer reply.
From the strace output, the last request sent is this one:
writev(3, [{\232\23\3\0\0\0\0\0\2\0\0\0, 12}], 1) = 12
This is a request with length 3*4=12 (third and fourth byte, little endian),
major number 0232 = 154 and minor number 023 = 19. Major numbers are assigned
dynamically, thus no idea what the 154 means (but xdpyinfo -ext all | grep
opcode: 154 would tell us), but the minor number 19 could help. GLX
QueryServerString has minor 19, which would mean the request contains screen=0
and name=2 which maches the output from gdb
__glXQueryServerString (dpy=dpy@entry=0x608010, opcode=optimized out,
screen=screen@entry=0, name=name@entry=2)
(Also I just looked up the GLX QueryExtension request from the strace output and
0232 is indeed GLX...)
The reply to this seems to be:
recvmsg(3, {msg_name(0)=NULL,
msg_iov(1)=[{\0\1\17\0\27\0\0\0\23\0\232\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 32
This is an error (\0) with error code 1 and sequence number 15 (\17\0). The
fields are: resource_id = \27\0\0\0 = 23, minor_code = \23\0 = 19, major_code =
\232 = 154 and all following fields being zero.
Error code 1 is a request error. From Xlib's src/XErrorDB this is described as
BadRequest (invalid request code or no such operation). Some other docs[1] say
The major or minor opcode does not specify a valid request.. I am confused...
TL;DR: No bug in anything xcb-related here, but there is (a) a bug in mesa where
it doesn't handle a request failure correctly and (b) some weirdness that I
don't understand that makes the server claim to support GLX, but not support GLX
QueryServerString.
Cheers,
Uli
[0]: http://cgit.freedesktop.org/xorg/xserver/tree/glx/glxcmds.c#n2390
[1]: http://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html#errors
--
99 little bugs in the code
99 little bugs in the code
Take one down, patch it around
117 little bugs in the code
-- @irqed
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733508: Unsets LD_LIBRARY_PATH from child processes
Package: rxvt-unicode-256color Version: 9.19-1 Severity: minor Hi, I got git builds of various libraries laying around (xcb, Xlib, cairo, ...) and want all my program to use these versions of the libraries so that I notice new problems early. To do this, I set LD_LIBRARY_PATH in ~/.xsession which is inherited by all processes in the X session. However, urxvt not unsets LD_LIBRARY_PATH. To test this I ran this command and checked for LD_LIBRARY_PATH in its output: env -i sh -c 'LD_LIBRARY_PATH=foo urxvt -hold -e /usr/bin/env' This happens because the urxvt binary is g+s, thanks to bug #500230. If I remove the setgid bit, LD_LIBRARY_PATH is passed on to the shell that urxvt starts. I know that this is not really urxvt's fault, but I have this problem due to a change in urxvt. It would be nice if urxvt used my local Xlib and xcb builds, but more importantly everything else should do so. Cheers, Uli -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-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 rxvt-unicode-256color depends on: ii base-passwd 3.5.28 ii libc6 2.17-97 ii libfontconfig12.11.0-2 ii libfreetype6 2.5.1-1 ii libgcc1 1:4.8.2-10 ii libgdk-pixbuf2.0-02.28.2-1+b1 ii libglib2.0-0 2.38.0-1 ii libperl5.18 5.18.1-5 ii libstartup-notification0 0.12-3 ii libx11-6 2:1.6.2-1 ii libxft2 2.3.1-1 ii libxrender1 1:0.9.8-1 ii ncurses-term 5.9+20130608-1 Versions of packages rxvt-unicode-256color recommends: pn fonts-vlgothic | fonts-japanese-gothic none ii ttf-dejavu 2.33+svn2514-3 rxvt-unicode-256color 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#723750: Missing dependency on libxcb-render-util0-dev
Package: libxcb-cursor-dev Version: 0.1.0-1 Severity: normal After installing libxcb-cursor-dev, I tried to use it through its pkg-config file, but cmake/pkg-config was not happy: $ cat CMakeLists.txt cmake_minimum_required(VERSION 2.8) include(FindPkgConfig) pkg_check_modules(FOO REQUIRED xcb-cursor) $ cmake . -- Found PkgConfig: /usr/bin/pkg-config (found version 0.26) -- checking for module 'xcb-cursor' -- found xcb-cursor, version 0.1.0 Package xcb-renderutil was not found in the pkg-config search path. Perhaps you should add the directory containing `xcb-renderutil.pc' to the PKG_CONFIG_PATH environment variable [snip] However, calling pkg-config directly does not complain, unless you use --static: $ pkg-config --libs --static xcb-cursor Package xcb-renderutil was not found in the pkg-config search path. Perhaps you should add the directory containing `xcb-renderutil.pc' to the PKG_CONFIG_PATH environment variable Package 'xcb-renderutil', required by 'XCB cursor library', not found So it seems to me as if libxcb-cursor-dev should depend on libxcb-render-util0-dev, but I am not completely convinced myself... Cheers, Uli -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-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 libxcb-cursor-dev depends on: ii libxcb-cursor0 0.1.0-1 libxcb-cursor-dev recommends no packages. libxcb-cursor-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721432: awesome: Memory leak (at least) when switching windows
Hi, turns out that this is ultimately a bug in Pango. However, a work-around was just committed to lua-lgi upstream: https://github.com/pavouk/lgi/commit/ec3dfe88ce013e78246b22adce88a2c97a934005 Uli -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712254: znc: Fails to build twice in a row
Hi, On 14.06.2013 17:26, Scott Kitterman wrote: [...] dpkg-source: warning: ignoring deletion of file modules/modpython/swigpyrun.h dpkg-source: warning: ignoring deletion of file modules/modpython/znc_core.py dpkg-source: warning: ignoring deletion of file modules/modpython/_znc_core.cpp dpkg-source: warning: ignoring deletion of file modules/modpython/functions.cpp dpkg-source: warning: ignoring deletion of file modules/modperl/ZNC.pm dpkg-source: warning: ignoring deletion of file modules/modperl/ZNC.cpp dpkg-source: warning: ignoring deletion of file modules/modperl/swigperlrun.h dpkg-source: warning: ignoring deletion of file modules/modperl/functions.cpp This is already known upstream (and quite an ugly issue): https://github.com/znc/znc/issues/276 Stupid, untested and possibly non-working workaround is make clean SWIG= instead of make clean (that is an idea I had just now, so no guarantees). dpkg-source: info: local changes detected, the modified files are: znc-1.0/include/znc/zncconfig.h znc-1.0/test/Makefile [...] Uhm. No idea what this is, neither zncconfig.h nor Makefile are part of the tarball, so how can non-existent files be modified? Uli -- For saving the Earth.. and eating cheesecake! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708252: iotop stop working
Hi,
I just ran into this issue and Google led me to debian bug #708252. The problem
likely was with a video file whose file name contained an Umlaut (ö).
I sudoedit-ed the patch[0] into my iotop installation to test it. The result
didn't look pretty:
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position
137: ordinal not in range(128)
Traceback (most recent call last):
File /usr/sbin/iotop, line 17, in module
main()
File /usr/lib/python2.7/dist-packages/iotop/ui.py, line 616, in main
main_loop()
File /usr/lib/python2.7/dist-packages/iotop/ui.py, line 606, in lambda
main_loop = lambda: run_iotop(options)
File /usr/lib/python2.7/dist-packages/iotop/ui.py, line 504, in run_iotop
return curses.wrapper(run_iotop_window, options)
File /usr/lib/python2.7/curses/wrapper.py, line 43, in wrapper
return func(stdscr, *args, **kwds)
File /usr/lib/python2.7/dist-packages/iotop/ui.py, line 497, in
run_iotop_window
ui.run()
File /usr/lib/python2.7/dist-packages/iotop/ui.py, line 155, in run
self.process_list.duration)
File /usr/lib/python2.7/dist-packages/iotop/ui.py, line 477, in
refresh_display
print_line(lines[i].encode('utf-8'))
File /usr/lib/python2.7/dist-packages/iotop/ui.py, line 473, in print_line
self.win.addstr(i + len(summary) + 1, 0, lines[i])
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position
137: ordinal not in range(128)
Notice that there is a new call to print_line() from line 477. So this caught
the original UnicodeEncodeError and the print_line(lines[i].encode('utf-8'))
then caused the same error again.
Since there doesn't seem to be an easy test case for this yet, the following
triggers this problem reliably for me:
$ dd if=/dev/zero of=öäü߀
Cheers,
Uli
[0]:
http://repo.or.cz/w/iotop.git/commitdiff/b3a739757b0c6246514e6ebc9bc02961bfa9ad15
--
Bruce Schneier can read and understand Perl programs.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703716: Bug fixed upstream
tags 703716 + upstream patch
thanks
Hi,
I just fixed this bug in DCMTK's git repository. The commit will soon be
publicly available[0]. The patch is also attached to this mail.
The problem was that with --disable-get some code was executed which used a
wrong value for the number of supported transfer syntax and thus a NULL pointer
got interpreted as a transfer syntax.
Cheers,
Uli
[0]:
http://git.dcmtk.org/web?p=dcmtk.git;a=commitdiff;h=29d8bca29c6c62c9f57618a58faf3b31cd12609b
diff --git a/dcmqrdb/libsrc/dcmqrsrv.cc b/dcmqrdb/libsrc/dcmqrsrv.cc
index 2b4239f..d0e77fe 100644
--- a/dcmqrdb/libsrc/dcmqrsrv.cc
+++ b/dcmqrdb/libsrc/dcmqrsrv.cc
@@ -796,7 +796,7 @@ OFCondition DcmQueryRetrieveSCP::negotiateAssociation(T_ASC_Association * assoc)
cond = ASC_acceptContextsWithPreferredTransferSyntaxes(
assoc-params,
dcmAllStorageSOPClassUIDs, numberOfAllDcmStorageSOPClassUIDs,
-(const char**)transferSyntaxes, DIM_OF(transferSyntaxes));
+(const char**)transferSyntaxes, numTransferSyntaxes);
if (cond.bad()) {
DCMQRDB_ERROR(Cannot accept presentation contexts: DimseCondition::dump(temp_str, cond));
}
Bug#681770: Moving terminal windows around makes them smaller
Hi, You write that this happens 'usually'. So it only happens sometimes? How often does moving a window around have this effect? (Always / every second times / only on full moon) When did this behavior start? Or did awesome always do this? Do you have some kind of roxterm or gnome-terminal config? (= Did you press any weird buttons ;-) What exactly do you mean with resizing the window first? Something like: - You are on a floating layout - You open roxterm - You press mod4 - You press the right mouse button and move the mouse to make roxterm larger - You release the mouse button - You do the same again with the left mouse button - roxterm doesnt get smaller - You release the mouse button and mod4 Does the resizing start as soon as you press the mouse button or only when you move the mouse? It continues even while you hold the mouse button but dont move the mouse? Finally, you write that this happens at a rate of 10-15 columns per second. Does this only affect columns (= the width of the terminal) or also rows? Is the effect on both axis the same? (does it get smaller horizontally at the same speed that it gets smaller vertically?) Cheers, Uli -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673251: Unreadable text with some PDFs
Package: libpoppler13 Version: 0.16.7-3 Severity: important Tags: upstream patch This problem was already reported upstream[0] and fixed[1]. Basically, cairo 1.12 started clipping user fonts to the text extents while cairo 1.10 didn't do any clipping. This results in only one pixel of each text line being visible for the affected PDFs. The upstream bug links to a sample file. Please apply the patch that fixes this problem[1]. [0]: https://bugs.freedesktop.org/show_bug.cgi?id=48222 [1]: http://cgit.freedesktop.org/poppler/poppler/commit/?id=f1e621adbbb74ec709022b2a31195331651c83fa -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-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 libpoppler13 depends on: ii libc6 2.13-32 ii libfontconfig1 2.9.0-3 ii libfreetype62.4.9-1 ii libjpeg88d-1 ii liblcms11.19.dfsg-1+b2 ii libopenjpeg21.3+dfsg-4+b1 ii libpng12-0 1.2.49-1 ii libstdc++6 4.7.0-7 Versions of packages libpoppler13 recommends: pn poppler-data none libpoppler13 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#666632: oocairo: FTBFS: tests failed
tags 32 patch fixed-upstream thanks Hi, this test failure is harmless. It's just cairo changing its behavior. Fix can be found here (and in the attachment): http://git.naquadah.org/?p=oocairo.git;a=commitdiff;h=d6c087dcf9557ecb16bc4741b2e47de0bb90c14b Cheers, Uli -- In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move. From d6c087dcf9557ecb16bc4741b2e47de0bb90c14b Mon Sep 17 00:00:00 2001 From: Uli Schlachter psyc...@znc.in Date: Fri, 10 Feb 2012 18:09:23 +0100 Subject: [PATCH] Tests: Fix for cairo 1.12.0 cairo recently (and accidentally?) changed its behavior and now the test fails. Signed-off-by: Uli Schlachter psyc...@znc.in --- test/surface.lua |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/test/surface.lua b/test/surface.lua index 73fe9a5..12108b0 100644 --- a/test/surface.lua +++ b/test/surface.lua @@ -299,7 +299,9 @@ if Cairo.check_version(1, 10, 0) then function test_subsurface() local surface = Cairo.image_surface_create(rgb24, 23, 45) local sub = surface:create_for_rectangle(10, 11, 12, 13) -assert_equal(subsurface, sub:get_type()) +local sub_type = sub:get_type() +-- This if is needed because of cairo commit ba855a12e8d686f2137f82d3177 +assert_true(sub_type == subsurface or sub_type == image) assert_error(function() sub:create_for_rectangle(0, 0, -1, -1) end) end end -- 1.7.9.1
Bug#658184: Fwd: Bug#658184: znc: suddenly no longer connects two irc servers
On 19.02.2012 13:10, folkert wrote: Could you also try /znc clearbindhost? Tried that but it did not help. Could you try /znc setbindhost 0.0.0.0? That should force znc to use ipv4. -- - Buck, when, exactly, did you lose your mind? - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658184: znc: suddenly no longer connects two irc servers
On 03.02.2012 20:42, folkert wrote:
Suddenly after a restart znc won't connect to irc.oftc.net 6667 and
irc.eu.rizon.net.
So I did an strace on the process to see what was going on and saw this:
what's the error message from ZNC?
20:23:20] *status: Cannot connect to IRC (Cannot assign requested
address (Is your IRC server's host name valid?)). Retrying...
[...]
Also, you could start znc with the argument --debug --foreground and see if
that
says anything more about the issue (although I'd almost doubt that).
http://keetweej.vanheusden.com/~folkert/znc.log.gz
No more details than what it says in the irc channel.
Well, the log says a little more. This not only happens with irc.eu.rizon.net,
but also with irc.oftc.net. Also, each failure is preceded by:
Csocket.cpp:267 DNS server returned answer with no data
Also, the log pretty much makes this clear already, but do you have any bindhost
set on your users?
On 03.02.2012 21:46, folkert wrote:
Suddenly after a restart znc won't connect to irc.oftc.net 6667 and
irc.eu.rizon.net.
So I did an strace on the process to see what was going on and saw this:
what's the error message from ZNC?
For the strace results:
ZNC uses libc-ares2 for doing its DNS, so that bad recvfrom() would have to
be a
bug in c-ares. Oh and btw 4294967295 (the fd used) is (uint32_t) -1.
So you're suggesting to file a bug for libc-ares2?
Maybe you can give me some details on the situation (from a code point
of view) in which this is happening?
If you want to, feel free.
Google found a minimal c-ares example: http://paste.lisp.org/display/86982/raw
Compiling that and running it with google.com as its argument:
$ strace -e recvfrom ./a.out google.com 21 1/dev/null
recvfrom(3, U\275\201\200\0\1\0\6\0\0\0\0\6google\3com\0\0\1\0\1\300\f\0\1...,
513, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(127.0.0.1)}, [16]) = 124
recvfrom(4294967295, 0x7fff0be82940, 513, 0, 0x7fff0be82b50, 0x7fff0be82b6c) =
-1 EBADF (Bad file descriptor)
However, that failing syscall doesn't seem to have any bad effects.
I took a closer look at your initial strace output:
recvfrom(3, \212\264\201\200\0\1\0\0\0\0\0\0\3irc\2eu\5rizon\3net\0\0\34..., 5
Aparts from the standard stuff (header, flags...) and the now-expected stuff
(number of replies: 0), I also noticed the query type: \0\34. This is decimal 28
which is[1] the code for records / IPv6 (An A record has type 1).
So something is forcing ZNC to try IPv6. The only possibility (besides weird
bugs which only you are seeing) is that you have a bindhost / vhost set.
Could you also try /znc clearbindhost?
Cheers,
Uli
[1]: Nope, I don't know this stuff by heart. I started wireshark, captured a DNS
packet and used its nice dissectors to compare stuff. The 28 I looked up in
c-ares' source code. :-)
--
Engineering - where the semi-skilled laborers execute the vision
of those who think and dream. Hello Oompa-Loompas of science.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641209: znc: does not use locking properly, fails on NFSv4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11.09.2011 18:19, Robert Kawecki wrote:
ZNC uses an exclusive lock on a file handle that is open read-only. This
operation is not supported on NFSv4, as described here:
http://www.spinics.net/lists/linux-nfs/msg18594.html
This problem makes znc unusable on NFSv4-mounted home directories, resulting
in
error message:
[ !! ]is already running on this config. ]
(since it can't lock the file, it assumes someone else did!)
Relevant output of strace -e open,flock znc:
open(/home/users/thewanderer/.znc/configs/znc.conf, O_RDONLY) = 3
flock(3, LOCK_EX|LOCK_NB) = -1 EIO (Input/output error)
Hi,
Welcome to the wonderful world that is file locks. To quote man 2 flock:
A shared or exclusive lock can be placed on a file regardless of the mode in
which the file was opened.
So technically a NFS bug, if you ask me.
I see two solutions:
0) Implement proper error checking when locking the config file. EIO is not
equal to EWOULDBLOCK!
How would that help? Instead of znc is already running on this config, startup
would fail with Could not lock config.
1) Use a writable file, like znc.conf.lock (config file path with .lock
suffix appended), for exclusive locks.
(Just znc.conf is fine, too, since ZNC rewrites its config regularly and thus
needs write access to it anyway)
Since SVN rev 2065 / git commit 33ce80f476be797a / ZNC 0.094, ZNC uses fcntl()
instead of flock() for file locks. This change was done for Solaris, but AFAIK
this should also make NFS happy.
Relevant strace output:
write(1, \33[1m\33[34m[\33[32m\33[34m]\33[39m\33[..., 92[] Opening
Config [/home/psychon/.znc/configs/znc.conf]... ) = 92
stat(/home/psychon/.znc/configs/znc.conf, {st_mode=S_IFREG|0600, st_size=2098,
...}) = 0
stat(/home/psychon/.znc/configs/znc.conf, {st_mode=S_IFREG|0600, st_size=2098,
...}) = 0
open(/home/psychon/.znc/configs/znc.conf, O_RDWR) = 3
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fcntl(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
lseek(3, 0, SEEK_SET) = 0
read(3, // WARNING\n//\n// Do NOT edit thi..., 4096) = 2098
read(3, , 4096) = 0
Cheers,
Uli
- --
Do you know that books smell like nutmeg or some spice from a foreign land?
-- Faber in Fahrenheit 451
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJObPqRAAoJECLkKOvLj8sGno4H/2VAbmpB5JN06pVrqhIodfwN
EfDpKQd3PSn9gdNMPkxhEnAL3wr+7YrG8dwuj5uUZAJAfv12Y3F0MvV85oMPdf+i
+oOtfmvXOOyQxYF/Hf78J5SdAJamVPQFPSSRhIp7R+r7KNTwhw5kRE7Am033qmPG
ilbvC3IT36rljLnevOXOUyRdncOusOjya1tk1zMdOYftxfGRGG7ViPwjLQO9Ty+1
tjxyRtPZgjUFqhZTCtEGrmcwpp35Y2fNHlY8eqjCNssqNSGdy7ifk3bc1+zGbxXR
xMkEO4O8hG9b9CYOcUys9lOuFj92hXF3TUrFIHp6UWWzFTvoATeFFLduXDswm9M=
=8TQh
-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#631590: znc periodically ends up in cpu-crunching EAGAIN loops
Easy way to reproduce: nc -l -p 1230 Then add 127.0.0.1 +6667 as an IRC server (important: ssl!) and see it eat all the CPU time. I'm not yet 100% sure what exactly happens, but it's definitely waiting for the SSL handshake to finish. @Michael: Why are you connecting to a broken SSL server with three users? :p Cheers, Uli -- Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626747: oocairo: FTBFS: testsuite failures
Hi, this issue was already reported to me by someone who built oocairo on ubuntu natty. These problems started happening with cairo 1.10. Fixes are in git: http://git.naquadah.org/?p=oocairo.git;a=commitdiff;h=420b9ed240db4be6f6472b6a8092690867caa2ce http://git.naquadah.org/?p=oocairo.git;a=commitdiff;h=720a7fc9b8194041aee7857454f727e6692f116f I guess this means that it's time for a new oocairo release. @jd: Once you handled awesome 3.4.10, I'll handle oocairo 1.4. ;-) Cheers, Uli -- The Angels have the phone box! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620777: znc: FTBFS: Csocket.cpp:1113:50: error: 'SSLv2_client_method' was not declared in this scope
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
attached is a patch which in theory might fix this. However, I don't have an
openssl version with SSLv2 disabled and thus can't properly verify this.
Could someone test this patch, please?
Cheers,
Uli
- --
The Angels have the phone box!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJNoBhoAAoJECLkKOvLj8sGOHsH/A/Mejai9SkXBfqE4YXwzeiM
5pVSxSkKmIUZx9OuoD3hpcYLbHktPyyILSNv6Nln4r6viMebg4MEqF+4csSI9XPG
w1UMUjxLUn1JQfdGQR1H5ppQHX5IBZ2YFudpCFrrH2/Xx+PpkpEUctUwGhpiw+Vu
KyPF2/ECcHv4LzI8HLnJIUQ9rbfucVgv3StoPA9PVxODWojSQ0xAibA8pl54mIPA
STl8G3Ml6rS7z1wcB1hySVg+QSrmaPW4JgHH9Hp4kQVHexNXvO6RzFPFTjeR6+fJ
PhzXwJqEPck2UfhWkrN+lEp3qPrilN1DC//kb0GMQXQ0rwb+cf1vbI4AVMC1YLE=
=ipx5
-END PGP SIGNATURE-
diff --git a/Csocket.cpp b/Csocket.cpp
index 2dab124..33569bf 100644
--- a/Csocket.cpp
+++ b/Csocket.cpp
@@ -1109,15 +1109,6 @@ bool Csock::SSLClientSetup()
switch( m_iMethod )
{
- case SSL2:
- m_ssl_ctx = SSL_CTX_new ( SSLv2_client_method() );
- if ( !m_ssl_ctx )
- {
-CS_DEBUG( WARNING: MakeConnection SSLv2_client_method failed! );
-return( false );
- }
- break;
-
case SSL3:
m_ssl_ctx = SSL_CTX_new ( SSLv3_client_method() );
if ( !m_ssl_ctx )
@@ -1134,6 +1125,17 @@ bool Csock::SSLClientSetup()
return( false );
}
break;
+ case SSL2:
+#ifndef OPENSSL_NO_SSLV2
+ m_ssl_ctx = SSL_CTX_new ( SSLv2_client_method() );
+ if ( !m_ssl_ctx )
+ {
+CS_DEBUG( WARNING: MakeConnection SSLv2_client_method failed! );
+return( false );
+ }
+ break;
+#endif
+
case SSL23:
default:
m_ssl_ctx = SSL_CTX_new ( SSLv23_client_method() );
@@ -1204,15 +1206,6 @@ bool Csock::SSLServerSetup()
switch( m_iMethod )
{
- case SSL2:
- m_ssl_ctx = SSL_CTX_new ( SSLv2_server_method() );
- if ( !m_ssl_ctx )
- {
-CS_DEBUG( WARNING: MakeConnection SSLv2_server_method failed! );
-return( false );
- }
- break;
-
case SSL3:
m_ssl_ctx = SSL_CTX_new ( SSLv3_server_method() );
if ( !m_ssl_ctx )
@@ -1231,6 +1224,17 @@ bool Csock::SSLServerSetup()
}
break;
+ case SSL2:
+#ifndef OPENSSL_NO_SSLV2
+ m_ssl_ctx = SSL_CTX_new ( SSLv2_server_method() );
+ if ( !m_ssl_ctx )
+ {
+CS_DEBUG( WARNING: MakeConnection SSLv2_server_method failed! );
+return( false );
+ }
+ break;
+#endif
+
case SSL23:
default:
m_ssl_ctx = SSL_CTX_new ( SSLv23_server_method() );
csocket_openssl_no_sslv2.patch.sig
Description: Binary data
Bug#599708: CVE-2010-2812 and CVE-2010-2934
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 10.10.2010 13:19, Moritz Muehlenhoff wrote: Package: znc Severity: grave Tags: security CVE-2010-2812 and CVE-2010-2934 are currently only fixed in experimental, but not sid and Squeeze. The Red Hat bug contains references to the patches: https://bugzilla.redhat.com/show_bug.cgi?id=622600 Cheers, Moritz - From a quick look at the source package, the included patch 01-out-of-range-error.diff seems to fix exactly this.[1] According to the patch description this would be a dupe of bug #592064. Cheers, Uli [1] http://patch-tracker.debian.org/patch/series/view/znc/0.092-3/01-out-of-range-error.diff - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJMsae+AAoJECLkKOvLj8sGqWwH/A49dSZCnA9VNlSUap/9QVq6 ADSSicKT6qc6mmZHW2rixzI5FLLIscaLOA6BqtE+S8jyyiLsJD1nfeO45sbxoRTX N0AeB6pJgL5kS65VgttGbynwU67pUYy27O5ipoHYeMUNQwnl64Z1hfuo0JSnH7gD 2VrgPiIxVFBAfP6VQk2ZxDNKg+6Ehrhpfpajav6rDqiuPlQA+KmxovHxNRzp2eXG iYT3QdJfN3A5WHUOsPh2+flB4+cNd9VtDMfkACK5zNZwSV+OltGy0605txl6pBMm T+cXlPM+Z18StQJsdhSpwABrINlflQLBGX0NIAhSFljwtXLnLv7rhRr9JlfZb0c= =zCX6 -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#595409: Acknowledgement (bip can be crashed remotely by unauthenticated users)
Hi, I just found out that someone at redhat cares. This was assigned CVE-2010-3071. http://seclists.org/oss-sec/2010/q3/276 http://seclists.org/oss-sec/2010/q3/289 Cheers, Uli -- - Buck, when, exactly, did you lose your mind? - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595409: bip can be crashed remotely by unauthenticated users
Package: bip
Version: 0.8.2-1
Severity: grave
Tags: security
Unauthenticated users can easily cause a NULL pointer dereference in bip (bip is
listening at localhost:7778):
$ echo USER | telnet localhost 7778
other window
==25787== Process terminating with default action of signal 11 (SIGSEGV)
==25787== Access not within mapped region at address 0x0
==25787==at 0x11BE5C: bip_on_event (irc.c:2483)
==25787==by 0x11BF4A: irc_main (irc.c:2554)
==25787==by 0x113A97: main (bip.c:1316)
The NULL pointer dereference happens in this code:
if (r == ERR_PROTOCOL) {
mylog(LOG_ERROR, [%s] Error in protocol, closing...,
LINK(lc)-name);
goto prot_err_lines;
}
AFAIK this has been reported upstream. However, I haven't talked directly with
any bip developer about this so far.
Cheers,
Uli
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (50,
'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-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 bip depends on:
ii adduser 3.112 add and remove users and groups
ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib
ii libssl0.9.8 0.9.8o-2 SSL shared libraries
ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip
bip recommends no packages.
bip suggests no packages.
-- Configuration Files:
/etc/bip.conf [Errno 13] Keine Berechtigung: u'/etc/bip.conf'
-- 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#583674: awsetbg: Prefers $wpsetters in wrong order
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, just FYI, this bug might be fixed in version 3.4.6. I'm 90% sure it was fixed by this commit: http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=4ed587206e6f34a7f367653b50e13316a82b3928 That bug was introduced here: http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=650afbb9ad5702df7f80b59ed25201d4056de5a7 Could you verify if this is fixed with 3.4.6? Thanks Cheers, Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJMPd7TAAoJECLkKOvLj8sGgkwIAKAyuixqJVcVVY8puFGUf2dz K0ko0Y6kamk1hbFbAtVrxR4Mzvlf2838yRTGToNtMfZnI/Ydzr1TRQvTv3NLELAU ma4s4t7v9iS2z6qx90wm/hHPzaWnx702ZcU07BFcaoFhtYdBwEVz9HuezjZU6I6w fIjaXXsMZzYonVLDk2FnvEL9Riz6mnTwPuA7ewuVcNYQmKwBvb5WcwUQmnKBOqvQ jaZ+bhErjy+hsL4bEbz0e2ly4ltS8N7yhlv6pIH5Zt8kuuTfQCpNn0vUoT1xA7Nb kbm4rKZ7NjZ6cBKY5YioJPioNa1KDMFDo4KC+Th/vKAzRFPP0GE0YCz/A8hk604= =Htqp -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#552208: Default layout missing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I liked the default layout implicitly being the first one in the list, since it is logical and doesn't require any additional code to express. FYI: The default config was modified so that the first entry in the layouts table is the default layout again[1]. Cheers, Uli [1] http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=3d887f09c626c94e46b0df2e05835989e830044c - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJMPeC3AAoJECLkKOvLj8sG+ekH/1svFndjL2iEIT770J4jZLZM i0WaZTssBcrpxWxVR4Ytwt5grGI/JOMURCs+4+l78YRX0eFWA4uU1K+giWIK26a4 C+O5ljJvPOlV3RTvBkv9BMyJAlUWCW0IQWAjG31JKcZkddt74m/Le39mzTxjPDRw BqRyviImfrLPDX3AY5e465H9MSf00y+bjga5b7oLSJX7EH2KuUGSZrWNGsBmKbVG 4bAiQaTGUwppPmW7IwSjsWUQjj/jILaWIxvH2YUQZLxZ85AG2cyjL7oVBPqynJZl TAKarKRyYDmDNbLdLl67YGFSHKdoCYc22AB3aV20s+uAmQLE08O2MQGLbsIyA6U= =OVBj -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#542709: git-core: unexpectedly dirty index after rebase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 16.05.2010 22:58, Jonathan Nieder wrote: found 542709 git-core/1:1.6.5-1 quit Uli Schlachter wrote: this happened to me the day I wrote the mail to this bug (google found this bug report while I was looking for a solution). [...] /var/log/dpkg.log.3.gz:2010-02-08 15:51:57 status installed git-core 1:1.6.6.1-1 /var/log/dpkg.log.7.gz:2009-10-26 19:55:00 status installed git-core 1:1.6.5-1 Drat. Agh, grasping at straws: . was $GREP_OPTIONS set? (rebase did not protect itself until v1.6.5.5~11^2) Never heard about this variable and certainly didn't set it myself (and it's not currently set). . does your repo track any symbolic links? Nope. . were there any directories whose name was a prefix of a filename, with the next character in the filename being a symbol that is below '/' in ASCII, like a/b/foo directory and a/b/foo-bar file? Uhm, what? Looking at $RANDOM_ASCII_TABLE, only '-' and '.' could really be the reason here. 'find | grep -- -' only lists untracked files (and a single file where there is no suitable directory) '.' is a little more common in file names here, that calls for a oneliner: $ for x in $( git ls-files | sed -e 's:^./::' | grep '\.' | cut -f1 -d.) ; do [ -e $x ] [ 0 != $(git ls-files $x | wc -l) ] echo $x ; done This finds the following directory/file combinations (Omitting stuff like configure / configure.in since configure is not a directory): doxygen/manpages/ doxygen/manpages.cfg oflog/include/dcmtk/oflog/config/ oflog/include/dcmtk/oflog/config.h I don't know if any of these were part of the conflict, but this might well be possible . any submodules? Nope, this is a cvs import via git cvsimport. Everyone else uses cvs. :( Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJL8Sd5AAoJECLkKOvLj8sGNbsIANU2P2PG/+97x1eOa+DqkaLT YeeRrhq0ybFIOR+mmcdq2sy6Mz8mQVQrpPeD1wbd9puTsOvqEibR+GbIknjvcjjh wDeV3eAPJJX0N2jXVhLoh2nlFBw2+jlEjXwV+O5/qLAm1dLbXH6LwSA+awYUEztr Tx2nc05f7Gnbrf100ZlfZzxQbhfdKFwjKp02z+owyfl/IcL7MdgA4HZtc+FuE5Mk vZfbvol1OwkHa8EELJhGjBx3Da7AdPgJ9UOP7zNZbDLxJdVs0xid+VS9o04bfP/2 DKVjnw+QJND+7nBaHUSSg16NqUx6tY/BbjuGuNUOspNEMUs5Rvjy1I4cfkSWla4= =55/K -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#542709: git-core: unexpectedly dirty index after rebase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 15.05.2010 21:36, Jonathan Nieder wrote: Uli, do you know whether you were using a release candidate when you experienced this problem? If you remember when that was, /var/log/dpkg.log would tell. I am asking because this would confirm whether the explanation is sane, since in any release before 1.7.0, ‘git status’ would have refreshed the index[2]. Hi, this happened to me the day I wrote the mail to this bug (google found this bug report while I was looking for a solution). This didn't happen again to me since then. I was running a release before 1.7.0 back then: (Output sorted chronological by hand) $ zgrep git-core /var/log/dpkg.log* | grep ' installed' /var/log/dpkg.log:2010-05-08 10:10:45 status installed git-core 1:1.7.0-1 /var/log/dpkg.log.2.gz:2010-03-01 19:14:50 status installed git-core 1:1.7.0-1 /var/log/dpkg.log.3.gz:2010-02-08 15:51:57 status installed git-core 1:1.6.6.1-1 /var/log/dpkg.log.7.gz:2009-10-26 19:55:00 status installed git-core 1:1.6.5-1 /var/log/dpkg.log.10.gz:2009-07-24 19:04:39 status installed git-core 1:1.6.3.3-2 /var/log/dpkg.log.11.gz:2009-06-30 10:07:59 status installed git-core 1:1.6.3.3-1 /var/log/dpkg.log.12.gz:2009-05-03 12:05:11 status installed git-core 1:1.6.2.4-1 /var/log/dpkg.log.12.gz:2009-05-29 15:39:19 status installed git-core 1:1.6.3.1-1 Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJL7/UMAAoJECLkKOvLj8sGlYMH/0g5E2yeoWvSLSn7RgbJEWB4 RSK6LhaqOfeSEynjYgfzKk7QQJM78w4J/GOUxO22cs3cTEgub6DT0tOoTAaIy8cg TcagpQjnjvW3wBFyCFROqJTP09bu+Kpnn5wasOCvKyUIFFTbcRmlq/vQyrfX9m/n jduXmjD9HiNOgeMq/4O6H1rFRXvBkZH5Hy1Ie9C1gGaZCSixc7emT88sDb5Fig8s gJdIWjeNWFao9xzjt3k7HvoS0Tewa5NCZBu5imO+mWfYsMPv4i5r9CD4Dj01zi0N hLX6xc4GO6IvVIstVmMyZLftm3r1mdXUfDt3K5JD4DDm0z0LmYmABLh3lnypBAI= =03Jv -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#562720: My 5 cents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, bug is kind of reproducible here. When I start an audio/video call, my local pidgin crashes. From the valgrind output I concluded that this is a NULL pointer dereference (EIP points to mov 0x38(%rbp),%rbp and valrgind talks about invalid access to 0x38). Starting from that instruction pointer I tried to figure out where in the source code this might be. I'm pretty sure this is in libpurple/media.c, media_bus_call() before the while loop which checks on !GST_IS_PIPELINE(). This would mean that the msg argument to media_bus_call() would be NULL or GST_IS_PIPELINE() is called with a NULL pointer. (Sorry, I looked into this a while ago and don't remember exactly how I came to his conclusion. There was a function call in objdump -S output to a function which would only be called in GST_IS_PIPELINE() or something like that) I hope this helps someone in debugging this. Cheers, Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJL7qDWAAoJECLkKOvLj8sGthcH/0SMiunn31puNPYtIHpJtMVK VaMEo1WC9IU9BQaCAG4y+2PX/nRbW0K8PPDObP4YwE6hMc9EpLxWFtFxagp84e7o Y7IJT/ajZOepD1PNVcBixAVrS+DSZJ79dCmDVpYo+sE4bHPYf9eXMwps0z9Dw/A4 Q6iCPXY6AbmGofMXMqR+gg4LcI1ylL8jQ2bH2rlxLsTTMZTlyuw9Mfw/w2vqxvRN WSxfwJklXvcWk9UmV1+aje3ZiUqro/D5FL9l2ARiXl4CgnnLswBQ5/+6m4LOCwNK XEUa080pydjc3mzVvSJ4Sp9yXrwesNr04S6K7sNKqQZSp05kYhRGnHQUxrOOCrI= =eyim -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#575835: ABI breakage with libev3 3.9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: libev3 Version: 1:3.9-1 Hi, libev 3.8 had the following definition in ev.h: #define EVFLAG_NOSIGFD0x0020U /* do not attempt to use signalfd */ libev 3.9 now contains: #define EVFLAG_NOSIGFD 0 /* compatibility to pre-3.9 */ #define EVFLAG_SIGNALFD 0x0020U /* attempt to use signalfd */ This means that packages compiled against libev 3.8 that explicitly disable signalfd() instead explicitly enable it when ran with libev 3.9. This obviously can be solved by recompiling the app in question against libev 3.9. I found this via the awesome window manager. When libev uses signalfd, it has to add the signals in question to the signal mask. The signal mask is inherited by child processes which makes everything started from awesome ignore e.g. SIGINT. Cheers, Uli - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLsOk5AAoJECLkKOvLj8sG0WwH/RypdhMmLgChFjETtbexM3WL GkcQYe9Fw0YdWdTYLULOB1sBlnl4UvwuJ+ldOaTrYQQSlXodkE5aJLVHCJsRNcQz q8Ep7cZfLwa8wzNh54XkebgR9igZMtLWfqURoT/I1ZZ+cAWSF9UMpT3Rn3CV6jyb 1aQjzIJGu/iz/gArl3hw/Irans7Jn0Ao6vrZeCbe1+4i4knqqY/qU2t3uBl5W7Zq 54HTNALJHOeojDj3b/maC+OVXHR/FKBdrqjFi8NssgKY/7gzRqco+o+PTWCeYss7 FrOoPwXa8t2sl9OW3USgBz4jhcn17Sszsn+1y5EYyRsz2UivIySMKeiI2i2bSkM= =T1tc -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#571215: Backlight turned off during bootup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 maximilian attems wrote: On Wed, Feb 24, 2010 at 12:58:54PM +0100, Uli Schlachter wrote: This morning when I booted my laptop, right after grub was done, the backlight turned off. I collected the attached info by entering my HDD passphrase blindly and starting up X (which partly worked but was damn slow). Kernel is 2.6.32-trunk-amd64. old, newer one is available in unstable: 2.6.32-8, check against it. Uhm, I might be blind... I installed the following. I'll report back with the results this evening. [AKTUALISIERUNG] linux-image-2.6-amd64 2.6.32+23 - 2.6.32+24 also do you have hotkey-setup installed, please post dpkg -l hotkey-setup Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-===-== ii hotkey-setup0.1-23 auto-configures laptop hotkeys - -- - - Buck, when exactly did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLhTetAAoJECLkKOvLj8sGHr0H/AxR8fFEfXjQh7595yujIBve HoeYEwaBUbkJ9GM4N3D3IHecidR5eRzFtOCl1UAb+gPs6PgWdjMRhDDO43RBaLpq 0FDCJ+/IzD8L0iNK5cA95vFiYlScoKl6a+5SMJMUnTT9xXK6RE1rqyOthfIw6seN rXEAV4leBO+WTXA8ACBunC9xStZjeHyv/tVuLz+tC3FID6qAEHAPCH3bpbINMGCH vq9CyGOW02Yl96mVnIhB3IgVZAuhKDOHMy/3lS+82nn7cduTvsQv028GSRdDNmYt r76Qt2be+NIDREZxyFpk3rtd+Lh5JjIgsbAlVNEEqWK2DpSF6YhqQLu9oqqdOj8= =kwmP -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#571215: Backlight turned off during bootup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 maximilian attems wrote: On Wed, Feb 24, 2010 at 03:29:04PM +0100, Uli Schlachter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 maximilian attems wrote: On Wed, Feb 24, 2010 at 12:58:54PM +0100, Uli Schlachter wrote: This morning when I booted my laptop, right after grub was done, the backlight turned off. I collected the attached info by entering my HDD passphrase blindly and starting up X (which partly worked but was damn slow). Kernel is 2.6.32-trunk-amd64. old, newer one is available in unstable: 2.6.32-8, check against it. Uhm, I might be blind... I installed the following. I'll report back with the results this evening. [AKTUALISIERUNG] linux-image-2.6-amd64 2.6.32+23 - 2.6.32+24 please corret your apt sources or whatever, I spoke about unstable and there you have linux-image-2.6.32-2-amd64 I'm now running this (thanks for the hint with the package name): $ uname -a Linux psytux 2.6.32-2-amd64 #1 SMP Fri Feb 12 00:01:47 UTC 2010 x86_64 GNU/Linux ii hotkey-setup0.1-23 auto-configures laptop hotkeys nuke it and reboot, probably cures your trouble not to have it. Neither of this helped my backlight, but booting with vga=ext as suggested by Marco d'Itri made everything work (and the kernel suddenly starts to notice my second screen...) Julien Cristau wrote: On Wed, Feb 24, 2010 at 12:58:54 +0100, Uli Schlachter wrote: Feb 24 12:34:40 psytux kernel: [0.548357] vesafb: framebuffer at 0x8000, mapped to 0xc9001098, using 5120k, total 5120k Feb 24 12:34:40 psytux kernel: [0.548360] vesafb: mode is 1280x1024x32, linelength=5120, pages=0 Feb 24 12:34:40 psytux kernel: [0.548362] vesafb: scrolling: redraw Feb 24 12:34:40 psytux kernel: [0.548364] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 Feb 24 12:34:40 psytux kernel: [0.588241] Console: switching to colour frame buffer device 160x64 Feb 24 12:34:40 psytux kernel: [0.628004] fb0: VESA VGA frame buffer device [...] Feb 24 12:34:40 psytux kernel: [0.732304] [drm] Initialized drm 1.1.0 20060810 Feb 24 12:34:40 psytux kernel: [0.743618] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 Feb 24 12:34:40 psytux kernel: [0.743622] i915 :00:02.0: setting latency timer to 64 Feb 24 12:34:40 psytux kernel: [0.758588] alloc irq_desc for 29 on node -1 Feb 24 12:34:40 psytux kernel: [0.758592] alloc kstat_irqs on node -1 Feb 24 12:34:40 psytux kernel: [0.758601] i915 :00:02.0: irq 29 for MSI/MSI-X Feb 24 12:34:40 psytux kernel: [0.758608] [drm] set up 63M of stolen space Feb 24 12:34:40 psytux kernel: [1.320148] [drm] TV-20: set mode NTSC 480i 0 Feb 24 12:34:40 psytux kernel: [1.466907] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver Feb 24 12:34:40 psytux kernel: [1.467017] fb1: inteldrmfb frame buffer device Screwed up handoff from vesafb to i915. Should be fixed with today's 2.6.32-9 hopefully. Although really you shouldn't be using vesafb. Uhm, I don't think I'm using vesafb on purpose, am I? My current /proc/cmdline is this: (no idea where I got that video= from) BOOT_IMAGE=//vmlinuz-2.6.32-2-amd64 root=/dev/mapper/psytux-root ro video=i915 quiet vga=ext I'll try 2.6.32-9 once it hits my mirror. Cheers, Uli - -- - - Buck, when exactly did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLhWYrAAoJECLkKOvLj8sG7XQH/1Nir1cpi+fdEf6LLM6ekvMO x5j53+uV3rZvwKbDU4UdOEwetMMQso4qffhAgNvFGwsjKO5skwaEO8YsCt7SB3Qf zARMozNYxaqqo1w6VUap0upI7/rgQsMQoq4EmEJx3TE0ksRpyMiTX6znef/BeM+0 ZWvGv8nKk3u+0YjP0BJae31rVdc9MgbfvqlJM+fHjzZaVPUnZ18gi8o6hUkRXizo zuv8LB3F6EdSrhMLCfd8E42sOfPtGwOcTlfQ8LpsvoKCkkObISn39zt+ahSPIn7Q DlM3gu9iTY9TklgfnfhcpglSv1udAo5lO6vJl62mCi9UkuSPbtWW/dGY4aPSImc= =Bre8 -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#542709: I saw this bug too
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I just saw something like this, too. After git rebase I got tons of conflicts, I fixed them up and git add'ed each file, but git rebase --continue just showed me the message the message above. (git status didn't report any unmerged files) With some googling I found git diff-files which gave me a file name. After also merging this file and git add'ing it, git rebase --continue worked. @Ximin Luo: Is it possible that you just missed a file, too, because 'git status' didn't list it? Cheers, Uli - -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLA/qdAAoJECLkKOvLj8sGSCIIAL8SynjFbQamBAHjW7ypBscI O+tCf2h8sFqNEntaqWbY2ZTMDh1VzWvgMUscGrZ9Q79+o3J8v/WqeLKGujT3WhBb naiK4okCcRQFYOCkRV/RjQto8JTezPnzhLQ382C+qZOzTg3jUIlca8aHJ3KdOMiQ iIbdi48WtZxP6f0Gb+kQo9f4ubYvLn2N9nEp/SZrzKxxSF8BSGVg/MfPcXUuWEZJ R6jeEg7c7SZh9x4i//GgqdU0tQ7aDgv64/NgvQMLM9EzIclwmrmTUge/KXuDPJcz Cd/jjTVbCv6Rc5Wn+eTQGR6ayFVNZ1pIg0Tt9ZY5CYElreMhJrjUEpSRG4zu3Ps= =VvXJ -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#516950: znc 0.066 privilege escalation when using webadmin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: znc Version: 0.045-3+etch1 Tags: Security Severity: critical All ZNC versions which have webadmin contain a privilege escalation bug in webadmin. This bug was fixed with znc 0.066. A quote from the changelog[1]: Webadmin doesn't properly validate user input. If you send a manipulated POST request to webadmin's edit user page which includes newlines in e.g. the QuitMessage field, this field will be written unmodified to the config. This way you can add new lines to znc.conf. The new lines will not be parsed until the next rehash or restart. This can be done with nearly all input fields in webadmin. Because every user can modify himself via webadmin, every user can exploit this bug. [1] http://en.znc.in/wiki/ChangeLog/0.066 - -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmkLHQACgkQABixOSrV998/+gCePRf5EmG7t1+lztdsr+tE3m+3 jJsAoJwhjz7YdyvoLGjRyRSfCdNSClSh =Hoee -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
