Bug#338637: slay: turns into a fork-bomb when used as non-root
Package: slay Version: 2.5 Severity: normal Tags: patch If, as user "kilobyte" I try to "slay kilobyte", instead of the expected behaviour slay will instead keep forking "$0 -KILL kilobyte". Patch: - # Misuse trap. - if [ "$USER" != "$1" ] - then + # Misuse trap. + if [ "$USER" != "$SLAYEE" ] + then -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages slay depends on: ii debconf 1.4.59 Debian configuration management sy slay recommends no packages. -- debconf information: * slay/butthead: true * slay/punish: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345480: xserver-xorg: vt switch changes console size to COLSx25
Package: xserver-xorg
Version: 6.9.0.dfsg.1-1
Severity: normal
I use a console size bigger than 80x25, and when I switch vt to a text
console, the kernel's idea (ie, TIOC{S,G}WINSZ) about the console height
gets set to 25, without touching the width. That is, if you use 100x40,
the size will be set to 100x25. Somehow, if X gets killed and restarted,
everything works ok until the next boot. "stty rows 40" helps until the
next switch to X and back, re-running SVGATextMode helps until the next
boot.
This behavior (working ok after X is killed and then restarted) reminds me
of a past bug which happened only with the nvidia-proprietary driver;
however, in that case it was the video mode was changed instead of the
kernel's idea; re-running SVGATextMode didn't help until after killing X
for the first time.
Here, changing display driver (nvidia, nv) doesn't change anything. I
don't have any other non-headless Debian boxes at hand so I can't check
if this happens on different hardware as well.
Setting BorderColor in /etc/TextConfig will affect lines 26..40, filling
them with the border color.
-- Package-specific info:
Contents of /var/lib/xfree86/X.roster:
xserver-xorg
/etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum.
X server symlink status:
lrwxrwxrwx 1 root root 17 Oct 7 20:42 /etc/X11/X -> /usr/bin/X11/Xorg
-rwxr-xr-x 1 root root 1852284 Dec 29 08:38 /usr/bin/X11/Xorg
Contents of /var/lib/xfree86/xorg.conf.roster:
xserver-xorg
VGA-compatible devices on PCI bus:
:01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX
5200] (rev a1)
/etc/X11/xorg.conf does not match checksum in /var/lib/xfree86/xorg.conf.md5sum.
Xorg X server configuration file status:
-rw-r--r-- 1 root root 3282 Dec 31 21:38 /etc/X11/xorg.conf
Contents of /etc/X11/xorg.conf:
# xorg.conf (Xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following commands as root:
#
# cp /etc/X11/xorg.conf /etc/X11/xorg.conf.custom
# md5sum /etc/X11/xorg.conf >/var/lib/xfree86/xorg.conf.md5sum
# dpkg-reconfigure xserver-xorg
Section "Files"
FontPath"unix/:7100"# local font server
# if the local font server has problems, we can fall back on these
FontPath"/usr/lib/X11/fonts/misc"
FontPath"/usr/lib/X11/fonts/cyrillic"
FontPath"/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath"/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath"/usr/lib/X11/fonts/Type1"
FontPath"/usr/lib/X11/fonts/CID"
FontPath"/usr/lib/X11/fonts/100dpi"
FontPath"/usr/lib/X11/fonts/75dpi"
EndSection
Section "Module"
Load"dbe"
Load"ddc"
Load"dri"
Load"extmod"
Load"freetype"
Load"glx"
Load"int10"
Load"record"
Load"type1"
Load"v4l"
Load"vbe"
EndSection
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "keyboard"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "pl"
EndSection
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device""/dev/input/mice"
Option "Protocol" "ImPS/2"
Option "Emulate3Buttons" "false"
Option "ZAxisMapping" "4 5"
EndSection
Section "Device"
Identifier "nVidia Corporation NV34 [GeForce FX 5200]"
Driver "nvidia"
BusID "PCI:1:0:0"
Option "RenderAccel" "true"
Option "backingstore" "true"
Option "NoLogo" "true"
Option "AllowGLXWithComposite" "true"
EndSection
Section "Monitor"
Identifier "Generic Monitor"
Option "DPMS"
HorizSync 30-70
VertRefresh 50-160
EndSection
Section "Screen"
Identifier "Default Screen"
Device "nVidia Corporation NV34 [GeForce FX 5200]"
Monitor "Generic Monitor"
DefaultDepth24
SubSection "Display"
Depth 1
Modes "1024x768" "" "800x600" "" "640x480"
End
Bug#334526: already present in the "udev" package
The rule is already in /etc/udev/permissions.rules: udev (0.071-1) unstable; urgency=low * permissions.rules: added fuse group fuse. (Closes: #334439) -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334639: patch
udev can create /dev/fuse itself, so this patch does it only if udev is not in use. A device in /dev/.static/dev/ is created anyway, though, otherwise fuse would be broken if the user uninstalled udev. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped)diff -urd fuse-2.4.0/debian/fuse-utils.postinst fuse-2.4.0.new/debian/fuse-utils.postinst --- fuse-2.4.0/debian/fuse-utils.postinst 2005-10-29 17:11:34.370704720 +0200 +++ fuse-2.4.0.new/debian/fuse-utils.postinst 2005-10-29 17:25:10.989559784 +0200 @@ -58,6 +58,19 @@ set_option FUSE_GROUPDELETE $RET chmod 0644 $CONFFILE + +if [ -d /dev/.static/dev ] + then + device="/dev/.static/dev/fuse" + else + device="/dev/fuse" +fi +if [ ! -c "$device" ] + then +mknod -m 0660 "$device" c 10 229 +chown root:$NEWGROUP "$device" +fi + ;; abort-upgrade|abort-remove|abort-deconfigure) diff -urd fuse-2.4.0/debian/fuse-utils.postrm fuse-2.4.0.new/debian/fuse-utils.postrm --- fuse-2.4.0/debian/fuse-utils.postrm 2005-10-29 17:11:34.371704568 +0200 +++ fuse-2.4.0.new/debian/fuse-utils.postrm 2005-10-29 17:22:15.922174072 +0200 @@ -16,6 +16,15 @@ test -x /usr/bin/ucf && ucf --purge $CONFFILE rm -f $CONFFILE dpkg-statoverride --remove /usr/bin/fusermount 2>/dev/null || true + +if [ -d /dev/.static/dev ] + then + device="/dev/.static/dev/fuse" + else + device="/dev/fuse" +fi +rm -rf "$device" + ;; failed-upgrade|upgrade)
Bug#340782: Still not working
> I have the directory /dev/.udevdb/ but not /dev/.udev/db/ My fault, there is a missing mkdir (workaround: mkdir /dev/.udev/ and retry). It will still fail on: mv /dev/.udevdb/ /dev/.udev/db/ Should be: mv /dev/.udevdb /dev/.udev/db I guess you probably noticed and/or fixed this, but since I can't find the new deb in incoming yet, I'll better point this issue out. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306380: leafnode: postinst adds spurious lines to /etc/inetd.conf
Package: leafnode Version: 1.11.0.rel-1 Severity: normal Every time postinst is called (including upgrades), a new entry is added to /etc/inetd.conf. update-inetd will catch this problem, and ask the following question: ,- | Setting up leafnode (1.11.0.rel-1) ... | | WARNING!! /etc/inetd.conf contains multiple entries for | the `nntp' service. You're about to disable these entries. | Do you want to continue? [n] `- Upon answering "n" (default), you'll be left to deal with the problem yourself, upon answering "y", update-inetd will make sure only one entry is enabled, leaving older ones disabled. This will cause cruft to accumulate. The extra configure-time question will also break hands-off installs/upgrades. Regards, 1KB -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages leafnode depends on: ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libpcre34.5-1.1 Perl 5 Compatible Regular Expressi ii logrotate 3.7-2Log rotation utility ii netbase 4.21 Basic TCP/IP networking system ii tcpd7.6.dbs-8Wietse Venema's TCP wrapper utilit -- debconf information: leafnode/expireinfo: leafnode/purge: false * leafnode/update-groups: false * leafnode/network: permanent * leafnode/server: news.tpi.pl leafnode/update-maxcount: leafnode/update-groupinfo: leafnode/tcpd: true leafnode/ppp: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306380: leafnode: postinst adds spurious lines to /etc/inetd.conf
On Tue, 26 Apr 2005, Mark Brown wrote: > Could you please supply your inetd.conf? # /etc/inetd.conf: see inetd(8) for further informations. # # Internet server configuration database # # # Lines starting with "#:LABEL:" or "##" should not # be changed unless you know what you are doing! # # If you want to disable an entry so it isn't touched during # package updates just comment it out with a single '#' character. # # Packages should modify this file by using update-inetd(8) # # # #:INTERNAL: Internal services #echo stream tcp nowait rootinternal #echo dgram udp waitrootinternal #chargenstream tcp nowait rootinternal #chargendgram udp waitrootinternal #discardstream tcp nowait rootinternal #discarddgram udp waitrootinternal #daytimestream tcp nowait rootinternal #daytimedgram udp waitrootinternal #time stream tcp nowait rootinternal #time dgram udp waitrootinternal #echo stream tcp nowait root/bin/sh /bin/sh -c /bin/cat >/tmp/plog #:STANDARD: These are standard services. #:BSD: Shell, login, exec and talk are BSD protocols. #:MAIL: Mail, news and uucp services. #disabled#smtp stream tcp nowait mail/usr/sbin/exim exim -bs ## imap2 stream tcp nowait root/usr/sbin/tcpd /usr/sbin/imapd imaps stream tcp nowait root/usr/sbin/tcpd /usr/sbin/imapd nntpstream tcp nowait news/usr/sbin/tcpd /usr/sbin/leafnode #:INFO: Info services #:BOOT: Tftp service is provided primarily for booting. Most sites # run this only on machines acting as "boot servers." #:RPC: RPC based services #:HAM-RADIO: amateur-radio services #:OTHER: Other services ## netbios-ssn stream tcp nowait root/usr/sbin/tcpd /usr/sbin/smbd --- After "apt-get --reinstall install leafnode", it becomes: #disabled#nntp stream tcp nowait news/usr/sbin/tcpd /usr/sbin/leafnode nntpstream tcp nowait news/usr/sbin/tcpd /usr/sbin/leafnode If I reinstall the package again, I get another #disabled# line. I'm probably wasting your time -- but, I can't spot any errors in my /etc/inetd.conf myself. Regards, 1KB -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306380: leafnode: postinst adds spurious lines to /etc/inetd.conf
On Tue, 26 Apr 2005, Mark Brown wrote: > One other question, sorry: which inetd are you running (and which > version)? I'll try to see if I can reproduce this tonight. netkit-inetd 0.10-10 (the version currently in testing) -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293581: bzip2: Example provided in documentation causes data loss
Package: bzip2
Version: 1.0.2-3
Severity: normal
The example code included in the documentation will silently drop the
last block of data. The file /usr/share/doc/bzip2/manual_3.html
contains the following example:
FILE* f;
BZFILE* b;
int nBuf;
charbuf[ /* whatever size you like */ ];
int bzerror;
int nWritten;
f = fopen ( "myfile.bz2", "r" );
if (!f) {
/* handle error */
}
b = BZ2_bzReadOpen ( &bzerror, f, 0, NULL, 0 );
if (bzerror != BZ_OK) {
BZ2_bzReadClose ( &bzerror, b );
/* handle error */
}
bzerror = BZ_OK;
while (bzerror == BZ_OK && /* arbitrary other conditions */) {
nBuf = BZ2_bzRead ( &bzerror, b, buf, /* size of buf */ );
==> if (bzerror == BZ_OK) {
/* do something with buf[0 .. nBuf-1] */
}
}
if (bzerror != BZ_STREAM_END) {
BZ2_bzReadClose ( &bzerror, b );
/* handle error */
} else {
BZ2_bzReadClose ( &bzerror );
}
The line marked with "==>" should be changed to:
if (nBuf) {
I've checked the libbz's source -- every error will return 0, and
non-zero nBuf guarantees that bzerror is either BZ_OK or BZ_STREAM_END.
The problem is, if the latter is returned, we still need to process
the last block.
While we're at it, could you also s/"r"/"rb"/ in the fopen line, to
help some poor sap who'll port some software using bzlib to a grossly
inferior platform?
Regards,
1KB
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages bzip2 depends on:
ii libbz2-1.0 1.0.2-1 A high-quality block-sorting file
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299771: ITP: ttf-antp -- Antykwa Poltawskiego font family
Package: wnpp Severity: wishlist Owner: Adam Borowski <[EMAIL PROTECTED]> * Package name: ttf-antp Version : 0.51 Upstream Author : Bogus³aw Jackowski, Janusz M. Nowacki and Piotr Strzelczyk * URL : http://www.janusz.nowacki.strefa.pl/poltawski-e.html * License : GPL Description : Antykwa Poltawskiego font family Long desc : This font was designed by Adam Poltawski in 1923-28 as a result of his research on readability of letter forms. Even though this typeface is pretty dated now, and the readability of screen fonts obeys different rules than it does on paper, this font still beats Bitstream-Vera when applied to large blocks of text. Packages: http://angband.pl/debian/ I'm not sure if a single font family warrants a separate package. Still, it would be good to have this one in Debian as generally the readability of existing free fonts is poor. Compared to Bitstream Vera (which is currently the default Gnome font), Antykwa Poltawskiego looks a lot better for larger chunks of text (as in a web browser, text documents, etc) while being worse when it comes to rendering random window text (dialogs, menus, etc). The hinting information differs from upstream, as the upstream hints play really poorly with freetype. The hints I included (produced by fontforge with hardly any manual intervention), on the other hand, fare pretty well, as does the freetype autohinter. On the gripping hand, now the win32 renderer hates the hints, but hey, the last time I checked, debian-win32 was dead... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299771: ITP: ttf-antp -- Antykwa Poltawskiego font family
On Wed, 16 Mar 2005, Frank Küster wrote: > Miros/law Baran <[EMAIL PROTECTED]> schrieb: > > The font is included in the tetex-base package, along with other Type1 > > GUST-sponsored fonts (Antykwa Toru?ska etc.) - I think such a package > > will be redundant. > > Well, tetex-base only has the afm and pfb files, along with some > TeX-specific stuff. There are no TrueType fonts; having them might be > worth a package. Is it even possible to directly use TeX fonts from a high-level GTK/whatever program without modifying the program in question? If so, it's way too unobvious for me... > Which sources did you use - AFAIK the original format is Metafont? According to the papers upstream published, it was done using Metafont, Metapost and Metatype1, and _then_ heavily processed. The available formaps are Type1 and TTF, I used the latter. > Did you submit your new hinting to the upstream authors at gust.or.pl? Well, you're overestimating my part. What I did was _removing_ the existing hinting, as it's worse than no hints at all. I did attempt improving the upstream hinting, however, I noticed that simply letting FontForge autohint it gives astonishing results (mostly for the Regular and Bold variants). For example, the "e" glyph is a tiny bit below the line, makes the original hints put the lowest part a pixel lower than it's the case for most other letters. FontForge can automatically correct this -- and so does FreeType's autohinter. It may be a coincidence that autohinting works so well here, or perhaps simply Poltawski did a very good job. GUST provides a number of other fonts, but the only other original one is Aktykwa Torunska. It doesn't look as good on the screen, however (but it's not bad either). Both fonts share the general resemblance, and the latter one has much wider charset coverage. Perhaps it may be a good idea to provide both in this package... your call. Anyway, a scientific poll conducted on three people proved that Antykwa Poltawskiego looks "much better" that Bitstream Vera. IMO they're right :p and good fonts are valuable, thus this ITP. 1KB -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped)
Bug#213361: Upgrading ITP
retitle 213361 ITP: kbtin -- A text-based MUD client tags 213361 patch thanks Upgrading the old ITP to the last public release. Packages uploaded to: deb-src http://mentors.debian.net/debian unstable main http://mentors.debian.net/debian/pool/main/k/kbtin/ (and SourceForge, sans the Closes:# tag) -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299771: Waiting for upstream
tags 299771 - patch tags 299771 + upstream thanks Asking upstream again about a proper license text... -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312325: Happens on Intel Celerons, too.
Same happens on real i686: (cpuid output) Vendor ID: "GenuineIntel"; CPUID level 2 Intel-specific functions: Version 0660: Type 0 - Original OEM Family 6 - Pentium Pro Model 6 - Celeron Stepping 0 Reserved 0 Feature flags 0183f9ff: FPUFloating Point Unit VMEVirtual 8086 Mode Enhancements DE Debugging Extensions PSEPage Size Extensions TSCTime Stamp Counter MSRModel Specific Registers PAEPhysical Address Extension MCEMachine Check Exception CX8COMPXCHG8B Instruction SEPFast System Call MTRR Memory Type Range Registers PGEPTE Global Flag MCAMachine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension MMXMMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore TLB and cache info: 01: Instruction TLB: 4KB pages, 4-way set assoc, 32 entries 02: Instruction TLB: 4MB pages, 4-way set assoc, 2 entries 03: Data TLB: 4KB pages, 4-way set assoc, 64 entries 41: 2nd-level cache: 128KB, 4-way set assoc, 32 byte line size 08: 1st-level instruction cache: 16KB, 4-way set assoc, 32 byte line size 04: Data TLB: 4MB pages, 4-way set assoc, 8 entries 0c: 1st-level data cache: 16KB, 4-way set assoc, 32 byte line size -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407232: gucharmap: please store the last script used
Package: gucharmap Version: 1:1.6.0-1 Severity: wishlist At the moment, gucharmap always picks Arabic on start. The glyphs may be pretty and so on, but well, what do they mean? Hardly any person knows more than 1-3 scripts, so users are nearly certain to look only for characters in scripts they know, or at most, common pictograms. What about storing the last script used, and starting gucharmap with it? Or, at the very least, with Latin as it's what about anyone capable of using a computer knows? It's somewhat tedious to have to select the script you want every single time gucharmap is started. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (150, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages gucharmap depends on: ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libglib2.0-02.12.6-2 The GLib library of C routines ii libgnome2-0 2.16.0-2 The GNOME 2 library - runtime file ii libgnomeui-02.14.1-2 The GNOME 2 libraries (User Interf ii libgtk2.0-0 2.8.20-4 The GTK+ graphical user interface ii libgtk2.0-bin 2.8.20-4 The programs for the GTK+ graphica ii libgucharmap4 1:1.6.0-1Unicode browser widget library (sh ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio ii scrollkeeper0.3.14-12A free electronic cataloging syste gucharmap recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402546: libgd-gd2-noxpm-perl: depends on XPM
Package: libgd-gd2-noxpm-perl Version: 1:2.34-1 Severity: normal Package: libgd-gd2-noxpm-perl ^ Depends: libc6 (>= 2.3.6-6), libfreetype6 (>= 2.2), libgd2-noxpm (>= 2.0.33) | libgd2-xpm (>= 2.0.33), libjpeg62, libpng12-0 (>= 1.2.8rel), libx11-6, libxpm4, zlib1g (>= 1:1.2.1), perlapi-5.8.8, perl (>= 5.8.8-6) ^^^ This goes against the very reason of the xpm/noxpm split, and causes pulling in all the X11 crap, pretty useless on a server. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages libgd-gd2-noxpm-perl depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib ii libgd2-xpm 2.0.33-5.2 GD Graphics Library version 2 ii libjpeg626b-13 The Independent JPEG Group's JPEG ii libpng12-0 1.2.13-4PNG library - runtime ii libx11-6 2:1.0.3-4 X11 client-side library ii libxpm4 1:3.5.5-2 X11 pixmap library ii perl 5.8.8-6.1 Larry Wall's Practical Extraction ii perl-base [perlapi-5.8.8]5.8.8-6.1 The Pathologically Eclectic Rubbis ii zlib1g 1:1.2.3-13 compression library - runtime libgd-gd2-noxpm-perl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295489: openvt: race condition when not using -c
Package: console-tools Version: 1:0.2.3dbs-56 Severity: normal If you invoke openvt twice in rapid succession, it will often open the same VT twice, spawning two shells in it. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages console-tools depends on: ii console-common 0.7.49Basic infrastructure for text cons ii debconf1.4.45Debian configuration management sy ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libconsole 1:0.2.3dbs-56 Shared libraries for Linux console ii sysvinit 2.86.ds1-1System-V like init -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295490: tintin++: Debian changelog is duplicated over the upstream one
Package: tintin++ Version: 1.93.7-1 Severity: minor /usr/share/doc/tintin++/changelog.gz and /usr/share/doc/tintin++/changelog.Debian.gz are identical (except for the compression level). Shouldn't changelog.gz be either the upstream changelog or at least be not there? (I know, I know, the upstream changes are strewn across some files, with mods/scandum.mods being the most recent one). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages tintin++ depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libncurses5 5.4-4Shared libraries for terminal hand ii libreadline55.0-10 GNU readline and history libraries ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410961: keyword bookmarks
> I guess you could include some logic that says if a person enters a > keyword for a bookmark that has a %s insert in it but doesn't supply a > second string then ignore it, but it's not really worth it. That would result in an invalid URL, and thus cause either an error message, redirecting the user to a .com squatter or send him to Google's Feel Lucky, depending on the settings. Not a good idea. The bug arises from the fact that if there's no argument provided, %s stays as-is. The expected behaviour would be to replace it with an empty string. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411588: cursor leaves weird artifacts in window titlebars
On Mon, Feb 19, 2007 at 03:52:51PM -0800, [EMAIL PROTECTED] wrote: > Package: chameleon-cursor-theme > Version: 0.5-1 > > Whenever the cursor moves across a title bar of a non-focused window it > makes a dark block in the title bar around where the cursor is. > > It also leaves an artifact when moving the bar that divides 2 frames, such as > the one separating the left and right panels in konqueror in file > management mode. This occurs after the cursor changes to a double arrow > and causes the text immediately to the right of where the cursor was to > be illegible. Hi! I've attempted to reproduce this bug, yet without much success -- or rather, with full success as everything worked for me. I checked the following X servers: xorg/nv, xorg/nvidia, vnc4, cygwin+xorg, xming. I really doubt it could be a fault of the theme itself, but rather an issue with a display driver not handling cursors with partial transparency. In some of drivers I checked it degrades to 1-bit transparency, looking ugly but still not leaving any artifacts. Thus, to find the cause you could: 1. try a different X driver 2. try flipping: Option "HWCursor" "off" in /etc/X11/xorg.conf 3. take a look whether other partially transparent cursor themes work ok -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299771: Closing due to licensing issues
close 299771 thanks Since the state of other fonts in Debian has improved greatly, and there is still no news from antp's upstream, I'm closing this ITP. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382438: bind9: please enable listening on IPv6 by default
Package: bind9
Version: 1:9.3.2-2
Severity: wishlist
Tags: patch, ipv6
Hello. It appears that bind9 appears to be among the last services in
Debian which are not IPv6-enabled by default. All the usual ones, like
apache, apache2, sshd, exim4 or ntpd listen on IPv6 even in sarge.
diff -Nurd bind9-9.3.2.orig/debian/named.conf.options
bind9-9.3.2/debian/named.conf.options
--- bind9-9.3.2.orig/debian/named.conf.options 2006-08-11 01:03:05.0
+0200
+++ bind9-9.3.2/debian/named.conf.options 2006-08-11 01:06:35.813718500
+0200
@@ -19,6 +19,7 @@
// };
auth-nxdomain no;# conform to RFC1035
+ listen-on-v6 { any; };
};
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages bind9 depends on:
ii adduser 3.96 Add and remove users and groups
ii libbind9-01:9.3.2-2 BIND9 Shared Library used by BIND
ii libc6 2.3.6-18 GNU C Library: Shared libraries
ii libdns21 1:9.3.2-2 DNS Shared Library used by BIND
ii libisc11 1:9.3.2-2 ISC Shared Library used by BIND
ii libisccc0 1:9.3.2-2 Command Channel Library used by BI
ii libisccfg11:9.3.2-2 Config File Handling Library used
ii liblwres9 1:9.3.2-2 Lightweight Resolver Library used
ii libssl0.9.8 0.9.8b-2 SSL shared libraries
ii lsb-base 3.1-12 Linux Standard Base 3.1 init scrip
ii netbase 4.25 Basic TCP/IP networking system
bind9 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382985: teergrubes NATted connections due to mangled IPv4 checksums
Package: linux-image-2.6.16-2-xen-686 Version: 2.6.16-17 Severity: grave A recently added optimization skips checksums on all packets it believes are destined for another Xen domain inside the same box. Too bad, it is sometimes wrong -- an analysis can be found on http://lists.xensource.com/archives/html/xen-users/2006-03/msg00159.html This had been fixed before -- NETIF_F_NO_CSUM was changed to 0; however, in the current version of the Xen patch in unstable it is again enabled, set to NETIF_F_IP_CSUM (ie, IPv4 tcp and udp only) this time. Unfortunately, an idiot running nearly only IPv6 can miss this bug, unknowingly teergrubing other hosts. I've personally managed to do this to lists.debian.org, making it keep a number of exim4 processes trying to deliver mail to my server. Thus, it was suggested to file this bug as 'grave'. IPv4 ICMP, all IPv6 and connections which actually don't leave the box work fine; same for those which get bridged away to a physical interface without passing through NAT. The fix: as in the quoted link, change dev->features= NETIF_F_IP_CSUM; to dev->features= 0; -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (202, 'unstable'), (201, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-xen-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.16-2-xen-686 depends on: ii initramfs-tools [linux-initra 0.73c tools for generating an initramfs ii linux-modules-2.6.16-2-xen-68 2.6.16-17 Linux kernel modules 2.6.16 image Versions of packages linux-image-2.6.16-2-xen-686 recommends: ii libc6-xen 2.3.6-19 GNU C Library: Shared libraries [X -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#733575: libtxc-dxtn-s2tc0: uninstallable on != amd64
Package: libtxc-dxtn-s2tc0 Version: 0~git20131104-1 Severity: important Setting up libtxc-dxtn-s2tc0:armhf (0~git20131104-1) ... update-alternatives: error: alternative path /usr/lib/x86_64-linux-gnu/libtxc_dxtn_s2tc.so.0 doesn't exist dpkg: error processing package libtxc-dxtn-s2tc0:armhf (--configure): subprocess installed post-installation script returned error exit status 2 That path being missing is not quite surprising on architectures other than amd64... -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (120, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 3.0.42 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libtxc-dxtn-s2tc0 depends on: ii libc6 2.17-97 ii libgcc11:4.8.2-10 ii libstdc++6 4.8.2-10 ii multiarch-support 2.17-97 libtxc-dxtn-s2tc0 recommends no packages. libtxc-dxtn-s2tc0 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#605380: ITP: aha -- ANSI HTML Adapter
On Mon, Nov 29, 2010 at 01:55:05PM +0100, Axel Beckert wrote: > * Package name: aha > * URL or Web page : http://ziz.delphigl.com/tool_aha.php > > aha converts ANSI colors to HTML, e.g. if you want to publish the > output of ls --color=yes as static HTML somewhere, e.g. in your blog. Uhm, except it doesn't even work. Or rather, there might possibly be some program whose output it happens to handle, but even ls isn't one of those. For example: 43mwall Besides totally broken parsing and handling of SGR codes, it will also take anything that starts with \e[ to be a SGR. Not to mention writing all messages in German. I vaguely recall there being some program with this functionality in Debian already, however, after a (very brief) search I can't seem to find it. If there indeed is none, you can use my implementation: http://angband.pl/svn/kbtin/trunk/ansi2html.c It can handle all standard SGR codes. There's no support for xterm-256 colors, but I can add that if it would be useful for someone. Cheers and schtuff. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Bug#605380: ITP: aha -- ANSI HTML Adapter
On Tue, Nov 30, 2010 at 12:20:52AM +0100, Axel Beckert wrote: > Adam Borowski wrote: > > If there indeed is none, you can use my implementation: > > > > http://angband.pl/svn/kbtin/trunk/ansi2html.c > > > > It can handle all standard SGR codes. There's no support for xterm-256 > > colors, but I can add that if it would be useful for someone. > > JFTR: "echo q | env TERM=xterm htop | ansi2html" doesn't catch all > codes either. htop is a full-screen rather than a line based program. Instead of a body of text with color tags, it produces codes for a terminal with an addressable cursor: instead of lines separated with \n, it says "go to position 0,15; write 'foo' there". This can be decoded only by simulating a terminal and then taking a snapshot at the end. There are libraries which can do this -- heck, I've written one myself, yet this is something pretty costly and limited. You'd have to assume an arbitrary fixed number of columns, keep all the text in memory while processing, and can't do this piecemeal -- so a pipe which does the equivalent of "tail -f" would be impossible. And to make it funnier, htop's output ends with a screen clear, so you'd end up with an empty HTML -- so you need a frame other than the final one. With such a scope creep, this functionality would rather belong in one of ttyrec-handling tools (http://en.wikipedia.org/wiki/ttyrec has a list). If you're interesting in coloring syslogs/IRC logs/MUD logs/build logs[1]/ colordiffs/etc, which can often take tens of megabytes, you'd want to limit yourself to plain ANSI text. Ie, anything that "less -R" can show. > But "screen -c /dev/null -L ccal ; cat screenlog.0 | ./ansi2html > ccal.html" > works fine with your implementation. "screen -c /dev/null -L htop ; cat > screenlog.0 | ./ansi2html > htop2.html" and quickly pressing works only > slightly better. I see the problem with ccal is that it disables all coloring if stdout is not a terminal (isatty() in C, [ -t 1 ] in bash). Most programs like ls, git or colorgcc do this as well but have an argument like --color=always. There's a number of programs which fake a tty. It might be clearer to use a dedicated one, but that would add a dependency, abusing "script" (priority: Required) doesn't: script -q /dev/null -c "ccal" > P.S.: Looking at http://angband.pl/svn/kbtin/trunk/COPYING I'd expect > ansi2html is GPL'ed code, right? Yes, but only because the program it's bundled with is a code base starting in the 80s; ansi2html can be of any license if you wish so. [1]. I've seen ANSI color codes in build logs quite a few times. It might be a good idea to process them with ansi2html or another such program. But then, this may unleash a wave of colorgcc use on us :p -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Bug#605380: New Version 0.3
On Mon, Nov 29, 2010 at 06:42:53PM +0100, Alexander Matthes wrote:
> It's great to know, that somebody has interests in my tool. I tried
> to translate it to English completely and fixed the warnings,
Cool!
> Which thing except the coloring in the terminal begins with \e[? O_o
For example, cursor movement commands if someone tries to process the output
from a full-screen program. Trying to understand those would be a long
story and for several reasons is not really plausible, but we need to at
least properly ignore those rather than misinterpret them as colors.
In proper line based programs in the wild, I've seen the following codes:
* \e[ ... J clear screen (usually 2 -- whole screen)
* \e[ ... K clear line (0 -- after cursor, 1 -- to cursor, 2 -- whole line)
* \e[ ... D move cursor left (abused as backspace/\r)
* \e[ ... C move cursor right (used for compressing spaces)
Of course, assuming a strict hardcopy terminal, you can't edit the line, so
\e[K and \e[D could be left unimplemented. It can be argued none of these
make sense in a colored log, so just ignoring them is a valid strategy -- as
long as they are actually parsed and ignored.
> I don't get your example, Adam. What exactly is the bug?
A SGR ("set graphic rendition", \e[ ... m) code is a series of commands.
You parse only the following cases:
\e[Xm
\e[3Xm
\e[4Xm
\e[X;3Ym
\e[X;4Ym
with X and Y being single digits.
The proper perl regexp is: \e\[\d*[;\d*]*m
There may be any number of commands -- popular sequences include for example
\e[0;44;33;1m which gives yellow-on-blue.
Any order is allowed, although of course later commands may render earlier
ones moot. An example is \e[2;37;0m -- popular through copy&paste among
people who use color codes without understanding the syntax. It first makes
the text dim, then makes it white/gray, then finally resets it making the
two first commands pointless.
The commands can be any unsigned integers. In particular, they can be
bigger numbers which happen to start with 3 -- there's none of these among
old-style values but they may be present in extensions.
The integers may have leading zeroes. Both curses and ls used to have 00 as
the reset command, for example.
An empty command is explicitely allowed by the standard, meaning "0". This
is often used in \[m although I've seen \e[;31m and the like as well.
This was about the syntax. About coverage of commands, popular ones which
you lack are:
* 39 reset foreground color
* 49 reset background color
* 21 turn off bold/brightness
* 7 inverse
The rest are nice to have, although support for rarer commands is spotty
among real terminals as well, so they're not that important.
There was a multitude of extensions in the past, but they seem to have died
off, save for xterm-256 colors which are gaining traction.
Hope this helps,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
signature.asc
Description: Digital signature
Bug#605380: ITP: aha -- ANSI HTML Adapter
On Tue, Nov 30, 2010 at 02:02:14AM +0100, Axel Beckert wrote: > Adam Borowski wrote: > > htop is a full-screen rather than a line based program. Instead of a body > > of text with color tags, it produces codes for a terminal with an > > addressable cursor: instead of lines separated with \n, it says "go to > > position 0,15; write 'foo' there". > > I see, so I'd probably better stick to "classic" screenshots for > everything which looks like colored curses (sic!). Seems less effort, > despite being less cool, too. :-) I admit that in a few cases when I wanted to show a screenshot for a full-screen program I converted that by hand. If there's a need, making it automated wouldn't be a lot of work, though. > Anyway, the blog posting for which I needed that stuff is now online: > http://noone.org/blog/English/Computer/Debian/CoolTools/ccal.futile Nice posting! Since color-highlighted output is far easier to read, it deserves to be popularized. > BTW: I had to modify the resulting code to not using
Bug#683195: gnome-terminal: "Open Link" on an URL doesn't work anymore
On Fri, Feb 14, 2014 at 12:01:12PM +, althaser wrote: > Hey Adam, > > Could you please try to reproduce this bug with newer version of > gnome-terminal like 3.4.1.1-2 or 3.10.1-1 ? 3.10.1-1 seems to work fine, couldn't reproduce. On the same system, which, running unstable, is not really the same as when the bug was reproducible. -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735630: nvidia-kernel-dkms: fails to work with kernel 3.13
On Sun, Jan 19, 2014 at 06:13:25PM +0100, Andreas Beckmann wrote: > On 2014-01-17 05:20, Adam Borowski wrote: > > Hi! I'm running a -rc kernel (as 3.12 doesn't work for me due to #730863), > > and the module builds but fails to insert with the following message: > > > > nvidia: Unknown symbol acpi_os_wait_events_complete (err 0) > > That symbol should be present in your kernel, it is present in the > packaged 3.13-rc6 in experimental. Check with > > grep acpi_os_wait_events_complete /boot/System.map-* /boot/System.map-3.11.0-x32+:8137fa0f T acpi_os_wait_events_complete /boot/System.map-3.11.0-x32+:81777000 r __ksymtab_acpi_os_wait_events_complete /boot/System.map-3.11.0-x32+:8178caa0 r __kcrctab_acpi_os_wait_events_complete /boot/System.map-3.11.0-x32+:817a5ed4 r __kstrtab_acpi_os_wait_events_complete /boot/System.map-3.13-rc6-amd64:812d7e76 T acpi_os_wait_events_complete /boot/System.map-3.13.0-rc8-x32+:81386097 T acpi_os_wait_events_complete So the symbol is there, what might be going wrong...? > If it is missing, compare the kernel .configs diff|grep -i acpi + CONFIG_ACPI_DEBUG=y - CONFIG_ACPI_HOTPLUG_MEMORY=y - a bunch of drivers (Toshiba, Thinkpad, etc) I'll recompile 3.13.0 with these options, to make sure. -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736158: random FTBFS: test_graceful_shutdown_waits_for_clients_to_stop
Package: src:bzr
Version: 2.6.0-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)
I'm afraid that bzr randomly (7/8 tries) FTBFSes due to a failure of one
test on speedier machines:
==
FAIL:
bzrlib.tests.test_smart_transport.TestSmartTCPServer.test_graceful_shutdown_waits_for_clients_to_stop
--
_StringException: log: {{{
INFO Requested to stop gracefully
305.285 Stopping SmartServerSocketStreamMedium(client=('127.0.0.1', 60256))
INFO Waiting for 1 client(s) to finish
INFO Requested to stop gracefully
}}}
Traceback (most recent call last):
File
"/tmp/buildd/bzr-2.6.0/build/lib.linux-x86_64-2.7/bzrlib/tests/test_smart_transport.py",
line 1458, in test_graceful_shutdown_waits_for_clients_to_stop
self.assertFalse(server._fully_stopped.isSet())
File "/usr/lib/python2.7/unittest/case.py", line 418, in assertFalse
raise self.failureException(msg)
AssertionError: True is not false
--
I repeated the build on an armhf box, all 3 tries succeeded. So did it on
all buildds for first-class architectures, while on the x32 buildd there
were two failures out of two attempts. It seems that the x32 buildd runs on
a good deal faster machine than i386 and amd64 ones: looking at some random
package, I see 25s:x32 vs 1m50s:i386. All other architectures are,
unsuprisingly, slower.
So it's some timing issue. I have a strong hunch it's a bug in the test
suite rather than in the code being tested, so if it's tricky to debug,
disabling that test wouldn't be as bad an idea as papering over test
failures usually is.
(Not sure what's the right severity for "FTBFSes on too fast". As my home
machines are not so hot, I went with "serious" as hardware only goes faster,
but you probably know better.)
Meow!
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13.0-rc8-x32+ (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735630: nvidia-kernel-dkms: fails to work with kernel 3.13
On Mon, Jan 20, 2014 at 12:46:02PM +0100, Adam Borowski wrote: > On Sun, Jan 19, 2014 at 06:13:25PM +0100, Andreas Beckmann wrote: > > If it is missing, compare the kernel .configs > > diff|grep -i acpi > + CONFIG_ACPI_DEBUG=y > - CONFIG_ACPI_HOTPLUG_MEMORY=y > - a bunch of drivers (Toshiba, Thinkpad, etc) > > I'll recompile 3.13.0 with these options, to make sure. Now this is interesting... I tried vanilla 3.13.0 with exact Debian's config, and it fails without the patch (and works with it). So what else differs from kernels that you say work for you unpatched? * Debian patches vs vanilla Linus' tree * build scheme (external kbuild vs make-kpkg) My exact invocation was: make-kpkg --rootcmd fakeroot --initrd linux-image linux-headers in a pristine Linus' 3.13.0 tree from git, with config copied from the package from experimental. The linux-kbuild-3.13 is missing, and procuring it myself would require a long ritual which I've forgotten, so I haven't checked the experimental package myself. -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736211: src:blackbox: FTBFS on x32
Package: src:blackbox
Version: 0.70.1-18
Severity: wishlist
Tags: patch
Hi! Blackbox fails to build on x32, for two reasons:
* it uses implicit casts between time_t and long, in template disambiguation
where exact types are needed
* its hand-written symbol arch table needs inclusion of x32
Patch attached.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (600, 'unstable'), (500, 'experimental')
Architecture: x32 (x86_64)
Kernel: Linux 3.13.0-x32+ (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -urd blackbox-0.70.1.0/debian/libbt0.symbols blackbox-0.70.1/debian/libbt0.symbols
--- blackbox-0.70.1.0/debian/libbt0.symbols 2013-11-20 14:25:58.0 +0100
+++ blackbox-0.70.1/debian/libbt0.symbols 2014-01-20 17:16:40.539105265 +0100
@@ -386,7 +386,7 @@
(optional)_ZNSbIjSt11char_traitsIjESaIjEE12_M_leak_hardEv@Base 0.70.1
(optional)_ZNSbIjSt11char_traitsIjESaIjEE12_S_constructIN9__gnu_cxx17__normal_iteratorIPKjS2_PjT_SA_RKS1_St20forward_iterator_tag@Base 0.70.1
(optional)_ZNSbIjSt11char_traitsIjESaIjEE15_M_replace_safeEjjPKjj@Base 0.70.1
- (arch=!any-i386 !alpha !armel !armhf !ia64 !m68k !mips !mipsel !powerpc !powerpcspe !ppc64 !s390 !s390x !sh4 !sparc !sparc64)_ZNSbIjSt11char_traitsIjESaIjEE15_M_replace_safeEmmPKjm@Base 0.70.1
+ (arch=!any-i386 !alpha !armel !armhf !ia64 !m68k !mips !mipsel !powerpc !powerpcspe !ppc64 !s390 !s390x !sh4 !sparc !sparc64 !x32)_ZNSbIjSt11char_traitsIjESaIjEE15_M_replace_safeEmmPKjm@Base 0.70.1
_ZNSbIjSt11char_traitsIjESaIjEE4_Rep20_S_empty_rep_storageE@Base 0.70.1
(optional)_ZNSbIjSt11char_traitsIjESaIjEE4_Rep8_M_cloneERKS1_j@Base 0.70.1
(optional)_ZNSbIjSt11char_traitsIjESaIjEE4_Rep8_M_cloneERKS1_m@Base 0.70.1
@@ -395,7 +395,7 @@
(optional)_ZNSbIjSt11char_traitsIjESaIjEE6appendEmj@Base 0.70.1
(optional)_ZNSbIjSt11char_traitsIjESaIjEE6assignERKS2_@Base 0.70.1
(optional)_ZNSbIjSt11char_traitsIjESaIjEE6resizeEjj@Base 0.70.1
- (arch=!any-i386 !alpha !armel !armhf !ia64 !m68k !mips !mipsel !powerpc !powerpcspe !ppc64 !s390 !s390x !sh4 !sparc !sparc64)_ZNSbIjSt11char_traitsIjESaIjEE6resizeEmj@Base 0.70.1
+ (arch=!any-i386 !alpha !armel !armhf !ia64 !m68k !mips !mipsel !powerpc !powerpcspe !ppc64 !s390 !s390x !sh4 !sparc !sparc64 !x32)_ZNSbIjSt11char_traitsIjESaIjEE6resizeEmj@Base 0.70.1
(arch=!amd64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !s390 !s390x !alpha !ppc64 !sparc64)_ZNSbIjSt11char_traitsIjESaIjEE7replaceEjjPKjj@Base 0.70.1
(arch=amd64 ia64 kfreebsd-amd64 mips64 mips64el s390 s390x alpha ppc64 sparc64)_ZNSbIjSt11char_traitsIjESaIjEE7replaceEmmPKjm@Base 0.70.1
(arch=!amd64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !s390 !s390x !alpha !ppc64 !sparc64)_ZNSbIjSt11char_traitsIjESaIjEE7reserveEj@Base 0.70.1
diff -urd blackbox-0.70.1.0/src/Toolbar.cc blackbox-0.70.1/src/Toolbar.cc
--- blackbox-0.70.1.0/src/Toolbar.cc 2005-04-12 09:38:00.0 +0200
+++ blackbox-0.70.1/src/Toolbar.cc 2014-01-20 17:12:33.059144580 +0100
@@ -44,8 +44,8 @@
{
timeval now;
gettimeofday(&now, 0);
- return (std::max(1000l, resolution - (now.tv_sec % resolution)) * 1000l))
- - (now.tv_usec / 1000l;
+ return (std::max((time_t)1000, resolution - (now.tv_sec % resolution)) * 1000))
+ - (now.tv_usec / 1000;
}
Bug#736158: linux-kbuild-3.13_3.13~rc8-0_amd64.deb
On Tue, Jan 21, 2014 at 02:58:34AM +0100, Andreas Beckmann wrote: > I built this locally before uploading 331.38-1 to experimental - the > nvidia kernel module builds successfully on every official Debian kernel > header package from squeeze to experimental including backports Thanks! > but of course I didn't test even one of them :-) Especially not the > 3.13~rc ones :-P Ah heh. I just did: unsurprisingly, the nvidia module doesn't work with official experimental kernels after all. Ie, the patch is needed for all 3.13 kernels. Meow! -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735630: doesn't work with experimental kernels without the patch
Hi! I accidentally sent my response to a wrong bug: with official kernels from experimental (thanks for the kbuild!), the module builds but fails to load just as well, unless patched. As for the second problem Maurizio reported: I got no EFI system, nor a relevant laptop, so I can't reproduce. The original patch is enough for my system, as far as I can tell. -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699185: upstream support is incomplete
Daniel Schepler wrote: > (It's strange > that there seems to be no way to configure for compiling to an x32 > target in upstream when the x32 support is definitely there in > pr/include/md/_linux.cfg.) That's because some guys already partially added it, but didn't finish the job: https://bugzilla.mozilla.org/show_bug.cgi?id=767759 I took the liberty of posting Daniel's patch there. It needs replacing mozilla/nsprpub -> nspr because of source tree's layout change, but after that, it works for me (for the values of "works" being "allows compiling nss against it", but "if it compiles, ship it", right?). As for this patch in Debian: after amending the path, it works, you can ignore hunks that fail to apply as they touch comments in a generated file(!). The two hunks that do matter happen to apply successfully. -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737850: crawl: menu icon entries missing
On Thu, Feb 06, 2014 at 02:35:08PM +0100, Markus Koschany wrote: > currently crawl does not supply a menu icon hence the > game is not well integrated into the user's desktop environment. > Please consider adding an icon entry to your menu file. Current state: crawl(text) crawl-tiles(SDL) menuYY menu icon -- XDG -Y XDG icon-Y What you report here is the lack of .xpm, that's a trivial fix (there's a .png nearby already). However, I wonder about the inconsistency between menu and XDG: the text version ships a menu entry but no XDG. I think we should either drop the menu from the non-graphical version (the user can start it from her favourite terminal), or add XDG for it as well. Any advice which would be better? -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737850: crawl: menu icon entries missing
On Thu, Feb 06, 2014 at 10:49:19PM +0100, Guus Sliepen wrote: > On Thu, Feb 06, 2014 at 10:38:47PM +0100, Adam Borowski wrote: > > > Current state: > > crawl(text) crawl-tiles(SDL) > > menuYY > > menu icon -- > > XDG -Y > > XDG icon-Y > > > > However, I wonder about the inconsistency between menu and XDG: the text > > version ships a menu entry but no XDG. I think we should either drop the > > menu from the non-graphical version (the user can start it from her > > favourite terminal), or add XDG for it as well. Any advice which would > > be better? > > Since it is a roguelike, it is not unlikely that someone would like to play it > with real ASCII art instead of tiles. So I think it is best to have menu and > XDG and icons for both text and tiles versions. Yes, but people using a terminal are likely to have one already open, rather than using mouse to start a mouse-less text game. I looked at our most direct competition: just like us, NetHack currently provides a menu entry for both console and tiles, and an XDG only for tiles. -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#627481: all colour codes share the same syntax
> > These codes depend on the terminal used, right? So just to get this
> > straight, you think column should get the valid escape sequences for the
> > terminal it runs in and then filter those out?
> Yep, if libtinfo makes that easy to do. Otherwise, checking for ANSI
> standard sequences would already be useful enough.
Using libtinfo means trusting TERM, which is almost never the right thing
to do since about 30 years ago when terminals got mostly standardized and
termcap/terminfo databases stopped being reasonably maintained (heck,
Solaris still doesn't know about TERM=linux; xterm, putty, konsole and
everything on libvte use the same TERM string despite having lots of
differences, etc).
But, weeding out color codes is far easier than that: all valid SGR ("set
graphics rendition") codes match the same syntax: \e [ m, where
matches /[0-9;]*/. There was an attempt to break this simplicity
in ITU T.416, but fortunately it was mostly ignored, and you can safely
assume all codes that alter character attributes follow this syntax.
There are more ANSI codes than SGR, but those all either move the cursor,
alter the screen, request some feedback or have a similar effect that's
inappropriate inside regular text.
Thus, I'd recommend ignoring /\e\[[0-9;]*m/ and nothing else.
--
A tit a day keeps the vet away.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732553: ITP: fonts-cosmic-sans-neue -- font family with great monospaced variant for programmers
On Wed, Dec 18, 2013 at 11:09:18PM +0530, Vasudev Kamath wrote: > * Package name: fonts-cosmic-sans-neue Ugh, really? Could you please ask upstream to rename the font to something sane? Especially that the infamous font this name alludes to might be perhaps fit for a tombstone you put for your worst enemy, or maybe even not that. > Not related to other Cosmic Sans from the Internet. So there actually are _three_ fonts with very similar names. With names, it's quite important to reduce the risk of mistaking one for another, and here you have pretty much a guarantee mistakes _will_ happen. Please pick something unique! -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722469: same for 304.108-4 -> 310.51-1
> libgl1-nvidia-glx postinst should display a debconf note about a > mismatch of the loaded kernel module and the driver being installed ... > > if it's a debconf problem, the next time you run into it, try > > export DEBCONF_DEBUG=developer > dpkg --configure --pending Setting up libgl1-nvidia-glx:amd64 (310.51-1) ... debconf (developer): frontend started debconf (developer): Trying to find a templates file.. debconf (developer): Trying /usr/lib/nvidia/check-for-conflicting-opengl-libraries.templates debconf (developer): Trying /usr/share/debconf/templates/check-for-conflicting-opengl-libraries.templates debconf (developer): Couldn't find a templates file. debconf (developer): frontend running, package name is debconf (developer): starting /usr/lib/nvidia/check-for-conflicting-opengl-libraries debconf (developer): frontend started debconf (developer): Trying to find a templates file.. debconf (developer): Trying /usr/lib/nvidia/check-for-mismatching-nvidia-module.templates debconf (developer): Trying /usr/share/debconf/templates/check-for-mismatching-nvidia-module.templates debconf (developer): Couldn't find a templates file. debconf (developer): frontend running, package name is debconf (developer): starting /usr/lib/nvidia/check-for-mismatching-nvidia-module 310.51 debconf (developer): <-- GET nvidia-support/check-running-module-version debconf (developer): --> 10 nvidia-support/check-running-module-version doesn't exist dpkg: error processing libgl1-nvidia-glx:amd64 (--configure): subprocess installed post-installation script returned error exit status 10 dpkg: dependency problems prevent configuration of nvidia-driver: nvidia-driver depends on libgl1-nvidia-glx (= 310.51-1); however: Package libgl1-nvidia-glx:amd64 is not configured yet. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722469: same for 304.108-4 -> 310.51-1
On Tue, Oct 22, 2013 at 04:57:44PM +0200, Andreas Beckmann wrote: > But the real problem is this: > > > debconf (developer): frontend running, package name is > > debconf (developer): starting > > /usr/lib/nvidia/check-for-mismatching-nvidia-module 310.51 > > debconf (developer): <-- GET nvidia-support/check-running-module-version > > debconf (developer): --> 10 nvidia-support/check-running-module-version > > doesn't exist > > dpkg: error processing libgl1-nvidia-glx:amd64 (--configure): > > subprocess installed post-installation script returned error exit status 10 > > dpkg: dependency problems prevent configuration of nvidia-driver: > > nvidia-driver depends on libgl1-nvidia-glx (= 310.51-1); however: > > Package libgl1-nvidia-glx:amd64 is not configured yet. > > before upgrading anything, please run > > debconf-get-selections | grep nvidia > debconf-show nvidia-support Neither shows any output. > PS: did you somehow mess up your debconf database in the past? Merely its cache, by a wholesale deletion of /var/cache/, as allowed by the Policy in a "must" clause. I did not mess with debconf in any other way (nor even specifically targetted it). -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732553: renamed to Fantasque Sans Mono
Hi! After a discussion with the upstream, the font got renamed to "Fantasque Sans Mono", which doesn't seem to conflict with anything relevant. Meow! -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735624: uninstallable: "/var/log/polipo: Is a directory"
Package: polipo Version: 1.0.4.1-5 Severity: grave When attempting to upgrade or uninstall+install: Setting up polipo (1.0.4.1-5) ... Starting polipo: Couldn't open log file /var/log/polipo: Is a directory invoke-rc.d: initscript polipo, action "start" failed. That directory gets recreated even if I remove it: [~]# apt-get remove polipo [~]# ls -al /var/log/polipo/ total 4 drwxr-sr-x 1 proxy adm44 Jan 12 06:25 . drwxr-xr-x 1 root root 1498 Jan 16 06:25 .. -rw-r- 1 proxy adm 0 Jan 12 06:25 polipo.log -rw-r- 1 proxy adm86 Jan 11 15:03 polipo.log.1 [~]# rm -rf /var/log/polipo/ [~]# apt-get install polipo [~]# ls -al /var/log/polipo/ total 0 drwxr-sr-x 1 proxy adm 0 Jan 15 17:28 . drwxr-xr-x 1 root root 1498 Jan 17 03:29 .. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: x32 (x86_64) Kernel: Linux 3.10.25-vs2.3.6.8-x32-vserver+ (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages polipo depends on: ii libc6 2.17-97 ii lsb-base 4.1+Debian12 polipo recommends no packages. polipo suggests no packages. -- Configuration Files: /etc/polipo/config changed: proxyAddress = "2001:6a0:114::3:82" allowedClients = 127.0.0.1/24, 2001:6a0:118::/48, 2001:6a0:114::/48, ::1/128 socksParentProxy = "localhost:9050" socksProxyType = socks5 censoredHeaders = from, accept-language, accept-encoding, accept-charset, user-agent, accept censorReferer = maybe -- 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#735630: nvidia-kernel-dkms: fails to work with kernel 3.13
Package: nvidia-kernel-dkms
Version: 319.82-1
Severity: normal
Tags: patch
Hi! I'm running a -rc kernel (as 3.12 doesn't work for me due to #730863),
and the module builds but fails to insert with the following message:
nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)
The following patch, pulled from some page, fixes it:
--- nv-acpi.c~ 2013-12-30 07:57:59.0 +0100
+++ nv-acpi.c 2014-01-17 04:54:31.846762347 +0100
@@ -303,7 +303,9 @@
if (pNvAcpiObject->notify_handler_installed)
{
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 13, 0)
NV_ACPI_OS_WAIT_EVENTS_COMPLETE();
+#endif
// remove event notifier
status = acpi_remove_notify_handler(device->handle,
ACPI_DEVICE_NOTIFY, nv_acpi_event);
I'm running kernels with this patch for quite a while, and everything seems
to work ok. 3.13 will be released tomorrow.
-- Package-specific info:
uname -a:
Linux umbar 3.13.0-rc8-x32+ #4 SMP Tue Jan 14 07:13:35 CET 2014 x86_64 GNU/Linux
/proc/version:
Linux version 3.13.0-rc8-x32+ (kilobyte@umbar) (gcc version 4.8.2 (Debian
4.8.2-13) ) #4 SMP Tue Jan 14 07:13:35 CET 2014
/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module 319.82 Mon Dec 30 02:18:32 PST
2013
GCC version: gcc version 4.8.2 (Debian 4.8.2-14)
lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT215 [GeForce GT
240] [10de:0ca3] (rev a2) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Device [1458:34e2]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Kernel driver in use: nvidia
dmesg:
[0.00] No AGP bridge found
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.626641] vgaarb: device added:
PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.626642] vgaarb: loaded
[0.626643] vgaarb: bridge control possible :01:00.0
[1.261474] PCI-DMA: Disabling AGP.
[1.261604] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[3.100549] nvidia: module license 'NVIDIA' taints kernel.
[3.116387] vgaarb: device changed decodes:
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none
[3.116945] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 319.82 Mon Dec
30 02:18:32 PST 2013
[3.142369] hda-intel :01:00.1: Handle VGA-switcheroo audio client
[3.952255] input: HDA NVidia HDMI/DP,pcm=9 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input17
[3.952458] input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input16
[3.952646] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input15
[3.952828] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:00/:00:02.0/:01:00.1/sound/card1/input14
OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root 15 Jan 17 04:50 /etc/alternatives/glx ->
/usr/lib/nvidia
lrwxrwxrwx 1 root root 48 Dec 1 21:47
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu ->
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 Dec 1 21:47
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu ->
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 41 Jan 17 04:50
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root 41 Jan 17 04:50
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root 43 Jan 17 04:50
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root 43 Jan 17 04:50
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root 49 Jan 17 04:50
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root 51 Jan 17 04:50
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root 25 Jan 17 04:50
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root 42 Jan 17 04:50
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf ->
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root 36 Jan 17 04:50
/etc/alternatives/glx--nvidia-bug-report.sh ->
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root 29 Jan 17 04:50
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root 22 Dec 1 21:47 /etc/alternatives/libGL.so-master
-> /usr/lib/mesa-diverted
lrwxrwxrwx 1 root root 43 Sep 11 02:29
/etc/alternative
Bug#735624: uninstallable: "/var/log/polipo: Is a directory"
On Fri, Jan 17, 2014 at 01:25:28PM +0800, Rolf Leggewie wrote: > On 17.01.2014 11:47, Adam Borowski wrote: > > When attempting to upgrade or uninstall+install: > > Setting up polipo (1.0.4.1-5) ... > > Starting polipo: Couldn't open log file /var/log/polipo: Is a directory > > invoke-rc.d: initscript polipo, action "start" failed. > > thank you for your report and my apologies for the problem. For what > it's worth, I cannot reproduce it in a chroot. And looking at the diff > to the latest version I don't see anything immediately obvious that > might be causing this. My suspicion is it has something to do with > http://anonscm.debian.org/gitweb/?p=collab-maint/polipo.git;a=commit;h=520dc059bf1c3b93b243c47c47bde5f4c1e697a3 > > What version are you upgrading from? >From 1.0.4.1-4. The system has been installed recently (a vserver container) and never had a version earlier than that; the config though comes from an old box, from earlier versions of polipo. None of settings it does set seems to be related, though. Reportbug attached all non-comment lines to the original report. > Did you set or unset $NAME somewhere? Not to my knowledge. > Does "env|grep -i name" show anything? LOGNAME=root (or LOGNAME=kilobyte as the user) > The log file should be /var/log/polipo/polipo.log, not > /var/log/polipo. What happens if you hardcode the configuration to > LOGFILE=/var/log/polipo/polipo.log in /etc/polipo/config? Setting up polipo (1.0.4.1-5) ... Starting polipo: /etc/polipo/config:155: unknown config variable LOGFILE Couldn't open log file /var/log/polipo: Is a directory invoke-rc.d: initscript polipo, action "start" failed. Meow! -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727833: ITP: node-bytes -- Byte string parser and formatter - Node.js module
On Sun, Nov 03, 2013 at 01:30:15AM +0100, Jérémy Lal wrote: > On 03/11/2013 00:56, Jean-Christophe Dubacq wrote: > > I have looked at the code, and it seems to me that, again, we introduce > > some code in debian that decide they can name the units any way they > > like (see http://en.wikipedia.org/wiki/Binary_prefix). > > > > They decide, for example, to use k, m and g prefixes for 2^10, 2^20 and > > 2^30, where usage should point to at least k, M and G and correct usage > > to Ki, Mi, Gi. They also call bytes 'b' (usage is more 'B'). > I agree the units are wrong and will fix it, and try to make > upstream fix it too. Please, don't break it. A well-entrenched practice used for 60+ years has more weight than what a random committee with delusions of importance decided a few years ago asked by a couple of sleazy disk manufacturers wanting to weasel their way out of lawsuits caused by lies of their marketing departments. And that "binary prefix" crap is outright harmful: if 1 MB stands for 1048576 bytes like it does, what would "1 MiB" be? That's intuitive, 1 _mi_llion, right? Right?? -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729938: crawl-tiles: tilesheets out of sync on !amd64
Package: crawl-tiles
Version: 2:0.13.0-1
Severity: important
Tags: patch fixed-upstream
I'm afraid that the tilesheets are out of sync between builds. This
affects any architecture other than the one matching whatever
crawl-tiles-data was built on (for Debian's 0.13.0-1 it's amd64),
and any user who rebuilds the package at home.
The culprit is perl hash order being randomized between runs in version
5.18 and greater, which art-data relied on.
The issue is fixed upstream (in trunk), but alas, because of webtiles
on public servers, the fix can't be backported to 0.13 easily there.
The public servers all run stable releases of Debian with old perls,
so they don't suffer from this bug. No ordinary user has a reason to
split the packaging either -- this matters only in Debian and perhaps
if some other distribution would split out arch:all bits too.
Thus, I'm afraid the fix in 0.13 needs to be kept in Debian during the
whole life of 0.12 and 0.13.
>From fc2aeb4d5915807a4ab8b62ff5adf3d1ead3c01d Mon Sep 17 00:00:00 2001
From: Adam Borowski
Date: Wed, 16 Oct 2013 19:13:58 +0200
Subject: [PATCH] Fix unrand tile mismatches between architectures.
They were written in hash order, which is not supposed to be stable.
---
crawl-ref/source/util/art-data.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crawl-ref/source/util/art-data.pl b/crawl-ref/source/util/art-data.pl
index a7ce797..5093ca9 100755
--- a/crawl-ref/source/util/art-data.pl
+++ b/crawl-ref/source/util/art-data.pl
@@ -775,7 +775,7 @@ sub write_tiles
HEADER_END
# Output the tile definitions sorted by type (and thus path).
-foreach my $type (keys %art_by_type)
+foreach my $type (sort keys %art_by_type)
{
print TILES "%sdir item/$type/artefact\n";
--
1.8.5.rc0
Bug#729939: apt-cacher-ng: fails to start after a /var/cache/ purge
Package: apt-cacher-ng Version: 0.7.19-1 Severity: serious After manually nuking the whole cache (troubleshooting an unrelated bug): [] Starting apt-cacher-ng: apt-cacher-ngCache directory not writable. Check the permissions of /var/cache/apt-cacher-ng! failed! This fails a "must" clause of the policy: # Files located under /var/cache may be expired in an application specific # manner, by the system administrator, or both. The application must always be # able to recover from manual deletion of these files (generally because of # disk space shortage). No other requirements are made on the data format of # the cache directories. Obviously, the init script needs to re-create the directory if needed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729941: apt-cacher-ng: fails on current experimental/non-free
Package: apt-cacher-ng Version: 0.7.19-1 Severity: normal For some reason, apt-cacher-ng gets spooked by some Package files. I've seen this before on other repositories, currently it's experimental/non-free that fails. I attached a copy of this file (as it's likely to have changed by the time you take a look). When using the cache, apt says: - Err http://apt.angband.pl:3142 experimental/non-free amd64 Packages Hit http://apt.angband.pl:3142 experimental/non-free amd64 Packages - (with a mysterious newline, but that's a weirdness in apt). Whenever the nightly cronjob comes, it spams, asking for manually expiring the cache via a web interface. This one says: - Parsing metadata in debrep/dists/experimental/non-free/binary-amd64/Packages.xz An error occured while reading this file, some contents may have been ignored. Tag - which persists even after asking it to remove it. Manually deleting just this one file ( /var/cache/apt-cacher-ng/debrep/dists/experimental/non-free/binary-amd64/Packages.xz ) lets expiration succeed, but running an apt update brings it back. I tried nuking the whole of /var/cache/apt-cacher-ng as well (which you probably noticed from #729939), didn't help. Packages.xz Description: application/xz
Bug#729941: apt-cacher-ng: fails on current experimental/non-free
On Tue, Nov 19, 2013 at 12:28:53PM +0100, Eduard Bloch wrote:
> > For some reason, apt-cacher-ng gets spooked by some Package files. I've
> > seen this before on other repositories, currently it's experimental/non-free
> > that fails. I attached a copy of this file (as it's likely to have changed
> > by the time you take a look).
>
> As you suspected, I have trouble reproducing it. Could you send your
> /etc/apt-cacher-ng/*.conf files please?
I brought them to the stock state when trying reinstalling, the only change
currently is:
244c244
< # ConnectProto: v6 v4
---
> ConnectProto: v4 v6
(as my IPv6 goes through SiXXS which is slower than native IPv4).
> Could you also turn up debug= value to 7 and send me your logs after a
> couple of days?
Sure, I've just set it ("Debug:7" in acng.conf).
--
A tit a day keeps the vet away.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684496: update for Unicode 7.0
Hi! With the release of Unicode 7.0, it would be nice to get an update of this package. The upstream supports most of the new stuff, let's have it in Debian. -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752028: src:gcc-defaults: please update x32 to 4.9
Package: src:gcc-defaults Version: 1.128 Severity: wishlist x32 suffered a long outage of its buildd, but Daniel Schepler has since fixed it and gcc-4.9 is now available for x32 as well. Thus, its defaults can be brought in line with the rest of architectures. It hasn't seen any testing yet, but it appears to work, and on a new architecture I expect it to fix more than it breaks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'experimental') Architecture: x32 (x86_64) Kernel: Linux 3.15.0-x32 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752041: src:texlive-bin: FTBFS on x32 due to luajit
Package: src:texlive-bin Version: 2014.20140528.34243-2 Severity: normal Tags: patch I'm afraid that the embedded copy of luajit in texlive-bin FTBFSes on x32: gcc -DHAVE_CONFIG_H -I. -I../../../../libs/luajit/native -I../../../../libs/luajit/native/../LuaJIT-2.0.3/src -DLUAJIT_ENABLE_LUA52COMPAT `cat ../native_flags` -Wall -g -O2 -c -o ../LuaJIT-2.0.3/src/host/buildvm-buildvm_lib.o `test -f '../LuaJIT-2.0.3/src/host/buildvm_lib.c' || echo '../../../../libs/luajit/native/'`../LuaJIT-2.0.3/src/host/buildvm_lib.c In file included from ../../../../libs/luajit/native/../LuaJIT-2.0.3/src/host/buildvm_lib.c:7:0: ../../../../libs/luajit/native/../LuaJIT-2.0.3/src/lj_obj.h: In function 'setlightudV': ../../../../libs/luajit/native/../LuaJIT-2.0.3/src/lj_obj.h:724:12: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] o->u64 = (uint64_t)p | (((uint64_t)0x) << 48); ^ gcc -DHAVE_CONFIG_H -I. -I../../../../libs/luajit/native -I../../../../libs/luajit/native/../LuaJIT-2.0.3/src -DLUAJIT_ENABLE_LUA52COMPAT `cat ../native_flags` -Wall -g -O2 -c -o ../LuaJIT-2.0.3/src/host/buildvm-buildvm_peobj.o `test -f '../LuaJIT-2.0.3/src/host/buildvm_peobj.c' || echo '../../../../libs/luajit/native/'`../LuaJIT-2.0.3/src/host/buildvm_peobj.c gcc -Wall -g -O2 -o buildvm ../LuaJIT-2.0.3/src/host/buildvm-buildvm.o ../LuaJIT-2.0.3/src/host/buildvm-buildvm_asm.o ../LuaJIT-2.0.3/src/host/buildvm-buildvm_fold.o ../LuaJIT-2.0.3/src/host/buildvm-buildvm_lib.o ../LuaJIT-2.0.3/src/host/buildvm-buildvm_peobj.o echo timestamp >buildvm-stamp make[7]: Leaving directory '/tmp/buildd/texlive-bin-2014.20140528.34243/Work/libs/luajit/native' native/buildvm -m bcdef -o lj_bcdef.h lib_base.c lib_math.c lib_bit.c lib_string.c lib_table.c lib_io.c lib_os.c lib_package.c lib_debug.c lib_jit.c lib_ffi.c Error: pointer size mismatch in cross-build. Try: make HOST_CC="gcc -m32" CROSS=... (It's not a cross build.) However, I'd say that fixing an embedded copy of a library is a waste of time. As luajit is optional for texlive, let's just disable it on x32. Trivial patch attached, tested. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'experimental') Architecture: x32 (x86_64) Kernel: Linux 3.15.0-x32 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nurd texlive-bin-2014.20140528.34243.0/debian/rules texlive-bin-2014.20140528.34243/debian/rules --- texlive-bin-2014.20140528.34243.0/debian/rules 2014-06-19 01:53:20.551099762 +0200 +++ texlive-bin-2014.20140528.34243/debian/rules 2014-06-19 01:39:48.162291789 +0200 @@ -4,7 +4,7 @@ export SHELL=/bin/bash export CONFIG_SHELL=/bin/sh -LUAJIT_FAIL_ARCHS := s390x hppa arm64 ppc64 ppc64el +LUAJIT_FAIL_ARCHS := s390x hppa arm64 ppc64 ppc64el x32 # In case one wants to build with old automake (<< 1.13.1), the following # variable has to be set. By default the debian/control requires high
Bug#752491: src:mpich: FTBFS on x32
Package: src:mpich
Version: 3.1-4
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: port-x32 ftbfs-x32
A year and half ago, Daniel Schepler submitted a fix of mpich misdetecting
x32 as i386 and using improper assembly, as #699629. Here's a version of
his patch ported to mpich 3.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (600, 'unstable'), (500, 'experimental')
Architecture: x32 (x86_64)
Kernel: Linux 3.15.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -urd mpich-3.1.orig/configure.ac mpich-3.1/configure.ac
--- mpich-3.1.orig/configure.ac 2014-02-20 07:21:27.0 +0100
+++ mpich-3.1/configure.ac 2014-06-24 04:42:11.030647892 +0200
@@ -4434,7 +4434,7 @@
long int newval = 20;
char ret;
long int readval;
-__asm__ __volatile__ ("lock; cmpxchgl %3, %1; sete %0"
+__asm__ __volatile__ ("push %%ecx; pop %%ecx; lock; cmpxchgl %3, %1; sete %0"
: "=q" (ret), "=m" (*p), "=a" (readval)
: "r" (newval), "m" (*p), "a" (oldval) : "memory");
return (compval == 20) ? 0 : -1;
@@ -4454,12 +4454,12 @@
AC_TRY_RUN([
int main(int argc, char *argv[])
{
-long int compval = 10;
-volatile long int *p = &compval;
-long int oldval = 10;
-long int newval = 20;
+long long int compval = 10;
+volatile long long int *p = &compval;
+long long int oldval = 10;
+long long int newval = 20;
char ret;
-long int readval;
+long long int readval;
__asm__ __volatile__ ("lock; cmpxchgq %3, %1; sete %0"
: "=q" (ret), "=m" (*p), "=a" (readval)
: "r" (newval), "m" (*p), "a" (oldval) : "memory");
Bug#742965: libc0.1: openpty()/forkpty() fail on kfreebsd >=9.0
Package: libc0.1
Version: 2.18-4
Severity: normal
If a process has a handler for SIGCHLD, openpty() fails on kfreebsd with 9.x
kernels. It worked ok on 8.x, and works on "real" (ie, no glibc) FreeBSD.
A reduced test case attached; when commenting out the sigaction line,
openpty() starts working again.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.2-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc0.1 depends on:
ii libgcc1 1:4.8.2-16
libc0.1 recommends no packages.
Versions of packages libc0.1 suggests:
ii debconf [debconf-2.0] 1.5.52
pn glibc-doc
ii locales2.18-4
-- debconf information:
glibc/upgrade: true
glibc/disable-screensaver:
glibc/restart-services:
glibc/restart-failed:
libraries/restart-without-asking: false
// Link with -lutil
#include
#include
#include
#include
#include
#include
#include
static void sigchild(int dummy)
{
while (waitpid(-1,0,WNOHANG)>0);
}
int main()
{
int master, slave;
struct sigaction act;
sigemptyset(&act.sa_mask);
act.sa_flags=SA_RESTART;
act.sa_handler=sigchild;
sigaction(SIGCHLD,&act,0);
if (openpty(&master, &slave, 0, 0, 0))
{
printf("Failed: %s\n", strerror(errno));
return 1;
}
printf("Ok!\n");
return 0;
}
Bug#742965: libc0.1: openpty()/forkpty() fail on kfreebsd >=9.0
On Wed, Apr 02, 2014 at 09:45:23AM +0200, Petr Salinger wrote: > The problem is not the handler for SIGCHLD, but it's content. Yeah, same happens with SA_NOCLDWAIT, it's about whether the child gets reaped. > I doubt that the testcase worked under previous kernels. My bad, I did not test this particular testcase but a larger body of code, with tons of different pty code paths (handling IRIX, old SunOS and such) on different Debian releases, it probably did something else. The small test case behaves the same on 8.x and 9.x. Sorry for undertesting. > The openpty() uses internally fork and waitpid. > The waitpid in the testcase signal handler eats result needed by > openpty implementation. The offending code is in grantpt(), which openpty() calls. I wonder how to fix it. Merely documenting the restriction isn't really an option, as no widespread system has it. Saving the signal handler, disabling it then restoring would work but introduces a slight race condition (a child process can exit while we're in grantpt()). It's interesting what real FreeBSD does. Apparently, grantpt() is a no-op there: http://svnweb.freebsd.org/base/head/lib/libc/stdlib/ptsname.c?view=markup but blindly commenting out the calls to grantpt()+unlockpt() doesn't seem work to for us. Meow! -- A tit a day keeps the vet away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629245: the symlinks are there, pointing to a wrong place
On Mon, May 05, 2014 at 02:07:30AM -0700, Manoj Srivastava wrote: > On Sat, Mar 16 2013, Adam Borowski wrote: > > > ls -al /lib/modules/3.8.2-x32 > > lrwxrwxrwx 1 root root 36 Sep 27 04:09 build -> > > /home/kilobyte/tmp/kernel/linux-source-3.8 > > lrwxrwxrwx 1 root root 37 Sep 27 04:09 source -> > > /home/kilobyte/tmp/kernel/linux-source-3.8 > > Actually, not so: The postinst should take care of all this. The symlinks still point to the build dir as of a week ago, with kernel-package 12.036+nmu3. Can't test 13.00* as those versions fail building the kernel for me due to an unrelated bug (just reported). > > Please fix, this breaks dkms among others. > > The dkms issue might be something else. Do you have full logs for that? I don't have kernel build logs due to #747142, DKMS output is: Loading new virtualbox-4.3.10 DKMS files... Building only for 3.14.2-x32 Module build for the currently running kernel was skipped since the kernel source for this kernel does not seem to be installed. If I restore the source to that directory, all works ok. Should I downgrade kernel-package to produce a full log? -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747105: breaks unrelated packages
reopen 747105 kthxbye > non-sense. Per the policy, severity for "breaks unrelated software" is "critical". Thus, this bug is valid. Please explain to me why a wrapper that executes, among others, "pm-suspend" or "halt", would be related to an init system? Especially if those commands (which in turn _could_ be related!) work just fine without it. If you can't fathom a reason why systemd might not work for someone, please re-read some of massive flamewars we had, I'm not going to repeat the arguments here. As for policykit, though, basic functionality like being able to shutdown from xfce, is something not related to systemd in any way. -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748862: kernel-common: missing dependency on dpkg-dev
Source: kernel-common Version: 13.011 Severity: important Trying to install a kernel package built by recent kernel-package: /var/lib/dpkg/info/kernel-common.postinst: line 70: dpkg-architecture: command not found It can be found in dpkg-dev. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748866: reportbug: sometimes assumes src: without being told to
Package: reportbug Version: 6.5.0 Severity: normal In current unstable, when you type "reportbug kernel-common", reportbug somehow acts as if you wrote "reportbug src:kernel-common". There is no binary package by that name (kernel-common comes from src:kernel-package). It has existed in unstable for several days, so it's probably safe to assume whatever remote services reportbug queries know about it already. -- Package-specific info: ** Environment settings: EDITOR="jstar" EMAIL="kilob...@angband.pl" INTERFACE="text" ** /home/kilobyte/.reportbugrc: reportbug_version "3.17" mode advanced ui text -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.3-x32 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages reportbug depends on: ii apt 1.0.3 ii python2.7.6-2 ii python-reportbug 6.5.0 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils ii debsums2.0.52+nmu1 pn dlocate pn emacs22-bin-common | emacs23-bin-common ii exim4 4.82-8 ii exim4-daemon-light [mail-transport-agent] 4.82-8 ii file 1:5.18-1 ii gnupg 1.4.16-1.1 ii python-gtk22.24.0-3+b1 pn python-gtkspell pn python-urwid pn python-vte ii xdg-utils 1.1.0~rc1+git20111210-7.1 Versions of packages python-reportbug depends on: ii apt 1.0.3 ii python2.7.6-2 ii python-debian 0.1.21+nmu3 ii python-debianbts 1.11 ii python-support1.0.15 python-reportbug 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#748882: RFS: hashalot/0.3-6 (updated, resend)
Package: sponsorship-requests
Severity: normal
Hi guys! It would be nice if someone could upload "hashalot" for me
(a tool for securely reading a passphrase). This upload fixes a "must"
requirement of the policy.
The package can be dgetted from:
http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-6.dsc
The changelog is:
* Document that only the first line of input is hashed, for people who
are looking for a general purpose hasher. Closes: #544165.
* Fix warnings from man.
* Replace debian/rules with dh.
* Use DEP-5 copyright format.
* Drop useless README and ancient NEWS.Debian.
* Upgrade the VCS to git.
+ ... including Vcs- fields (closes: #720265).
* Upgrade to policy 3.9.5 (build-{arch,indep}), debhelper 9 (hardening).
The big change here is changing old style packaging to a dh two-liner.
Thus, it's probably easier to review this upload as a new package -- but
thanks to dh, that's quite minimal work.
Meow!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750497: don't use sysconf(_SC_SYMLOOP_MAX), please
I'm afraid this patch doesn't work. It makes the code compile, but if you
try to execute it, it will assume any symlinks form a loop.
The relevant snippet is:
if (++num_links > MAXSYMLINKS)
{
errno = ELOOP;
goto error;
}
which fails to execute if the returned value is -1. Linux' headers use an
arbitrary bogus value of MAXSYMLINKS 20 to let old code work, Hurd guys
decided that it's better for wrong code to fail at compilation stage.
It's the same story as MAX_PATH.
sysconf(_SC_SYMLOOP_MAX) returns -1 on Linux as well.
--
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going
on with replacing usable interfaces with tabletized ones?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750497: don't use sysconf(_SC_SYMLOOP_MAX), please
On Thu, Jun 05, 2014 at 07:23:48AM +, Mike Gabriel wrote:
> On Mi 04 Jun 2014 01:07:21 CEST, Adam Borowski wrote:
> >I'm afraid this patch doesn't work. It makes the code compile, but if you
> >try to execute it, it will assume any symlinks form a loop.
> >
> >The relevant snippet is:
> >if (++num_links > MAXSYMLINKS)
> >{
> >errno = ELOOP;
> >goto error;
> >}
> >which fails to execute if the returned value is -1. Linux' headers use an
> >arbitrary bogus value of MAXSYMLINKS 20 to let old code work, Hurd guys
> >decided that it's better for wrong code to fail at compilation stage.
> >It's the same story as MAX_PATH.
> >
> >sysconf(_SC_SYMLOOP_MAX) returns -1 on Linux as well.
>
> with so much background knowledge on this, do you think you can
> provide a patch for the patch?
>
> Should we simply set MAXSYMLINKS to this value of 20 instead?
I don't see much gain in trying to exhaust the system limit on pathological
symlink-to-symlink scenarios, so yeah, just setting this to 20 sounds a good
idea to me.
--
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going
on with replacing usable interfaces with tabletized ones?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750794: engrampa: please downgrade recommends:rpm2cpio to suggests:
Package: engrampa Version: 1.8.0+dfsg1-5 Severity: wishlist Hi! For some reason, engrampa automatically installs rpm2cpio (and its dependencies), while it merely suggests decompressors for a number of popular archivers. This seems wrong to me: RPM is by no way a general-purpose archiver. RPM files are pretty unlikely to be found on a Debian system, as well. Thus, I'd suggest downgrading rpm to a Suggests: It might be also a good idea to upgrade unzip and xz-utils to Recommends: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.0-rc8-x32+ (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages engrampa depends on: ii bzip21.0.6-5 ii caja-common 1.8.1-2 ii engrampa-common 1.8.0+dfsg1-5 ii gzip 1.6-3 ii libatk1.0-0 2.12.0-1 ii libc62.19-1 ii libcairo21.12.16-2 ii libcaja-extension1 1.8.1-2 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-0 2.24.23-1 ii libjson-glib-1.0-0 1.0.0-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-01.36.3-1 ii p7zip-full 9.20.1~dfsg.1-4.1 ii tar 1.27.1-2 Versions of packages engrampa recommends: ii gvfs 1.20.2-1 ii mate-icon-theme 1.8.0-1 pn rpm2cpio Versions of packages engrampa suggests: pn arj ii binutils 2.24.51.20140604-2 ii cpio 2.11+dfsg-2 pn lha pn lzip ii lzop 1.03-3 pn ncompress ii rar 2:4.2.0-1 pn rzip ii sharutils1:4.14-2 pn unace pn unalz ii unrar1:5.0.10-1 ii unzip6.0-12 ii xz-utils [lzma] 5.1.1alpha+20120614-2 ii zip 3.0-8 pn zoo -- 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#750798: mate-desktop-environment: please rename to mate{,-core,-extras}
Package: mate-desktop-environment Version: 1.8.0+2 Severity: wishlist Hi! Back in the day, this kind of metapackages used to be named foo-desktop-environment. This is no more, yet I see that for some reason MATE uses this old scheme. I'd say this is both inconsistent and confusing. A package named "mate-desktop" exists, yet it's not what one would expect. On the other hand, other desktop environments' metapackages are named: gnome lxde kde-standard xfce4 xfce4-goodies As 3/4 of these use just their short name, I'd suggest using just "mate" as well. Meow! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750798: mate-desktop-environment: please rename to mate{, -core, -extras}
On Sat, Jun 07, 2014 at 12:50:53PM +, Mike Gabriel wrote: > On Sa 07 Jun 2014 03:09:58 CEST, Adam Borowski wrote: > >Package: mate-desktop-environment > > > >Hi! > > > >Back in the day, this kind of metapackages used to be named > >foo-desktop-environment. This is no more, yet I see that for some reason > >MATE uses this old scheme. > > > >I'd say this is both inconsistent and confusing. A package named > >"mate-desktop" exists, yet it's not what one would expect. On the other > >hand, other desktop environments' metapackages are named: > > gnome > > lxde > > kde-standard > > xfce4 xfce4-goodies > >As 3/4 of these use just their short name, I'd suggest using just "mate" as > >well. > > I have been wondering about the reason of other packaging teams for > dropping that old naming scheme for desktop shell meta packages, as > I think it makes more sense than those short names we currently have > in Debian. > > If there is a consensus on such short names, I will follow that > consensus and rename bin:packages of the meta src:package > mate-desktop-environment. > > However, if it is just a matter of trendyness, I'd offer adding > "Provides: mate" resp. "Provides: mate-core", resp. "Provides: > mate-extras" to the different bin:package in src:package > mate-desktop-environment as a solution while keeping the current > bin:package names. > > Feedback? Comments? Probably the best place to colour bikesheds like this is -devel, let's see what folks have to say. My arguments for just "mate" are: * requires less searching from the user * no confusion with "mate-desktop" but your idea of using Provides: has some merit, too. Meow! -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751367: unupgradeable: "shared/packages-wordlist doesn't exist"
Package: dictionaries-common Version: 1.23.5 Severity: important Trying to upgrade dictionaries-common fails with: Setting up dictionaries-common (1.23.5) ... update-default-wordlist: Question empty but elements installed for class "wordlist" dictionaries-common/default-wordlist: return code: "0", value: "" Choices: , Manual symlink setting shared/packages-wordlist: return code: "10" owners/error: "shared/packages-wordlist doesn't exist" Installed elements: american (American English) Please see "/usr/share/doc/dictionaries-common/README.problems", section "Debconf database corruption" for recovery info. update-default-wordlist: Selected wordlist "" does not correspond to any installed package in the system and no alternative wordlist could be selected. dpkg: error processing package dictionaries-common (--configure): subprocess installed post-installation script returned error exit status 2 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.0-x32 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dictionaries-common depends on: ii debconf [debconf-2.0] 1.5.53 ii emacsen-common 2.0.8 ii libtext-iconv-perl 1.7-5+b1 dictionaries-common recommends no packages. Versions of packages dictionaries-common suggests: ii aspell0.60.7~20110707-1 ii wamerican [wordlist] 7.1-1 -- debconf information: dictionaries-common/selecting_ispell_wordlist_default: dictionaries-common/move_old_usr_dict: true dictionaries-common/old_wordlist_link: true dictionaries-common/remove_old_usr_dict_link: false dictionaries-common/ispell-autobuildhash-message: dictionaries-common/default-wordlist: dictionaries-common/invalid_debconf_value: dictionaries-common/default-ispell: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751367: unupgradeable: "shared/packages-wordlist doesn't exist"
On Thu, Jun 12, 2014 at 12:55:19PM +0200, Agustin Martin wrote: > On Thu, Jun 12, 2014 at 09:58:24AM +0200, Adam Borowski wrote: > > Trying to upgrade dictionaries-common fails with: > > > > Setting up dictionaries-common (1.23.5) ... > > update-default-wordlist: Question empty but elements installed for class > > "wordlist" > > dictionaries-common/default-wordlist: return code: "0", value: "" > > Choices: , Manual symlink setting > > shared/packages-wordlist: return code: "10" owners/error: > > "shared/packages-wordlist doesn't exist" > > Installed elements: american (American English) > > This is typically related to debconf database corruption. I've seen this bug before: around a year ago, I wiped /var/cache (or rather, didn't have it on backup), then a number of packages refused to upgrade -- despite failing to handle clearing of /var/cache being a RC bug. However, this would be strange in this case as dictionaries-common has been upgraded a number of times since then. Unless you changed it to require that key, without creating it first, during this upload. > > Please see "/usr/share/doc/dictionaries-common/README.problems", section > > "Debconf database corruption" for recovery info. > > Have you looked at this info? It should help recovering from debconf > database corruption. debconf (developer): <-- UNREGISTER shared/packages-wordlist debconf (developer): --> 10 shared/packages-wordlist doesn't exist dictionaries-common: (re)configuring ... debconf (developer): <-- METAGET shared/packages-ispell owners debconf (developer): --> 10 shared/packages-ispell doesn't exist > Note that dictionaries-common just triggers the error message because it > checks for consistency, but it does not mean that dictionaries-common is > causing the database corruption. > > By the way, which was your old dictionaries-common version? 1.23.4 -> 1.23.5 (daily updated unstable) -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751367: unupgradeable: "shared/packages-wordlist doesn't exist"
On Thu, Jun 12, 2014 at 03:06:47PM +0200, Agustin Martin wrote:
> On Thu, Jun 12, 2014 at 01:54:22PM +0200, Adam Borowski wrote:
> > On Thu, Jun 12, 2014 at 12:55:19PM +0200, Agustin Martin wrote:
> > > On Thu, Jun 12, 2014 at 09:58:24AM +0200, Adam Borowski wrote:
> > > > Trying to upgrade dictionaries-common fails with:
> > > >
> > > > Setting up dictionaries-common (1.23.5) ...
> > > > update-default-wordlist: Question empty but elements installed for
> > > > class "wordlist"
> > > > dictionaries-common/default-wordlist: return code: "0", value: ""
> > > > Choices: , Manual symlink setting
> > > > shared/packages-wordlist: return code: "10" owners/error:
> > > > "shared/packages-wordlist doesn't exist"
> > > > Installed elements: american (American English)
> Debconf database corruption might have happened for other reasons, and
> I'd expect it to have affected more packages.
>
> By the way, what "/var/cache/dictionaries-common/ispell-default" and
> "/var/cache/dictionaries-common" contain in your box?
/var/cache/dictionaries-common/ispell-default: notexistent
/var/cache/dictionaries-common:
drwxr-xr-x 1 root root 310 Feb 24 02:00 .
drwxr-xr-x 1 root root 230 May 15 15:47 ..
-rw-r--r-- 1 root root 741 Jun 12 13:49 aspell.db
-rw-r--r-- 1 root root 173 May 29 05:42 emacsen-ispell-default.el
-rw-r--r-- 1 root root 897 Jun 12 13:49 emacsen-ispell-dicts.el
-rw-r--r-- 1 root root 188 Jun 12 13:49 hunspell.db
-rw-r--r-- 1 root root 0 May 29 05:42 ispell-dicts-list.txt
-rw-r--r-- 1 root root 188 May 29 05:42 ispell.db
-rw-r--r-- 1 root root 881 Jun 12 13:49 jed-ispell-dicts.sl
-rw-r--r-- 1 root root 366 Jun 12 13:49 sqspell.php
-rw-r--r-- 1 root root 27 May 29 05:42 wordlist-default
-rw-r--r-- 1 root root 267 Jun 12 13:49 wordlist.db
> Did running "/usr/share/debconf/fix_db.pl" help?
Yes, it did. After running it, dictionaries-common upgraded successfully.
I do have a btrfs snapshot of the system from yesterday and before, though,
so further debugging is possible.
> As pointed out in
> "README.problems" document, you can also look about affected templates
> once run
>
> $ diff -u /var/cache/debconf/config.dat{-old,}| grep ^[+-]Name
empty
> $ diff -u /var/cache/debconf/templates.dat{-old,} | grep ^[+-]Name
empty
--
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going
on with replacing usable interfaces with tabletized ones?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751367: unupgradeable: "shared/packages-wordlist doesn't exist"
On Thu, Jun 12, 2014 at 06:24:09PM +0200, Agustin Martin wrote: > On Thu, Jun 12, 2014 at 05:40:17PM +0200, Adam Borowski wrote: > > > Debconf database corruption might have happened for other reasons, and > > > I'd expect it to have affected more packages. When testing on a quite large set of packages, only dictionaries-common seems to be affected. > Note that this debconf database corruption is unlikely to have its origin > in dictionaries-common, it is probably caused by the combination of a > package and special circumstances. If dictionaries-common was to blame I > would have received a flood of bug reports about this. Here's a reproducer: * install wheezy * install dictionaries-common * rm -rf /var/cache/* * dist-upgrade to jessie -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747142: caused by DEB_BUILD_OPTS=parallel=6
reopen 747142 retitle 747142 fails with DEB_BUILD_OPTIONS=parallel= kthxbye On Thu, May 08, 2014 at 07:21:20AM +, Debian Bug Tracking System wrote: > From the Problems file: > > w) If you build out of a kernel git repositoty, and if the >repository is not in a clean annotated or signed tagged >state and LOCALVERSION= is not specified. then the script >scripts/setlocalversion will append a plus sign to the >version. This creates a problem with the packaging tools. > >Solutions: >+ Create a LOCALVERSION variable in the kernel configuration >+ export a shell LOCALVERSION variable >+ create a signed or annotated tag. I'm afraid this doesn't help, the build failure happens regardless whether the tree is exactly at a tag or not (ie, whether there is a plus or not). Setting LOCALVERSION makes no difference as well. On the other hand, I just found out that the failure was caused by the following environment variable: DEB_BUILD_OPTIONS=parallel=6 Unsetting it allows the build to succeed. It's a new regression, caused by make 4.0. -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634259: #634259 - gnome-session: stop-multiple-users dialog fails to clear screen
On Wed, May 07, 2014 at 01:59:20PM +0100, althaser wrote: > Hey Adam, > > this is an old bug. > > Could you please still reproduce this issue with newer gnome-session > version like 3.4.2.1-4 or 3.8.4-3 ? I'm afraid I don't use Gnome[3] anymore, and installing it to test would take too much work because of hard-dependency on systemd gnome in unstable already has. Installing a fresh virtual machine would take quite a bit of time, too, so I'm sorry but I can't help test this bug right now. If I recall correctly, reproducing it back in 2011 (on Gnome 2) was a matter of trying to shutdown Gnome over 20ish times, with policykit forbidding the shutdown due to it believing there is another user logged on¹. Thus, the bug took quite an effort to reproduce. With the extent of changes Gnome underwent since then, I believe this report can be dropped unless someone else can test it. ¹ Those days, policykit had a race that _sometimes_ caused bogus failures if you had a root shell in a terminal in the session that was being torn down. Of course, you can force a legitimate failure by ssh-ing in from another machine, ie, having an actual other user. -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747142: closed
On Thu, May 08, 2014 at 04:33:20PM +, Debian Bug Tracking System wrote: > Hi, > > I ran the tests. First, from man make-kpkg: > --8<---cut here---start->8--- >WARNING: Do NOT set the -j option in MAKEFLAGS directly, this >shall cause the build to fail. Use CONCURRENCY_LEVEL as >specified below. There is also a -j flag that can be used. > --8<---cut here---end--->8--- > > This works: > make-kpkg -j 6 --rootcmd fakeroot --revision=$EXTRAVERSION > --append-to-version '-anzu' kernel_image > This fails: > DEB_BUILD_OPTIONS=parallel=6 make-kpkg --rootcmd fakeroot > --revision=$EXTRAVERSION --append-to-version '-anzu' kernel_image > So use the facilities provided by make-kpkg. This is still a > make bug, but is being tracked in #622863 and #714072 It fails even if I don't specify -j anywhere, just parallel=X. DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l` is the usual interface, used among others by dh --parallel, ie, the current fashion for packaging. It would be nice if make-kpkg could parse this option and convert it to CONCURRENCY_LEVEL. And somehow, it did work with make 3.82. Meow! -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629245: the symlinks are there, pointing to a wrong place
On Tue, May 06, 2014 at 07:30:58AM -0700, Manoj Srivastava wrote: > On Tue, May 06 2014, Adam Borowski wrote: > > > On Mon, May 05, 2014 at 02:07:30AM -0700, Manoj Srivastava wrote: > >> On Sat, Mar 16 2013, Adam Borowski wrote: > >> > >> > ls -al /lib/modules/3.8.2-x32 > >> > lrwxrwxrwx 1 root root 36 Sep 27 04:09 build -> > >> > /home/kilobyte/tmp/kernel/linux-source-3.8 > >> > lrwxrwxrwx 1 root root 37 Sep 27 04:09 source -> > >> > /home/kilobyte/tmp/kernel/linux-source-3.8 > > If this is not your build machine, are the symlinks dangling? > The image package postinst is supposed to remove them. On machines other than the build one, the "source" symlink has been removed, the "build" one correctly goes to /usr/src/linux-headers-3.14.3-x32 > If it is your build machine, then this is the current behaviour > to leave the links pointing to your build directory. This can of course > be overridden by adding your own postint file to the postinst.d > drectory. On the build machine, both "source" and "build" point to the directory the kernel happened to be built in, in my case in a directory owned by an user other than root. This leads to failures: * if I delete the unpacked sources, dkms fails to find installed linux-headers-XXX. This is likely when using packaged linux-source which embeds its version number in its top directory's name. * if I checkout some other version, dkms will build against the currently unpacked tree rather than installed linux-headers-XXX. This is likely when building from git. -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748228: NMU patch for kbtin_1.0.14-1.1
On Fri, May 16, 2014 at 09:36:35PM +1000, Aníbal Monsalve Salazar wrote: > My NMU patch for kbtin_1.0.14-1.1 is below, at the end of this > message. Looks like there's some work duplication: yesterday I prepared an upload fixing this and also a bunch of other problems, and sent a request to Bartosz Feński asking for sponsoring. He did not respond yet. I assumed no one would try an NMU the very next day. Had I not do the fix already, that would be welcome, but it led to work duplication instead. If you'd care before Bartosz finds some time, the upload is at: http://mentors.debian.net/debian/pool/main/k/kbtin/kbtin_1.0.15-1.dsc The only packaging change is adding V=y (the "verbose build logs" release goal), with a bunch of assorted bugfixes in the upstream tarball. The most important being an annoying segfault that often happens on window resize (introduced in 1.0.14). Meow! -- Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going on with replacing usable interfaces with tabletized ones? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742366: irssi-scripts: please include query-connection-notifier
Package: irssi-scripts Version: 20131030 Severity: wishlist Please include the following script: https://github.com/meh/random/blob/master/perl/irssi/query-connection-notifier.pl Without it, irssi reports only when a given person quits, which makes catching someone who connects only for brief periods pretty hard. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.7.10-vs2.3.5.6 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages irssi-scripts depends on: ii irssi 0.8.15-5.0kb2 ii perl 5.18.2-2+b1 Versions of packages irssi-scripts recommends: ii libwww-perl 6.05-2 Versions of packages irssi-scripts suggests: ii elinks [www-browser] 0.12~pre6-4 pn libdbi-perl ii net-tools 1.60-25 ii perl-modules 5.18.2-2 -- 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#742369: irssi-scripts: many scripts use ancient encodings
Package: irssi-scripts Version: 20131030 Severity: normal Tags: l10n A good deal of scripts include non-ASCII characters, and all which do so, with one exception, use some ancient encoding. This is bad for at least two reasons: 1. they may spew mangled characters to the user (you or others), and 2. as most scripts need to be RTFSed to see what they do, reading them is cumbersome. This is annoying in languages such as Polish that include characters with diacritics (quite a few scripts in this package are written in Polish). Debian uses UTF-8 by default for a decade, it should be safe to assume there are about no users of other locales other than C, which can't handle non-ASCII anyway. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.7.10-vs2.3.5.6 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages irssi-scripts depends on: ii irssi 0.8.15-5.0kb2 ii perl 5.18.2-2+b1 Versions of packages irssi-scripts recommends: ii libwww-perl 6.05-2 Versions of packages irssi-scripts suggests: ii elinks [www-browser] 0.12~pre6-4 pn libdbi-perl ii net-tools 1.60-25 ii perl-modules 5.18.2-2 -- 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#699185: fixed upstream, but symbols need updating
Hi! This bug has been fixed upstream, and the fix is included in what you uploaded this Thursday. However, the package still doesn't build due to the symbols file listing architectures by hand. A trivial patch attached. -- A tit a day keeps the vet away. --- debian/libnspr4.symbols~ 2014-02-08 02:50:41.0 +0100 +++ debian/libnspr4.symbols 2014-03-22 22:53:29.220110011 +0100 @@ -399,10 +399,10 @@ (arch=amd64 kfreebsd-amd64)_PR_x86_64_AtomicDecrement@Base 1.8.0.10 (arch=amd64 kfreebsd-amd64)_PR_x86_64_AtomicIncrement@Base 1.8.0.10 (arch=amd64 kfreebsd-amd64)_PR_x86_64_AtomicSet@Base 1.8.0.10 - (arch=i386 kfreebsd-i386 hurd-i386)_PR_x86_AtomicAdd@Base 1.8.0.10 - (arch=i386 kfreebsd-i386 hurd-i386)_PR_x86_AtomicDecrement@Base 1.8.0.10 - (arch=i386 kfreebsd-i386 hurd-i386)_PR_x86_AtomicIncrement@Base 1.8.0.10 - (arch=i386 kfreebsd-i386 hurd-i386)_PR_x86_AtomicSet@Base 1.8.0.10 + (arch=i386 kfreebsd-i386 hurd-i386 x32)_PR_x86_AtomicAdd@Base 1.8.0.10 + (arch=i386 kfreebsd-i386 hurd-i386 x32)_PR_x86_AtomicDecrement@Base 1.8.0.10 + (arch=i386 kfreebsd-i386 hurd-i386 x32)_PR_x86_AtomicIncrement@Base 1.8.0.10 + (arch=i386 kfreebsd-i386 hurd-i386 x32)_PR_x86_AtomicSet@Base 1.8.0.10 (arch=ia64)_PR_ia64_AtomicAdd@Base 1.8.0.10 (arch=ia64)_PR_ia64_AtomicDecrement@Base 1.8.0.10 (arch=ia64)_PR_ia64_AtomicIncrement@Base 1.8.0.10
Bug#68585: looks like it applies holds too late
Looking more closely (because it's especially bad for multiarch), I see that it appears to be caused by applying holds too late. Let's say we have the following versions and dependencies: A=1 (installed) A=2 Breaks: B B (installed, held) C (installed) Depends: B (or any similar scenario, in my case A having available versions A:amd64-2 and A:i386-1, B:i386 depending on A:i386) If the resolver wants to upgrade A to version 2, it will decide that it needs to remove B and C. It only then processes holds, marking B and (transitively) A as kept. C still remains marked for removal, even though any reason to do so is gone. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692171: missing Replaces:
reopen 692171 severity 692171 important retitle 692171 missing Replaces: iptables << 1.4.16.3-3 kthxbye There is a file conflict between previous version of binary:iptables and new libxtables9. An upgrade will thus fail, yet if iptables = 1.4.16.3-3 has been installed in the same dpkg run, all you need to clear the error is to retry. -- Sanity is for the weak. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606158: refreshed patch
Hi!
Here's Adrian's patch, rebased onto pbuilder 213.
Please apply, even on ext4 it makes a drastic speed-up.
From 2ebea361de614b5e482bc71432c71e80e9f40e02 Mon Sep 17 00:00:00 2001
From: Adam Borowski
Date: Sun, 16 Dec 2012 17:55:12 +0100
Subject: [PATCH] Eatmydata integration (Adrian von Bidder).
---
debian/control | 3 ++-
pbuilder| 2 +-
pbuilder-buildpackage-funcs | 2 +-
pbuilder-checkparams| 14 ++
pbuilder-createbuildenv | 12
pbuilder-modules| 6 ++
pbuilder-satisfydepends-checkparams | 4
pbuilder.8 | 6 +-
pdebuild-checkparams| 4
pdebuild-internal | 8
10 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/debian/control b/debian/control
index f4a1f94..47b77ad 100644
--- a/debian/control
+++ b/debian/control
@@ -31,7 +31,8 @@ Recommends: fakeroot,
devscripts
Suggests: pbuilder-uml,
gdebi-core,
- cowdancer
+ cowdancer,
+ eatmydata
Homepage: http://pbuilder.alioth.debian.org
Description: personal package builder for Debian packages
pbuilder constructs a chroot system, and builds a package inside the
diff --git a/pbuilder b/pbuilder
index d816183..4bfee48 100755
--- a/pbuilder
+++ b/pbuilder
@@ -69,7 +69,7 @@ File extracted to: $BUILDPLACE
"
fi
executehooks "F"
- (${CHROOTEXEC} bin/bash -c 'exec -a -bash bin/bash')
+ (${CHROOTEXEC} /bin/bash -c 'exec -a -bash bin/bash')
RET=$?
save_aptcache
diff --git a/pbuilder-buildpackage-funcs b/pbuilder-buildpackage-funcs
index 3083f03..98d6de1 100644
--- a/pbuilder-buildpackage-funcs
+++ b/pbuilder-buildpackage-funcs
@@ -50,7 +50,7 @@ function checkbuilddep () {
fi
# install extra packages to the chroot
if [ -n "$EXTRAPACKAGES" ]; then
- $CHROOTEXEC usr/bin/apt-get -q -y "${APTGETOPT[@]}" install ${EXTRAPACKAGES}
+ $CHROOTEXEC /usr/bin/apt-get -q -y "${APTGETOPT[@]}" install ${EXTRAPACKAGES}
fi
}
diff --git a/pbuilder-checkparams b/pbuilder-checkparams
index 3cdc48e..cf08d77 100755
--- a/pbuilder-checkparams
+++ b/pbuilder-checkparams
@@ -231,6 +231,10 @@ while [ -n "$1" ]; do
OUTPUTFILE[${#OUTPUTFILE[@]}]="$2";
shift; shift;
;;
+--no-eatmydata)
+EATMYDATA="no"
+ shift;
+;;
## internal options.
--internal-chrootexec)
@@ -321,6 +325,16 @@ fi
# sort BINDMOUNTS to ensure that deeper directories are mounted last
BINDMOUNTS="$(for i in $BINDMOUNTS; do echo $i; done | sort -u)"
+# enable eatmydata if available and not disabled
+if [ -f "/usr/lib/libeatmydata/libeatmydata.so" -a "$EATMYDATA" != "no" ]; then
+if [ -z "$LD_PRELOAD" ]; then
+export LD_PRELOAD="/usr/lib/libeatmydata/libeatmydata.so"
+else
+pbuilder_old_LD_PRELOAD="$LD_PRELOAD"
+export LD_PRELOAD="$LD_PRELOAD:/usr/lib/libeatmydata/libeatmydata.so"
+fi
+fi
+
if [ "$ALLOWUNTRUSTED" = "yes" ]; then
PBUILDERSATISFYDEPENDSOPT[${#PBUILDERSATISFYDEPENDSOPT[@]}]='--allow-untrusted'
# Also duplicated in pbuilder-satisfydepends-checkparams!
diff --git a/pbuilder-createbuildenv b/pbuilder-createbuildenv
index 8362b1c..40057f4 100755
--- a/pbuilder-createbuildenv
+++ b/pbuilder-createbuildenv
@@ -89,6 +89,12 @@ mkdir -p "$BUILDPLACE/tmp/buildd"
copy_local_configuration
installaptlines
add_additional_aptkeyrings
+
+# Can't use eatmydata while it is not yet installed in the chroot
+if echo "$LD_PRELOAD" | grep -q libeatmydata.so; then
+LD_PRELOAD="$pbuilder_old_LD_PRELOAD"
+fi
+
executehooks "G"
log "I: Refreshing the base.tgz "
@@ -112,6 +118,12 @@ else
EXTRAPACKAGES="$EXTRAPACKAGES ccache-"
fi
+if [ "$EATMYDATA" != "no" ]; then
+EXTRAPACKAGES="$EXTRAPACKAGES eatmydata"
+else
+EXTRAPACKAGES="$EXTRAPACKAGES eatmydata-"
+fi
+
if [ -n "$REMOVEPACKAGES" ]; then
# FIXME this wont work if the packages have some reverse dependencies;
# apt-get can also remove package, either with apt-get remove or purge, or
diff --git a/pbuilder-modules b/pbuilder-modules
index 5c935eb..ebf60ce 100644
--- a/pbuilder-modules
+++ b/pbuilder-modules
@@ -457,6 +457,12 @@ function extractbuildplace () {
mountproc
mkdir -p "$BUILDPLACE/tmp/buildd"
+
+# if available inside the chroot and if not disabled, use eatmydata:
+if [ -f "$BUILDPLACE/usr/lib/libeatmydata/libeatmydata.so" \
+-a "$EATMYDATA" != "no" ]; then
+CHROOTEXEC="$CHROOTEXEC eatmydata "
+fi
}
Bug#606158: refreshed patch
On Sun, Dec 16, 2012 at 05:49:02PM +, Thorsten Glaser wrote: > Adam Borowski dixit: > > >Please apply, even on ext4 it makes a drastic speed-up. > > It’s buggy: I admit, I haven't reviewed it beyond rebasing Adrian's work and checking that the basic functionality works. > pbuilder_old_LD_PRELOAD is not initialised in all > cases, and this can break (for example when already called with > eatmydata and pbuilder’s automatic one was disabled). So pbuilder_old_LD_PRELOAD="$LD_PRELOAD" needs to be moved before the "if". I'm not sure what should happen if eatmydata was already enabled but pbuilder is set to not use it. There's no regression, at least -- you might get some spam about the library not being present. > It also doesn’t catch the case where eatmydata isn’t available > outside of the build chroot but inside very well. Again a simple fix, but considering eatmydata's size, a simple dependency would be safer -- less moving parts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696105: irssi: line highlights on -mask don't work
Package: irssi Version: 0.8.15-5 Severity: normal Tags: patch upstream Hi! /hilight -line doesn't have any effect for -mask selectors. This bug has been reported upstream 7.5 years ago, and there's a patch rotting in the upstream bug tracker. http://bugs.irssi.org/index.php?do=details&task_id=275 Considering the glacial pace of irssi's development (a few commits per year), perhaps this bug could be patched in Debian? -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6-trunk-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages irssi depends on: ii libc6 2.16-0experimental1 ii libglib2.0-02.33.12+really2.32.4-3 ii libncurses5 5.9-10 ii libperl5.14 5.14.2-16 ii libssl1.0.0 1.0.1c-4 ii libtinfo5 5.9-10 ii perl5.14.2-16 ii perl-base [perlapi-5.14.2] 5.14.2-16 irssi recommends no packages. Versions of packages irssi suggests: pn irssi-scripts -- 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#608214: FTBFSIASW
Hi!
I believe this is FTBFSIASW, which is RC ("fails to build from source in a
sane way" -- a not-so-descriptive name for builds that technically succeed,
yet omit a good part of the package's content unless you manually do some
action during the build). You don't see that acronym often, as this problem
is on ftpmasters' checklist since quite some time and such a package won't
enter the archive in the first place. Yet lletters-media is both very old
and has only arch-indep parts so it has never been autobuilt.
The packaging also fails to fail on this error, which fools automated checks
(like Lucas Nussbaum's archive rebuilds).
I wouldn't be bringing up obscure RC categories, but the package seems to be
useless for a bunch of other reasons as well:
* clicking most buttons cause a crash
+ looking around, it's because of a hard assumption (not checked for!) of
OSS, which has been long dropped from Debian's kernels and for practical
purposes upstream as well
* GTK2 conversion is pretty incomplete
+ package description talks about technicalities of GTK1
+ no encoding handling (GTK2 uses UTF-8 internally), resulting in mojibake
* the code can be rewritten using a RAD tool in half an hour, or in a sane
language in not that much longer
* same for the data: you can find a more consistent set of better images on
a random site with freely licensed images in half an hour
* faulty locale detection
+ lletters look only at LANG, people tend to use LC_*
* in most locales, buttons tend to bring up no image, or a word from an
unrelated language
* it is dead upstream for 12 years
... and so on.
Thus, especially with the crashiness, are you sure it is fit for wheezy?
I'd suggest removing it from testing, and perhaps from unstable as well.
What would you say? Would it be better to request a removal, or try to fix
the problems?
(To be honest, what I really care about here is getting rid of #659345 in
some way, as lletters-media, the only package with filenames being invalid
UTF-8, stay in the way of a secret plan of mine.)
Meow!
--
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition. For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688905: filters: "scottish" adds stray dollar signs
Package: filters Version: 2.48 Severity: normal Tags: patch Hi! If the input includes words that end with "ally", the scottish filter will add '$' after them. The relevant rule is ally$:'lly$ -- there should be a dollar on the left side but not on the right. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-vserver-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages filters depends on: ii libc6 2.13-35 filters recommends no packages. Versions of packages filters suggests: pn bsdgames -- no debconf information --- scottish.old 2012-09-26 21:17:24.047724641 +0200 +++ scottish 2012-09-26 21:17:41.291725110 +0200 @@ -22,7 +22,7 @@ doesn't:don't at_a$:atta ith$:it' ered$:'red into$:inta ^before:'fore wit'_':wit_' wit'_t:wit_t wit'_w:wit_w - wit'_y:wit_y get_a:git_a ally$:'lly$ + wit'_y:wit_y get_a:git_a ally$:'lly ^my:me ^i_think$:methinks nay_w:na_w ^one$:'un ^'un_a:one_a at_ta$:atta ot_ta$:otta ^isn't$:ain't ^so_th:s'th
Bug#693249: RFS: etw/3.6+svn140-4 [RC] [ITA] arcade-style soccer game
On Sat, Nov 17, 2012 at 05:25:35PM -0500, Michael Gilbert wrote:
> I've just reviewed this, and it looks mostly good. I did notice
> things like the following:
>
> + FILE *f;
> ++char path[1024];
> ++sprintf(path, "%s/%s", getenv("HOME"), ".etw/etw.cfg" );
> + D(bug("Reading configuration...\n"/*-*/));
>
> Note that a hardcoded 1024 isn't very portable. C defines PATH_MAX
> for this purpose. Please use that instead.
1024 is more portable than PATH_MAX...
This define should have died a couple of decades ago, and it's kept only for
compat purposes. If you use it, you'll get a FTBFS on Hurd, as they decided
to force the issue and get rid of the blighter.
You can sometimes get suggestions to use pathconf(_PC_PATH_MAX), which is
even worse, as you'd be dynamically allocating a static buffer.
And obviously, the code above has a buffer overflow, no matter if you use
1024 bytes or PATH_MAX. You'd want asprintf() or an equivalent.
--
How to squander your resources: those silly Swedes have a sauce named
"hovmästarsås", the best thing ever to put on cheese, yet they waste it
solely on mere salmon.
signature.asc
Description: Digital signature
Bug#640499: hardening, too
Hi!
I just got bit by the lack of multiarch here (wine is broken on amd64 if
nvidia is involved), and wrote a multiarchification patch before realizing
there's already one here. It's redundant, except for one bit: since an
upload is needed anyway, you could just as well add the hardening flags
(another release goal). It's a trivial change, but "git am" is still faster
than doing that yourself...
(attached)
--
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition. For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623
From 3c4c72a1e62212952ce09834c1dd09ae9a02383e Mon Sep 17 00:00:00 2001
From: Adam Borowski
Date: Sat, 18 Aug 2012 03:55:26 +0200
Subject: [PATCH] Enable hardening flags.
---
debian/rules | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/debian/rules b/debian/rules
index 4ec442c..3900c51 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,12 +12,10 @@ PACKAGE = libxvmc1
include debian/xsfbs/xsfbs.mk
-CFLAGS = -Wall -g
-ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
- CFLAGS += -O0
-else
- CFLAGS += -O2
-endif
+CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
+CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
+LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
+
ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
MAKEFLAGS += -j$(NUMJOBS)
@@ -43,7 +41,8 @@ build-stamp:
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--sysconfdir=/etc --mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info $(confflags) \
- CFLAGS="$(CFLAGS)"
+ CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" \
+ LDFLAGS="$(LDFLAGS)"
cd build && $(MAKE)
>$@
--
1.7.10.4
signature.asc
Description: Digital signature
Bug#640499: hardening, too
On Sat, Aug 18, 2012 at 01:04:42PM +0200, Cyril Brulebois wrote: > Adam Borowski (18/08/2012): > > I just got bit by the lack of multiarch here (wine is broken on amd64 > > if nvidia is involved), and wrote a multiarchification patch before > > realizing there's already one here. It's redundant, except for one > > bit: since an upload is needed anyway > > given the intrusiveness of that patch [libxvmc/multiarch], I'm pretty > sure it's going to be considered too late in the release cycle. I'm > also pretty sure that we (release team) said that already for similar > packages. It stops a prominent package [wine] from working for a good part of users, so that's quite a motivation. It's your package, your call, of course. > [cc: release team for other opinions.] And theirs. > > you could just as well add the hardening flags (another release goal). > > It's a trivial change, but "git am" is still faster than doing that > > yourself... > > Thanks, but please note that requesting unrelated features in a given > bug report isn't too nice. I wanted to have them in one place, as both are release goals. > BTW, you call it trivial but you lost -Wall… Good point, that's not a case where hardening is really important too... so scratch this part. > Mraw, Hell yeah, mraw! > KiBi. 1KB (the real pre-committee 1024 :p). -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677864: alternative?
On Sat, Aug 18, 2012 at 06:38:47PM +0200, Julien Cristau wrote: > On Fri, Aug 17, 2012 at 09:21:00 +0200, Piotr Szydełko wrote: > > > For a time being I'm using the last version that was available but I would > > like to know what will happen when I install new instance of wheezy? Will > > there be a window manager that supports compositing? > > gnome and kde both have window managers that support compositing. > There's probably others. Neither of those support even a decent fraction of compiz' features, both for those who want eyecandy, and those like me who want features like instant zoom, making arbitrary windows partially transparent, colour filters, etc. This said, I realized that no one I know uses compiz without at least some parts not included in Debian, and even though it works well after some tinkering, the need for such tinkering is not something a new user would expect from Debian. Thus, the extent of polishing needed exceeds what would be acceptable at this time of the freeze. Also, no one stepped up to do this. I for one can submit a FTBFS fix here and a random patch there, but don't know window manager interactions well enough to take a major part of responsibility. There's hope guys who want Unity will need to handle the upgrade to Compiz 9.* as it's an Unity's dependency even if it can still work with XFCE or MATE, but considering that nothing really moved in ages, I wouldn't hold my breath. So in other words: let's return here after Wheezy :( Meow! -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556796: not related to #540150
Seems that creating the symlink doesn't let git-svn succeed on a large repository, so this bug appears to be unrelated to #540150. Thus, I agree with the closing -- if anything else was moved from "git-foo" to "git foo", there's no reason for git-svn to be any different. -- 1KB // Yo momma uses IPv4! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#633845: initscripts: unupgradeable on vserver
On Tue, Jun 26, 2012 at 10:14:03PM +0100, Roger Leigh wrote: > Just a quick ping on this bug. > > Are vservers now working OK with the current ischroot implementation, > or is further work needed here? According to exhaustive testing by upgrading a single random vserver from squeeze to unstable, seems to work fine now. -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678575: wheezy has Icedove 10
Wheezy has stable Icedove 10, rather than one of later snapshots (I kind of refuse to call them releases). Thus, if you have an incompatible version of it, you have non-wheezy apt sources anyway. It would be nice to have a newer version of firetray, but only if it works with Icedove 10 as well. In any case, I wouldn't call this bug RC for wheezy. -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659345: lletters-media: uninstallable on some filesystems
Package: lletters-media Version: 0.1.9a-4 Severity: important This package contains files whose names are not valid UTF-8, but use a smattering of obsolete national encoding. This means, they cannot be accessed on filesystems that store names as a set of Unicode codepoints rather than an arbitrary byte string. These include JFS with iocharset=utf8, ZFS, etc. A list can be found at https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits If you still care about ancient encodings, they will accept a filename with mangled characters, so there's at least no installability problem. And modern graphical environments don't support such locales anymore anyway, so I wouldn't even care about them. -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash lletters-media depends on no packages. Versions of packages lletters-media recommends: ii lletters 0.1.95+gtk2-3 GTK letters-learning game for smal lletters-media 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#606158: Adrian's patch is attached
> Sounds interesting, except for that I don't see a patch actually attached. It's an attachment: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=13;filename=eatmydata.patch;att=1;bug=606158 -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679903: ftp.debian.org: please create an empty wheezy-updates repository
Package: ftp.debian.org Severity: wishlist Hi! Now that wheezy is frozen, a number of adventureous admins are going to play with upgrading test or unimportant systems, for a number of reasons. Such upgrades start with adding wheezy to sources.list. And here's a problem: if any of repositories there don't exist yet, the error will break some automated scripts, cause cron spam, etc. This means, people will remove wheezy-updates, and that's something one is extremely likely to forget to enable back. Thus, could you please put empty files there, so the final configuration will already work? Once wheezy-updates actually launch, they'll overwrite those empty files with actual data. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#647522: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote: > For those not subscribed to that bug, how to reproduce[1] and possible > fix[2] are available now. There might be other places where buffers are > reused, I only spent a few minutes on this during my lunch break. > > 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=60;bug=647522 Even if you ensure a particular build behaves exactly the same on a given architecture, you're merely introducing future problems. gzip's output is likely to change: * on a new version * after a bugfix (including security ones) * on a different architecture * with different optimizations * with a different implementation (like those parallel ones) * possibly with a different moon phase Especially the first is pretty guaranteed to bite: whenever the upstream does a small improvement, binaries in the archive get invalidated until rebuilt with the new gzip. Breaking the ideas for diverting /bin/gzip by pigz is not nice, too. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542095: N-M: Depends->Recommends (was: Re: duplicates in the archive)
On Mon, Jul 09, 2012 at 07:46:52PM +0100, Ian Jackson wrote:
> Adam Borowski writes ("Re: duplicates in the archive"):
> > "Breaks unrelated software" on the system is a RC severity, and there's no
> > way one can say a windowing environment is related to core networking.
> > Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to
> > Recommends: is a non-intrusive fix. It will cause n-m to be installed
> > unless explicitely refused, just like you want it to be.
>
>I tested a good part of Gnome today without n-m and it appears there
>are no regressions at all. The only differences are:
>
>* it gets rid of n-m icon in the systray (duh)
Actually, the very mail you reference, contains an continuation (with
apologies for accidentally pressing 'y' instead of 'q'):
} [was incomplete]
} * "network settings" deep in the control panel will say the networking on
}this system is not compatible
and also, as Philipp Kern noticed before, things that use N-M to distinguish
between online and offline modes will think they're offline after
uninstalling N-M until they are restarted.
Of course, none of the three are a big deal, at least comparing to not being
able to connect a phone or use complex networking.
--
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition. For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623
signature.asc
Description: Digital signature
Bug#678784: fix for FTBFS in 0.8.4-8.2
Here's a fix for the FTBFS.
It has been broken by a change recently introduced in KDE 4.8.
--
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition. For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623
>From bd1eb33d577e3aadf3d71666d665eaac5ca7d2af Mon Sep 17 00:00:00 2001
From: Adam Borowski
Date: Thu, 12 Jul 2012 02:36:02 +0200
Subject: [PATCH] Resolve a conflict between X11 Region and kdecoration
Region.
The latter is a (pointless for now) enum that has been added in KDE 4.8.
---
kde/window-decorator-kde4/window.cpp |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kde/window-decorator-kde4/window.cpp b/kde/window-decorator-kde4/window.cpp
index ecf3a63..279300c 100644
--- a/kde/window-decorator-kde4/window.cpp
+++ b/kde/window-decorator-kde4/window.cpp
@@ -890,10 +890,10 @@ KWD::Window::updateBlurProperty (int topOffset,
{
Atomatom = Atoms::compizWindowBlurDecor;
QRegion topQRegion, bottomQRegion, leftQRegion, rightQRegion;
-Region topRegion = NULL;
-Region bottomRegion = NULL;
-Region leftRegion = NULL;
-Region rightRegion = NULL;
+::Region topRegion = NULL;
+::Region bottomRegion = NULL;
+::Region leftRegion = NULL;
+::Region rightRegion = NULL;
int size = 0;
int w, h;
--
1.7.10.4
Bug#677864: compiz works just fine
Could you please elaborate what exactly is the problem with compiz 0.8? It works well; I use it at home (currently with xfce) and the only problem is remembered window positions being wrong on startup. At least the situation is worlds better than the current state of certain other window managers that are somehow made default. So I don't think there is a reason for this artificial RC bug, just because a newer but messy upstream version exists. I agree with Alex Goebel: compiz in its current state is fully releaseable, even if it's not at the bleeding edge. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
