Bug#1024342: /etc/X11/Xsession.d/90x11-common_ssh-agent: ssh-agent missing on second log-in
Package: x11-common Version: 1:7.7+23 Severity: normal File: /etc/X11/Xsession.d/90x11-common_ssh-agent Dear Maintainer, When logging out of Cinnamon and back in, I don't have ssh-agent running any more. Several current desktop environments persist environment variables across logins, so that on a logout followed by a login these variables are available. I have found code for doing so in Gnome [1] and Cinnamon [2]. The X11 ssh-agent session startup script checks [ -z "$SSH_AUTH_SOCK" ] as a precondition for launching ssh-agent [3]. So when taken together, the first login will launch ssh-agent, then save environment variables to dbus. The next session will be initialized with these environment variables (presumably something systemd does, haven't checked) and will therefore skip launching ssh-agent, despite the fact that the previous agent got terminated at shutdown of the first session. One possible solution to this would be to replace [ -z "$SSH_AUTH_SOCK" ] with [ ! -S "$SSH_AUTH_SOCK" ], i.e. to check that the environment variable is not only set but actually refers to a socket. That way, when ssh-agent for the first session terminates, the socket will get closed and the next session will launch its own agent despite the fact that the environment variable got persisted. An alternative might be to also inspect SSH_AGENT_PID, and when it's set and doesn't refer to a running process then that could also be taken as in indication that a new agent is needed. I can't think of a reasonable scenario that would warrant such a complex approach; I'd think that the solution in the previous paragraph should be enough, but if I'm missing some legitimate use case where the environment variable would be set before the agent gets launched, then the PID might offer a viable and even safer alternative. Personally I'm not a fan of environment variables getting persisted in this fashion, but given that it is default behavior in multiple desktop environments, and probably there for a reason, I think it makes sense to cater for it in the script. The benefits should outweigh potential drawbacks in weird corner cases. My current workaround, based on [4], is having this in my ~/.xsessionrc: if [ -n "$SSH_AUTH_SOCK" ] && [ ! -S "$SSH_AUTH_SOCK" ]; then unset SSH_AUTH_SOCK unset SSH_AGENT_PID fi [1] https://salsa.debian.org/gnome-team/gnome-session/-/blob/81c88fa3485949f8c7ea12e68d07e8060d368e79/gnome-session/gsm-util.c#L544-707 [2] https://salsa.debian.org/cinnamon-team/cinnamon-session/-/blob/255fd6600dfafe131ca3247d641fdd64098f7f47/cinnamon-session/csm-util.c#L569-715 [3] https://salsa.debian.org/xorg-team/xorg/-/blob/d6af3f0a48de41f74069a8befc4fe9ca0fcd0118/debian/local/Xsession.d/90x11-common_ssh-agent#L10 [4] https://utcc.utoronto.ca/~cks/space/blog/linux/Fedora26CinnamonSSHAgent -- System Information: Debian Release: rodete Architecture: amd64 (x86_64) Foreign Architectures: i386 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages x11-common depends on: ii lsb-base 11.2 x11-common recommends no packages. x11-common suggests no packages. -- no debconf information
Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure
Similar here. Had been getting error messages about missing PV during boot for a while, but since everything worked fine once booted I didn't bother to resolve that. Now I started getting boot errors instead. Turns out the initramfs was missing a module (pata_atiixp) needed for the controller for that PV. Working this out required time, and until that point I could only boot previous kernel & initramfs (which required navigating grub menu so no headless boots) and I didn't dare upgrade anything. https://salsa.debian.org/lvm-team/lvm2/-/commit/2340adad4b3875331be1ba7abba881cc1b6e6738 for 2.03.15-1 appears to be the relevant commit here causing this change in behavior. Probably has something to do with the --autoactivation flag which I don't see documented on https://manpages.debian.org/testing/lvm2/vgchange.8.en.html. It probably makes sense for udev to wait for all PVs before activation *if* the PV can be expected to turn up eventually. During boot, falling back to degraded activation after some timeout might be beneficial, in particular to resolve situations where the extra PVs need later boot steps to become available. The man page describes --activationmode but according to comments in my (unedited) /etc/lvm/lvm.conf that setting is "degraded" by default and should thus be able to work with absent PVs. Particularly since I currently don't even have any LVs on the absent PV. But perhaps --autoactivation trumps that default? If you would like to get more data on why things behave differently, I can probably restore a reproducing setup easily enough and can then execute commands in the initramfs console to debug further. Steps that helped me fix the problem: 1. "lvm pvs" from the initramfs fallback prompt to see the missing PV 2. "lvm pvs" when booted from previous initramfs to see what device that is, sdc1 in my case 3. "udevadm info -a -n /dev/sdc1 | grep -E 'looking|DRIVER'" to find the driver needed for it 4. "$EDITOR /etc/initramfs-tools/modules" to add the module there 5. "update-initramfs -u -k 5.18.0-4-amd64" to build a new initramfs with that module included
Bug#947813: SIGSEGV resulting from mesa dri2_add_config dealing poorly with invalid attrib
My issue appears to be largely due to a version mismatch, and I have been able to resolve this. I had tried to get a specific version from unstable to test a fix for a different bug, but apparently I misunderstood how pinning works and got updates to mesa packages from the unstable release even after the version for which I intended this. Once I downgraded mesa packages to testing version, I was able to start X again. I'll leave it to you whether you believe this kind of issue is worth addressing at the distro level (perhaps via more strict version dependencies?) or forwarding to the upstream maintainers (so that unexpected behavior from a module library gets detected in a nicer fashion than by crashing the X server). If you decide to just close this bug, that's fine with me, too. In that case sorry for the noise. $ cat /etc/apt/preferences.d/mesa.pref Explanation: test fix for #933906 Package: *mesa* Pin: release a=unstable Version: 19.1.4-1 Pin-Priority: 600 $ dpkg -l '*mesa*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---=> ii libegl-mesa0:amd64 19.2.6-1 amd64free implementation of the EGL API -- Mesa vendor library ii libegl-mesa0-dbgsym:amd64 19.2.6-1 amd64debug symbols for libegl-mesa0 ii libegl1-mesa:amd64 19.3.1-3 amd64 transitional dummy package ii libgl1-mesa-dri:amd64 19.3.1-3 amd64free implementation of the OpenGL API -- DRI modules ii libgl1-mesa-dri-dbgsym:amd6419.3.1-3 amd64debug symbols for libgl1-mesa-dri un libgl1-mesa-glx (no description available) un libgl1-mesa-swx11 (no description available) ii libglapi-mesa:amd64 19.3.1-3 amd64free implementation of the GL API -- shared library ii libglapi-mesa-dbgsym:amd64 19.3.1-3 amd64debug symbols for libglapi-mesa un libgles2-mesa (no description available) ii libglu1-mesa:amd64 9.0.1-1 amd64Mesa OpenGL utility library (GLU) ii libglx-mesa0:amd64 19.3.1-3 amd64free implementation of the OpenGL API -- GLX vendor libra> un libwayland-egl1-mesa (no description available) un mesa-opencl-icd (no description available) un mesa-utils(no description available) ii mesa-va-drivers:amd64 19.3.1-3 amd64Mesa VA-API video acceleration drivers ii mesa-vdpau-drivers:amd6419.3.1-3 amd64Mesa VDPAU video acceleration drivers ii mesa-vdpau-drivers-dbgsym:amd64 19.3.1-3 amd64debug symbols for mesa-vdpau-drivers ii mesa-vulkan-drivers:amd64 19.3.1-3 amd64Mesa Vulkan graphics drivers un mesag3(no description available) un xlibmesa3 (no description available)
Bug#947813: SIGSEGV resulting from mesa dri2_add_config dealing poorly with invalid attrib
Package: libegl-mesa0 Version: 19.2.6-1 It seems dri2_add_config is encountering some invalid values causing memory corruption and subsequent SIGSEGV at X server startup. The stack trace written to the Xorg log isn't too useful, so I ran X under gdb with debug symbols installed, and copied relevant portions below. The way I read the results from that, for i==24 I get attrib==__DRI_ATTRIB_MAX(=50). So dri2_add_config will enter the default case in egl_dri2.c:319, call the inlined _eglSetConfigKey for some invalid key for which _eglOffsetOfConfig returns its default of -1 (as seen in %rdx). The assertion of a positive offset apparently is disabled in my build. This clobbers some bytes of the display pointer in the base data structure, which will lead to invalid access later on, e.g. during _eglValidateConfig. I haven't been able to work out where the invalid attrib is coming from. I don't know where dri2_dpy->core->indexConfigAttrib is implemented. (gdb) break dri2_add_config Breakpoint 1 at 0x7fffecce8a40: file ../src/egl/drivers/dri2/egl_dri2.c, line 221. ⋮ Thread 1 "Xorg" hit Breakpoint 1, dri2_add_config (disp=disp@entry=0x55891220, dri_config=0x5585ab90, id=id@entry=1, surface_type=surface_type@entry=4, attr_list=attr_list@entry=0x7fffe2e4, rgba_masks=rgba_masks@entry=0x0) at ../src/egl/drivers/dri2/egl_dri2.c:221 221 ../src/egl/drivers/dri2/egl_dri2.c: No such file or directory. ⋮ [step past _eglInitConfig call] (gdb) watch base.Display Hardware watchpoint 2: base.Display (gdb) c Continuing. Thread 1 "Xorg" hit Hardware watchpoint 2: base.Display Old value = (_EGLDisplay *) 0x55891220 New value = (_EGLDisplay *) 0x5500 dri2_add_config (disp=disp@entry=0x55891220, dri_config=0x5585ab90, id=id@entry=1, surface_type=surface_type@entry=4, attr_list=attr_list@entry=0x7fffe2e4, rgba_masks=rgba_masks@entry=0x0) at ../src/egl/drivers/dri2/egl_dri2.c:239 239 in ../src/egl/drivers/dri2/egl_dri2.c (gdb) bt surface_type=surface_type@entry=4, attr_list=attr_list@entry=0x7fffe2e4, rgba_masks=rgba_masks@entry=0x0) at ../src/egl/drivers/dri2/egl_dri2.c:239 #1 0x7fffeccef239 in drm_add_configs_for_visuals (drv=0x7fffe370, disp=0x55891220) at ../src/egl/drivers/dri2/platform_drm.c:640 #2 dri2_initialize_drm (drv=drv@entry=0x55891d00, disp=disp@entry=0x55891220) at ../src/egl/drivers/dri2/platform_drm.c:761 #3 0x7fffecce894b in dri2_initialize (disp=0x55891220, drv=0x55891d00) at ../src/egl/drivers/dri2/egl_dri2.c:911 #4 dri2_initialize (drv=0x55891d00, disp=0x55891220) at ../src/egl/drivers/dri2/egl_dri2.c:876 #5 0x7fffecce4b9d in _eglMatchAndInitialize (disp=disp@entry=0x55891220) at ../src/egl/main/egldriver.c:75 #6 0x7fffecce4be6 in _eglMatchDriver (disp=disp@entry=0x55891220) at ../src/egl/main/egldriver.c:96 #7 0x7fffeccdf188 in eglInitialize (dpy=0x55891220, major=0x0, minor=0x0) at ../src/egl/main/eglapi.c:617 #8 0x7621d292 in glamor_egl_init (scrn=scrn@entry=0x557ff150, fd=) at ../../../../../../glamor/glamor_egl.c:927 #9 0x77fbd183 in try_enable_glamor (pScrn=0x557ff150) at ../../../../../../../hw/xfree86/drivers/modesetting/driver.c:769 #10 PreInit (pScrn=0x557ff150, flags=) at ../../../../../../../hw/xfree86/drivers/modesetting/driver.c:996 #11 0x555ef814 in InitOutput (pScreenInfo=pScreenInfo@entry=0x557c37c0 , argc=argc@entry=1, argv=argv@entry=0x7fffe6a8) at ../../../../../../hw/xfree86/common/xf86Init.c:522 #12 0x555b2714 in dix_main (argc=1, argv=0x7fffe6a8, envp=) at ../../../../dix/main.c:193 #13 0x76ed3bbb in __libc_start_main (main=0x5559c710 , argc=1, argv=0x7fffe6a8, init=, fini=, rtld_fini=, stack_end=0x7fffe698) at ../csu/libc-start.c:308 #14 0x5559c74a in _start () (gdb) disas Dump of assembler code for function dri2_add_config: 0x7fffecce8a40 <+0>: push %r15 0x7fffecce8a42 <+2>: push %r14 0x7fffecce8a44 <+4>: push %r13 0x7fffecce8a46 <+6>: push %r12 0x7fffecce8a48 <+8>: mov%rsi,%r12 0x7fffecce8a4b <+11>: mov%rdi,%rsi 0x7fffecce8a4e <+14>: push %rbp 0x7fffecce8a4f <+15>: xor%ebp,%ebp 0x7fffecce8a51 <+17>: push %rbx 0x7fffecce8a52 <+18>: lea0x15b7f(%rip),%rbx# 0x7fffeccfe5d8 0x7fffecce8a59 <+25>: sub$0x118,%rsp 0x7fffecce8a60 <+32>: mov0x70(%rdi),%r15 0x7fffecce8a64 <+36>: mov%rdi,(%rsp) 0x7fffecce8a68 <+40>: lea0x44(%rsp),%r14 0x7fffecce8a6d <+45>: lea0x40(%rsp),%r13 0x7fffecce8a72 <+50>: mov%edx,0x3c(%rsp) 0x7fffecce8a76 <+54>: mov%ecx,0x14(%rsp) 0x7fffecce8a7a <+58>: mov%r8,0x20(%rsp) 0x7fffecce8a7f <+63>: mov%r9,0x28(%rsp) 0x7fffecce8a84 <+68>: mov%fs:0x28,%rax 0x7fffecce8a8d <+77>: mov%rax,0x108(%rsp)
Bug#933667: sagemath: FTBFS in sid
Build log from https://launchpad.net/ubuntu/+source/sagemath/8.6-6build1/+build/17348800 shows SIGSEGV in sage.libs.gap.util.initialize. That makes this a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932367 I believe. Merge?
Bug#932367: GAP_Initialize signature changed
Instead of fixing GAP by backporting an upstream commit, we might also consider updating sagemath to include said commit. The first release to contain that is 8.8. I started https://salsa.debian.org/science-team/sagemath/merge_requests/12 in the hope that it helps getting that upgrade off the ground.
Bug#932367: GAP_Initialize signature changed
I tried locally rebuilding sagemath against GAP 4r10p2-2. It seems we need https://github.com/sagemath/sage/commit/e6e80bfa0f36688904716f93e04ad0121b7a4136.patch to account for changes to the GAP_Initialize signature from https://github.com/gap-system/gap/commit/5dad0ef01e5527d83d7ade6677891b855381aee3 and https://github.com/gap-system/gap/commit/eab71117db3a3afd1adec9a87e96b3b4a9414f60. Unfortunately the patch doesn't apply cleanly, and I don't have time just now to massage it. So I'm sending what information I have in case someone else can cherry-pick it in. Without this, I get a SIGSEGV when loading sage.libs.gap.libgap because the address of a data structure (the old env argument) is treated as a function pointer that gets called during garbage collection. The error doesn't stop the build at that point, but it causes the documentation build to hang indefinitely eventually, similar to bug #901532. Check sage/logs/dochtml.log for the actual problem report.
Bug#716104: [wdiff-bugs] mdiff crashes with exit status 139
Hello. Sorry for this late reply. On 05.07.2013 11:32, Santiago Vila wrote: I've received a report from The Mayhem Team, Cylab, Carnegie Mellon University. [...] Simplified as much as possible, this is the bug: $ mdiff --expand- mdiff: ignoring option --tolerance (not implemented) Segmentation fault I have not packaged wdiff 1.2.1 for Debian yet, but the bug may be reproduced there as well. Thank you for the report. The issue is indeed present in 1.2.1. It is due to a conflict in short option letters. I just committed a fix for this, but don't intend to roll a new release just for this single fix in an obscure option to an experimental binary. 1.2.2 will see this fixed but may take some time, e.g. until another translation comes in. I would advise Debian to not include the --enable-experimental option in the configure call for this package. The code for those parts receives too little attention to be let loose on the masses, imho. That is the reason why I don't enable building those parts by default. Greeings, Martin signature.asc Description: OpenPGP digital signature
Bug#649515: [9a19418] Fix committed to git
On 02.06.2012 14:50, Mario 'BitKoenig' Holbe wrote:
This would, btw., also enable the script to use plain /bin/sh rather
than depending on bash.
As far as I can tell, there is nothing specific to bash about this.
Compare sections 2.9.3 and 2.9.4 of the Shell and Utilities part of
the POSIX.1-2008 standard.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
Both || and { …; } are defined there, so any POSIX shell should work.
But that doesn't change the fact that the syntax you propose would be
easier to read and maintain.
Greetings,
Martin
signature.asc
Description: OpenPGP digital signature
Bug#649515: [9a19418] Fix committed to git
On 12.05.2012 12:57, Giuseppe Iuculano wrote: You can check the diff of the fix at: http://git.debian.org/?p=collab-maint/smartmontools.git;a=commitdiff;h=9a19418 The fix is incorrect for two reasons. bash requires the space after the opening curly brace, otherwise it will consider it a word for brace expansion instead of the beginning of a command list. This isn't perfectly clear from the bash docs, but a simple example on the command line will clearly exhibit that problem. bash also requires a final semicolon to end the list of commands. That fact has been explicitely stated in bash docs. A space after that appears to be optional, but for reasons of symmetry I'd add one as well. I suggest you improve the fix accordingly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649515: /etc/smartmontools/run.d/10mail has broken check for /usr/bin/mail
Package: smartmontools
Version: 5.41+svn3365-1
The file /etc/smartmontools/run.d/10mail contains the following line:
[ -x /usr/bin/mail ] || (echo [...] ; exit 0)
The exit 0 is inside a subshell, so it will only exit that subshell.
As a result, the whole script will still continue, and still attempot to
run /usr/bin/mail even if it doesn't exist. Not a real problem, I think,
but in that case one might as well omit the check line. A better
solution would be using curly braces instead of the parentheses:
[ -x /usr/bin/mail ] || { echo [...] ; exit 1; }
Should work well enough.
signature.asc
Description: OpenPGP digital signature
Bug#649448: udev loading radeon drivers garbles screen output
? If there is any additional information I can provide, please let me know. Greetings, Martin von Gagern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649448: udev loading radeon drivers garbles screen output
On 21.11.2011 02:02, Jonathan Nieder wrote: Yes, the radeon driver currently copes poorly when firmware is missing. Compare [1], [2], [3]. [1] http://bugs.debian.org/607194 [2] http://bugs.debian.org/637943 [3] http://bugs.debian.org/627497 [2] sounds a lot like what I see. Thanks for reporting it. If you can (for example by ssh-ing in), please attach full output from dmesg Here you go, everything after the modprobe: [ 380.238466] [drm] Initialized drm 1.1.0 20060810 [ 380.274651] [drm] radeon defaulting to kernel modesetting. [ 380.274654] [drm] radeon kernel modesetting enabled. [ 380.274692] radeon :00:01.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 380.274696] radeon :00:01.0: setting latency timer to 64 [ 380.274851] [drm] initializing kernel modesetting (SUMO2 0x1002:0x9644 0x1849:0x9640). [ 380.275171] [drm] register mmio base: 0xFEB0 [ 380.275173] [drm] register mmio size: 262144 [ 380.275320] ATOM BIOS: General [ 380.275348] radeon :00:01.0: VRAM: 32M 0x - 0x01FF (32M used) [ 380.275351] radeon :00:01.0: GTT: 512M 0x0200 - 0x21FF [ 380.275357] mtrr: type mismatch for fc00,200 old: write-back new: write-combining [ 380.275360] [drm] Detected VRAM RAM=32M, BAR=32M [ 380.275361] [drm] RAM width 32bits DDR [ 380.275532] [TTM] Zone kernel: Available graphics memory: 2002580 kiB. [ 380.275535] [TTM] Initializing pool allocator. [ 380.275563] [drm] radeon: 32M of VRAM memory ready [ 380.275565] [drm] radeon: 512M of GTT memory ready. [ 380.275581] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 380.275582] [drm] Driver supports precise vblank timestamp query. [ 380.275618] radeon :00:01.0: irq 55 for MSI/MSI-X [ 380.275623] radeon :00:01.0: radeon: using MSI. [ 380.275656] [drm] radeon: irq initialized. [ 380.275661] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 380.276516] [drm] Loading SUMO2 Microcode [ 380.296057] r600_cp: Failed to load firmware radeon/SUMO2_pfp.bin [ 380.296099] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 380.296134] radeon :00:01.0: disabling GPU acceleration [ 380.297203] radeon :00:01.0: 880114d75400 unpin not necessary [ 380.297205] radeon :00:01.0: 880114d75400 unpin not necessary [ 380.297229] failed to evaluate ATIF got AE_BAD_PARAMETER [ 380.297411] [drm] Radeon Display Connectors [ 380.297413] [drm] Connector 0: [ 380.297414] [drm] DVI-D [ 380.297415] [drm] HPD2 [ 380.297417] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 380.297419] [drm] Encoders: [ 380.297420] [drm] DFP2: INTERNAL_UNIPHY2 [ 380.297422] [drm] Connector 1: [ 380.297423] [drm] DVI-D [ 380.297424] [drm] HPD1 [ 380.297426] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 380.297427] [drm] Encoders: [ 380.297428] [drm] DFP1: INTERNAL_UNIPHY2 [ 380.776030] [drm] Radeon display connector DVI-D-1: No monitor connected or invalid EDID [ 380.830275] [drm] Radeon display connector DVI-D-2: Found valid EDID [ 380.830311] [drm] Internal thermal controller without fan control [ 380.830348] [drm] radeon: power management initialized [ 380.985119] [drm] fb mappable at 0xFC04 [ 380.985120] [drm] vram apper at 0xFC00 [ 380.985122] [drm] size 1892352 [ 380.985123] [drm] fb depth is 8 [ 380.985124] [drm]pitch is 1792 [ 380.985182] fbcon: radeondrmfb (fb0) is primary device [ 381.003344] Console: switching to colour frame buffer device 210x65 [ 381.004682] fb0: radeondrmfb frame buffer device [ 381.004683] drm: registered panic notifier [ 381.004690] [drm] Initialized radeon 2.10.0 20080528 for :00:01.0 on minor 0 and from /usr/share/bug/xserver-xorg-video-radeon/script 31 after reproducing the problem. No xorg installed on that machine, and I'd like to keep it that way. Greetings, Martin signature.asc Description: OpenPGP digital signature
Bug#553490: [wdiff-bugs] Bug#553490: wdiff: Does not handle UTF-8 properly (fwd)
Dear Santiago, Dear Josh, I've already noticed that bug in your bug tracker, and added it to the wdiff bug tracker at Savannah: https://savannah.gnu.org/bugs/?34224 Right now, I'm not sure how best to handle this case. Unicode support is a big problem for the current wdiff implementation, in many ways. For example, I guess that the most sensible way to really simulate overstrike printing would be detecting grapheme clusters, i.e. even treat sequences ofmultiple code points as a single entity if some of the codepoints are combining. http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries has the details on this, but I don't think I'll implement this in wdiff myself. I've been toying with the idea of writing wdiff up from scratch with stuff like this in mind, using ICU break iterators or similar. Won't happen too soon, though. I'm also not sure what versions of less are behaving in what ways. For one, I doubt that all of them will know about grapheme clusters when reading their input, so they might fail to turn it back into character attributes as expected. I also think that most less implementations these days will handle terminal control codes just fine, particularly if called as less -R. So that overstriking thing might be obsolete in any case. Therefore I hope to roll a release soon which will pass terminal control sequences to less, thus avoiding that overstrike stuff. I'll have to give a bit more thought to the best combination of configure switches, environment variables and command line options, though. Greetings, Martin von Gagern signature.asc Description: OpenPGP digital signature
Bug#543992: automake and /usr/share/info/dir.gz
Ignorant questions: do distributions other than Debian take care of running install-info automatically, too? Gentoo portage removes dir files from package DESTDIR: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=bin/misc-functions.sh;h=46be5011cebd20945de34839f48686f8a6fa346e;hb=2ac37d36a1a265654860e9f509f6bcf420a8e734#l675 When the package is installed on a system, install-info is called again: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=pym/_emerge/main.py;h=912fab51b7346367ee6f5a46f4ae6a613f73b09e;hb=2ac37d36a1a265654860e9f509f6bcf420a8e734#l166 The rpm 4.8.1 sources seem to have some mandrake-specific macros for install-info commands in the platform.in file: http://www.google.com/codesearch?q=install_info+file%3Aplatform.in These macros can be called post installation or pre uninstall to call install-info. Haven't figured where they get rid of their dir entries, though, as I don't have an RPM-based system at my disposal. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509116: Cross references
Hi there. Some cross references: http://article.gmane.org/gmane.comp.web.fastcgi.devel/1167 Good analysis of the issue. Contains patch. From 2005. No reply. https://bugs.launchpad.net/ubuntu/+source/libapache-mod-fastcgi/+bug/381384 Same bug as this one here but in Ubuntu. I wrote a lengthy text there. http://thread.gmane.org/gmane.comp.web.fastcgi.devel/2613 Recent upstream thread providing a different patch and mentioning a commit as well as a snapshot version containing said change. So there is some information as to what went wrong, and there are several patches to fix it, one of them even incorporated upstream. I've also written to the fastcgi-developers mailing list, mentioning the references quoted above (and this Debian bug report here) and asking when a release containing the fix is to be expected. As I'm not subscribed to that list, my post is still awaiting moderator approval. Greetings, Martin signature.asc Description: OpenPGP digital signature
Bug#495224: Show error messages from c_rehash
Package: ca-certificates Version: 20080809 Severity: minor In https://bugs.gentoo.org/show_bug.cgi?id=234816 I encountered problems with openldap, caused by broken symlinks in /etc/ssl/certs. Gentoo also uses update-ca-certificates to manage that directory. That script calls c_rehash, which would have reported the issue, but all output from c_rehash is redirected to /dev/null, including all error messages. I suggest showing the error messages, so that admins are more likely to notice possible problems with their certificates. I already submitted a patch for this as https://bugs.gentoo.org/attachment.cgi?id=162959 for Gentoo, but as the issue probably affects all users of ca-certificates, I think you might want to address it at the source. diff -ur ca-certificates-20080809/sbin/update-ca-certificates ca-certificates/sbin/update-ca-certificates --- ca-certificates-20080809/sbin/update-ca-certificates +++ ca-certificates/sbin/update-ca-certificates @@ -83,7 +83,7 @@ # only run if set of files has changed if [ $verbose = 0 ]; then -c_rehash . /dev/null 21 +c_rehash . /dev/null else c_rehash . fi Greetings, Martin von Gagern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
