Bug#1064071: RFP: hipblaslt -- portable interface for extended general matrix-matrix operations
retitle 1064071 ITP: hipblaslt -- portable interface for extended general matrix-matrix operations owner 1064071 k...@debian.org thanks Hop.
Bug#1063741: ITP: hipify -- CUDA to HIP source-to-source translation tools
Hi, I had a look. Looks simple enough but the control file needs one change at least. On Sun, Feb 11, 2024 at 03:40:43PM -0700, Cordell Bloor wrote: > hipify is a set of tools to convert CUDA sources into HIP sources. It > provides hipify-clang, which uses a clang-based parser and can therefore > translate complex C++ constructs, but requires complete input sources, > including access to any CUDA headers used. For cases where this is not If CUDA headers are a necessity then the section for hipify-clang needs to be contrib/devel, not devel. That's for free software that has dependencies on non-free software. Also, it should have a dependency on nvidia-cuda-dev. Unless its reasonable to assume CUDA users to get their headers otherwise but even in that case the section needs to be contrib/devel. > possible, it provides hipify-perl, which uses a simple perl-based parser hipify-perl is fine with regular devel section. Either package didn't include any documentation and there's no -doc package, which isn't really ideal. There is the docs directory and it could be used, but even without going for it I would suggest a README.Debian with a note about documentation being available at https://rocmdocs.amd.com/projects/HIPIFY/en/latest/. Strictly optional but something I'd like to see: Have an example .cu file to use hipify on to test the package. Can any of the unit test files serve the purpose?
Bug#1061219: Please upgrade to llvm-toolchain-17
On Sat, Feb 17, 2024 at 09:25:29AM +0100, Petter Reinholdtsen wrote: > I tried switching to a newer llvm package, but it seem to me the > libmlir-14-dev and mlir-14-tools content changed in a way that break the > build with newer llvm versions. Not sure how to work around this, not > skilled enough with cmake to figure out a solution so far. My suggestion: upgrade to the new upstream version. Triton 2.1.0 has support for newer LLVM. I just tried it and the cmake configuration succeeded with LLVM 17 (though I needed to patch lib/Dialect/TritonGPU/IR/CMakeLists.txt and lib/Conversion/TritonGPUToLLVM/CMakeLists.txt with s/MLIRGPUOps/MLIRGPUDialect/). I still got some compile errors after that that I don't unfortunately have time to look further into right now. I guess 2.1.0 would work out of the box with LLVM 16, but I'd wager it's still much closer to working with LLVM 17 than Triton 2.0.0 would be.
Bug#1063388: ITP: chuffed -- lazy clause generation CP solver
Package: wnpp Severity: wishlist Owner: Kari Pahula X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: chuffed Version : 0.13.1 * URL : https://github.com/chuffed/chuffed * License : MIT/X Programming Lang: C++ Description : lazy clause generation CP solver Chuffed is a state of the art lazy clause solver designed from the ground up with lazy clause generation in mind. Lazy clause generation is a hybrid approach to constraint solving that combines features of finite domain propagation and Boolean satisfiability. It combines some of the advantages of finite domain constraint programming (high level model and programmable search) with some of the advantages of SAT solvers (reduced search by nogood creation, and effective autonomous search using variable activities). Chuffed only supports 3 different propagator priorities. Chuffed implements a number of global propagators (alldiff, inverse, minimum, table, regular, mdd, cumulative, disjunctive, circuit, difference). It also only supports two kinds of integer variables. Small integer variables for which the domain is represented by a byte string. And large integer variables for which the domain is represented only by its upper and lower bound (no holes allowed). All boolean variables and boolean constraints are handled by the builtin SAT solver. The solver, when run with lazy clause generation disabled, is somewhat comparable in speed with older versions of Gecode. The overhead from lazy clause generation ranges from negligible to perhaps around 100%. The search reduction, however, can reach orders of magnitude on appropriate problems. Thus lazy clause generation is an extremely important and useful technology. The easiest way to use Chuffed is as a backend to the MiniZinc constraint modelling language. Chuffed can also be used as a C++ library. The description is edited from upstream's description, it went into more detail than this about the implementation. For certain types of CP problems it works better than the alternatives. Chuffed is both a library and it provides a binary (fzn-chuffed). The library can be used as a dependency for both minizinc and minizinc-ide (which I maintain) and it provides an alternative flatzinc implementation for minizinc. I plan to maintain this under the Debian Science team. As of now upstream is building chuffed as a static library only but I'll try to convince them to provide a shared library before packaging it.
Bug#1060225: protobuf: Install proto_api.h
Source: protobuf Version: 3.21.12-8 Severity: wishlist For some reason, protobuf doesn't apparently install python/google/protobuf/proto_api.h anywhere. For example https://github.com/pybind/pybind11_protobuf uses it with an #include which it assumes to find under "python" directory after fetching it with cmake. For packaging use that won't work and it'd help to have it available in protobuf's packages. I'm not quite sure whether python3-protobuf or libprotobuf-dev would be a better choice. Probably latter.
Bug#1031035: RM: crossfire-maps-small -- ROM; Obsolete package, low popcon, one map set should be enough
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: crossfire-maps-sm...@packages.debian.org, 965474-submit...@bugs.debian.org Control: affects -1 + src:crossfire-maps-small Let's just remove this old thing.
Bug#1031033: O: cxxtools -- library of unrelated but useful C++ classes
Package: wnpp Severity: normal X-Debbugs-Cc: cxxto...@packages.debian.org Control: affects -1 + src:cxxtools I intend to orphan the cxxtools package. The package description is: cxxtools contains an argument-parser, a base-64 encoder/decoder, a C++ interface to iconv, md5-stream for easy MD5 calculation, threading classes, socket classes, a dynamic exception-safe buffer, a wrapper for dlopen/dlsym, a pool template (e.g., for a connection pool in a multi-threaded application), query_params, and a class for easy parsing of CGI parameters (GET and POST) in a CGI program. . This package has the development headers and the static libraries.
Bug#1031032: O: tntdb -- Development headers for tntdb
Package: wnpp Severity: normal X-Debbugs-Cc: tn...@packages.debian.org Control: affects -1 + src:tntdb I intend to orphan the tntdb package. Not in testing currently so likely to miss bookworm. The package description is: This library provides a thin, database independent layer over an SQL database. It lacks complex features like schema queries or wrapper classes like active result sets or data bound controls. Instead you get to access the database directly with SQL queries. The library is suited for application programming, not for writing generic database handling tools. . Currently has support for MySQL, PostgreSQL and SQLite.
Bug#1031031: O: tntnet -- modular, multithreaded web application server for C++
Package: wnpp Severity: normal X-Debbugs-Cc: tnt...@packages.debian.org Control: affects -1 + src:tntnet I intend to orphan the tntnet package. Not in testing currently and unfortunately bookworm will likely not have it. The package description is: Tntnet has a template-language called ecpp similar to PHP, JSP or Mason, where you can embed c++ code inside a HTML page to generate active content. The ecpp files are precompiled to C++ classes called components and compiled and linked into a shared library. This process is done at compiletime. The web server Tntnet needs only the compiled component library. . Because the web applications are compiled into native code, they are very fast and compact. . Components can call other components. So you can create building blocks of HTML parts and call them in other pages like subprocesses. . Requests are parsed by tntnet and the request information is easily accessible to the components. It supports GET and POST parameters and MIME multipart requests for file upload. . The template language has also support for internationalized applications. You can easily create web applications for different languages. . Other features are: cookies, HTTP upload, automatic request parameter parsing and conversion, automatic session management, scoped variables (application, request and session), internationalisation and keep-alive. . Logging is done through cxxtools, which provides a unique API for log4cpp, log4cxx or simple logging to files or console. . Tntnet is fully multithreaded and much work has been gone into making it scalable. It uses a dynamic pool of worker threads, which answer requests from HTTP clients.
Bug#992617: xserver-xorg-video-radeon: Screen rotate doesn't work
reassign 992617 libgl1-mesa-dri found 992617 21.2.1-1 retitle 992617 startx freezes on Radeon HD 6570 with GPU hangs, no acceleration thanks On Fri, Aug 27, 2021 at 12:20:55PM +0200, Michel Dänzer wrote: > What else changed on the system since it was last working? E.g. if > Mesa packages were upgraded, it's worth trying to downgrade > those. Or maybe xserver-xorg-video-radeon. I tested a bit more. Mesa 18.3.6 was fine and so was 20.3.5 as well. 18.3.6 had incomplete dependencies so now the whole set of latest packages confirmed to work is: libegl-mesa020.3.5-1 libgbm1 20.3.5-1 libgl1-mesa-dri 20.3.5-1 libglapi-mesa 20.3.5-1 libglx-mesa020.3.5-1 The rest of the system is at current unstable versions.
Bug#992617: xserver-xorg-video-radeon: Screen rotate doesn't work
On Fri, Aug 27, 2021 at 12:20:55PM +0200, Michel Dänzer wrote: > What else changed on the system since it was last working? E.g. if > Mesa packages were upgraded, it's worth trying to downgrade > those. Or maybe xserver-xorg-video-radeon. Ok, I downgraded libegl-mesa0, libgdbm1 and libgl1-mesa-dri to version 18.3.6-2+deb10u1. It's not the version I had in run prior to this all but it was what was readily available in Debian. I'm having no issues after the downgrade. startx worked right away, acceleration works, rotate works and no stalls reported in dmesg log.
Bug#992617: xserver-xorg-video-radeon: Screen rotate doesn't work
On Sat, Aug 21, 2021 at 12:17:02PM +0200, Michel Dänzer wrote: > > DRM Information from dmesg: > > --- > > > > > > Since there are no DRM driver related messages in dmesg, looks like > something is preventing the radeon kernel driver from loading at > all. If you're passing nomodeset on the kernel command line, remove > that. Otherwise, full dmesg output would be needed to diagnose. I'm not using nomodeset. I've attached a dump from dmesg after a reboot. That "ring 0 stalled" message doesn't look promising at all. Actually, when I first tried running startx it just stopped after showing the initial log messages to tty, while occasionally blinking my screens black. I did a kill -9 on the Xorg process and then startx worked when I tried it again, but I guess it gave up on any acceleration at that point. I tried booting the last kernel I had (linux-image-5.10.0-4) and the one from Buster but those didn't solve anything. [0.00] Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03) [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.10.0-8-amd64 root=/dev/mapper/corsair-root ro quiet [0.00] random: get_random_u32 called from bsp_init_amd+0x284/0x2c0 with crng_init=0 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xba6e9fff] usable [0.00] BIOS-e820: [mem 0xba6ea000-0xba719fff] reserved [0.00] BIOS-e820: [mem 0xba71a000-0xba729fff] ACPI data [0.00] BIOS-e820: [mem 0xba72a000-0xbb531fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb532000-0xbca33fff] reserved [0.00] BIOS-e820: [mem 0xbca34000-0xbca34fff] usable [0.00] BIOS-e820: [mem 0xbca35000-0xbcc3afff] ACPI NVS [0.00] BIOS-e820: [mem 0xbcc3b000-0xbd082fff] usable [0.00] BIOS-e820: [mem 0xbd083000-0xbd7f3fff] reserved [0.00] BIOS-e820: [mem 0xbd7f4000-0xbd7f] usable [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfec2-0xfec20fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed61000-0xfed70fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfef0-0x] reserved [0.00] BIOS-e820: [mem 0x00011000-0x00083eff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: To be filled by O.E.M. To be filled by O.E.M./SABERTOOTH 990FX R2.0, BIOS 2901 05/04/2016 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 4013.328 MHz processor [0.001431] e820: update [mem 0x-0x0fff] usable ==> reserved [0.001433] e820: remove [mem 0x000a-0x000f] usable [0.009268] AGP: No AGP bridge found [0.009338] last_pfn = 0x83f000 max_arch_pfn = 0x4 [0.009342] MTRR default type: uncachable [0.009342] MTRR fixed ranges enabled: [0.009344] 0-9 write-back [0.009345] A-B write-through [0.009345] C-C write-protect [0.009346] D-EAFFF uncachable [0.009347] EB000-F write-protect [0.009348] MTRR variable ranges enabled: [0.009349] 0 base mask 8000 write-back [0.009350] 1 base 8000 mask C000 write-back [0.009351] 2 base BD80 mask FF80 uncachable [0.009352] 3 base BE00 mask FE00 uncachable [0.009353] 4 disabled [0.009354] 5 disabled [0.009354] 6 disabled [0.009355] 7 disabled [0.009356] TOM2: 00083f00 aka 33776M [0.010192] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.010307] e820: update [mem 0xbd80-0x] usable ==>
Bug#992617: xserver-xorg-video-radeon: Screen rotate doesn't work
Package: xserver-xorg-video-radeon Version: 1:19.1.0-2 Severity: normal $ xrandr --output DVI-0 --rotate left xrandr: output DVI-0 cannot use rotation "left" reflection "none" $ xrandr -o left X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 2 (RRSetScreenConfig) Serial number of failed request: 14 Current serial number in output stream: 14 This used to work. I don't know which versions I had in run before but my uptime before last reboot was 158 days. I searched about it and some forum posts suggested using Option "RandRRotation" but that only resulted a log message 'Option "RandRRotation" is not used'. My laptop with Ryzen R5 PRO 4650U can run xrandr -o left just fine. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jan 24 2012 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Apr 13 19:07 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550 / R5 230] [1002:6759] /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 4 -rw-r--r-- 1 root root 113 Aug 21 02:50 05-device.conf~ KMS configuration files: /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03) Xorg X server log files on system: -- -rw-r--r-- 1 root root 68636 Feb 17 2013 /var/log/Xorg.1.log -rw-r--r-- 1 kaol kaol 47399 Aug 21 02:26 /home/kaol/.local/share/xorg/Xorg.0.log -rw-r--r-- 1 kaol kaol 68333 Aug 21 03:11 /home/kaol/.local/share/xorg/Xorg.1.log -rw-r--r-- 1 root root 63322 Aug 21 11:49 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 33984.277] X.Org X Server 1.20.11 X Protocol Version 11, Revision 0 [ 33984.277] Build Operating System: linux Debian [ 33984.277] Current Operating System: Linux sammakko3 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 [ 33984.277] Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-8-amd64 root=/dev/mapper/corsair-root ro quiet [ 33984.277] Build Date: 13 April 2021 04:07:31PM [ 33984.277] xorg-server 2:1.20.11-1 (https://www.debian.org/support) [ 33984.277] Current version of pixman: 0.40.0 [ 33984.277]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 33984.277] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 33984.277] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Aug 21 11:48:57 2021 [ 33984.277] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 33984.277] (==) No Layout section. Using the first Screen section. [ 33984.277] (==) No screen section available. Using defaults. [ 33984.277] (**) |-->Screen "Default Screen Section" (0) [ 33984.277] (**) | |-->Monitor "" [ 33984.278] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 33984.278] (==) Automatically adding devices [ 33984.278] (==) Automatically enabling devices [ 33984.278] (==) Automatically adding GPU devices [ 33984.278] (==) Max clients allowed: 256, resource mask: 0x1f [ 33984.278] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 33984.278]Entry deleted from font path. [ 33984.278] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 33984.278] (==) ModulePath set to "/usr/lib/xorg/modules" [ 33984.278] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 33984.278] (II) Loader magic: 0x559c08ffee40 [ 33984.278] (II) Module ABI versions: [ 33984.278]X.Org ANSI C Emulation: 0.4 [ 33984.278]X.Org Video Driver: 24.1 [ 33984.278]X.Org XInput driver : 24.1 [ 33984.278]X.Org Server Extension : 10.0 [ 33984.278] (++) using VT number 7 [ 33984.278] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 33984.280] (II) xfree86: Adding drm device (/dev/dri/card0) [ 33984.289] (--) PCI:*(1@0:0:0) 1002:6759::
Bug#970629: xserver-xorg-video-radeon: rotating screen with xrandr locks up displays and keyboard
Package: xserver-xorg-video-radeon Version: 1:19.1.0-2 Severity: normal I have three monitors and I keep one of them in vertical orientation. I had to reboot my system and afterwards, rotating with xrandr doesn't work. Running xrandr --output DVI-0 --rotate left apparenlty copies the contents of another display to it but it's not rotated and the image on that screen doesn't change anymore after that, no matter what I do. Running xrandr --output DVI-0 --rotate normal to try to reset the situation locks up my screens and input devices. As does trying to go to the console with Ctrl-Shift-Fn. I can still SSH into my system and running kill -9 on the Xorg process resolves the situation. I don't know which versions of X software I had in use before the reboot, I think they were still at whatever was current when Linux 5.5.0 was the newest in unstable. I tried to downgrade a few packages to stable's versions but I didn't find one that would have solved the bug. I've switched to using xserver-xorg-video-vesa for now. It has no trouble with rotating my screen. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jan 24 2012 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Aug 31 18:49 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550] [1002:6759] /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 0 KMS configuration files: /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 5.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 (2020-09-05) Xorg X server log files on system: -- -rw-r--r-- 1 root root 68636 Feb 17 2013 /var/log/Xorg.1.log -rw-r--r-- 1 root root 64288 Jul 15 2019 /var/log/Xorg.0.log -rw-r--r-- 1 kaol kaol 65690 Sep 20 11:34 /home/kaol/.local/share/xorg/Xorg.0.log Contents of most recent Xorg X server log file (/home/kaol/.local/share/xorg/Xorg.0.log): - [ 1824.900] X.Org X Server 1.20.9 X Protocol Version 11, Revision 0 [ 1824.900] Build Operating System: Linux 4.19.0-10-amd64 x86_64 Debian [ 1824.900] Current Operating System: Linux sammakko3 5.8.0-1-amd64 #1 SMP Debian 5.8.7-1 (2020-09-05) x86_64 [ 1824.900] Kernel command line: BOOT_IMAGE=/vmlinuz-5.8.0-1-amd64 root=/dev/mapper/corsair-root ro quiet [ 1824.900] Build Date: 31 August 2020 03:49:48PM [ 1824.900] xorg-server 2:1.20.9-1 (https://www.debian.org/support) [ 1824.900] Current version of pixman: 0.36.0 [ 1824.900]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1824.900] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1824.900] (==) Log file: "/home/kaol/.local/share/xorg/Xorg.0.log", Time: Sun Sep 20 11:26:33 2020 [ 1824.901] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 1824.901] (==) No Layout section. Using the first Screen section. [ 1824.901] (==) No screen section available. Using defaults. [ 1824.901] (**) |-->Screen "Default Screen Section" (0) [ 1824.901] (**) | |-->Monitor "" [ 1824.901] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 1824.901] (==) Automatically adding devices [ 1824.901] (==) Automatically enabling devices [ 1824.901] (==) Automatically adding GPU devices [ 1824.901] (==) Max clients allowed: 256, resource mask: 0x1f [ 1824.901] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 1824.901]Entry deleted from font path. [ 1824.901] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 1824.901] (==) ModulePath set to "/usr/lib/xorg/modules" [ 1824.901] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 1824.901] (II) Loader magic: 0x55d0e7a13e20 [ 1824.901] (II) Module ABI versions: [ 1824.901]X.Org ANSI C Emulation: 0.4 [ 1824.901]X.Org Video Driver: 24.1 [ 1824.901]X.Org XInput driver : 24.1 [ 1824.901]X.Org Server Extension : 10.0 [ 1824.902] (++) using VT number 1 [ 1824.906] (II) systemd-logind: took
Bug#959416: RM: pxsl-tools -- ROM; ROM; low popcon
Package: ftp.debian.org Severity: normal I thought I'd use pxsl when I packaged it but I never did. Very few other people do either.
Bug#947885: transition: gecode
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I'm about to update gecode from 6.1.0 to 6.2.0 in unstable. SONAME changes from 48 to 49. The only reverse dependency is minizinc which I also maintain. Transitively minizinc-ide as well. All of these have had new versions uploaded to experimental. Strictly speaking, the minizinc version in unstable doesn't depend on the library itself but only on flatzinc which is also built from the gecode source package. But the version in experimental would add a dependency on the library. Ben file: title = "gecode"; is_affected = .depends ~ "libgecode48" | .depends ~ "libgecodegist48" | .depends ~ "libgecodeflatzinc48" | .depends ~ "libgecode49" | .depends ~ "libgecodegist49" | .depends ~ "libgecodeflatzinc49"; is_good = .depends ~ "libgecode49" | .depends ~ "libgecodegist49" | .depends ~ "libgecodeflatzinc49"; is_bad = .depends ~ "libgecode48" | .depends ~ "libgecodegist48" | .depends ~ "libgecodeflatzinc48"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#928903: ITP: piperka-client -- Mobile oriented web comics reader client
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: piperka-client Version : 0.2.1 Upstream Author : Kari Pahula * URL : https://gitlab.com/piperka/client * License : GPLv2 or later Programming Lang: C++ Description : Mobile oriented web comics reader client Piperka is a web comic tracking and bookmarking service with over 6000 comics listed on it. It doesn't host any web comics by itself but maintains a list of them and an index of their archive pages. . Piperka Client uses Piperka's database to provide browsing and navigation for web comics' archives in a unified manner with an embedded browser. It stores user's bookmarks and periodically contacs the server to check for any updates to the comics that a user reads. . This program is geared towards mobile use. I originally wrote this app for Sailfish and then implemented a generic Qt mobile oriented version of it, mainly to get it to Android. Packaging it for Debian is a low hanging fruit so why not. I haven't actually tagged a 0.2.1 yet but will do so soon.
Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries
tags 926182 + patch
thanks
Hi.
/usr/bin/guile uses alternatives system and the real binary is under
/usr/lib, as well as providing /usr/bin/guile-2.2 as a symlink.
My patch gives the same treatment for the binaries in guile-2.2-dev.
diff -Nru guile-2.2-2.2.4+1/debian/changelog guile-2.2-2.2.4+1/debian/changelog
--- guile-2.2-2.2.4+1/debian/changelog 2018-07-28 23:10:51.0 +0300
+++ guile-2.2-2.2.4+1/debian/changelog 2019-05-03 21:58:01.0 +0300
@@ -1,3 +1,11 @@
+guile-2.2 (2.2.4+1-1.1) unstable; urgency=medium
+
+ * NMU
+ * Use alternatives system for guild, guile-config, guile-snarf and
+guile-tools and use version suffixed names. (Closes: #926182)
+
+ -- Kari Pahula Fri, 03 May 2019 21:58:01 +0300
+
guile-2.2 (2.2.4+1-1) unstable; urgency=medium
* Upgrade to 2.2.4.
diff -Nru guile-2.2-2.2.4+1/debian/guile-dev.install guile-2.2-2.2.4+1/debian/guile-dev.install
--- guile-2.2-2.2.4+1/debian/guile-dev.install 2018-07-28 23:10:09.0 +0300
+++ guile-2.2-2.2.4+1/debian/guile-dev.install 2019-05-03 21:56:57.0 +0300
@@ -1,7 +1,7 @@
-debian/tmp/usr/bin/guild
-debian/tmp/usr/bin/guile-config
-debian/tmp/usr/bin/guile-snarf
-debian/tmp/usr/bin/guile-tools
+debian/tmp/usr/bin/guild /usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin
+debian/tmp/usr/bin/guile-config /usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin
+debian/tmp/usr/bin/guile-snarf /usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin
+debian/tmp/usr/bin/guile-tools /usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin
debian/tmp/usr/include/*
debian/tmp/usr/lib/*/*.a
debian/tmp/usr/lib/*/libguile-@DEB_SRC_EFF_VER@.so
diff -Nru guile-2.2-2.2.4+1/debian/guile-dev.links guile-2.2-2.2.4+1/debian/guile-dev.links
--- guile-2.2-2.2.4+1/debian/guile-dev.links 1970-01-01 02:00:00.0 +0200
+++ guile-2.2-2.2.4+1/debian/guile-dev.links 2019-05-03 21:56:57.0 +0300
@@ -0,0 +1,4 @@
+usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin/guild usr/bin/guild-@DEB_SRC_EFF_VER@
+usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin/guile-config usr/bin/guile-config-@DEB_SRC_EFF_VER@
+usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin/guile-snarf usr/bin/guile-snarf-@DEB_SRC_EFF_VER@
+usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin/guile-tools usr/bin/guile-tools-@DEB_SRC_EFF_VER@
diff -Nru guile-2.2-2.2.4+1/debian/guile-dev.postinst guile-2.2-2.2.4+1/debian/guile-dev.postinst
--- guile-2.2-2.2.4+1/debian/guile-dev.postinst 1970-01-01 02:00:00.0 +0200
+++ guile-2.2-2.2.4+1/debian/guile-dev.postinst 2019-05-03 21:56:57.0 +0300
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+for bin in guild guile-config guile-snarf guile-tools; do
+update-alternatives \
+--install \
+/usr/bin/$bin \
+$bin \
+/usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin/$bin \
+@DEB_ALT_PRIORITY@
+done
+
+#DEBHELPER#
diff -Nru guile-2.2-2.2.4+1/debian/guile-dev.prerm guile-2.2-2.2.4+1/debian/guile-dev.prerm
--- guile-2.2-2.2.4+1/debian/guile-dev.prerm 1970-01-01 02:00:00.0 +0200
+++ guile-2.2-2.2.4+1/debian/guile-dev.prerm 2019-05-03 21:56:57.0 +0300
@@ -0,0 +1,12 @@
+#! /bin/sh
+
+set -e
+
+if [ "$1" != "upgrade" ] ; then
+for bin in guild guile-config guile-snarf guile-tools; do
+update-alternatives --remove $bin \
+/usr/lib/@MARCH@guile-@DEB_SRC_EFF_VER@/bin/$bin
+done
+fi
+
+#DEBHELPER#
diff -Nru guile-2.2-2.2.4+1/debian/rules guile-2.2-2.2.4+1/debian/rules
--- guile-2.2-2.2.4+1/debian/rules 2018-07-28 23:10:09.0 +0300
+++ guile-2.2-2.2.4+1/debian/rules 2019-05-03 21:56:57.0 +0300
@@ -129,6 +129,7 @@
guile-$(deb_src_eff_ver).menu \
guile-$(deb_src_eff_ver).undocumented \
guile-$(deb_src_eff_ver)-dev.install \
+ guile-$(deb_src_eff_ver)-dev.links \
guile-$(deb_src_eff_ver)-doc.README.Debian \
guile-$(deb_src_eff_ver)-doc.install \
guile-$(deb_src_eff_ver)-libs.install \
@@ -137,6 +138,8 @@
autogen_installdeb_files := $(addprefix debian/, \
guile-$(deb_src_eff_ver).postinst \
guile-$(deb_src_eff_ver).prerm \
+ guile-$(deb_src_eff_ver)-dev.postinst \
+ guile-$(deb_src_eff_ver)-dev.prerm \
guile-$(deb_src_eff_ver)-doc.postinst \
guile-$(deb_src_eff_ver)-doc.prerm \
guile-$(deb_src_eff_ver)-libs.postinst \
@@ -233,12 +236,6 @@
-Xusr/lib/$(march)guile/$(deb_src_eff_ver)/extensions/guile-readline.a \
-Xusr/lib/$(march)guile/$(deb_src_eff_ver)/extensions/guile-readline.la
- sed -i'' '0,\|/usr/bin/guile|s||$(deb_guile_bin_path)|' \
- debian/$(deb_pkg_basename)-dev/usr/bin/guile-config
-
- sed -i'' '0,\|\$${exec_prefix}/bin/guile|s||$(deb_guile_bin_path)|' \
- debian/$(deb_pkg_basename)-dev/usr/bin/guild
-
test -e $(gdb_ext)
mkdir -p $(gdb_ext_dir)
mv $(gdb_ext) $(gdb_ext_dir)
Bug#924610: Ports of CVE patches from Debian LTS for libsdl2
Hi.
I've ported the CVE patches from Debian LTS for libsdl2 in unstable.
>From 71a63c55e96dc351058d3700d1a4cba1726136e2 Mon Sep 17 00:00:00 2001
From: Kari Pahula
Date: Wed, 24 Apr 2019 16:56:30 +0300
Subject: [PATCH] Port patches from Debian LTS release for CVE bugs.
Fixes for CVE-2019-7572, CVE-2019-7573, CVE-2019-7574,
CVE-2019-7575, CVE-2019-7576, CVE-2019-7577, CVE-2019-7578,
CVE-2019-7635, CVE-2019-7636, CVE-2019-7637, CVE-2019-7638.
---
debian/patches/CVE-2019-7572_CVE-2019-7574.patch | 92 ++
debian/patches/CVE-2019-7573.patch | 69
debian/patches/CVE-2019-7575_CVE-2019-7577.patch | 91 +
debian/patches/CVE-2019-7577_1_2.patch | 34
debian/patches/CVE-2019-7578.patch | 79 +++
...CVE-2019-7635_CVE-2019-7636_CVE-2019-7638.patch | 83 +++
debian/patches/CVE-2019-7637.patch | 86
debian/patches/series | 8 ++
8 files changed, 542 insertions(+)
create mode 100644 debian/patches/CVE-2019-7572_CVE-2019-7574.patch
create mode 100644 debian/patches/CVE-2019-7573.patch
create mode 100644 debian/patches/CVE-2019-7575_CVE-2019-7577.patch
create mode 100644 debian/patches/CVE-2019-7577_1_2.patch
create mode 100644 debian/patches/CVE-2019-7578.patch
create mode 100644 debian/patches/CVE-2019-7635_CVE-2019-7636_CVE-2019-7638.patch
create mode 100644 debian/patches/CVE-2019-7637.patch
diff --git a/debian/patches/CVE-2019-7572_CVE-2019-7574.patch b/debian/patches/CVE-2019-7572_CVE-2019-7574.patch
new file mode 100644
index 000..32e347e
--- /dev/null
+++ b/debian/patches/CVE-2019-7572_CVE-2019-7574.patch
@@ -0,0 +1,92 @@
+Description: CVE-2019-7572, CVE-2019-7574
+ CVE-2019-7572: a buffer over-read in IMA_ADPCM_nibble in audio/SDL_wave.c.
+ CVE-2019-7574: a heap-based buffer over-read in IMA_ADPCM_decode in audio/SDL_wave.c.
+
+---
+Author: Abhijith PA
+Origin: https://bugzilla-attachments.libsdl.org/attachment.cgi?id=3610
+https://bugzilla.libsdl.org/attachment.cgi?id=3612
+https://bugzilla.libsdl.org/attachment.cgi?id=3618
+Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=4496
+ https://bugzilla.libsdl.org/show_bug.cgi?id=4495
+Last-Update: <2018-03-12>
+
+Index: libsdl2/src/audio/SDL_wave.c
+===
+--- libsdl2.orig/src/audio/SDL_wave.c
libsdl2/src/audio/SDL_wave.c
+@@ -272,6 +272,14 @@ IMA_ADPCM_nibble(struct IMA_ADPCM_decode
+ 22385, 24623, 27086, 29794, 32767
+ };
+ Sint32 delta, step;
++/* Clamp index value. The inital value can be invalid. */
++ if ( state->index > 88 ) {
++ state->index = 88;
++ } else
++ if ( state->index < 0 ) {
++ state->index = 0;
++ }
++
+
+ /* Compute difference and new sample value */
+ if (state->index > 88) {
+@@ -338,7 +346,7 @@ static int
+ IMA_ADPCM_decode(Uint8 ** audio_buf, Uint32 * audio_len)
+ {
+ struct IMA_ADPCM_decodestate *state;
+-Uint8 *freeable, *encoded, *decoded;
++Uint8 *freeable, *encoded, *encoded_end, *decoded, *decoded_end;
+ Sint32 encoded_len, samplesleft;
+ unsigned int c, channels;
+
+@@ -354,6 +362,7 @@ IMA_ADPCM_decode(Uint8 ** audio_buf, Uin
+ /* Allocate the proper sized output buffer */
+ encoded_len = *audio_len;
+ encoded = *audio_buf;
++encoded_end = encoded + encoded_len;
+ freeable = *audio_buf;
+ *audio_len = (encoded_len / IMA_ADPCM_state.wavefmt.blockalign) *
+ IMA_ADPCM_state.wSamplesPerBlock *
+@@ -363,11 +372,13 @@ IMA_ADPCM_decode(Uint8 ** audio_buf, Uin
+ return SDL_OutOfMemory();
+ }
+ decoded = *audio_buf;
++decoded_end = decoded + *audio_len;
+
+ /* Get ready... Go! */
+ while (encoded_len >= IMA_ADPCM_state.wavefmt.blockalign) {
+ /* Grab the initial information for this block */
+ for (c = 0; c < channels; ++c) {
++if (encoded + 4 > encoded_end) goto invalid_size;
+ /* Fill the state information for this block */
+ state[c].sample = ((encoded[1] << 8) | encoded[0]);
+ encoded += 2;
+@@ -381,6 +392,7 @@ IMA_ADPCM_decode(Uint8 ** audio_buf, Uin
+ }
+
+ /* Store the initial sample we start with */
++if (decoded + 2 > decoded_end) goto invalid_size;
+ decoded[0] = (Uint8) (state[c].sample & 0xFF);
+ decoded[1] = (Uint8) (state[c].sample >> 8);
+ decoded += 2;
+@@ -390,6 +402,9 @@ IMA_ADPCM_decode(Uint8 ** audio_buf, Uin
+ samplesleft = (IMA_ADPCM_state.wSamplesPerBlock - 1) * channels;
+ while (samplesleft > 0) {
+ for (c = 0; c < channels; ++c) {
++if (encoded + 4 > encoded_end) goto invalid_size;
+++ if (decoded + 4 * 4 * channels > decoded_end)
+++
Bug#924609: Ports of CVE patches from Debian LTS for libsdl1.2
Hi.
I've ported the CVE patches from Debian LTS for libsdl1.2 in unstable.
>From 3aa83f5059f9e8203177350101ab43415b901f93 Mon Sep 17 00:00:00 2001
From: Kari Pahula
Date: Wed, 24 Apr 2019 16:51:03 +0300
Subject: [PATCH] Port patches from Debian LTS release for CVE bugs.
Fixes for CVE-2019-7572, CVE-2019-7573, CVE-2019-7574,
CVE-2019-7575, CVE-2019-7576, CVE-2019-7577, CVE-2019-7578,
CVE-2019-7635, CVE-2019-7636, CVE-2019-7637, CVE-2019-7638.
---
debian/patches/CVE-2019-7572_CVE-2019-7574.patch | 105
debian/patches/CVE-2019-7573.patch | 66
debian/patches/CVE-2019-7575_7577.patch | 78 +
debian/patches/CVE-2019-7577-1_2.patch | 32
debian/patches/CVE-2019-7578.patch | 53 ++
debian/patches/CVE-2019-7635_636_638.patch | 81 +
debian/patches/CVE-2019-7637.patch | 207 +++
debian/patches/series| 8 +
8 files changed, 630 insertions(+)
create mode 100644 debian/patches/CVE-2019-7572_CVE-2019-7574.patch
create mode 100644 debian/patches/CVE-2019-7573.patch
create mode 100644 debian/patches/CVE-2019-7575_7577.patch
create mode 100644 debian/patches/CVE-2019-7577-1_2.patch
create mode 100644 debian/patches/CVE-2019-7578.patch
create mode 100644 debian/patches/CVE-2019-7635_636_638.patch
create mode 100644 debian/patches/CVE-2019-7637.patch
diff --git a/debian/patches/CVE-2019-7572_CVE-2019-7574.patch b/debian/patches/CVE-2019-7572_CVE-2019-7574.patch
new file mode 100644
index 000..c1ecdb9
--- /dev/null
+++ b/debian/patches/CVE-2019-7572_CVE-2019-7574.patch
@@ -0,0 +1,105 @@
+Description: CVE-2019-7572, CVE-2019-7574
+ CVE-2019-7572: a buffer over-read in IMA_ADPCM_nibble in audio/SDL_wave.c.
+ CVE-2019-7574: a heap-based buffer over-read in IMA_ADPCM_decode in audio/SDL_wave.c.
+
+---
+Author: Abhijith PA
+Origin: https://bugzilla-attachments.libsdl.org/attachment.cgi?id=3610
+https://bugzilla.libsdl.org/attachment.cgi?id=3612
+https://bugzilla.libsdl.org/attachment.cgi?id=3618
+Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=4496
+ https://bugzilla.libsdl.org/show_bug.cgi?id=4495
+Last-Update: <2018-03-05>
+
+Index: libsdl1.2-1.2.15/src/audio/SDL_wave.c
+===
+--- libsdl1.2-1.2.15.orig/src/audio/SDL_wave.c
libsdl1.2-1.2.15/src/audio/SDL_wave.c
+@@ -264,6 +264,14 @@ static Sint32 IMA_ADPCM_nibble(struct IM
+ };
+ Sint32 delta, step;
+
++ /* Clamp index value. The inital value can be invalid. */
++ if ( state->index > 88 ) {
++ state->index = 88;
++ } else
++ if ( state->index < 0 ) {
++ state->index = 0;
++ }
++
+ /* Compute difference and new sample value */
+ step = step_table[state->index];
+ delta = step >> 3;
+@@ -275,12 +283,6 @@ static Sint32 IMA_ADPCM_nibble(struct IM
+
+ /* Update index value */
+ state->index += index_table[nybble];
+- if ( state->index > 88 ) {
+- state->index = 88;
+- } else
+- if ( state->index < 0 ) {
+- state->index = 0;
+- }
+
+ /* Clamp output sample */
+ if ( state->sample > max_audioval ) {
+@@ -323,7 +325,7 @@ static void Fill_IMA_ADPCM_block(Uint8 *
+ static int IMA_ADPCM_decode(Uint8 **audio_buf, Uint32 *audio_len)
+ {
+ struct IMA_ADPCM_decodestate *state;
+- Uint8 *freeable, *encoded, *decoded;
++ Uint8 *freeable, *encoded, *encoded_end, *decoded, *decoded_end;
+ Sint32 encoded_len, samplesleft;
+ unsigned int c, channels;
+
+@@ -339,6 +341,7 @@ static int IMA_ADPCM_decode(Uint8 **audi
+ /* Allocate the proper sized output buffer */
+ encoded_len = *audio_len;
+ encoded = *audio_buf;
++ encoded_end = encoded + encoded_len;
+ freeable = *audio_buf;
+ *audio_len = (encoded_len/IMA_ADPCM_state.wavefmt.blockalign) *
+ IMA_ADPCM_state.wSamplesPerBlock*
+@@ -349,11 +352,13 @@ static int IMA_ADPCM_decode(Uint8 **audi
+ return(-1);
+ }
+ decoded = *audio_buf;
++ decoded_end = decoded + *audio_len;
+
+ /* Get ready... Go! */
+ while ( encoded_len >= IMA_ADPCM_state.wavefmt.blockalign ) {
+ /* Grab the initial information for this block */
+ for ( c=0; c encoded_end) goto invalid_size;
+ /* Fill the state information for this block */
+ state[c].sample = ((encoded[1]<<8)|encoded[0]);
+ encoded += 2;
+@@ -367,6 +372,7 @@ static int IMA_ADPCM_decode(Uint8 **audi
+ }
+
+ /* Store the initial sample we start with */
++ if (decoded + 2 > decoded_end) goto invalid_size;
+ decoded[0] = (Uint8)(state[c].sample&0xFF);
+ decoded[1] = (Uint8)(state[c].sample>>8);
+ decoded += 2;
+@@ -376,6 +382,9 @@ static int IMA_ADPCM_decode(Uint8 **audi
+ samplesleft = (IMA_ADPCM_state.wSamplesPerBlock-1)*channels;
+ while ( samplesleft > 0 ) {
+ for ( c=0; c encoded_end) goto invalid_size;
++if (decoded + 4 * 4 * channels > decoded_end)
++
Bug#921810: RM: crossfire-client-sounds -- ROM; Files included in crossfire-client by upstream
Package: ftp.debian.org Severity: normal crossfire-client version 1.73.0 release tarball included the sound files in it, superseding the need for a separate source package for the sounds.
Bug#912969: gecode: FTBFS on mips and mipsel
Package: gecode Version: 6.1.0-1 Severity: serious Tags: ftbfs Forwarded: https://github.com/Gecode/gecode/issues/34 Building Gecode 6.1.0-1 fails on mips and mipsel. The previous version (6.0.1-1) had no trouble. GCC versions have changed between the build attempts and that may be a factor. The error occurs in the test suite that's run after the build itself at the same place for both arches. https://buildd.debian.org/status/fetch.php?pkg=gecode=mips=6.1.0-1=1540903224=0 https://buildd.debian.org/status/fetch.php?pkg=gecode=mipsel=6.1.0-1=1540907457=0 I've reported this to the upstream but it's likely that this needs to be figured out on Debian's end.
Bug#861670: man page for sqldiff
tags 861670 + patch thanks I wrote a man page for sqldiff based on the html page. .TH sqldiff 1 "2018-05-10" .SH sqldiff sqldiff - sqlite3 database difference utility .SH SYNOPSIS .B sqldiff .RI [ options ] .I database1.sqlite database2.sqlite .SH DESCRIPTION The .B sqldiff binary is a command-line utility program that displays the differences between SQLite databases. The usual output is an SQL script that will transform .I database1.sqlite (the "source" database) into .I database2.sqlite (the "destination" database). The .B sqldiff utility works by finding rows in the source and destination that are logical "pairs". The default behavior is to treat two rows as pairs if they are in tables with the same name and they have the same rowid, or in the case of a WITHOUT ROWID table if they have the same PRIMARY KEY. Any differences in the content of paired rows are output as UPDATEs. Rows in the source database that could not be paired are output as DELETEs. Rows in the destination database that could not be paired are output as INSERTs. The .B --primarykey flag changes the pairing algorithm slightly so that the schema-declared PRIMARY KEY is always used for pairing, even on tables that have a rowid. This is often a better choice for finding differences, however it can lead to missed differences in the case of rows that have one or more PRIMARY KEY columns set to NULL. .SH OPTIONS .TP .BI \-\-changset\ FILE Do not write changes to standard output. Instead, write a (binary) changeset file into .IR FILE . The changeset can be interpreted using the sessions extension to SQLite. .TP .BI \-\-lib\fR\ LIBRARY\fR,\ \-L\fR\ LIBRARY Load the shared library or DLL file .I LIBRARY into SQLite prior to computing the differences. This can be used to add application-defined collating sequences that are required by the schema. .TP .B --primarykey Use the schema-defined PRIMARY KEY instead of the rowid to pair rows in the source and destination database. (See additional explanation below.) .TP .B --schema Show only differences in the schema not the table content .TP .B --summary Show how many rows have changed on each table, but do not show the actual changes .TP .BI --table\fR\ TABLE Show only the differences in content for .IR TABLE , not for the entire database .TP .B --transaction Wrap SQL output in a single large transaction .TP .B --vtab Add support for handling FTS3, FTS5 and rtree virtual tables. See below for details. .SH LIMITATIONS The .B sqldiff utility is unable to compute differences for rowid tables for which the rowid is inaccessible. An example of a table with an inaccessible rowid is: .nf CREATE TABLE inaccessible_rowid( "rowid" TEXT, "oid" TEXT, "_rowid_" TEXT ); .fi The .B sqldiff utility does not (currently) display differences in TRIGGERs or VIEWs. By default, differences in the schema or content of virtual tables are not reported on. However, if a virtual table implementation creates real tables (sometimes referred to as "shadow" tables) within the database to store its data in, then sqldiff.exe does calculate the difference between these. This can have surprising effects if the resulting SQL script is then run on a database that is not exactly the same as the source database. For several of SQLite's bundled virtual tables (FTS3, FTS5, rtree and others), the surprising effects may include corruption of the virtual table content. If the .B --vtab option is passed to .BR sqldiff , then it ignores all underlying shadow tables belonging to an FTS3, FTS5 or rtree virtual table and instead includes the virtual table differences directly. .SH SEE ALSO .BR sqlite3 (1).
Bug#849416: fpc-source: Please provide a symbolic link to the corresponding source directory
Package: fpc-source Version: 3.0.0+dfsg-10 Severity: wishlist I'm using fpc-source-3.0.0 as a build dependency for gearhead, to copy over and patch some line drawing instructions to get smoother console mode box borders for it. Currently, I've used fpc-source-3.0.0 directly as the build dependency and access files from under /usr/share/fpcsrc/3.0.0/ in my debian/rules. I'd like to rather use fpc-source as the build dependency. I expect to have the files I use stay the same across fpc versions. Nothing really prevents me from doing that as is but it would get downright trivial to do so on my end if fpc-source had a symlink like /usr/share/fpcsrc/default which pointed to the 3.0.0 (as it is currently) directory. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fpc-source depends on: ii fpc-source-3.0.0 3.0.0+dfsg-10 fpc-source recommends no packages. fpc-source suggests no packages. -- no debconf information
Bug#832174: ITP: js-build-tools -- collection of tools to help building Jane Street Packages
On Sat, Jul 23, 2016 at 11:58:49AM +0200, Stéphane Glondu wrote: > * Package name: js-build-tools That's an unfortunate choice for a name. This package has nothing to do with javascript.
Bug#819276: RM: mgm -- ROM; Dead upstream, low popcon score, broken
Package: ftp.debian.org Severity: normal I tried updating this package but now that I run it, it doesn't even do anything but output errors. It would need some love but there are plenty of other, maintained, system load monitors in Debian. I think it'd be no great loss to let this package go.
Bug#808422: xmonad should provide an upgrade path for user compiled xmonad from libff5 to libffi6
Package: xmonad Version: 0.11.1-4 Severity: normal I upgraded my laptop and couldn't startx after rebooting the system. Starting X itself went okay but digging in to logs found this in my .xsession-errors: /home/kaol/.xmonad/xmonad-x86_64-linux: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory My .xsession is #! /bin/sh exec xmonad /usr/bin/xmonad tries to execute my xmonad-x86_64-linux but linker won't be able to since I no longer had libffi5 installed on my system. Removing my xmonad-x86_64-linux solved the situation. xmonad built me a new xmonad-x86_64-linux and I could proceed as normal. Looks like I hadn't needed to update my xmonad.hs in a while. It would be nice if xmonad would fail gracefully when a user's own xmonad binary had gone stale. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xmonad depends on: ii libc6 2.21-4 ii libffi6 3.2.1-4 ii libgmp10 2:6.1.0+dfsg-2 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxinerama1 2:1.1.3-1+b1 ii libxrandr22:1.5.0-1 ii x11-utils 7.7+3 Versions of packages xmonad recommends: pn libghc-xmonad-dev pn libghc-xmonad-doc ii xfonts-base1:1.0.4+nmu1 Versions of packages xmonad suggests: pn gnome-session-flashback ii suckless-tools [dmenu] 41-1 -- no debconf information
Bug#803636: ITP: hsakmt -- thunk library for AMD's HSA Linux kernel driver (amdkfd)
Package: wnpp Severity: wishlist Owner: Kari Pahula <k...@debian.org> * Package name: hsakmt Version : 1.0.0 Upstream Author : Advanced Micro Devices, Inc. * URL : http://cgit.freedesktop.org/amd/hsakmt/ * License : MIT/X Programming Lang: C Description : thunk library for AMD's HSA Linux kernel driver (amdkfd) hsakmt is a thunk library that provides a userspace interface to amdkfd (AMD's HSA Linux kernel driver). It is the HSA equivalent of libdrm. . Heterogeneous System Architecture (HSA) is a computer processor architecture that integrates central processing units and graphics processors on the same bus, with shared memory and tasks. The HSA is being developed by the HSA Foundation, which includes (among many others) AMD and ARM. The platform's stated aim is to reduce communication latency between CPUs, GPUs and other compute devices, and make these various devices more compatible from a programmer's perspective, relieving the programmer of the task of planning the moving of data between devices' disjoint memories (as must currently be done with OpenCL or CUDA). This library is needed (along with hsa-runtime, ITP for that will follow later) to enable HSA features in AMD's Kaveri and Carrizo APUs. The amdkfd driver is already included in the mainline kernel.
Bug#791042: Library transition needed, patch attached
On Sun, Sep 06, 2015 at 10:40:30AM +0100, Simon McVittie wrote: > I have done this as a "sponsored upload" to keep the transition moving. I just did a a test build with the current unstable and was about to write about it here. Here's quick steps to test that the library works correctly. mkdir -p /tmp/gecode cd /tmp/gecode cp -r /usr/share/doc/libgecode-doc/examples . cd examples make ./all-interval I got a segfault with that. Running with gdb placed it in libQtGui.so.4: Program received signal SIGSEGV, Segmentation fault. 0x737c7144 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 Can you please verify that your build doesn't do the same?
Bug#791042: Library transition needed, patch attached
On Sun, Sep 06, 2015 at 02:42:54PM +0100, Simon McVittie wrote: > On 06/09/15 12:43, Kari Pahula wrote: > > Here's quick steps to test that the library works correctly. > > Thanks, this is very useful information. Could you automate this as an > autopkgtest[1], please? I'll have to look at it. There's already a check as a part of the build itself, controlled by DEB_BUILD_OPTIONS=nocheck. > ... although my build of the examples used Qt 5 (not through anything I > did deliberately, it's just what happens when I follow your > instructions), which means a segfault in libQtGui.so.4 would have come > as quite a surprise to me :-) My quick and dirty check must have been a bit dirtier than I thought. > I picked a few other random executables from the build you described, > and they all seem to produce some sort of a result without crashing. Thanks for looking into it, I'm happy with this result.
Bug#793733: ITP: minizinc-ide -- MiniZinc constraint modelling language IDE
Package: wnpp Severity: wishlist Owner: Kari Pahula k...@debian.org * Package name: minizinc-ide Version : 0.9.8 Upstream Author : Guido Tack guido.t...@monash.edu * URL : http://www.minizinc.org/ide/ * License : MPL-2.0 Programming Lang: C++ Description : MiniZinc constraint modelling language IDE The MiniZinc IDE is a simple Integrated Development Environment for writing and running MiniZinc models. It provides a tabbed editor with MiniZinc syntax highlighting, configuration dialogs for solver options and model parameters, and an integrated environment for compiling models and running solvers. This is to go along with minizinc package (#791608). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791608: ITP: minizinc -- Constraint modelling language and tool chain
Package: wnpp Severity: wishlist Owner: Kari Pahula k...@debian.org * Package name: minizinc Version : 2.0.4 Upstream Author : Guido Tack guido.t...@monash.edu * URL : http://www.minizinc.org/ * License : MPL-2.0, MS-PL Programming Lang: C++ Description : constraint modelling language and tool chain MiniZinc is a medium-level constraint modelling language. It is high-level enough to express most constraint problems easily, but low-level enough that it can be mapped onto existing solvers easily and consistently. It is a subset of the higher-level language Zinc. . MiniZinc is designed to interface easily to different backend solvers. It does this by transforming an input MiniZinc model and data file into a FlatZinc model. FlatZinc models consist of variable declaration and constraint definitions as well as a definition of the objective function if the problem is an optimization problem. The translation from MiniZinc to FlatZinc is specializable to individual backend solvers, so they can control what form constraints end up in. In particular, MiniZinc allows the specification of global constraints by decomposition. I already maintain Gecode, which includes a FlatZinc interpreter. I intend to package minizinc and minizinc-ide to provide more use for Gecode. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748533: Okular didn't print for me either, switching from lpr to cups-bsd helped
Hi. I had okular fail at printing for myself, too. I ran okular from an xterm and noticed that it output this to stderr when I tried to print: usage: lpr [-cdfghlmnpqrstv] [-#num] [-1234 font] [-C class] [-i [numcols]] [-J job] [-Pprinter] [-T title] [-U user] [-wnum] [name ...] I ran aptitude install cups-bsd and that resolved the problem for me. The version of lpr in lpr package, which I had at first, didn't work. signature.asc Description: Digital signature
Bug#691643: Checked with 2.7.0: still readds linked manpages with different mtimes
tags 691643 - patch thanks Hi. I tested this with the new version. # touch /usr/share/man/man3/ # mandb -p 2/dev/null |tail -n3 1 man subdirectory contained newer manual pages. 1108 manual pages were added. 0 stray cats were added. # mandb -p 2/dev/null |tail -n3 0 man subdirectories contained newer manual pages. 0 manual pages were added. 0 stray cats were added. Looks like this still happens. For anyone following this, I wrote last about this on the mailing list: http://lists.nongnu.org/archive/html/man-db-devel/2013-12/msg8.html The simplest way I found to make the issue go away was to use stat instead of lstat to get the mtimes, but that ran afoul with the test suite. I didn't explore that further. I wrote a small script to equalize man links' mtimes with the man page files. I'm not suggesting it as a solution but if you want to see what kind of impact this has, then feel free to test it (run mandb -c afterwards). #! /bin/bash set -e if [ -z $1 ]; then echo Usage: $0 path 2 exit 1 fi cd $1 for f in $(find . -type l); do touch -h -m -c $f -r $(readlink $f) done -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759668: ITP: libnet-oauth2-perl -- implementation of the OAuth 2.0 protocol
Package: wnpp Severity: wishlist Owner: Kari Pahula k...@debian.org * Package name: libnet-oauth2-perl Version : 0.61 Upstream Author : Mark Overmeer m...@overmeer.net * URL : https://metacpan.org/release/Net-OAuth2 * License : Artistic or GPL-1+ Programming Lang: Perl Description : implementation of the OAuth 2.0 protocol Net::OAuth2 implements OAuth 2.0 authorization protocol client. OAuth 2.0 is imcompatible with OAuth 1.0. . The library can be used to authenticate users against OAuth 2.0 service providers such as Google and Facebook. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748716: False positives for po templates in crossfire
forcemerge 748716 750810 reassign 748716 po-debconf severity 748716 normal tags 748716 - patch retitle 748716 False debconf po templates reported for crossfire thanks Hi. As discussed at http://lists.alioth.debian.org/pipermail/debian-l10n-devel/2014-June/003372.html , po-debconf somehow reports crossfire as having debconf templates, despite having none. Please reassign if po-debconf isn't the right package responsible for these. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709775: RM: simplelist -- ROM; low popcon, alternatives exist
Package: ftp.debian.org Severity: normal simplelist was a dependency for ggtl, which was removed a long time ago. There are plenty of other C libraries offering linked lists. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691643: Revised version of ctime patch
I updated my patch a bit.
There was a problem with storing only mtime's seconds as mandb's last
changed time. There's a chance that if mandb -p gets called twice
within a second that it won't know to crawl a directory on the second
run. That didn't matter as much before, since the changed files would
be indexed on the next run, whenever that happened. But with the
ctime patch, there's a risk that it could never catch some files if
this happened. I made mandb store nanoseconds to avoid this.
Index: man-db-2.6.3/src/check_mandirs.c
===
--- man-db-2.6.3.orig/src/check_mandirs.c 2012-10-27 12:00:13.0
+0300
+++ man-db-2.6.3/src/check_mandirs.c2012-10-31 20:24:59.285914354 +0200
@@ -316,12 +316,15 @@
free (lg.whatis);
}
-static inline void add_dir_entries (const char *path, char *infile)
+static inline void add_dir_entries (const char *path, char *infile,
+ time_t last, time_t ulast)
{
char *manpage;
int len;
struct dirent *newdir;
DIR *dir;
+ struct stat statbuf;
+ int fd, ret;
manpage = appendstr (NULL, path, /, infile, /, NULL);
len = strlen (manpage);
@@ -332,7 +335,17 @@
*/
dir = opendir (infile);
- if (!dir) {
+ if (dir) {
+#if _BSD_SOURCE
+ if ( (fd = dirfd (dir)) != -1)
+ ret = fchdir (fd);
+ else
+ ret = chdir (infile);
+#else
+ ret = chdir (infile);
+#endif
+ }
+ if (!dir || ret == -1) {
error (0, errno, _(can't search directory %s), manpage);
free (manpage);
return;
@@ -343,12 +356,25 @@
while ( (newdir = readdir (dir)) )
if (!(*newdir-d_name == '.'
strlen (newdir-d_name) (size_t) 3)) {
+#if _BSD_SOURCE
+ if (last)
+ lstat(newdir-d_name, statbuf);
+ if (!last || last statbuf.st_ctime ||
+ (last == statbuf.st_ctime
+ ulast statbuf.st_ctim.tv_nsec)) {
+ manpage = appendstr (manpage, newdir-d_name,
NULL);
+ test_manfile (manpage, path);
+ *(manpage + len) = '\0';
+ }
+#else
manpage = appendstr (manpage, newdir-d_name, NULL);
test_manfile (manpage, path);
*(manpage + len) = '\0';
+#endif
}
free (manpage);
+ chdir (..);
closedir (dir);
}
@@ -425,13 +451,14 @@
* scanned for new files, which are then added to the db.
*/
static int testmandirs (const char *path, const char *catpath, time_t last,
- int create)
+ time_t ulast, int create)
{
DIR *dir;
struct dirent *mandir;
struct stat stbuf;
int amount = 0;
int created = 0;
+ int fd;
debug (Testing %s for new files\n, path);
@@ -441,7 +468,14 @@
return 0;
}
+#ifdef _BSD_SOURCE
+ if ( (fd = dirfd (dir)) != -1)
+ fchdir (fd);
+ else
+ chdir (path);
+#else
chdir (path);
+#endif
while( (mandir = readdir (dir)) ) {
if (strncmp (mandir-d_name, man, 3) != 0)
@@ -453,13 +487,26 @@
continue;
if (!S_ISDIR(stbuf.st_mode))/* not a directory */
continue;
- if (last stbuf.st_mtime = last) {
+#ifdef _BSD_SOURCE
+ if (last (stbuf.st_mtime last
+|| (stbuf.st_mtime == last
+ stbuf.st_mtim.tv_nsec ulast))) {
+ /* scanned already */
+ debug (%s modified %ld.%09d, db modified %ld.%09d\n,
+ mandir-d_name, (long) stbuf.st_mtime,
+ (int) stbuf.st_mtim.tv_nsec,
+ (long) last, (int) ulast);
+ continue;
+ }
+#else
+ if (last stbuf.st_mtime last) {
/* scanned already */
debug (%s modified %ld, db modified %ld\n,
mandir-d_name, (long) stbuf.st_mtime,
(long) last);
continue;
}
+#endif
debug (\tsubdirectory %s has been 'modified'\n,
mandir-d_name);
@@ -508,7 +555,7 @@
if (!tty)
fprintf (stderr, \n);
}
- add_dir_entries (path, mandir-d_name);
+ add_dir_entries (path,
Bug#691643: man-db -p's mtime check fails and man-db readds man pages needlessly
Package: man-db
Version: 2.6.3-1
Severity: normal
Tags: upstream patch
mandb -p (which is run by the dpkg trigger) takes a lot of time to
run. I started looking at it (again) and noticed something peculiar
(edited a bit for clarity).
# mandb -p | grep manual pages were added
0 manual pages were added.
# touch /usr/share/man/man3
# mandb -p | grep manual pages were added
1101 manual pages were added.
# touch /usr/share/man/man3
# mandb -p | grep manual pages were added
1101 manual pages were added.
As I haven't done anything but update the directory's mtime, I would
have expected the subsequent mandb -p runs add no pages. I tested
this on a few Debian installs with various uses and saw similar thing
happen with their man directories.
I looked at the code and saw that mandb stores man pages' mtimes to
its database, but there's something off with the code and it gives
false positives on differing mtimes. I didn't come up with a fix for
that issue, but using man pages' ctimes instead I could do this:
Index: man-db-2.6.3/src/check_mandirs.c
===
--- man-db-2.6.3.orig/src/check_mandirs.c 2012-10-27 12:00:13.0
+0300
+++ man-db-2.6.3/src/check_mandirs.c2012-10-28 00:31:35.200950213 +0300
@@ -316,12 +316,14 @@
free (lg.whatis);
}
-static inline void add_dir_entries (const char *path, char *infile)
+static inline void add_dir_entries (const char *path, char *infile,
+ time_t last)
{
char *manpage;
int len;
struct dirent *newdir;
DIR *dir;
+ struct stat filestat;
manpage = appendstr (NULL, path, /, infile, /, NULL);
len = strlen (manpage);
@@ -344,7 +346,10 @@
if (!(*newdir-d_name == '.'
strlen (newdir-d_name) (size_t) 3)) {
manpage = appendstr (manpage, newdir-d_name, NULL);
- test_manfile (manpage, path);
+ if (last)
+ lstat(manpage, filestat);
+ if (filestat.st_ctime = last)
+ test_manfile (manpage, path);
*(manpage + len) = '\0';
}
@@ -508,7 +513,7 @@
if (!tty)
fprintf (stderr, \n);
}
- add_dir_entries (path, mandir-d_name);
+ add_dir_entries (path, mandir-d_name, last);
MYDBM_CLOSE (dbf);
amount++;
}
Note that test_manfile calls stat on manpage too and those calls could
be merged but I left that change out of this, for simplicity's sake.
I'm happy to say that this makes the trigger work a lot faster. What
do you think of my approach to this?
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages man-db depends on:
ii bsdmainutils 9.0.3
ii debconf [debconf-2.0] 1.5.46
ii dpkg 1.16.9
ii groff-base 1.21-9
ii libc6 2.13-36
ii libgdbm3 1.8.3-11
ii libpipeline1 1.2.2-1
ii zlib1g 1:1.2.7.dfsg-13
man-db recommends no packages.
Versions of packages man-db suggests:
ii chromium [www-browser] 22.0.1229.94~r161065-2
ii elinks [www-browser] 0.12~pre5-8
ii groff1.21-9
ii iceweasel [www-browser] 10.0.10esr-1
ii konqueror [www-browser] 4:4.8.4-2
ii less 451-1
ii w3m [www-browser]0.5.3-8
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675501: DDPO: Provide link to http://qa.debian.org/data/bts/graphs/by-maint/$EMAIL.png
Package: qa.debian.org Severity: wishlist Here's an idea: I'd like to see this on my DDPO page, along with the Bugs links: a href=http://qa.debian.org/data/bts/graphs/by-maint/kaol%40debian.org.png;graph/a Thank you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672720: libvirt-bin: KVM with usb-tablet causes constant CPU load
retitle 672720 libvirt-bin: KVM with usb-tablet causes constant CPU load thanks On Sun, May 13, 2012 at 06:23:39PM +0200, Guido Günther wrote: I'd check the monitor commands issued by libvirt and reproduce this with stand alone kvm. Libvirt shouldn't be doing anything special here and you should be able to check kvm's state. See also: I think I found the culprit: usb-tablet. I tested this with a minimal kvm command line and saw the cpu load drop to zero, even without pausing anything, with a running but idle virtual machine. When I started dropping options from virsh's kvm command line I saw that removing -device usb-tablet,id=input0 stopped kvm's cpu hogging. I'm using my virtual machines as development environments for web sites and can just drop input type='tablet' bus='usb'/ from my virsh domain config without trouble. I'll leave it to you to decide what to do with this information. Can anyone reproduce this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672720: [Pkg-libvirt-maintainers] Bug#672720: libvirt-bin: KVM with usb-tablet causes constant CPU load
Sorry, but could you please clarify these two statements? On Mon, May 14, 2012 at 09:24:56PM +0200, Guido Günther wrote: Yes the usb table hogging the cpu is a known issue: http://lists.gnu.org/archive/html/qemu-devel/2010-04/msg00149.html however the cpu load should drop to zero even when you have the usb tablet enabled. I'll leave it to you to decide what to do with this information. Can anyone reproduce this? Yes. Saving cpu cycles without the tables is reproducable here. Does usb-tablet cause extra cpu load or not? According to powertop, with usb-tablet, I didn't see wakeups/second go under 800. Without, the system easily reached 150. Did you create the vm using virt-manager? It's adding the tablet by default since we can't easily distinguish between systems that need it and those that don't. With virt-install. Is this a good default? I'd expect tablets to be quite rare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672720: libvirt-bin: KVM domains suspended with virsh suspend still use CPU time
Package: libvirt-bin Version: 0.9.11.3-1 Severity: wishlist I ran some tests with powertop and a wattmeter, and I'm not sure if virsh suspend really does what it says. With my system idle, no kvm domains running, powertop shows over 99% C2 state and wattage goes down to almost 60W. When I start a kvm domain and the virtual machine is idling after booting, C2 state drops below 90%, wattage is at about 75W and top shows kvm using about 10% CPU time. When I run virsh suspend, I see no change in system load. Man page says: When in a paused state the domain will still consume allocated resources like memory, but will not be eligible for scheduling by the hypervisor. Am I wrong in expecting to see my system load drop more towards the idle system situation with suspend? What else is it doing besides keeping the domain in memory? kvm doesn't like it if I kill -19 it... -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/6 CPU cores) Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libvirt-bin depends on: ii adduser 3.113+nmu1 ii gettext-base0.18.1.1-7 ii libavahi-client30.6.31-1 ii libavahi-common30.6.31-1 ii libblkid1 2.20.1-4 ii libc6 2.13-32 ii libcap-ng0 0.6.6-1 ii libdevmapper1.02.1 2:1.02.74-3 ii libgcrypt11 1.5.0-3 ii libgnutls26 2.12.19-1 ii libnetcf1 0.1.9-2 ii libnl1 1.1-7 ii libnuma12.0.8~rc3-1 ii libparted0debian1 2.3-9.1 ii libpcap0.8 1.2.1-2 ii libpciaccess0 0.13.1-2 ii libreadline66.2-8 ii libsasl2-2 2.1.25.dfsg1-4 ii libudev0175-3.1 ii libvirt00.9.11.3-1 ii libxenstore3.0 4.1.2-6 ii libxml2 2.7.8.dfsg-9 ii libyajl22.0.4-2 ii logrotate 3.8.1-1 Versions of packages libvirt-bin recommends: ii bridge-utils1.5-2 ii dmidecode 2.11-6 ii dnsmasq-base2.61-1 ii ebtables2.0.9.2-2.1 ii gawk1:4.0.1+dfsg-1 ii iproute 20120319-1 ii iptables1.4.13-1.1 ii libxml2-utils 2.7.8.dfsg-9 ii netcat-openbsd 1.105-6 ii parted 2.3-9.1 ii qemu1.0.1+dfsg-1 ii qemu-kvm1.0+dfsg-11 Versions of packages libvirt-bin suggests: pn policykit-1 0.105-1 pn radvdnone -- 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#664529: python2.7: PyFile_FromString leaks file descriptors
Package: python2.7
Version: 2.7.3~rc1-1
Severity: important
File descriptors opened by PyFile_FromString don't get closed when the
reference count is decreased.
Here's my test program, pythony.c:
#include Python.h
int main()
{
int i = 0;
PyObject *obj;
Py_Initialize();
while (i++ 5) {
obj = PyFile_FromString(hello.py, r);
assert(obj);
Py_DECREF(obj);
}
Py_Finalize();
}
hello.py is 'print(hello world)'.
I'm compiling it with both Python 2.6 and 2.7.
$ gcc pythony.c -lpython2.6 -L/usr/lib/python2.6/config
-I/usr/include/python2.6/ -o pythony-2.6
$ gcc pythony.c -lpython2.7 -L/usr/lib/python2.7/config
-I/usr/include/python2.7/ -o pythony-2.7
$ strace ./pythony-2.6 21 | tail -n 20
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb1d097b0) = -1 EINVAL (Invalid
argument)
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb1d097b0) = -1 EINVAL (Invalid
argument)
open(hello.py, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)= 0
open(hello.py, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)= 0
open(hello.py, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)= 0
open(hello.py, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)= 0
open(hello.py, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)= 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f1e1a0224f0},
{0x7f1e1a49a160, [], SA_RESTORER, 0x7f1e1a0224f0}, 8) = 0
exit_group(0) = ?
$ strace ./pythony-2.7 21 | tail -n 20
fstat(4, {st_mode=S_IFREG|0644, st_size=1950, ...}) = 0
read(4, , 4096) = 0
close(4)= 0
munmap(0x7fa41f10f000, 4096)= 0
close(3)= 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x77bd33f0) = -1 EINVAL (Invalid
argument)
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x77bd33f0) = -1 EINVAL (Invalid
argument)
open(hello.py, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
open(hello.py, O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
open(hello.py, O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
open(hello.py, O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
open(hello.py, O_RDONLY) = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7fa4206e24f0},
{0x7fa420b8dd50, [], SA_RESTORER, 0x7fa4206e24f0}, 8) = 0
exit_group(0) = ?
The Python 2.7 version never calls close, not even at Py_Finalize().
On #d-d, jwilk suspected that this change might be the cause:
http://hg.python.org/cpython/rev/0f5b64630fda/#l4.46
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages python2.7 depends on:
ii libbz2-1.0 1.0.6-1
ii libc6 2.13-27
ii libdb4.8 4.8.30-11
ii libexpat1 2.0.1-7.2
ii libgcc11:4.6.3-1
ii libncursesw5 5.9-4
ii libreadline6 6.2-8
ii libsqlite3-0 3.7.10-1
ii libtinfo5 5.9-4
ii mime-support 3.52-1
ii python2.7-minimal 2.7.3~rc1-1
python2.7 recommends no packages.
Versions of packages python2.7 suggests:
pn binutils 2.22-6
pn python2.7-doc none
-- 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#658573: ITP: lincity -- build maintain a city/country
Package: wnpp Severity: wishlist Owner: Kari Pahula k...@debian.org * Package name: lincity Version : 1.13.1 Upstream Author : I J Peters, Greg Sharp, Corey Keasling * URL : http://lincity.sourceforge.net/ * License : GPLv2 Programming Lang: C Description : build maintain a city/country You are required to build and maintain a city. You must feed, house, provide jobs and goods for your residents. You can build a sustainable economy with the help of renewable energy and recycling, or you can go for broke and build rockets to escape from a pollution ridden and resource starved planet, it's up to you. Due to the finite resources available in any one place, this is not a game that you can leave for long periods of time. This game is similar to the commercial simulation game with a similar name. lincity has been in Debian for over a decade and was abandoned and finally removed a year ago. I prefer the classic lincity over lincity-ng, so I'm bringing it back. Upstream seems pretty much dead and I don't expect to do any new development myself, but just fix bugs, keep it up to standards and in a buildable state. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579640: lost+found check triggers on bind-mounted subdir
On Fri, Jan 20, 2012 at 08:21:00PM +0100, Javier Fernández-Sanguino Peña wrote: On Fri, Jan 20, 2012 at 10:49:21AM +0100, Christian Kastner wrote: with /etc/mtab now being a symlink to /proc/mounts (which doesn't store information about bind mounts), I believe we will have to disable this check altogether. Maybe we have to, but if that information is no longer readily available I would think this is an undesired behaviour. Where can one determine now if a mounted filesystem uses a bind mount? /proc/self/mountinfo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646214: O: klone
Package: wnpp Severity: normal Looks like I just don't have the time and inclination to take care of this one. A new upstream version exists. Uses a custom build system. If you take this one, feel free to take webserver-package too, in some form, if you find it useful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646216: RFA: preload
Package: wnpp Severity: normal With my current hardware, I would never notice what effect preload would have. Any takers? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630465: Please build or include sql/pgpool-{recovery,regclass,walrecrunning}
Package: pgpool2 Version: 3.0.4-1 Severity: wishlist The sql directory in pgpool source directory has buildable modules, pgpool-recovery, pgpool-regclass and pgpool-walrecrunning. Would it be possible to get those built and packaged too? I'm not sure how much of an complication it is that they'd need to be built against postgresql-server-dev-* and there can be multiple versions of those in unstable at the same time. Alternatively, having them included as source and providing a script to build and package them could work. It'd be a nice feature to be able to avoid needing to build them on a production server. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624219: Patch to fix race condition in sudo_execve, second version
I was still thinking of this thing. Better make it more predictable by blocking the signals too, everywhere but near the select call. sigchld-longjmp Description: Binary data
Bug#624219: Patch to fix race condition in sudo_execve
tags 624219 + patch thanks The attached patch makes the signal handling more robust in sudo_execve. It'd be great to get this fixed in stable too. sigchld-longjmp Description: Binary data
Bug#613823: linux-image-2.6.32-5-xen-686: Dell Poweredge with xen hypervisor fails to boot
Package: linux-2.6
Version: 2.6.32-30
Severity: important
The kernel version shipped with squeeze fails to boot with our Dell
Poweredge R310 server, when using Xen hypervisor. The last line
visible is Scrubbing Free RAM:
As described in this forum post:
http://xen.1045712.n5.nabble.com/xen4-kernel-crash-2-6-32-5-xen-amd64-poweredge-R710-w-s-td3262651.html
This patch fixes the issue:
http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commit;h=fa9bb82fe5b971cdbea301b76c9be709c4c34b29
I can verify that making this change fixed the issue for us. We're
running an i386 kernel on the server, if that matters. I've copied
the patch here too:
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 2189432..eed895e 100644 (file)
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -87,6 +87,11 @@ static unsigned long __init xen_release_chunk(phys_addr_t
start_addr,
if (end = start)
return 0;
+ if (end PFN_DOWN(ISA_END_ADDRESS))
+ return 0;
+ if (start PFN_DOWN(ISA_END_ADDRESS))
+ start = PFN_DOWN(ISA_END_ADDRESS);
+
printk(KERN_INFO xen_release_chunk: looking at area pfn %lx-%lx: ,
start, end);
for(pfn = start; pfn end; pfn++) {
@@ -159,6 +164,7 @@ char * __init xen_memory_setup(void)
rc = HYPERVISOR_memory_op(XENMEM_memory_map, memmap);
if (rc == -ENOSYS) {
+ BUG_ON(xen_initial_domain());
memmap.nr_entries = 1;
map[0].addr = 0ULL;
map[0].size = mem_end;
@@ -196,9 +202,13 @@ char * __init xen_memory_setup(void)
}
/*
-* Even though this is normal, usable memory under Xen, reserve
-* ISA memory anyway because too many things think they can poke
+* In domU, the ISA region is normal, usable memory, but we
+* reserve ISA memory anyway because too many things poke
* about in there.
+*
+* In Dom0, the host E820 information can leave gaps in the
+* ISA range, which would cause us to release those pages. To
+* avoid this, we unconditionally reserve them here.
*/
e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS,
E820_RESERVED);
-- Package-specific info:
** Kernel log: boot messages should be attached
I can send a video if you want, but I can tell that the patch works.
-- System Information:
Debian Release: 6.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608033: libnet-openid-consumer-perl: Should depend on libcrypt-ssleay-perl
Package: libnet-openid-consumer-perl
Version: 1.03-1
Severity: normal
#! /usr/bin/perl -w
# A small test script, to test this out...
use Net::OpenID::Consumer;
use LWPx::ParanoidAgent;
my $csr = Net::OpenID::Consumer-new(
ua= LWPx::ParanoidAgent-new,
consumer_secret = fsdjfkjsdlfjsdlkfjjsdkl,
required_root = http://example.com/;,
debug = 1,
);
my $claimed_identity =
$csr-claimed_identity(https://www.google.com/accounts/o8/id;);
if (defined $claimed_identity) {
print it works\n;
} else {
print $csr-err.\n;
}
Here's the output of this script with no libcrypt-ssleay-perl installed:
[DEBUG Net::OpenID::Consumer] Cache MISS for
https://www.google.com/accounts/o8/id
[DEBUG Net::OpenID::Consumer] Cache MISS for
https://www.google.com/accounts/o8/id
[DEBUG Net::OpenID::Consumer] fail(no_head_tag) Couldn't find OpenID servers
due to no head tag
[DEBUG Net::OpenID::Consumer] fail(no_identity_server) The provided URL doesn't
declare its OpenID identity server.
no_identity_server: The provided URL doesn't declare its OpenID identity server.
Here's what I get with that package installed:
[DEBUG Net::OpenID::Consumer] Cache MISS for
https://www.google.com/accounts/o8/id
[DEBUG Net::OpenID::Consumer] Discovered version 2 endpoint at
https://www.google.com/accounts/o8/ud via Yadis
[DEBUG Net::OpenID::Consumer] Delegate is
http://specs.openid.net/auth/2.0/identifier_select
it works
The above error was the same error I got with an invalid OpenID
provider URL, making this situation a bit difficult to debug.
Net::OpenID::Consumer should at least give a different error when the
underlying user agent complains about a missing package, or you could
just add a dependency on libcrypt-ssleay-perl.
I used LWPx::ParanoidAgent for this but the same thing happens with
the regular LWP::UserAgent.
-- System Information:
Debian Release: 6.0
APT prefers unstable
APT policy: (700, 'unstable'), (600, 'stable'), (500, 'oldstable'), (500,
'testing')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libnet-openid-consumer-perl depends on:
ii libcrypt-dh-perl 0.06-3 Diffie-Hellman key exchange system
ii libdigest-sha1-perl 2.13-1 NIST SHA-1 message digest algorith
ii liburi-perl 1.54-2 module to manipulate and access UR
ii libwww-perl 5.836-1Perl HTTP/WWW client/server librar
ii libxml-simple-perl2.18-3 Perl module for reading and writin
ii perl 5.10.1-16 Larry Wall's Practical Extraction
libnet-openid-consumer-perl recommends no packages.
libnet-openid-consumer-perl 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#589427: dh_builddeb: support for parallel builds of debs
Package: debhelper
Version: 7.9.3
Severity: wishlist
It'd be useful to have dh_builddeb have support for building debs in
parallel. As a case, the ghc6 6.12.3 package I'm working on now has
debs sized 4M, 8M, 16M, 32M and 43M. After building it all I'm fairly
sure to have it all in memory and the CPU is the bottleneck, running
gzip on all that data. I'd love to pass some of that to the second
core.
I did some tests on this, making a rather trivial change to
dh_builddeb's foreach loop, like this:
my $processes = 0;
foreach ... {
my $pid = fork();
if ($pid == 0) {
...
exit 0;
} else {
if (++$processes 1) {
wait;
--$processes;
}
}
}
while (wait != -1) {}
Here's time dh_builddeb with the current version:
real4m0.960s
user3m56.903s
sys 0m2.636s
And here's what I got with this (some noise in there but you get the
idea):
real2m21.527s
user3m54.475s
sys 0m2.536s
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584464: ITP: tpl -- efficient C serialization library
Package: wnpp Severity: wishlist Owner: Kari Pahula k...@debian.org * Package name: tpl Version : 1.5 Upstream Author : Troy Hanson * URL : http://tpl.sourceforge.net/ * License : One clause BSD Programming Lang: C Description : efficient C serialization library Tpl is a library for serializing C data. The data is stored in its natural binary form. The API is small and tries to stay out of the way. Tpl can serialize many C data types, including structures. . Tpl makes a convenient file format. For example, suppose a program needs to store a list of user names and ids. This can be expressed using the format string A(si). If the program needs two such lists (say, one for regular users and one for administrators) this could be expressed as A(si)A(si). It is easy to read and write this kind of structured data using tpl. . Tpl can also be used as an IPC message format. It handles byte order issues and deframing individual messages off of a stream automatically. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581506: snapshot.debian.org: Versions of gearhead and fpc undistributable
Package: snapshot.debian.org Severity: normal snapshot.debian.org shouldn't distribute the binary package gearhead, versions 1.100-1, due to static linking and #506977. The source and -data packages are fine. Some versions of fpc are undistributable, too, but their maintainers know more about it than me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572054: RM: ghc6 [ia64] -- ROM; fails to build on ia64
Package: ftp.debian.org Severity: normal Please remove ghc6 and its rdeps from ia64. The last time ghc6 got successfully built on ia64 was with 6.8.2, and I never got 6.10.x built on ia64. I was hoping that 6.12.1 could've been buildable and I apparently got close to that but not quite. I'd rather have ghc6 enter testing now instead of trying it anymore. Following is a list of packages. Hopefully this is all. alex | 2.2-0.1+b1 | unstable | ia64 arch2darcs | 1.0.13+b1 | unstable | ia64 bnfc | 2.2-3.1+b1 | unstable | ia64 c2hs | 0.15.1-4+b1 | unstable | ia64 cpphs | 0.7-4+b1 | unstable | ia64 darcs |2.2.0-1 | unstable | ia64 darcs-buildpackage | 0.5.12+b1 | unstable | ia64 darcs-monitor |0.3.6-2 | unstable | ia64 datapacker | 1.0.1 | unstable | ia64 drift | 2.2.3-2+b1 | unstable | ia64 frown | 0.6.1-9+b1 | unstable | ia64 frown-doc | 0.6.1-9+b1 | unstable | ia64 ghc6 | 6.12.1-11 | unstable | ia64 ghc6-prof | 6.12.1-11 | unstable | ia64 gtkrsync | 1.0.2 | unstable | ia64 happy | 1.17-0.1+b1 | unstable | ia64 haskell-utils |1.11+b1 | unstable | ia64 hat | 2.05+rerolled-7+b1 | unstable | ia64 haxml | 1.13.3-2+b3 | unstable | ia64 helium | 1.6-4+b1 | unstable | ia64 hmake | 3.13-0.1+b1 | unstable | ia64 hpodder | 1.1.5.0+b1 | unstable | ia64 hscolour | 1.8-1+b1 | unstable | ia64 kaya |0.4.4-1 | unstable | ia64 lhs2tex | 1.13-4 | unstable | ia64 libghc6-alut-dev | 2.1.0.0-2 | unstable | ia64 libghc6-alut-prof | 2.1.0.0-2 | unstable | ia64 libghc6-arrows-dev | 0.3-2 | unstable | ia64 libghc6-arrows-prof | 0.3-2 | unstable | ia64 libghc6-binary-dev | 0.4.1-3+b2 | unstable | ia64 libghc6-binary-prof | 0.4.1-3+b2 | unstable | ia64 libghc6-cairo-dev | 0.9.13-5 | unstable | ia64 libghc6-cgi-dev | 3001.1.5.1-5 | unstable | ia64 libghc6-cgi-prof | 3001.1.5.1-5 | unstable | ia64 libghc6-configfile-dev |1.0.4.6 | unstable | ia64 libghc6-diff-dev |0.1.2-1 | unstable | ia64 libghc6-fgl-dev | 5.4.1.1-2 | unstable | ia64 libghc6-fgl-prof | 5.4.1.1-2 | unstable | ia64 libghc6-ftphs-dev |1.0.4.6 | unstable | ia64 libghc6-gconf-dev | 0.9.13-5 | unstable | ia64 libghc6-glade-dev | 0.9.13-5 | unstable | ia64 libghc6-glib-dev | 0.9.13-5 | unstable | ia64 libghc6-glut-dev | 2.1.1.1-2 | unstable | ia64 libghc6-glut-prof | 2.1.1.1-2 | unstable | ia64 libghc6-gnomevfs-dev | 0.9.13-5 | unstable | ia64 libghc6-gstreamer-dev | 0.9.13-5 | unstable | ia64 libghc6-gtk-dev | 0.9.13-5 | unstable | ia64 libghc6-gtkglext-dev | 0.9.13-5 | unstable | ia64 libghc6-haskell-src-dev | 1.0.1.1-2 | unstable | ia64 libghc6-haskell-src-prof | 1.0.1.1-2 | unstable | ia64 libghc6-haskelldb-dev | 0.10-5+b1 | unstable | ia64 libghc6-hat-dev | 2.05+rerolled-7+b1 | unstable | ia64 libghc6-haxml-dev | 1.13.3-2+b3 | unstable | ia64 libghc6-hdbc-dev |1.1.6.2 | unstable | ia64 libghc6-hdbc-odbc-dev | 1.1.6.0.1 | unstable | ia64 libghc6-hdbc-postgresql-dev | 1.1.6.0.1 | unstable | ia64 libghc6-hdbc-sqlite3-dev | 1.1.6.0.1 | unstable | ia64 libghc6-hgl-dev | 3.2.0.0-3 | unstable | ia64 libghc6-hgl-prof | 3.2.0.0-3 | unstable | ia64 libghc6-highlighting-kate-dev | 0.2.1-3+b2 | unstable | ia64 libghc6-highlighting-kate-prof | 0.2.1-3+b2 | unstable | ia64 libghc6-hlist-dev | 2.0+darcs20070929-1+b3 | unstable | ia64 libghc6-hlist-prof | 2.0+darcs20070929-1+b3 | unstable | ia64 libghc6-hsh-dev |1.2.6.4 | unstable | ia64 libghc6-hslogger-dev |1.0.7.2 | unstable | ia64 libghc6-hsql-dev | 1.7-2+b1 | unstable | ia64 libghc6-hsql-mysql-dev | 1.7-2+b1 | unstable | ia64 libghc6-hsql-mysql-prof | 1.7-2+b1 | unstable | ia64 libghc6-hsql-odbc-dev | 1.7-1+b1 | unstable | ia64 libghc6-hsql-odbc-prof | 1.7-1+b1 | unstable | ia64 libghc6-hsql-postgresql-dev | 1.7-2+b1 | unstable | ia64 libghc6-hsql-postgresql-prof | 1.7-2+b1 | unstable | ia64 libghc6-hsql-prof | 1.7-2+b1 | unstable | ia64 libghc6-hsql-sqlite3-dev | 1.7-1+b1 | unstable | ia64 libghc6-hsql-sqlite3-prof | 1.7-1+b1 | unstable | ia64 libghc6-html-dev | 1.0.1.1-2 | unstable | ia64 libghc6-html-prof | 1.0.1.1-2 | unstable | ia64 libghc6-http-dev | 30010004-3 | unstable | ia64 libghc6-http-prof | 30010004-3 | unstable | ia64 libghc6-hunit-dev | 1.2.0.0-2 | unstable | ia64 libghc6-hunit-prof | 1.2.0.0-2 | unstable | ia64 libghc6-irc-dev | 0.4.3-1+b2 | unstable | ia64 libghc6-ldap-dev |0.6.4.1 | unstable | ia64 libghc6-magic-dev |1.0.7.1 | unstable | ia64 libghc6-missingh-dev |1.0.3.2 |
Bug#569157: RM: haddock -- ROM; haddock now built from ghc6's source
Package: ftp.debian.org Severity: normal ghc6's source has included haddock in it for some time now. Starting with version 6.12.1, I'm building /usr/bin/haddock from that source and won't be building it from the source package haddock. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539238: ITP: gearhead2 -- roguelike mecha role playing game in space
Package: wnpp Severity: wishlist Owner: Kari Pahula k...@debian.org * Package name: gearhead2 Version : 0.603 Upstream Author : Joseph Hewitt pyrrh...@yahoo.ca * URL : http://www.gearheadrpg.com/ * License : LGPL v2.1 or later Programming Lang: Pascal Description : roguelike mecha role playing game in space Set a century and a half after nuclear war, you can explore a world where various factions compete to determine the future of the human race. Major features include random plot generation, a detailed character system, and over two hundred customizable mecha designs. . GearHead 2 is set five years after the events of GearHead 1. It is currently under development and is initially set in the L5 Orbital Pattern. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#242600: Shouldn't use Accept: */* until links2 supports application/xhtml+xml
links2 sends Accept: */* in HTTP requests currently. Servers interpret this to mean that they're free to send anything, including application/xhtml+xml and application/xml. It should use something like Accept: text/html,*/*;q=0.9 instead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535967: Inconsistent state after removal.
On Tue, Jul 07, 2009 at 02:21:44PM +0200, Joachim Breitner wrote: Kaol, can you comment on the ghc-pkg behaviour? Is --force the right thing to do, or is there an alternative? Did you try --no-user-package-conf yet? Other than that, something like HOME=/ ghc-pkg ... should work, even if that's an ugly hack. I'm not sure if ignoring ghc-pkg unregister's error or using --force is that good an idea. There's global user installed Cabal packages to consider (inadvisable as those may be). I'd rather expect users to unregister those first by themselves with ghc-pkg. After all, they're there because they installed them by themselves with ghc-pkg, in the first place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534883: ITP: haskell-lazysmallcheck -- A library for demand-driven testing of Haskell programs
Package: wnpp Severity: wishlist Owner: Kari Pahula k...@debian.org * Package name: haskell-lazysmallcheck Version : 0.3 Upstream Author : Matthew Naylor m...@cs.york.ac.uk * URL : http://www.cs.york.ac.uk/fp/smallcheck/ * License : BSD Programming Lang: Haskell Description : A library for demand-driven testing of Haskell programs Lazy SmallCheck is a library for exhaustive, demand-driven testing of Haskell programs. It is based on the idea that if a property holds for a partially-defined input then it must also hold for all fully-defined refinements of the that input. Compared to `eager' input generation as in SmallCheck, Lazy SmallCheck may require significantly fewer test-cases to verify a property for all inputs up to a given depth. I'm packaging this since other Haskell packages depend on this one. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531768: RM: haskell-happs-util -- ROM; orphaned, out of date
Package: ftp.debian.org Severity: normal I hope you don't mind if I merge several requests to one report. Maintaining HAppS packages in Debian isn't (IMHO) worth the trouble. I asked someone to adopt them (no interest). At this point, upgrading the packages would involve NEW anyway, since the project's been forked since. This actually concerns 6 packages. The rest of HAppS can go also: haskell-happs-state haskell-happs-server haskell-happs-ixset haskell-happs-data Also, haskell-hspread was only packaged since it looked like a prospective dependency for HAppS at one point. I'd like to ask to have it removed, too. I expect to see little interest in hspread by itself. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524097: /usr/include/arch-kernel-os/ dropped from implicit -I list in gcc-4.3
I did some testing with gcc versions 4.2.4-6 and 4.3.3-7. Looks like gcc-4.3 dropped /usr/include/i486-linux-gnu (and the equivalent on other arches) from the implicit -I list. I'm not sure if that was on purpose, so I'm not reassigning this bug. It's in GCC maintainers' domain, either way. $ gcc-4.2 -v hello.c -o hello (snip) ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../i486-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.2.4/include /usr/include/i486-linux-gnu /usr/include End of search list. (snip) $ gcc-4.3 -v hello.c -o hello (snip) ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../i486-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed /usr/include End of search list. (snip) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520860: Sorry, ghci is still unsupported on most arches
reassign 520860 haskell-convertible tags 520860 + patch thanks Sorry, but nothing's changed in this regard between 6.8 and 6.10. runghc is a wrapper that calls ghci, and the tier 2 platforms with GHCi No listed at http://hackage.haskell.org/trac/ghc/wiki/Platforms won't have the RTS linker that'd be needed for it. That's all in rts/Linker.c, in its arch-specific glory. It's still better to not rely on runghc in build scripts. --- orig/haskell-convertible-1.0.2/Makefile 2009-04-06 21:31:12.0 +0300 +++ haskell-convertible-1.0.2/Makefile 2009-04-06 19:58:47.0 +0300 @@ -1,13 +1,14 @@ -all: +all: setup @echo Please use Cabal to build this package; not make. - runghc Setup.lhs configure - runghc Setup.lhs build + ./setup configure + ./setup build -install: - runghc Setup.lhs install +install: setup + ./setup install -clean: - runghc Setup.lhs clean +clean: setup + ./setup clean + rm -f setup Setup.o Setup.hi .PHONY: test test: test-ghc test-hugs @@ -18,9 +19,12 @@ @echo ** Running hugs tests runhugs -98 +o -P$(PWD):$(PWD)/testsrc: testsrc/runtests.hs -test-ghc: +test-ghc: setup @echo ** Building GHC tests - runghc Setup.lhs configure -f buildtests - runghc Setup.lhs build + ./setup configure -f buildtests + ./setup build @echo ** Running GHC tests ./dist/build/runtests/runtests + +setup: + ghc6 -package Cabal Setup.lhs -o setup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518308: haskell-devscripts: dh_haskell_depends should get the transitive closure of dependencies
Package: haskell-devscripts Version: 0.6.15+nmu6 Severity: normal As an example, currently, libghc6-parsec-dev has Depends: ghc6 (= 6.10.1+dfsg1-13), ghc6 ( 6.10.1+dfsg1+), libghc6-mtl-dev (= 1.1.0.2-6), libghc6-mtl-dev ( 1.1.0.2+) And libghc6-network-dev has Depends: ghc6 (= 6.10.1+dfsg1-13), ghc6 ( 6.10.1+dfsg1+), libghc6-parsec-dev (= 3.0.0-4), libghc6-parsec-dev ( 3.0.0+) This may cause problems if mtl ever gets updated to a new upstream version. Its ABI has likely changed (along with the cabal version) and this change may or may not propagate to parsec's interface, affecting network. To play it safe, both parsec and network should be uninstallable together with the new mtl. BinNMUing parsec will fix its ABI, but then nothing in network's dependencies will prevent it from being installed together with the new mtl and new parsec. Taking the transitive closure of dependencies for network would solve this issue, ie. make it have Depends: ghc6 (= 6.10.1+dfsg1-13), ghc6 ( 6.10.1+dfsg1+), libghc6-parsec-dev (= 3.0.0-4), libghc6-parsec-dev ( 3.0.0+), libghc6-mtl-dev ( 1.1.0.2+) I see no need to include libghc6-mtl-dev (= 1.1.0.2-6) in libghc6-network-dev's dependencies, since that part won't play role in ABI changes and depending on libghc6-parsec-dev will already get the correct lower bound. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507912: Getting the cabal version easily out of a Debian package's version
Just to add a bit to this topic. I'd find it preferrable, from a script writing POV, to keep package versions such that matching regexp /[.0-9]*/ on the Debian package's version number uniquely matches with the Cabal version. The alternative is to grab the source and peek in the .cabal file. I'd like to get by with just what dpkg's database knows. Upstream gives little guarantees about it, but I'd still like to act like libraries are compatible as long as their cabal versions match. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516414: haskell-devscripts: Please separate dh_haskell_depends' and dh_haskell_prep's roles
Package: haskell-devscripts Version: 0.6.15+nmu2 Severity: wishlist Currently, dh_haskell_prep * generates postinst and postrm scripts * generates haskell:Depends substvar + adds a dependency on ghc6 + adds a dependency from the -prof package to the -dev package dh_haskell_depends * generates haskell:Depends substvar + adds a dependency on ghc6 + adds dependencies on any libraries that the package uses that aren't included in ghc6 itself I'd put that -prof to -dev link generation to dh_haskell_depends and wouldn't touch any substvars in dh_haskell_prep. Another possibility would be to merge these scripts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514847: RM: gecodej/experimental -- ROM; orphaned by upstream
Package: ftp.debian.org Severity: normal This package has never left experimental and upstream decided to discontinue making a Java interface for the library. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512027: ghc6: Build-Depends on itself
Package: ghc6 Version: 6.8.2dfsg1-1 Severity: important GHC is self-hosting, ie. ghc6 has a build dependency on ghc6. This complicates things more than what I'd like. GHC 6.12 might again be more readily bootstrappable without a previously built ghc binary. Until such time, I'm leaving this bug on ghc6. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511857: haskell-devscripts: Don't use -999 in ghc6 dependencies
Package: haskell-devscripts
Version: 0.6.14
Severity: important
Tags: patch
This is a bit boring one. I need to repackage ghc6's orig.tar.gz to
fix #511496 and name the new version as 6.8.2dfsg1. This'll work well
along with most haskell libraries, which use ghc6 ( 6.8.2+) as a
dependency. Sometimes haskell-devscripts still inserts 6.8.2-999,
instead. Could you please change that to use a + instead?
In general, + is better than -999 from ghc6's maintainer's POV, since
it allows more leeway about changing its version number.
Since the version in unstable is newer than the one in testing, you'll
need to either convince RMs to allow the new version to testing or use
t-p-u.
After this, there'll be a round of binNMUs...
--- dh_haskell_prep 2009-01-15 00:45:21.0 +0200
+++ dh_haskell_prep.new 2009-01-15 00:47:21.0 +0200
@@ -42,7 +42,7 @@
$pkgtype, = .
upstream_version(version_of_type($pkgtype)));
if (! ($pkgtype eq hugs)) {
addsubstvar($package, haskell:Depends,
- $pkgtype, .
upstream_version(version_of_type($pkgtype)) . -999);
+ $pkgtype, .
upstream_version(version_of_type($pkgtype)) . +);
}
# add postinst/prerm scripts
@@ -70,7 +70,7 @@
upstream_version(version_of_type($pkgtype)));
addsubstvar($package, haskell:Depends,
$pkgtype, .
- upstream_version(version_of_type($pkgtype)) . -999);
+ upstream_version(version_of_type($pkgtype)) . +);
# Call isnative becuase it sets $dh{VERSION}
# as a side effect.
isnative($package);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511857: Let's postpone #511857 post-lenny after all
severity 511857 normal thanks On second thought, I'll just go forward with uploading ghc6 6.8.2dfsg1-1 before libraries. No need to touch haskell-devscripts at this point. Though I's still prefer to see this thing changed, if only to make dh_haskell_prep and dh_haskell_depends give divergent results. I'm not sure there should be two scripts with apparently overlapping functions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511756: ghc6: Includes GMP, which has non-free GNU documentation
Package: ghc6 Version: 6.8.2-7 Severity: serious Justification: Policy 2.1. GHC includes GNU MP library with it, in gmp/gmp-4.2.1.tar.gz. The build system already does the right thing and doesn't link against the local copy of the library, but it still carries the tarball with the accompanying GNU documentation, with this license: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover Texts being ``A GNU Manual'', and with the Back-Cover Texts being ``You have freedom to copy and modify this GNU Manual, like GNU software''. I'll need to repackage the upstream tarball to remove its copy of GMP. That shouldn't be too disruptive. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#345780: Patch for #345780
Attached is a patch for #345780. RFC 821 says that an implementation
should at least handle text lines of 1000 characters, but it says also
that when possible, an implementation should avoid having these
limits. These issues happen with lines over 2k long, but even if it
didn't support them, it should return 500 Line too long. and not
just die or litter extra \r\n markers in between long lines.
I can NMU but I'd like to have someone review my patch. This thing
involves far too many buffers to my liking and I'm sure I've missed an
off by one error in there somewhere.
Index: ssmtp-2.62/ssmtp.c
===
--- ssmtp-2.62.orig/ssmtp.c 2008-11-04 14:56:56.0 +0200
+++ ssmtp-2.62/ssmtp.c 2008-11-04 15:05:27.0 +0200
@@ -343,28 +343,26 @@
/*
standardise() -- Trim off '\n's and double leading dots
*/
-void standardise(char *str)
+bool_t standardise(char *str, bool_t *linestart)
{
size_t sl;
char *p;
-
- if((p = strchr(str, '\n'))) {
- *p = (char)NULL;
- }
+ bool_t leadingdot = False;
/* Any line beginning with a dot has an additional dot inserted;
- not just a line consisting solely of a dot. Thus we have to slide
- the buffer down one */
- sl = strlen(str);
+ not just a line consisting solely of a dot. Thus we have to move
+ the buffer start up one */
- if(*str == '.') {
- if((sl + 2) BUF_SZ) {
- die(standardise() -- Buffer overflow);
- }
- (void)memmove((str + 1), str, (sl + 1));/* Copy
trailing \0 */
+ if(*linestart *str == '.') {
+ leadingdot = True;
+ }
+ *linestart = False;
- *str = '.';
+ if((p = strchr(str, '\n'))) {
+ *p = (char)NULL;
+ *linestart = True;
}
+ return(leadingdot);
}
/*
@@ -1359,12 +1357,12 @@
*/
ssize_t smtp_write(int fd, char *format, ...)
{
- char buf[(BUF_SZ + 1)];
+ char buf[(BUF_SZ + 2)];
va_list ap;
ssize_t outbytes = 0;
va_start(ap, format);
- if(vsnprintf(buf, (BUF_SZ - 2), format, ap) == -1) {
+ if(vsnprintf(buf, (BUF_SZ - 1), format, ap) == -1) {
die(smtp_write() -- vsnprintf() failed);
}
va_end(ap);
@@ -1402,16 +1400,18 @@
*/
int ssmtp(char *argv[])
{
- char buf[(BUF_SZ + 1)], *p, *q;
+ char b[(BUF_SZ + 2)], *buf = b+1, *p, *q;
#ifdef MD5AUTH
char challenge[(BUF_SZ + 1)];
#endif
struct passwd *pw;
int i, sock;
uid_t uid;
- bool_t minus_v_save;
+ bool_t minus_v_save, leadingdot, linestart = True;
int timeout = 0;
+ int bufsize = sizeof(b)-1;
+ b[0] = '.';
outbytes = 0;
ht = headers;
@@ -1494,12 +1494,12 @@
}
strncpy(challenge, strchr(buf,' ') + 1,
sizeof(challenge));
- memset(buf, 0, sizeof(buf));
+ memset(buf, 0, bufsize);
crammd5(challenge, auth_user, auth_pass, buf);
}
else {
#endif
- memset(buf, 0, sizeof(buf));
+ memset(buf, 0, bufsize);
to64frombits(buf, auth_user, strlen(auth_user));
if (use_oldauth) {
outbytes += smtp_write(sock, AUTH LOGIN %s, buf);
@@ -1511,7 +1511,7 @@
die(Server didn't like our AUTH LOGIN (%s),
buf);
}
/* we assume server asked us for Username */
- memset(buf, 0, sizeof(buf));
+ memset(buf, 0, bufsize);
to64frombits(buf, auth_user, strlen(auth_user));
outbytes += smtp_write(sock, buf);
}
@@ -1520,7 +1520,7 @@
if(smtp_read(sock, buf) != 3) {
die(Server didn't accept AUTH LOGIN (%s), buf);
}
- memset(buf, 0, sizeof(buf));
+ memset(buf, 0, bufsize);
to64frombits(buf, auth_pass, strlen(auth_pass));
#ifdef MD5AUTH
@@ -1631,7 +1631,7 @@
/* don't hang forever when reading from stdin */
while(!feof(stdin) timeout MEDWAIT) {
- if (!fgets(buf, sizeof(buf), stdin)) {
+ if (!fgets(buf, bufsize, stdin)) {
/* if nothing was received, then no transmission
* over smtp should be done */
sleep(1);
@@ -1639,12 +1639,25 @@
continue;
}
/* Trim off \n, double leading .'s */
- standardise(buf);
-
- outbytes += smtp_write(sock, %s, buf);
+ leadingdot = standardise(buf, linestart);
+ if (linestart)
Bug#462482: darcs repository for hlibrary.mk
FYI, I'm keeping the newest version of my CDBS rule file in http://people.debian.org/~kaol/repos/hlibrary/ With your permission, I would like to step in as a comaintainer for haskell-devscripts and include hlibrary.mk in it and take care of that part. Another possible home for it would be in the cdbs package itself, but I feel that hlibrary.mk may be more tightly bound to haskell-devscripts instead. It's too small to really justify having it in a package of its own. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435040: xserver-xorg-video-ati: switching VT from console to X freezes computer with X22 (Radeon Mobility M6 LY)
On Sat, Aug 09, 2008 at 09:41:22AM +0200, Brice Goglin wrote: This time, this is very likely to be fixed upstream for real. I just wanted to confirm that VT switching works again. Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374901: Patch for #374901
tag 374901 + patch severity 374901 important thanks I bumped the bug's severity since running into this isn't all that rare (and to justify fixing this to RMs). I ran the game in gdb and reproduced this. The flow of events, AFAICT, is thus: 1. The windmill has the grid ID stored in int_6 in the map.info array 2. Bulldozing it sets int_6 to zero, while the info window continues displaying the status for that map square (that's why the game warns MPS unimplemented for that module, since there's no info for grass). 3. Building a windmill over the same square determines the grid it belongs to only after the phase of the game loop that refreshes the text in the info window. int_6 is still zero at this point, leading to a seg fault on this line: format_power (s, sizeof(s), grid[MP_INFO(x,y).int_6]-max_power); A cleaner solution might be to reorder the order of events at step 3, but I went to a less invasive approach with my patch. I just disabled showing the grid status info if the grid ID is not set. It gets displayed correctly on the next game tick. I patched the substation code too since the same bug applies to that, too. diff -ru lincity-1.13.1/modules/substation.c ../lincity-1.13.1/modules/substation.c --- lincity-1.13.1/modules/substation.c 2004-07-03 10:37:35.0 +0300 +++ ../lincity-1.13.1/modules/substation.c 2008-07-28 10:42:19.0 +0300 @@ -101,8 +101,11 @@ format_power (s, sizeof(s), MP_INFO(x,y).int_5); mps_store_title(i++,_(Local Demand)); mps_store_title(i++,s); -i++; +if (MP_INFO(x,y).int_6 == 0) + return; + +i++; mps_store_title(i++,_(Grid Status)); format_power (s, sizeof(s), grid[MP_INFO(x,y).int_6]-max_power); diff -ru lincity-1.13.1/modules/windmill.c ../lincity-1.13.1/modules/windmill.c --- lincity-1.13.1/modules/windmill.c 2004-06-23 17:49:52.0 +0300 +++ ../lincity-1.13.1/modules/windmill.c2008-07-28 10:42:58.0 +0300 @@ -97,6 +97,10 @@ mps_store_sfp(i++,_(Tech), MP_INFO(x,y).int_2 * 100.0 / MAX_TECH_LEVEL); + + if (MP_INFO(x,y).int_6 == 0) + return; + i++; mps_store_title(i++,_(Grid Status)); signature.asc Description: Digital signature
Bug#119583: mozart for amd64 using gcc-multilib
It wouldn't be pretty, but it should be possible to compile a 32-bit version of Mozart for amd64 using gcc-multilib and/or g++-multilib. That's what I did with smlnj, which only supports powerpc and i386. IMHO having a package that users can install is preferrable over not having a package at all, even if it wouldn't be the real thing. Doing this is likely to necessiate some changes to the build system, to force it use i386 as the build arch on amd64. That and Build-Depends: g++-multilib [amd64] should do the trick. (Mozart's written in C++?) /me looks forward to seeing 1.4.0. :-) signature.asc Description: Digital signature
Bug#435040: Still have this bug
On Wed, May 14, 2008 at 02:07:07PM +0200, Brice Goglin wrote: Actually, UseFBDev has been removed in 6.8.0. So we are not dealing with the same problem anymore. It is the same problem that you observed earlier when you tried disabling UseFBDev. I don't think that UseFBDev has ever mattered, other than via causing an extra delay at some critical point during VT switching, which has helped to avoid the crash. Attaching strace to X or even raising the nice value and running a busy loop in other process seems to make the freeze bug go away, too. But even when there's no freeze, I still have at least 10 seconds' delay before I get to use X after pressing alt-F11 (yes, I have 10 virtual consoles), so I guess the whole issue is rather moot unless that gets cut down to some sane duration. I guess I would spend my time better teaching some WM to give me as quick an access to an xterm as the flick of ctrl-alt-F1 rather than hope that this all gets fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435040: Still have this bug
On Mon, May 12, 2008 at 01:36:11PM +0200, Brice Goglin wrote: Which xserver-xorg-core and xserver-xorg-video-ati were you using at this point? xserver-xorg-core 2:1.4.1~git20080507-1 and xserver-xorg-video-ati 1:6.8.0-1 Upstream claims the bug is fixed. NACK. My laptop still freezes when I switch the VT from console back to X. When I attached strace on the X process, everything went fine, but without, I get the same hard freeze. I can't even seem to get X to freeze with strace this time around. The xorg.conf file is still the same as when I first reported this bug. I don't think that the int10 issue matters... I didn't see anything related to it in the current log dump (attached), either. Looks like I'd need to grab the source and start adding some delay loops at selected places to try to find where this happens. Sounds daunting. I know that I may well be the only one who encounters this bug. I know that there was nothing wrong with VT switching during the XFree86 days. My laptop is old and nobody's likely to have another like it anymore. For all I know my laptop might even be subtly broken. I'm half expecting you to tell me to just live with this already. This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.4.0.90 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20080507-1) Current Operating System: Linux sininen 2.6.25.3 #2 Mon May 12 16:46:59 UTC 2008 i686 Build Date: 09 May 2008 11:51:59AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Mon May 12 17:03:49 2008 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Generic Monitor (**) | |--Device ATI Technologies Inc Radeon Mobility M6 LY (**) |--Input Device Generic Keyboard (**) |--Input Device Configured Mouse (**) |--Input Device Synaptics Touchpad (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to /etc/X11/rgb (==) ModulePath set to /usr/lib/xorg/modules (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x81d8500 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: pcidata (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor=X.Org Foundation compiled for 1.4.0.90, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) using VT number 11 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,3575 card 1014,021d rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,3576 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card 1014,0220 rev 01 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2484 card 1014,0220 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2487 card 1014,0220 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 41 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card , rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card 1014,0220 rev 01 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,2483 card 1014,0220 rev 01 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 1014,0222 rev 01 class 04,01,00 hdr 00 (II) PCI: 01:00:0: chip 1002,4c59 card 1014,0239 rev 00 class 03,00,00 hdr 00 (II) PCI: 02:03:0: chip 1180,0476 card 3000, rev 80 class 06,07,00 hdr 82 (II) PCI: 02:03:1: chip 1180,0476 card 3800, rev 80 class 06,07,00 hdr 82 (II) PCI: 02:05:0: chip 11c1,0449 card 1468,0410 rev 01 class 07,80,00 hdr 00 (II) PCI: 02:08:0: chip 8086,1031 card 1014,0209 rev 41 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II)
Bug#479557: sox: /usr/bin/play accepts at most 32 input files
Package: sox Version: 14.0.1-2 Severity: wishlist $ ls | wc -l 51 $ play * play sox: Too many filenames; maximum is 32 input files and 1 output file Could you please lift this one? I can easily hit this limit with longer playlists. Looks like allocating an array for the input files dynamically wouldn't hurt. I can see this gem in sox.c: #define MAX_INPUT_FILES 32 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474921: dh_haskell_depends: can't find the installed package description file for -prof
Package: haskell-devscripts Version: 0.6.10 Severity: normal Tags: patch I encountered another issue with the dh_haskell_depends script. That last dollar sign gets added literally to the pkg variable, leading to breakage. --- /usr/bin/dh_haskell_depends 2008-03-31 13:02:59.0 +0300 +++ dh_haskell_depends 2008-04-08 00:55:07.0 +0300 @@ -177,7 +177,7 @@ pkg=$1 case $pkg in libghc6-*-prof) - pkg=`echo $pkg | sed -e 's/-prof$/-dev$/'` + pkg=`echo $pkg | sed -e 's/-prof$/-dev/'` ;; *) ;; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474549: RM: happs -- RoM; source package split into haskell-happs-*
Package: ftp.debian.org Severity: wishlist The upstream distributes HAppS as smaller components currently and I've packaged the separate components as different source packages. It's a pain, IMO, but it's still easier to go along with that. Please remove the happs package, it's been superceded by haskell-happs-*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473549: dh_haskell_depends: fails for calculating dependencies on Debian native packages
Package: haskell-devscripts
Version: 0.6.10
Severity: important
Tags: patch
dh_haskell_depends fails when processing dependencies on Debian native
Haskell library packages (CosmicRay, I'm looking at you).
As an example, take libghc6-hslogger-dev. Its version is 1.0.5.0 as
of this writing. dh_haskell_depends tries to run sed -e 's/-[^-]*$/+/'
on that to add a plus after the string, which will fail.
Consequently, this is the dependency I got for a library I'm
packaging: libghc6-hslogger-dev (= 1.0.5.0), libghc6-hslogger-dev ( 1.0.5.0)
That's not installable. A patch for this:
--- /usr/bin/dh_haskell_depends 2008-03-22 22:28:43.0 +0200
+++ dh_haskell_depends 2008-03-31 12:59:39.0 +0300
@@ -68,8 +68,8 @@
local next_upstream_version
package=$1
version=`dpkg-query --showformat='${Version}' -W $package`
-next_upstream_version=`echo $version | sed -e 's/-[^-]*$/+/'`
-echo $package (= $version), $package ( $next_upstream_version)
+next_upstream_version=`echo $version | sed -e 's/-[^-]*$//'`
+echo $package (= $version), $package ( $next_upstream_version+)
}
dependencies(){
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.23.9 (SMP w/2 CPU cores)
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Versions of packages haskell-devscripts depends on:
ii dctrl-tools 2.12 Command-line tools to process Debi
ii debhelper 6.0.10 helper programs for debian/rules
ii ghc6 6.8.2-4GHC - the Glasgow Haskell Compilat
ii xutils-dev1:7.4+1X Window System utility programs f
haskell-devscripts recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473563: ITP: haskell-hspread -- Haskell client library for the Spread toolkit
Package: wnpp Severity: wishlist Owner: Kari Pahula [EMAIL PROTECTED] * Package name: haskell-hspread Version : 0.3 Upstream Author : Andrea Vezzosi [EMAIL PROTECTED] * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hspread-0.3 * License : 3 clause BSD Programming Lang: Haskell Description : Haskell client library for the Spread toolkit A haskell library that supports the most recent version of the Spread protocol. Its aim is to make easier to implement correct distribuited applications by taking advantage of the guarantees granted by Spread: such as reliable and total ordered messages. It's intended to be used with a serialization library like binary, and a separate installation of the spread deamon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435040: Still have this bug
I recently used my laptop again for some time and can report that same VT freeze issues are still there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473324: libghc6-happs-dev: Should split source packages according to upstream's scheme
Package: libghc6-happs-dev Version: 0.9.2.1-1 Severity: serious HAppS is currently distributed by upstream as 5 different cabal packages. I merged them together into one by hand for this version. While this does the job, it causes problems for any Haskell programs using HAppS, since there's no cabal package called HAppS outside of Debian. I'll upload a new version that follows upstream's packaging shortly. In the meantime, I don't want to have this version enter testing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465103: RM: terraform -- RoM; depends on gnome1 libs, upstream dead
Package: ftp.debian.org Severity: normal Terraform's upstream is dead (last release in 2002) and it depends on gnome1 libraries and I'm not about to try porting it to use gnome2 libraries myself. Let's just remove it. Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464120: Make pbzip2 recognize all of bzip2's command line options
Package: pbzip2 Version: 1.0.2-0 Severity: wishlist It would be useful to have pbzip2 recognise all the command line options that bzip2 does, so that pbzip2 could be used as a drop in replacement. -z, -q, -L and -- should be easy. -s could be just ignored... perhaps? --repetitive-fast and --repetitive-best could be parsed and safely ignored. pbzip2 has some options that bzip2 doesn't, but that's all good and well as long as they don't clash with anything that bzip2 has. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462482: haskell-devscripts: CDBS rule file for haskell libraries
Package: haskell-devscripts
Version: 0.6.6
Severity: wishlist
Tags: patch
Please include the attached hlibrary.mk file and install it in
/usr/share/cdbs/1/class/.
The man page should also have a mention using
include /usr/share/cdbs/1/class/hlibrary.mk
as an alternative to using dh_haskell.
Having haskell-devscripts Suggest or even Recommend cdbs wouldn't
hurt, either.
I would still like to get more feedback about using this CDBS makefile
class, but I think it's ready for wider use already.
# -*- mode: makefile -*-
# Copyright 2008 Kari Pahula [EMAIL PROTECTED]
# Description: A class for Haskell library packages
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2, or (at
# your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
# 02111-1307 USA.
_cdbs_scripts_path ?= /usr/lib/cdbs
_cdbs_rules_path ?= /usr/share/cdbs/1/rules
_cdbs_class_path ?= /usr/share/cdbs/1/class
include $(_cdbs_rules_path)/debhelper.mk$(_cdbs_makefile_suffix)
CABAL_PACKAGE = $(shell cat *.cabal |\
perl -ne 'if (/^name:\s*(.*)$$/i) {$$_ = $$1; tr/A-Z/a-z/; print; exit 0;}')
ENABLE_PROFILING = $(shell egrep -qe '^Package: libghc6-.*-prof$$' debian/control echo --enable-library-profiling; exit 0)
# TODO:
# - some of this would probably be useful for generic Haskell programs,
# not just libraries
# - provide more hooks
# - get this included in the cdbs package once this gets mature enough (maybe?)
clean::
test ! -e setup-bin || ./setup-bin clean
rm -rf dist dist-ghc6 dist-hugs setup-bin Setup.hi Setup.ho Setup.o .*config*
rm -f build-ghc6-stamp build-hugs-stamp
setup-bin:
if test ! -e Setup.lhs -a ! -e Setup.hs; then echo No setup script found!; exit 1; fi
for setup in Setup.lhs Setup.hs; do if test -e $$setup; then ghc6 -package Cabal $$setup -o setup-bin; exit 0; fi; done
dist-ghc6: setup-bin
echo ENABLE_PROFILING is $(ENABLE_PROFILING)
./setup-bin configure --ghc --prefix=/usr/lib/haskell-packages/ghc6 -v2 $(ENABLE_PROFILING) $(DEB_SETUP_GHC6_CONFIGURE_ARGS)
mv dist dist-ghc6
build-ghc6-stamp: dist-ghc6
mv dist-ghc6 dist
./setup-bin build
mv dist dist-ghc6
touch build-ghc6-stamp
build/libghc6-$(CABAL_PACKAGE)-prof build/libghc6-$(CABAL_PACKAGE)-dev:: build-ghc6-stamp
# Provide two alternate names for the -doc package
build/haskell-$(CABAL_PACKAGE)-doc build/libghc6-$(CABAL_PACKAGE)-doc:: dist-ghc6
mv dist-ghc6 dist
./setup-bin haddock
mv dist dist-ghc6
dist-hugs: setup-bin
./setup-bin configure --hugs --prefix=/usr -v2
mv dist dist-hugs
build/libhugs-$(CABAL_PACKAGE):: dist-hugs
mv dist-hugs dist
./setup-bin build $(DEB_SETUP_HUGS_CONFIGURE_ARGS)
mv dist dist-hugs
install/libghc6-$(CABAL_PACKAGE)-dev:: setup-bin
mv dist-ghc6 dist
./setup-bin copy --destdir=debian/libghc6-$(CABAL_PACKAGE)-dev
find debian/libghc6-$(CABAL_PACKAGE)-dev/usr/lib/haskell-packages/ghc6/lib/ -name *_p.a -exec rm '{}' ';'
find debian/libghc6-$(CABAL_PACKAGE)-dev/usr/lib/haskell-packages/ghc6/lib/ -name *.p_hi -exec rm '{}' ';'
rm -rf debian/libghc6-$(CABAL_PACKAGE)-dev/usr/share/doc/*
dh_haskell_prep -plibghc6-$(CABAL_PACKAGE)-dev
cp dist/installed-pkg-config debian/libghc6-$(CABAL_PACKAGE)-dev/usr/lib/haskell-packages/ghc6/lib/*/
rm -rf debian/libghc6-$(CABAL_PACKAGE)-dev/usr/lib/haskell-packages/ghc6/share/
mv dist dist-ghc6
install/libghc6-$(CABAL_PACKAGE)-prof:: setup-bin
mv dist-ghc6 dist
./setup-bin copy --destdir=debian/libghc6-$(CABAL_PACKAGE)-prof
find debian/libghc6-$(CABAL_PACKAGE)-prof/usr/lib/haskell-packages/ghc6/lib/ -name *[^p].a -exec rm '{}' ';'
find debian/libghc6-$(CABAL_PACKAGE)-prof/usr/lib/haskell-packages/ghc6/lib/ -name *.o -exec rm '{}' ';'
find debian/libghc6-$(CABAL_PACKAGE)-prof/usr/lib/haskell-packages/ghc6/lib/ -name *.hi -exec rm '{}' ';'
rm -rf debian/libghc6-$(CABAL_PACKAGE)-prof/usr/share/doc/*
dh_haskell_prep -plibghc6-$(CABAL_PACKAGE)-prof
cp dist/installed-pkg-config debian/libghc6-$(CABAL_PACKAGE)-dev/usr/lib/haskell-packages/ghc6/lib/*/
rm -rf debian/libghc6-$(CABAL_PACKAGE)-prof/usr/lib/haskell-packages/ghc6/share/
mv dist dist-ghc6
install/haskell-$(CABAL_PACKAGE)-doc install/libghc6-$(CABAL_PACKAGE)-doc:: setup-bin
mv dist-ghc6 dist
mkdir -p debian/libghc6-$(CABAL_PACKAGE)-doc/usr/share/doc/libghc6-$(CABAL_PACKAGE)-doc/html/
cp -r dist/doc/html/*/* debian/libghc6-$(CABAL_PACKAGE)-doc/usr/share/doc/*/html/
mv dist dist-ghc6
install/libhugs-$(CABAL_PACKAGE):: setup-bin
mv dist-hugs dist
./setup-bin copy
Bug#461449: O: droidbattles
Package: wnpp Severity: normal I tried to do an upload with some minor fixes to set the maintainer as QA but I couldn't even get droidbattles to compile anymore. A prime candidate for removal unless someone steps forward to adopt this. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.23.9 (SMP w/2 CPU cores) Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460558: haskell-devscripts: dh_haskell_prep sets dependency on ghc6-prof-prof for -prof packages
Package: haskell-devscripts
Version: 0.6.4
Severity: important
This is from dh_haskell_prep:
if (type_of_package($package) eq ghc6-prof) {
# substitute ${haskell:Depends} for profiling package
my $pkgtype = type_of_package($package);
snip
# add depends on ghc?-prof
addsubstvar($package, haskell:Depends, $pkgtype . -prof);
}
$pkgtype . -prof equals ghc6-prof-prof. I'm thinking that you
could remove that last part completely, since you're adding versioned
dependencies for ghc6-prof inside that if block already.
This is what the contents of my debian/libghc6-binary-prof.substvars
looked like:
haskell:Depends=ghc6-prof-prof, ghc6-prof ( 6.8.2-999), ghc6-prof (= 6.8.2),
libghc6-binary-dev (= 0.4.1-1)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460457: Please provide a libghc6-haxml-prof package
Package: haxml Version: 1.13.2-9 Severity: wishlist HAppS depends on HaXml and I'd like to provide profiling support for HAppS. For that, I'd need a HaXml library with profiling support compiled in. Could you please look into it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457373: ITP: pxsl -- Parsimonious XML Shorthand Language
Package: wnpp Severity: wishlist Owner: Kari Pahula [EMAIL PROTECTED] * Package name: pxsl Version : 1.0 Upstream Authors: Tom Moertel [EMAIL PROTECTED] and Bill Hubauer [EMAIL PROTECTED] * URL : http://community.moertel.com/ss/space/PXSL * License : GPLv2 or later Programming Lang: Haskell Description : Parsimonious XML Shorthand Language PXSL (pixel) provides XML authors and programmers with a simple, concise syntax that they can use to create XML documents. . For more advanced users, PXSL offers customizable shortcuts and sophisticated refactoring tools like functional macros that can markedly reduce the size and complexity of markup-dense XML documents. . The short version is this: PXSL is XML turned inside-out. Instead of tagging the structure, you tag the non-structure, which is the better approach when most of your information is structure. . Also, PXSL lets users intermix PXSL and XML syntax in one document. Users are free to use whichever syntax works best for each portion of their documents. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442618: RM: singularity-data -- RoM; merged back into singularity
Package: ftp.debian.org Severity: normal The package singularity-data was split from singularity originally due to non-free game data. Starting with 0.26-1, they have been remerged into a single package and resectioned to main since the licenses allowed that. Now that the new singularity version has entered testing, I would like to request the removal of singularity-data from unstable and testing. Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432094: Singularity 0.26 media under BY-SA 3
On Tue, Aug 07, 2007 at 07:35:02PM -0500, Phil Bordelon wrote: Just to let you know: the upcoming release of E:S 0.26 has its media relicensed under CC BY-SA 3 (although I hadn't seen this bug before I pushed for it), so the game will be able to get moved out of non-free once we cut a release ... which will be in the next few days. That's great. But still, one more thing. What about acknoff.ttf? You've got that from http://www.aenigmafonts.com/fonts/fontsa.html and that still remains non-free. Debian likes to be able to Sell or Distribute Fonts for profit or alter them without having to ask the author first. You cropped off the rest of the upstream's disclaimer from your README.txt, that last bit was in the text on the font author's site. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435040: xserver-xorg-video-ati: switching VT from console to X freezes computer with X22 (Radeon Mobility M6 LY)
On Mon, Aug 06, 2007 at 10:14:35AM +0200, Michel Dänzer wrote: Does explicitly loading the int10 module in the xorg.conf section Module work around it? Yeah, that seemed to fix it. This is what I see in the log after switching the VT to X: (II) Open ACPI successful (/var/run/acpid.socket) (WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10. (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (II) Configured Mouse: ps2EnableDataReporting: succeeded There's a delay of more than 15 seconds (mostly calling FBIOPUTCMAP ioctl and gettimeofday, apparently) after the V_BIOS entry and before X is usable, but at least the VT switches without any screen freezes with int10. But those delays are a separate issue altogether. Thanks.
Bug#435040: xserver-xorg-video-ati: switching VT from console to X freezes computer with X22 (Radeon Mobility M6 LY)
On Mon, Aug 06, 2007 at 11:48:14AM +0200, Michel Dänzer wrote:
On Mon, 2007-08-06 at 11:43 +0300, Kari Pahula wrote:
There's a delay of more than 15 seconds (mostly calling FBIOPUTCMAP
ioctl and gettimeofday, apparently) after the V_BIOS entry and before
X is usable, but at least the VT switches without any screen freezes
with int10. But those delays are a separate issue altogether.
Does not using Option UseFBDev make any difference for this?
Commenting out the UseFBDev option made a difference, in that it made
starting X faster. But it also brought the VT switching freeze back,
and this time it would lock down the kernel and not just the screen.
Doesn't respond to pings or anything. I still had the int10 module
loaded.
I did some debugging and noticed that running X with
nice -n -10 strace X 2stracedump
made the freezes go away... If I took away the nice command with the
negative priority, the system would freeze. Looks like X really likes
to have a bit longer delay at some point. I suppose the delay(s)
caused by FBDev could cause the same thing. I know that I'm happily
making only guesses about this... I don't know why it would behave
like it does.
Some of the time X didn't lock up the system even without that nice
thing I did above, but at least I think I could identify where the
system gets locked up.
This time I didn't even see anything as distinctive in the strace dump
as I did last time... I attached the output of
tail -n 400 ~/stracedump | uniq -c
This is from a run where strace wasn't niced and I got the freeze.
With a niced strace, the part where the freeze apparently happens goes
like this:
ioctl(6, VIDIOC_S_FMT or VT_RELDISP, 0x1) = 0
shutdown(5, 2 /* send and receive */) = 0
close(5)= 0
iopl(0) = 0
ioperm(0, 0x400, 0) = 0
gettimeofday({1186408789, 97309}, NULL) = 0
gettimeofday({1186408789, 97409}, NULL) = 0
select(256, [1 3 4], NULL, NULL, {111, 851000}) = ? ERESTARTNOHAND (To be restar
ted)
--- SIGUSR1 (User defined signal 1) @ 0 (0) ---
rt_sigaction(SIGUSR1, {0x80b0f60, [USR1], SA_RESTART}, {0x80b0f60, [USR1], SA_RE
START}, 8) = 0
sigreturn() = ? (mask now [IO])
ioctl(6, VIDIOC_S_FMT or VT_RELDISP, 0x2) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [IO], 8) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 5
connect(5, {sa_family=AF_FILE, path=/var/run/acpid.socket}, 110) = 0
write(0, (II) Open ACPI successful (/var/..., 50) = 50
1 read(10, 9-9\nDejaVuSansCondensed.ttf -dej..., 4096) = 4096
1 read(10, 0-iso8859-2\nDejaVuSansMono.ttf -..., 4096) = 4096
1 read(10, -dejavu-dejavu serif-medium-o-c..., 4096) = 786
2 read(10, , 4096) = 0
1 close(10) = 0
1 munmap(0xb7f72000, 4096)= 0
1 open(/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/fonts.alias,
O_RDONLY) = 10
2 fstat64(10, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
1 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f72000
1 read(10, , 4096) = 0
1 close(10) = 0
1 munmap(0xb7f72000, 4096)= 0
1 open(/usr/share/fonts/X11/misc/6x13-ISO8859-1.pcf.gz, O_RDONLY) = 10
1 read(10, \37\213\10\0I4\246F\0\3\355\\it\33\327u\376\260I\264\265...,
8192) = 4637
1 read(10, , 8192) = 0
1 close(10) = 0
1 open(/usr/share/fonts/X11/misc/cursor.pcf.gz, O_RDONLY) = 10
1 read(10, \37\213\10\0:4\246F\0\3\355\233{p\335\305u\307\217\356...,
8192) = 5225
1 read(10, , 8192) = 0
1 brk(0x83a6000) = 0x83a6000
1 close(10) = 0
1 rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0
1 rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0
1 gettimeofday({1186401940, 291870}, NULL) = 0
1 gettimeofday({1186401940, 291958}, NULL) = 0
1 gettimeofday({1186401940, 292053}, NULL) = 0
1 gettimeofday({1186401940, 292151}, NULL) = 0
1 select(256, [1 3 4 5 6], NULL, NULL, {600, 0}) = 1 (in [6], left {594,
704000})
1 rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0
1 read(6, \35, 64) = 1
1 gettimeofday({1186401945, 589552}, NULL) = 0
1 rt_sigprocmask(SIG_BLOCK, [], [IO], 8) = 0
1 rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0
1 setitimer(ITIMER_REAL, {it_interval={0, 2}, it_value={0, 2}},
NULL) = 0
1 gettimeofday({1186401945, 589917}, NULL) = 0
1 select(256, [1 3 4 5 6], NULL, NULL, {594, 703000}) = 1 (in [6], left
{594, 696000})
1 rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0
1 read(6, 8, 64)= 1
1 gettimeofday({1186401945, 595499}, NULL) = 0
1 rt_sigprocmask(SIG_BLOCK, [], [IO], 8) = 0
1
Bug#435040: xserver-xorg-video-ati: switching VT from console to X freezes computer with X22 (Radeon Mobility M6 LY)
On Mon, Aug 06, 2007 at 12:03:41AM +0200, Brice Goglin wrote:
Kari Pahula wrote:
Package: xserver-xorg-video-ati
Version: 1:6.6.192-1
Severity: important
Changing the VT from X to console and back to X locks up the computer
completely, unless I'm using the console framebuffer device. With
console fbdev, just the screen freezes and I can still ssh to it or type
blindly.
Does 1:6.6.193-1 (in experimental now) help?
No, I'm still seeing this bug. With the new version, the last few
lines of Xorg.0.log become
(II) Configured Mouse: ps2EnableDataReporting: succeeded
(II) Open ACPI successful (/var/run/acpid.socket)
(WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10.
Where the last two entries get into the log when I switch the VT.
I debugged this issue a bit further. Apparently switching the VT
kills the X process and leaves the screen frozen. Restarting X via
ssh unfreezes the screen (not that surprising really, IMHO). I tried
VT switching again after disabling ACPI support from the kernel, which
didn't help any. Only the log messages changed a bit.
(II) Configured Mouse: ps2EnableDataReporting: succeeded
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(II) No APM support in BIOS or kernel
(WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10.
I ran /usr/bin/X with strace. The whole dump would be bigger than
what I'd care to attach, but I saw this (relevant?) line at the end of
it.
writev(2, [{X, 1}, {: , 2}, {symbol lookup error, 19}, {: , 2},
{/usr/lib/xorg/modules/drivers//r..., 44}, {: , 2}, {undefined symbol:
xf86InitInt10, 31}, {, 0}, {, 0}, {\n, 1}], 10X: symbol lookup error:
/usr/lib/xorg/modules/drivers//radeon_drv.so: undefined symbol: xf86InitInt10
) = 102
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424056: Missing libsmlnj-smlnj
On Sun, Aug 05, 2007 at 05:55:39PM -0700, Phil Miller wrote: So, after looking more carefully at the list of available packages from the smlnj source package and what each contained, I realized that the things I was looking for were part of libsmlnj-smlnj. After installing this, both the open of LibBase and what I really needed to That was a rather opportune timimg from my perspective, since I was just about to start trying to nail this bug down. Thank you. do my work worked perfectly well. I'd like to request that the SML/NJ packages either be reorganized to match how the users will see them, or at least that smlnj declare some sort of relationship with libsmlnj-smlnj. Depends would be nice, but I would have solved my problem sooner if there had even been a Suggests or Recommends. The semantics of Recommends is already you really want these, but I could conceivably be used without so I think that relation fits this situation. I think I'll move my build dir under some other directory than /home/kaol. That'll stop people from sending bugs about seeing it, at least. As for the dependencies and the uninformative error messages about them, I could add a bunch of Suggests for the rest of the libraries... But it's already easy enough to check the reverse dependecies for the smlnj package, I hope. I'm hoping that this bug has now been resolved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
