Bug#821113: Rethink d-s-a Reply-To to avoid frustrated users and administrivia/off-topic floods
splash noise. 4a. Whatever filter is supposed to be keeping administrivia from hitting the list in general obviously isn't working; "machine learning is hard" aside, I repeatedly see messages with the subject or first line literally being "unsubscribe" in its entirety. In any event, this wouldn't help with everything, because inattentive replies in general (which are coming from a psychological context of not being in "interactive mailing list mode") and unsuitably-configured out-of-office autoresponders are also problems, and all of these seem to come from the same disconnect between action and effect caused by the weird Reply-To configuration. Thus my suggestion at the top. Aside from any of that, I'd volunteer to play docent to the users affected by this if I had the energy over time, but I really don't. If there's a one-off action I can do to help, it would be nice to know what it is in case I can manage it somehow. Can we please get this to stop? ---> Drake Wilson
Bug#820105: Agreement re: xscreensaver: please consider removal from sid
Absolutely agreed. (The rest of this is long because I lack the time to shorten it.) I already set Package: xscreensaver xscreensaver-* Pin: version * Pin-Priority: -1 whenever I remember to, for more or less this reason; it's been clear for years that upstream doesn't really want to play ball and considers their having done most of the work to absolve them from concern about unexpected impact on people and processes who consume it (consider #702258). Benevolent Dictators for Life are one thing, but Apathetic Inconsiderate Dictators for Life make things dangerous to rely on. I have some empathy for their position, but that doesn't make it one that should be integrated directly into a broader context like Debian. If their strong notion of how things Should Be Done is so thoroughly incompatible with mine, then I'm going to avoid installing their software if I have an alternative. Similarly, if their strong notions are incompatible with how Debian packaging works, I see no reason not to oblige their desire for removal. I wouldn't object to a hostile fork, but it seems more trouble than it's worth, and in particular I wouldn't trust upstream not to try to sabotage this somehow. I'd rather just use a different screen locker/blanker. I currently install i3lock, which is a bit feature-weak but works for now. What _does_ potentially concern me is whether alternative lock programs nowadays handle the X side of things with enough finesse to avoid problems such as the ones JWZ described with gnome-screensaver a while ago (which seemed to have a legitimate factual basis). I haven't audited any of this more deeply; can anyone comment on the current situation along those lines? It would be good to have a solid community recommendation for anyone who wants to transition away from xscreensaver in terms of not introducing security issues in particular. ---> Drake Wilson
Bug#770211: LUKS partition types, redux
Firstly: thank you very much for engaging in a reasonable discussion about this. Karel Zak wrote: On Wed, Nov 19, 2014 at 02:59:01PM -0600, Drake Wilson wrote: Summary: I would like to reopen the suggestion to add LUKS partition type codes for MBR and for GPT to util-linux's fdisk. In a previous discussion, it was said that since Linux does not interpret partition types, there is no need for this, but concrete data loss has now occurred as a result of a related bug in other software combined with the lack of a user-visible LUKS type in a similar partitioning program, and I believe that warrants re-examination of the situation. But it seems that the problem is what details partitioning tools provide to end-users rather than problem with data within disk labels. I don't see problem to add FS type column to fdisk(s) (it's already linked with libblkid). I don't quite understand the relation of this paragraph to what I was talking about. The case of data loss via partman-lvm wasn't related to what fdisk would have presented to me, but what the disklabel presented to partman-lvm as a result of the choices fdisk would have presented. You want to make a connection between partition type and partition format (FS, LUKS, LVM...). This idea is more than 30years old and it has been always fragile and introduced for poorly designed systems (kernels and boot loaders). It's not quite that I _want_ to make such a connection, more that I think it has already been made and the current interop situation is suboptimal; see below. I would be quite happy as well with a single Linux other type instead of a LUKS-specific type. The current trend is to use partition type to define for what purpose we want to use the partition (for example this is /home) independently on partition format. I can see some of that, yes. I've only recently encountered this. This can somewhat conflict with the purpose of disk encryption, incidentally, which tends to want to keep those subdivisions hidden if possible (thus LUKS+LVM being a common setup). I'm not opposed to the idea being around; _requiring_ it would conflict with my goals, but I don't see any evidence of that, so let's put that away. Anyway, I'd like to minimize number of situations when we depend on GPT/MBR partition types at all. So, my more concrete concern here is not in places where Linux or util-linux read partition type codes; it is where fdisk or a similar utility writes them, and some other program entirely reads them. In the bad case I ran into, the some other system happened to be partman-lvm from Debian, but it could just as well be something else. Here's the specific scenario: imagine I'm a Linux sysadmin who is writing a disklabel for a new disk which will contain a LUKS volume. (The volume does not necessarily correspond to any of the usage types you mentioned, and I may not want to expose that information anyway.) The type code field in MBR or GPT exists already; I cannot simply remove it, and there is no null value. What value do I type in for that field? The likely chain of events, if I'm using fdisk or a similar tool, is that I look up the list of type codes included in that tool and pick the closest one. If there is no LUKS type, and no Linux other or other type in general, I'm likely to wind up picking one of the existing Linux types. This risks the disk being plugged into a system that misinterprets the type, because those other types are _notionally_ meaningful even if the core Linux kernel and utilities don't care much. Adding a LUKS type to the table means I can pick that, and if Linux, cryptsetup, etc. never read it, that's fine---the point is that no _other_ system will read it as something it wasn't meant to be either. A Linux other or generic / unspecified type would also satisfy this, but more weakly because it wouldn't be as visible (and I would actually love to have all three, honestly). So it's a combined interop and UI problem, and is related to the disklabel data itself. And my main goal in participating here is to help avoid other users running into similar problems to what I did if they write disklabels using fdisk, by reducing the risk of accidentally encouraging the user to trigger aggressive interpretation by other software, even if that other software should not have made such assumptions in the first place. Does that help at all? --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770684: lxc-start creates /dev with wrong permissions if invoked with restrictive umask
Package: lxc Version: 1:1.0.6-3 Severity: minor Recently I started a container via « sudo lxc-start … » without configuring sudo to reset the umask first. I subsequently found SSHing into the container was slightly broken and user sessions were hanging in weird ways. This turned out to be because /dev had been created with mode 0750 instead of the proper 0755; the problem went away when I explicitly reset the umask from 0027 to 0022. It would be nice if LXC programs that deal with files in the container either reset the umask themselves or explicitly chmodded created files to avoid causing problems when so invoked. --- Drake Wilson -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lxc depends on: ii init-system-helpers 1.21 ii libapparmor1 2.9.0-2 ii libc62.19-13 ii libcap2 1:2.24-6 ii libseccomp2 2.1.1-1 ii libselinux1 2.3-2 ii multiarch-support2.19-13 ii python3 3.4.2-1 Versions of packages lxc recommends: ii debootstrap 1.0.64 ii openssl 1.0.1j-1 ii rsync3.1.1-2+b1 Versions of packages lxc suggests: pn lua5.2 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#770667: lxsession: logout dialog banner is confusing
Package: lxsession Version: 0.5.1-1 Severity: wishlist Attempting to log out of an LXDE session yields a dialog with the banner Logout LXDE testing session?. It seems that that's meant to mean LXDE desktop on a 'testing' OS since I'm tracking jessie at the moment, but that's not how it reads at a glance. Maybe fiddling the order and using lsb_release -i to get something like Debian LXDE session would be less confusing? --- Drake Wilson -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lxsession depends on: ii consolekit 0.4.6-5 ii libatk1.0-02.14.0-1 ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libdbus-1-31.8.10-1 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.0-2 ii libgtk2.0-02.24.25-1 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-01.36.8-2 ii libpangoft2-1.0-0 1.36.8-2 ii libpolkit-agent-1-00.105-7 ii libpolkit-gobject-1-0 0.105-7 ii libx11-6 2:1.6.2-3 ii lsb-release4.1+Debian13+nmu1 ii systemd215-5+b1 ii upower 0.99.1-3 Versions of packages lxsession recommends: ii lxde-common 0.99.0-1 ii openbox [x-window-manager] 3.5.2-8 ii openssh-client [ssh-client] 1:6.7p1-3 Versions of packages lxsession suggests: ii gpicview 0.2.4-2+b2 ii lxpanel 0.7.2-1 ii pcmanfm 1.2.3-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770211: /sbin/fdisk: add LUKS partition type code to fdisk
Package: util-linux Version: 2.25.2-2 Severity: wishlist File: /sbin/fdisk Greetings! According to [1], LUKS partitions on MBR disklabels can be assigned the type code e8. If this is correct, it would be nice if this could be added to fdisk's named type list, probably as Linux encrypted or similar. I've submitted a similar request for gdisk at #769631. --- Drake Wilson [1] http://www.win.tue.nl/~aeb/partitions/partition_types-1.html -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages util-linux depends on: ii init-system-helpers 1.21 ii initscripts 2.88dsf-57 ii libblkid12.25.2-2 ii libc62.19-13 ii libmount12.25.2-2 ii libncurses5 5.9+20140913-1 ii libpam0g 1.1.8-3.1 ii libselinux1 2.3-2 ii libslang22.3.0-2 ii libsmartcols12.25.2-2 ii libtinfo55.9+20140913-1 ii libuuid1 2.25.2-2 ii lsb-base 4.1+Debian13+nmu1 ii tzdata 2014i-1 ii zlib1g 1:1.2.8.dfsg-2 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 3.0.26-4 ii kbd 1.15.5-2 ii util-linux-locales 2.25.2-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770211: LUKS partition types, redux
Good day, folks of util-linux; Summary: I would like to reopen the suggestion to add LUKS partition type codes for MBR and for GPT to util-linux's fdisk. In a previous discussion, it was said that since Linux does not interpret partition types, there is no need for this, but concrete data loss has now occurred as a result of a related bug in other software combined with the lack of a user-visible LUKS type in a similar partitioning program, and I believe that warrants re-examination of the situation. Details: I recently submitted Debian wishlist bug #770211 [1] suggesting to add e8 as the MBR type code for LUKS to fdisk, per [2], mainly for consistency with my wishlist item for gdisk at [3]. I was asked to ask about it here. (I see now that fdisk also handles GPT disklabels, which I wasn't previously aware of.) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770211 [2] http://www.win.tue.nl/~aeb/partitions/partition_types-1.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769631 I see now that there was a thread in January starting at [4] (message-ID 1390934933.15213.17.ca...@heisenberg.scientia.net) about this, and the overall result seemed to be that since Linux ignores partition type codes, there is no reason to provide one for LUKS volumes. The counterargument (which I agree with) was roughly that since the type code slots exist in the first place, it would be better to help the user semantically align them with the partition contents, to prevent future issues from other type codes being used instead and then misinterpreted by other systems. [4] http://marc.info/?l=util-linux-ngm=139093540719399w=2 I would like to point out additional concrete evidence for the counterargument now, in terms of harm minimization. I previously tagged LUKS volumes on GPT with a type code corresponding to the underlying volume type, as the closest thing I could find (and a straw poll of some other Linux sysadmins I know says some of them do the same). I recently submitted Debian bug #768897 [5] in which partman-lvm, a component of the Debian installer, overaggressively interprets the LVM type as a normative request to make the partition contain an LVM PV, thus destroying all of my existing LVM-on-LUKS volumes. While I firmly believe that this is a bug in partman-lvm and not in util-linux, had I used util-linux's fdisk to make the partition tables, the presentation of a LUKS type code there would have prevented significant data loss in this case. (In my case, I used gdisk, but I'm taking it up with them separately.) [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768897 I would thus like to re-propose adding a LUKS type. Alternatively, if a LUKS type is still considered a bad idea, I would like to suggest allocating a GPT ID analogous to the da = Non-FS data MBR type code, which would at least allow the user to choose a fallback that has a known null semantic, rather than tagging their volumes with some arbitrary ID that may be misinterpreted; that would help avert analogous problems for future types as well. (I also believe more philosophically that the user should be supported in the possibility of integrating with other partition management systems that may wish to detect LUKS and do something special with it, without requiring all other such systems to incorporate a blkid-like system for checking in several places for the basic nature of a volume. I mention this only for the record, since the previous thread suggests the util-linux maintainers don't agree with this.) Thanks for any (polite) replies. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768897: MBR disklabels also yield destructive pvcreate
FYI: I've just confirmed with partman-lvm 99 (plus whatever libparted is in the last Debian testing weekly ISO) that MBR disklabels using 8e (Linux LVM) as a type code for LUKS are also affected by this. So it's not just GPT. It's arguably even more dangerous for MBR, because the type code space is so small that collisions should be expected, but util-linux's fdisk in MBR mode also provides a 0xda code for non-FS data, so users in that case may be less tempted to default to the underlying volume type. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769631: gdisk: add LUKS partition type code
Package: gdisk Version: 0.8.10-1 Severity: wishlist Greetings! gdisk has short pseudo-codes available in its type list for Linux filesystem, Linux RAID, etc. [1] claims to define a type code for LUKS partitions, and I wasn't able to find any conflicting definitions on the Web. I would thus appreciate it if it could be added to the gdisk type list (after the maintainer verifies the lack of apparent conflict): Short: 83ec (or whatever the gdisk maintainer finds appropriate) Long: ca7d7ccb-63ed-4c53-861c-1742536059cc Name: Linux encrypted (or: Linux LUKS) [1] http://www.saout.de/pipermail/dm-crypt/2014-January/003855.html (This is very marginally related to #768897, in that the lack of an obvious LUKS type in gdisk resulted in my deciding on the ambiguous partition typing that triggered that, just for the record.) --- Drake Wilson -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gdisk depends on: ii libc6 2.19-13 ii libgcc1 1:4.9.1-19 ii libncursesw5 5.9+20140913-1 ii libpopt0 1.16-10 ii libstdc++64.9.1-19 ii libtinfo5 5.9+20140913-1 ii libuuid1 2.25.2-2 Versions of packages gdisk recommends: ii groff-base 1.22.2-8 gdisk 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#769631: LUKS partition short code revisions
Further inspection of [1] suggests that if the gdisk short codes are loosely based on MBR type codes, e800 or 83e8 (reflecting the e8 code on that page) might be better for LUKS partitions. (I'd prefer the latter aesthetically, to group more of the Linux types together, but the former would be more consistent with the presence of fd00. It's a bit unfortunate that e8 and 8e would be so easy to mistype as each other, too, though...) [1] http://www.win.tue.nl/~aeb/partitions/partition_types-1.html --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768897: debian-installer: manual partitioning with LVM destroys all non-target LVM+LUKS+GPT volumes
configuration was somewhat more complicated than this test case, which also made it harder to see the non-target disks as most of them were off the screen. I also used EFI boot into an LXDE-variant expert install then; I don't think that matters here. Outcome: all attached LVM+LUKS+GPT volumes were destroyed. :-( :-( :-( Expected outcome: Manual partitioning mode should only ever overwrite data on volumes specifically designated by the user. Additionally, I would normally expect that: - Partitions with _existing_ LVM type codes but no recognizable PV header should not be presumed to be uninitialized PVs without asking the user. (What if a future LVM release creates a new, incompatible PV type, even, and the user wants to incorporate the existing volume?) + ... and _certainly_ not if they have a header recognizable by blkid, which might apply more generally too. - The warning screen used for writing new partition tables and filesystems should also appear before physically initializing LVM PVs, LUKS, etc., as that would be the clearest for the user to know which data might I be about to vaporize and have the option to back out. I rechecked the Installation Guide and Release Notes and I didn't see anything about this specifically, but I'd sure appreciate a pointer if I just missed it somehow. Unrelatedly, I was actually planning on unplugging all the non-target disks first as a precautionary measure, but then I forgot to and didn't think anything further of it until the cold chill of cryptsetup failing when I tried to read anything from them. Now I am sad and have filesystems to reconstruct. I had backups of the more important unreplaceable stuff, but some of the configuration will be a major pain. :-( (One might say the real lesson is never install with insufficient sleep and insufficient tea, but anyway.) I'll upload the test disk images shortly. --- Drake Wilson Additional data: * STARTING-TABLES host% /sbin/gdisk -l disk1 [...] Found valid GPT with protective MBR; using GPT. Disk disk1: 8388608 sectors, 4.0 GiB Logical sector size: 512 bytes Disk identifier (GUID): 958553DA-8C9D-45F8-81D0-F061581778D1 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 8388574 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector)End (sector) Size Code Name 12048 526335 256.0 MiB EF00 EFI System 2 526336 2099199 768.0 MiB 8300 Linux filesystem 3 2099200 8388574 3.0 GiB 8E00 Linux LVM host% /sbin/gdisk -l disk2 [...] Found valid GPT with protective MBR; using GPT. Disk disk2: 8388608 sectors, 4.0 GiB Logical sector size: 512 bytes Disk identifier (GUID): 4B88191F-49C6-4DA5-B126-5C09CA409E8B Partition table holds up to 128 entries First usable sector is 34, last usable sector is 8388574 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector)End (sector) Size Code Name 32048 8388574 4.0 GiB 8E00 Linux LVM -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768897: Test disk images uploaded
disk1_pristine, disk2_pristine, and the key file for the test LUKS volume on p3 of disk2 are now available at: http://dasyatidae.net/tmp/d-i-test-20141109.tar.xz (49 MiB) SHA-256: f35d2a8573998f6a82949cf8bb302b1e34c7fdc3f184545f8d682a6e19bb1059 Use tar -S or equivalent to unpack! The disk images are raw, 4 GiB sparse files. And please make a local copy of this file if you wish to keep it. The LUKS volume should contain an LVM PV in a single-PV VG, with one LV with an ext4 filesystem with one test file in it, though most of that is not directly relevant to the report. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768897: Rough data flow trace
It seems that (debugging with the assumption that latest git and the on-DVD version are Sufficiently Similar): 1. Flags for partitions are retrieved via libparted, which sets the lvm flag on any partitions that have that GPT type. 2. partman-lvm/init.d/lvm sets the lvm method on all partitions with the lvm flag, resulting in (3) from the test sequence. 3. partman-lvm/lib/lvm-base.sh:pv_list assumes all devices with the method lvm are PVs. 4. partman-lvm/choose_partition/lvm/do_option:do_initial_setup iterates over pv_list and does pv_create on everything in it immediately. 5. partman-lvm/lib/lvm-base.sh:pv_create tests for the presence of an active PV using the exit code of the pvs command, and anything that doesn't indicate one results in pvcreate -ff, resulting in (8) from the test sequence. Running pvcreate without -f interactively will detect the LUKS signature and offer an abort, as it happens. On the immediate front, it _may_ be that testing whether it's safe to create a new PV there would be better done via something like pvcreate --test --quiet -- $pv /dev/null /dev/null 21 (which e.g. exits 5 on finding a LUKS signature) rather than checking using ! pvs. Or, better yet, along the lines of crypttab(5)'s precheck=un_blkid. By itself, that would probably make the install fail without further reworking though. A better question would probably be why that flag-method propagation is done in manual partitioning mode in the first place; I assume that's used for something, but I don't know what, having not delved into this code before. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687887: Possibly due to flat-volumes
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674935 et al. describe what happens due to flat-volumes = yes being the default. I've just experienced a similar problem with VLC in which I set the volume to 120% for a specific media file. This raised the sink volume permanently to 120%, thus causing other audio to clip until I manually undid this with pacmd. Fortunately I rely on the ALSA hardware volume for most of my output limiting. Thus I _suspect_ that this can be merged with #674935. If the original submitter is still listening: what happens if you add flat-volumes = no to /etc/pulse/daemon.conf? --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726774: Does this also leave a nologin file around?
After a failed aptitude full-upgrade due to this problem, I found that logging in by SSH failed due to the presence of /run/nologin. I've manually removed it again. Have others experienced this? I can't quite tell whether it's related, since so many packages were being manipulated at once. Either way, I'm not sure this is console-tools's fault; invoke-rc.d seems to bomb on any init.d scripts with .sh in the name, including the mentioned console-screen.sh. I have: ii systemd 204-5 amd64 system and service manager ii sysv-rc 2.88dsf-43 all System-V-like runlevel change mechanism iF console-tools 2:0.2.3-72 amd64 Linux console and font utilities A cursory glance didn't turn up anything about this reported against sysv-rc or systemd, but I haven't time to be more thorough just now. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724839: fonts-liberation: U+266B incorrect glyph with extra beam
Package: fonts-liberation Version: 2.00.1-1 Severity: normal Using gucharmap 1:3.8.2-2 to view Liberation Serif characters with Show only glyphs from this font enabled, the glyph for U+266B BEAMED EIGHTH NOTES shows what is clearly beamed sixteenth notes instead; it should have only one beam rather than two. FontForge confirms this after opening LiberationSerif-Regular.ttf with SHA-256 = ea76595ed32ec4bb117fc715e393b4cca3d42cabe53101baec6bbbeb800fa26a. The glyph for U+266C BEAMED SIXTEENTH NOTES is correct. --- Drake Wilson -- Package-specific info: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersionArchitecture Description +++-===-==-==-=== ii fontconfig 2.10.2-2 amd64 generic font configuration library - support binaries ii libfreetype6:amd64 2.4.9-1.1 amd64 FreeType 2 font engine, shared library files ii libfreetype6:i386 2.4.9-1.1 i386 FreeType 2 font engine, shared library files ii libxft2:amd64 2.3.1-1amd64 FreeType-based font drawing library for X -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash fonts-liberation depends on no packages. Versions of packages fonts-liberation recommends: pn fonts-liberation-sans-narrow none fonts-liberation 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#707127: ocaml-base: Big_int.extract_big_int does not handle negative numbers properly
Package: ocaml-base Version: 3.12.1-4 Severity: normal This function seems to assume that unrepresented prefix regions of bits in a Big_int.big_int are always zero, but this is not so for negative numbers. The documentation explicitly states that a two's complement representation is used for those, but see the transcript with comments inline: % ocaml nums.cma Objective Caml version 3.12.1 # open Big_int;; # let mu = minus_big_int unit_big_int;; val mu : Big_int.big_int = abstr # let s offset count = string_of_big_int (extract_big_int mu offset count);; val s : int - int - string = fun # s 0 16;; - : string = 65535 # s 16 16;; - : string = 65535 # s 32 16;; - : string = 65535 # s 48 16;; - : string = 65535 (* Okay so far... *) # s 64 16;; - : string = 0 (* Oops! *) # s 56 16;; - : string = 255 (* Function seems to think this is a 2^64-1. *) # eq_big_int (big_int_of_int 255) (extract_big_int mu 56 16);; - : bool = true (* It's not just a problem with the stringifier. *) # eq_big_int (big_int_of_int (-1)) mu;; - : bool = true (* Nor is it a problem with the earlier negation. *) --- Drake Wilson -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ocaml-base depends on: ii libc6 2.13-38 ii libx11-62:1.5.0-1 ii ocaml-base-nox [ocaml-base-nox-3.12.1] 3.12.1-4 ii tcl8.5 8.5.11-2 ii tk8.5 8.5.11-2 ocaml-base recommends no packages. ocaml-base 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#705634: lua-mode: use of last-command-char bombs with emacs24 24.3+1-1
Package: lua-mode Version: 20110121-1 Severity: important Typing any closing bracket character in a lua-mode buffer results in the error Symbol's value as variable is void: last-command-char instead of inserting the character. The culprit appears to be in lua-electric-match: (defun lua-electric-match (arg) Insert character and adjust indentation. (interactive P) (insert-char last-command-char (prefix-numeric-value arg)) (if lua-electric-flag (lua-indent-line)) (blink-matching-open)) I imagine that variable has disappeared from bleeding-edge GNU Emacs. I'm not sure when, but the equivalent seems to be last-command-event. As a workaround, I've added: (defadvice lua-electric-match (around last-command-char-fixup activate) (let ((last-command-char last-command-event)) ad-do-it)) to my .emacs file, which works for me, but I don't have enough bandwidth to reliably figure out what the Most Compatible Solution is for upstream, unfortunately. :-\ --- Drake Wilson -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lua-mode depends on: ii emacs24 [emacsen] 24.3+1-1 lua-mode recommends no packages. lua-mode 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#680574: ruby1.9.1: system gem installation should reset umask or explicitly set file security attributes as needed
Package: ruby1.9.1 Version: 1.9.3.194-1 Severity: important Running « gem1.9.1 install ... » with umask 0077 as root installs files into /var/lib/gems that are only readable by root, breaking many Ruby applications for all other users (this causes require to abort upon encountering the unreadable directories, even if the modules requested are not in them). Expected behavior: the files are readable by all users, or (if having some kind of restricted gems is considered an actual feature, which at the moment I doubt) the gems are at least ignored by users who cannot read them rather than breaking require. Arguably using such a restrictive default umask when running commands as root is unusual, but trees managed by a package manager and/or by convention should probably have their permissions so managed as well; examples include the behavior of dpkg and common Makefiles that use the -m option to /usr/bin/install. I reported an equivalent bug in rubygems1.8 as #585838; I am reporting the severity of this one as important rather than normal due to the large extent of potential breakage due to closer integration of RubyGems in MRI 1.9. --- Drake Wilson -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ruby1.9.1 depends on: ii libc6 2.13-34 ii libruby1.9.1 1.9.3.194-1 ruby1.9.1 recommends no packages. Versions of packages ruby1.9.1 suggests: ii graphviz2.26.3-11 ii ri1.9.1 1.9.3.194-1 pn ruby-switch none pn ruby1.9.1-dev none pn ruby1.9.1-examples 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#673968: gplanarity: does not start, complaining somewhere fontconfig-related
Package: gplanarity Version: 17906-2 Severity: grave Justification: renders package unusable Severity justification is based on my own system only; it may be that this does not occur on most systems, but I haven't the resources to check. Here's what happens: $ gplanarity gplanarity: fcmatch.c:548: IA__FcFontMatch: Assertion `result != ((void *)0)' failed. Aborted Expected behavior: the game starts normally. --- Drake Wilson -- 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/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gplanarity depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-32 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-5 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libgtk2.0-0 2.24.10-1 ii libpango1.0-0 1.30.0-1 gplanarity recommends no packages. gplanarity 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#666757: python-gtk2: warns about mismatched gtype registration at startup
Package: python-gtk2 Version: 2.24.0-3 Severity: minor When starting any Python GTK+ program, the following warnings appear from somewhere in the GNOME stack (demonstrated with a direct import from the Python REPL): Python 2.7.3rc2 (default, Mar 21 2012, 06:59:11) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. import gtk ** (process:18976): WARNING **: Trying to register gtype 'GMountMountFlags' as flags when in fact it is of type 'GEnum' ** (process:18976): WARNING **: Trying to register gtype 'GDriveStartFlags' as flags when in fact it is of type 'GEnum' ** (process:18976): WARNING **: Trying to register gtype 'GSocketMsgFlags' as flags when in fact it is of type 'GEnum' This doesn't happen when importing gobject or glib by itself, so I assume this is related to python-gtk2. I haven't detected this affecting any application behavior yet, possibly because I haven't run any Python GTK+ applications that make use of the types involved. Expected behavior: no such warnings appear. --- Drake Wilson -- 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/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-gtk2 depends on: ii libatk1.0-0 2.2.0-2 ii libc6 2.13-27 ii libcairo2 1.10.2-7 ii libfontconfig12.8.0-3.1 ii libfreetype6 2.4.8-1 ii libgdk-pixbuf2.0-02.24.1-1 ii libglib2.0-0 2.30.2-6 ii libgtk2.0-0 2.24.10-1 ii libpango1.0-0 1.29.4-3 ii python2.7.2-10 ii python-cairo 1.8.8-1+b2 ii python-gobject-2 2.28.6-10 ii python-numpy [python-numpy-abi9] 1:1.5.1-4 ii python2.6 2.6.7-4 ii python2.7 2.7.3~rc2-1 python-gtk2 recommends no packages. Versions of packages python-gtk2 suggests: ii python-gtk2-doc 2.24.0-3 -- 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#503044: Should update README.Debian re loop devices as well
As a quick extra note, /usr/share/doc/xen-utils-4.1/README.Debian from xen-utils-4.1 version 4.1.2-2 still reads: | 1. Maximum number of loop devices |By default the loop driver supports a maximum of 8 loop devices. Of |course since every Xen domain uses at least two (one for the data and one |for the swap) this number is absolutely insufficient. You should increase |it by adding a file named local-loop in /etc/modprobe.d containing the |string options loop max_loop=128, if the loop driver is compiled as a |module, or by appending the string max_loop=128 to your kernel parameters |if the driver is in-kernel. Of course you can increase or decrease the |number 128 as you see fit. This is now multiply wrong: firstly, module-init-tools 3.16-1 (I haven't tried other versions) says that new files placed in /etc/modprobe.d should have a .conf suffix, and secondly, assuming Anders Kaseorg's message upthread about max_loop disabling dynamic allocation is correct, this configuration is no longer directly desirable. So whoever comes back to look at the loop device behavior should please make sure to update the README.Debian file also. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632746: ttf-freefont: Strange glyphs for some chars in Control Pictures block
Subject: ttf-freefont: Strange glyphs for some chars in Control Pictures block Package: ttf-freefont Version: 20100919-1 Severity: normal In the FreeMono, FreeSans, and FreeSerif fonts, the glyphs for the following characters are strange: U+2404 SYMBOL FOR END OF TRANSMISSION: shows as ENQ, should be EOT U+2405 SYMBOL FOR ENQUIRY: shows as EOT, should be ENQ (The above two seem to be transposed.) U+240E SYMBOL FOR SHIFT OUT: shows as SS, should arguably be SO (This one isn't as clear, but I'm going by the abbrevs from ascii(7).) --- Drake Wilson -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#625798: qtractor: Track names with slashes cause MIDI recording to silently fail
Package: qtractor Version: 0.4.8-2 Severity: normal (This arguably causes data loss.) To reproduce: 1. Start up Qtractor. Connect a MIDI source to its Master bus using the ALSA sequencer. 2. Create a new MIDI track named Foo / Bar, assigned to channel 1. 3. Arm the track for recording, then enable the master record arm with the red record button. Create a new session of any unused name when/if so prompted. 4. Start the transport using the play button. Play MIDI notes on channel 1. They will appear in the timeline as they are purportedly recorded. 5. Stop the transport using the play button again. The MIDI clip that has just been recorded now contains no visible events. 6. Double-click on the clip to open it in the clip editor to confirm that there are no events. (It additionally has no apparent name and shows up with the name of the session's containing directory, which are less serious anomalies.) Observe that a track named Foo ; Bar (with a semicolon instead of a slash) does not experience the same behavior. My wild guess is that since the track name is used as part of the name of the backing store MIDI file, the slash isn't getting denatured from its role as a directory separator, so creating the backing file fails due to a bogus nonexistent path component, destroying the recorded data. (At least, I haven't found any obvious way of getting it back. Fortunately I was able to record it again after figuring out what was going on.) --- Drake Wilson -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qtractor depends on: ii jackd5 JACK Audio Connection Kit (default ii libasound2 1.0.23-3shared library for ALSA applicatio ii libc62.13-2 Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-6 GCC support library ii libjack0 [libjack-0. 1:0.120.1+svn4142-1 JACK Audio Connection Kit (librari ii liblo7 0.26~repack-7 Lightweight OSC library ii libmad0 0.15.1b-6 MPEG audio decoder library ii libogg0 1.2.0~dfsg-1Ogg bitstream library ii libqt4-xml 4:4.7.2-4 Qt 4 XML module ii libqtcore4 4:4.7.2-4 Qt 4 core module ii libqtgui44:4.7.2-4 Qt 4 GUI module ii librdf0 1.0.13-2Redland Resource Description Frame ii librubberband2 1.3-1.1+b1 an audio time-stretching and pitch ii libsamplerate0 0.1.7-3 Audio sample rate conversion libra ii libslv2-90.6.6-9 A library for simple use of LV2 pl ii libsndfile1 1.0.24-1Library for reading/writing audio ii libstdc++6 4.6.0-6 The GNU Standard C++ Library v3 ii libvorbis0a 1.3.2-1 The Vorbis General Audio Compressi ii libvorbisenc21.3.2-1 The Vorbis General Audio Compressi ii libvorbisfile3 1.3.2-1 The Vorbis General Audio Compressi ii libx11-6 2:1.4.3-1 X11 client-side library ii zlib1g 1:1.2.3.4.dfsg-3compression library - runtime qtractor recommends no packages. qtractor 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#622732: vlc: spatial offset for (subpicture?) subtitles would be nice
Package: vlc Version: 1.1.7-4 Severity: wishlist While watching DVD-based video with VLC, with subtitle tracks enabled and the main video frame scaled down to less than the available screen (due to differing aspect ratio), the subpicture-based (I'm assuming) subtitles still obscure parts of the main video. It would be nice to be able to offset these into the surrounding letterboxing area, of course taking the risk of unwanted distortions should any of the content rely on spatial alignment with the main video. --- Drake Wilson -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vlc depends on: ii libaa1 1.4p5-38 ascii art library ii libavcodec524:0.6.1-5FFmpeg codec library ii libavutil50 4:0.6.1-5FFmpeg utility library ii libc6 2.11.2-13Embedded GNU C Library: Shared lib ii libfreetype62.4.4-1 FreeType 2 font engine, shared lib ii libfribidi0 0.19.2-1 Free Implementation of the Unicode ii libgcc1 1:4.5.2-6GCC support library ii libgl1-mesa-glx [libgl1 7.10-4 A free implementation of the OpenG ii libqtcore4 4:4.7.2-2Qt 4 core module ii libqtgui4 4:4.7.2-2Qt 4 GUI module ii libsdl-image1.2 1.2.10-2+b2 image loading library for Simple D ii libsdl1.2debian 1.2.14-6.1 Simple DirectMedia Layer ii libstdc++6 4.5.2-6 The GNU Standard C++ Library v3 ii libtar 1.2.11-6 C library for manipulating tar arc ii libva-x11-1 1.0.8-3 Video Acceleration (VA) API for Li ii libva1 1.0.8-3 Video Acceleration (VA) API for Li ii libvlccore4 1.1.7-4 base library for VLC and its modul ii libx11-62:1.4.1-5X11 client-side library ii libx11-xcb1 2:1.4.1-5Xlib/XCB interface library ii libxcb-keysyms1 0.3.6-1 utility libraries for X C Binding ii libxcb-randr0 1.7-2X C Binding, randr extension ii libxcb-shm0 1.7-2X C Binding, shm extension ii libxcb-xv0 1.7-2X C Binding, xv extension ii libxcb1 1.7-2X C Binding ii libxext62:1.2.0-2X11 miscellaneous extension librar ii libxpm4 1:3.5.9-1X11 pixmap library ii ttf-freefont20100919-1 Freefont Serif, Sans and Mono True ii vlc-nox 1.1.7-4 multimedia player and streamer (wi ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages vlc recommends: pn vlc-plugin-notifynone (no description available) ii vlc-plugin-pulse 1.1.7-4 PulseAudio plugin for VLC ii xdg-utils1.1.0~rc1-2 desktop integration utilities from Versions of packages vlc suggests: ii mozilla-plugin-vlc1.1.7-4multimedia plugin for web browsers ii videolan-doc 20070626-1 documentation for the VideoLAN str Versions of packages vlc-nox depends on: ii liba52-0.7.40.7.4-15 library for decoding ATSC A/52 str ii libasound2 1.0.23-2.1 shared library for ALSA applicatio ii libass4 0.9.9-1 library for SSA/ASS subtitles rend ii libavahi-client30.6.29-1 Avahi client library ii libavahi-common30.6.29-1 Avahi common library ii libavc1394-00.5.3-1+b2 control IEEE 1394 audio/video devi ii libavcodec524:0.6.1-5FFmpeg codec library ii libavformat52 4:0.6.1-5FFmpeg file format library ii libavutil50 4:0.6.1-5FFmpeg utility library ii libc6 2.11.2-13Embedded GNU C Library: Shared lib ii libcaca00.99.beta17-1colour ASCII art library ii libcddb21.3.2-2 library to access CDDB data - runt ii libcdio10 0.81-4 library to read and control CD-ROM ii libdbus-1-3 1.4.6-1 simple interprocess messaging syst ii libdc1394-222.1.3-1 high level programming interface f ii libdca0 0.0.5-3 decoding library for DTS Coherent ii libdirac-encoder0 1.0.2-3 open and royalty free high quality ii libdvbpsi6 0.1.7-1 library for MPEG TS and DVB PSI ta ii libdvdnav4 4.1.3-7 DVD navigation library ii libdvdread4 4.1.3-10
Bug#606537: youtube-dl: new upstream version
Package: youtube-dl Version: 2010.11.19-1 Severity: important (Setting to important due to the volatility of this package's code, even though this is theoretically grave due to the old version no longer functioning.) Upstream at git://github.com/rg3/youtube-dl contains a new commit that is necessary for continued function: commit d157d2597a5fe99db60304fe1e89523de78b7981 Author: Ricardo Garcia sarbalap+freshm...@gmail.com Date: Thu Dec 9 19:22:32 2010 +0100 Fix YoutubeIE after recent YouTube changes (closes #34) --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages youtube-dl depends on: ii python 2.6.6-3+squeeze1 interactive high-level object-orie youtube-dl recommends no packages. Versions of packages youtube-dl suggests: pn rtmpdump none (no description available) -- 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#605408: [general] volatile.debian.org: one of its IP addresses fails.
Quoth Roger Leigh rle...@codelibre.net, on 2010-11-29 18:43:30 +: On Mon, Nov 29, 2010 at 06:34:55PM +0100, Manolo Díaz wrote: volatile.debian.org works fine to me except when resolved to 2001:610:1908:a000::149:227. In this case always fails to update or upgrade, my system remains waiting until the timeout. It's all working fine here (native IPv6, no tunnel, not that it should make a difference). In addition to traceroute6 and ping6, I can also browse the archive just fine. Works for me too (reformatted slightly), with HE tunnel broker: traceroute to 2001:610:1908:a000::149:227 (2001:610:1908:a000::149:227) from 2001:470:d:967:f031:b8ff:fe05:f438, port 33434, from port 33843, 30 hops max, 60 byte packets 1 zwischenschaltung.begriffli.ch (2001:470:d:967::1) 2.614 ms 0.518 ms 0.499 ms 2 begrifflich-1.tunnel.tserv15.lax1.ipv6.he.net (2001:470:c:967::1) 39.507 ms 35.387 ms 28.261 ms 3 gige-g4-6.core1.lax1.he.net (2001:470:0:9d::1) 32.088 ms 28.525 ms 45.946 ms 4 10gigabitethernet4-3.core1.nyc4.he.net (2001:470:0:10e::2) 95.410 ms 116.310 ms 86.181 ms 5 10gigabitethernet1-2.core1.lon1.he.net (2001:470:0:3e::2) 178.838 ms 157.894 ms 165.986 ms 6 10gigabitethernet1-1.core1.ams1.he.net (2001:470:0:3f::2) 167.547 ms 163.807 ms 180.946 ms 7 XSR03.Asd001A.surf.net (2001:7f8:1::a500:1103:1) 164.053 ms 181.227 ms 211.377 ms 8 AE2.500.JNR01.Asd001A.surf.net (2001:610:e08:76::78) 181.644 ms 211.616 ms 176.798 ms 9 utwente-router.Customer.surf.net (2001:610:f00:4000::2) 213.965 ms 190.713 ms 205.283 ms 10 2001:610:1908:a000::149:227 (2001:610:1908:a000::149:227) 179.688 ms 186.076 ms 176.834 ms --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#436466: dash: Please optimise single command given to -c to exec it
Quoth Jonathan Nieder jrnie...@gmail.com, on 2010-11-26 01:10:47 -0600: Inserting, say, a debugging echo before the actual command is virtually guaranteed to not exec the final command directly. How do you like the ksh93 behavior? I wasn't previously aware of the ksh93 behavior. So they _do_ do that in cases where the entire script is not a single simple command. (My previous experience was always otherwise, including with Bash, pdksh, I think zsh though that appears to exhibit ksh93-esque behavior now so I may have misremembered, and one or two other shells.) ksh93 appears to also handle various other tail positions, including subshells and and ||. That's more the sort of thing I could get behind if I were made Dictator of Shells. :-) Obviously my information above was out of date. I amend it to say in many cases will not exec the final command directly. (This means that a program that wishes to be portable to multiple underlying shells can rely even less on the process tree shape, so my previous points mostly stand anyway.) Actually, let me take that back. If you actually want a guarantee that future versions of dash will have or lack this feature, Let me be a little clearer, at the risk of restating myself. I don't personally need a guarantee either way, especially since it's something I'll have to deal with regardless of what dash does in the future. I mostly wanted to ensure that people reading the bug trail were aware of some of the subtler ramifications of a decision to do tail execution optimization in shells, and in particular, I wanted to: - Add a dissenting voice to some ideas from upthread that making the last command a child of the shell is wrong and that relying on a highly compact process tree shape that was not actually requested is a sane thing to do in a POSIX or GNU/Linux environment, which IMHO it is not. - Point out that full tail execution optimization is not as localized as the anything without shell meta-stuff that some people think it is, and that partial tail execution optimization can lead to subtle problems if not done carefully. Cf. a vaguely similar case where I was attempting to use an XSI shell builtin (which I was willing to rely on on the target system) as a single command in a series of commands in a makefile, and GNU Make decided that it didn't look enough like a shell thing and could be optimized into an exec, which naturally hosed the command. Of course, the case of doing exec transformation _in_ the shell is not as bad as that. Thanks for the attention. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#436466: This would be an actual semantic change
I'm tempted to be snarky and say you think this is just an optimization, but it is not, but that's probably a bit too harsh. I would tend not to want this type of hidden semantic change to occur in dash if it can practically be avoided, because it would make dash less simple and clean in an unobvious way in exchange for a small gain in performance and a small gain in compatibility with Bash. exec foo ... and foo ... do not have exactly equivalent semantics even when each is the only command that will be executed by the shell before exiting, and Bash's behavior is something I would consider a somewhat kludgy extension behavior. It is entirely possible for a parent process that knows it is invoking a POSIX shell and needs the process tree to be shaped a certain way to specify the 'exec' itself---and for that matter it may as well just _do_ the exec itself in most cases. Depending on how it's implemented, this can also cause a sort of inconsistency fault line. Seemingly unrelated elements, such as changing one parameter into a backquote expansion or adding a redirect, can then introduce a new process even when the final execve() could theoretically be done the same way. Inserting, say, a debugging echo before the actual command is virtually guaranteed to not exec the final command directly. Essentially the question boils down to whether a provably final execution in a shell script should be treated as a tail execution in the absence of an explicit 'exec'. I would argue that for cleanliness either they should always be (which would be a lot of work and potentially more inconsistent with classic shell behavior and may make certain operations very difficult) or they should never be (which I believe is the current behavior). I believe Tim Connors's notion that not doing the exec transformation causes the PPid line in /proc/$pid/status to be WRONG is _thoroughly unjustified_ from a theoretical perspective, since system() does not specify that it will optimize away the shell process for a single command. This concern may however be valid as a matter of unfortunate backward compatibility for many forms of GNU/Linux. Nonetheless, POSIX:2001[1] seems to be ambiguous on the matter: it states that the shell shall execute the utility in a separate utility environment with actions equivalent to calling the execve() function defined in the System Interfaces volume of IEEE Std 1003.1-2001 [...] but the relation between utility environments and process environments seems to be unspecified, so the exec transformation may be acceptable to POSIX. (The dash man page doesn't seem to say which version of POSIX it's targeting.) [1] http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604628: audacity: would like non-sticky initial directory for import
Package: audacity Version: 1.3.12-6 Severity: wishlist When I start Audacity (with or without any audio files specifed on the command line) and then wish to import additional audio files, usually I want them from either the same directory as the files I specified on the command line, or from the current directory. Instead, using the Import Audio... function from the File menu brings up a file dialog centered on (apparently) the last directory from which I imported any audio in. This is often a completely unrelated directory; then I must (sometimes extensively) navigate to the correct directory to find the files I want. Further, the other directory sometimes has many entries or resides on a different medium, in which case there is a noticeable wait for the unrelated directory to be completely shown before I can start any navigation at all. This may be difficult to change due to users expectations and/or not wanting to add a profusion of interactive options, but I'd like to have it recorded that at least one person finds this behavior less than optimal. I would prefer that the import directory default to the directory of the most recently imported audio file in the _current_ project (ignoring any other simultaneous or previous sessions or projects), or to the current directory if there is no such file (e.g., the project is blank or only uses newly-recorded audio). --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages audacity depends on: ii audacity-data 1.3.12-6 A fast, cross-platform audio edito ii libasound2 1.0.23-2.1shared library for ALSA applicatio ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libflac++6 1.2.1-3 Free Lossless Audio Codec - C++ ru ii libflac8 1.2.1-3 Free Lossless Audio Codec - runtim ii libgcc11:4.4.5-8 GCC support library ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-02.20.1-2 The GTK+ graphical user interface ii libid3tag0 0.15.1b-10ID3 tag reading library from the M ii libjack0 [libjack-0.11 1:0.118+svn3796-7 JACK Audio Connection Kit (librari ii libmad00.15.1b-5 MPEG audio decoder library ii libogg01.2.0~dfsg-1 Ogg bitstream library ii libsamplerate0 0.1.7-3 Audio sample rate conversion libra ii libsndfile11.0.23-1 Library for reading/writing audio ii libsoundtouch1c2 1.3.1-2 sound stretching library ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libtwolame00.3.12-1 MPEG Audio Layer 2 encoding librar ii libvamp-hostsdk3 2.1-1 helper library for Vamp hosts writ ii libvorbis0a1.3.1-1 The Vorbis General Audio Compressi ii libvorbisenc2 1.3.1-1 The Vorbis General Audio Compressi ii libvorbisfile3 1.3.1-1 The Vorbis General Audio Compressi ii libwxbase2.8-0 2.8.10.1-3+b1 wxBase library (runtime) - non-GUI ii libwxgtk2.8-0 2.8.10.1-3+b1 wxWidgets Cross-platform C++ GUI t Versions of packages audacity recommends: ii libavcodec52 4:0.5.2-6 ffmpeg codec library ii libavformat52 4:0.5.2-6 ffmpeg file format library Versions of packages audacity suggests: ii amb-plugins [ladspa-plugin] 0.6.1-2ambisonics LADPSA plugins ii blepvco [ladspa-plugin] 0.1.0-2LADSPA, minBLEP-based, hard-sync-c ii blop [ladspa-plugin] 0.2.8-5Bandlimited wavetable-based oscill ii caps [ladspa-plugin] 0.4.2-1C* Audio Plugin Suite ii cmt [ladspa-plugin] 1.16-1 a collection of LADSPA plugins pn libmp3lame0 none (no description available) ii mcp-plugins [ladspa-plugin] 0.4.0-1LADSPA plugins designed for Alsa M ii omins [ladspa-plugin] 0.2.0-6a collection of LADSPA plugins aim ii rev-plugins [ladspa-plugin] 0.3.1-1greverb-like ladspa plugin ii swh-plugins [ladspa-plugin] 0.4.15+1-4 Steve Harris's LADSPA plugins ii tap-plugins [ladspa-plugin] 0.7.1-1Tom's Audio Processing LADSPA plug ii vco-plugins [ladspa-plugin] 0.3.0-1LADSPA plugin sporting anti-aliase -- 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#598001: youtube-dl: handling CAPTCHA requests
Quoth Rogério Brito rbr...@ime.usp.br, on 2010-10-25 02:42:42 -0200: The version that I am uploading in a few minutes has this feature implemented. Can you please test it? Appears to work with some tweaking, though finding documentation on the format of the cookie jar file is a little awkward. I have at least one report that it works for the CAPTCHA too. Excellent. In particular, I would expect that to be a superset of the complexity of the above, since due to youtube-dl not accepting multiple URLs, one would want to be able to store the cookie for later invocations. I beg your pardon? youtube-dl *does* accept multiple URLs. I use that all the time (and it can even download whole playlists from youtube). Ah, interesting. I must have missed that feature appearing; I worked around the lack of it earlier with a shell function, so probably I was just mistaken about that part (and can get rid of that function now). Sorry for the noise. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600292: libsdl1.2-dev: please provide debug symbols
Package: libsdl1.2-dev Version: 1.2.14-6.1 Severity: wishlist Subject says it all, mostly: please provide a debug symbol package for the SDL library. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libsdl1.2-dev depends on: ii libaa1-dev 1.4p5-38 ascii art library, development kit ii libartsc0-dev 1.5.9-3+b2development files for the aRts sou ii libasound2-dev 1.0.23-2 shared library for ALSA applicatio ii libaudio-dev 1.9.2-3 Network Audio System - development ii libcaca-dev0.99.beta17-1 development files for libcaca ii libdirectfb-dev1.2.10.0-4direct frame buffer graphics libra ii libesd0-dev0.2.41-7 Enlightened Sound Daemon - Develop ii libglu1-mesa-dev 7.8.2-2 The OpenGL utility library -- deve ii libpulse-dev 0.9.21-3+b1 PulseAudio client development head ii libsdl1.2debian1.2.14-6.1Simple DirectMedia Layer ii libsvga1-dev 1:1.4.3-30console SVGA display development l ii libx11-dev 2:1.3.3-3 X11 client-side library (developme ii libxext-dev2:1.1.2-1 X11 miscellaneous extensions libra ii libxt-dev 1:1.0.7-1 X11 toolkit intrinsics library (de libsdl1.2-dev recommends no packages. libsdl1.2-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600307: bzflag-data: data files should probably be in /usr/share/games
Package: bzflag-data Version: 2.0.16.20100405 Severity: minor The BZFlag client and server executables are both in /usr/games. Therefore, the FHS and other examples in Debian seem to suggest that the static data for them should be found in /usr/share/games, but instead it is at /usr/share/bzflag. This is slightly inconsistent and confusing. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#599938: electric-fence: does not handle posix_memalign
Package: electric-fence Version: 2.1.16 Severity: important According to POSIX, free() may be called on memory allocated by posix_memalign(), but Electric Fence doesn't catch the posix_memalign and therefore kills the program when the free happens. See attached ef_memalign_20101012.c; compile the program with and without -lefence to observe this in action. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages electric-fence depends on: ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib electric-fence recommends no packages. electric-fence 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#598072: elinks: disabling mouse usage
Package: elinks Version: 0.12~pre5-2 Severity: wishlist ELinks will acquire the terminal mouse when on a terminal which allows this. However, this impedes the use of the mouse for grabbing parts of the (completely text-based) interface as an X selection for copying into other programs. It would be nice if I could tell ELinks to ignore the mouse completely, either globally or on a finer-grained basis, but I see nothing in the Terminals or User Interface option groups or in the keybinding manager that provides this. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages elinks depends on: ii elinks-data 0.12~pre5-2advanced text-mode WWW browser - d ii libbz2-1.01.0.5-6high-quality block-sorting file co ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libcomerr21.41.12-2 common error description library ii libexpat1 2.0.1-7XML parsing C library - runtime li ii libfsplib00.11-1 FSP v2 protocol stack library - sh ii libgnutls26 2.8.6-1the GNU TLS library - runtime libr ii libgpm2 1.20.4-3.3 General Purpose Mouse - shared lib ii libgssapi-krb5-2 1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries - k ii libidn11 1.18-1 GNU Libidn library, implementation ii libk5crypto3 1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries - C ii libkrb5-3 1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries ii liblua50 5.0.3-4Main interpreter library for the L ii liblualib50 5.0.3-4Extension library for the Lua 5.0 ii libmozjs2d1.9.1.13-1 The Mozilla SpiderMonkey JavaScrip ii libperl5.10 5.10.1-14 shared Perl library ii libruby1.81.8.7.249-2Libraries necessary to run Ruby 1. ii libtre5 0.8.0-2regexp matching library with appro ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime elinks recommends no packages. Versions of packages elinks suggests: pn elinks-docnone (no description available) -- 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#598073: gnome-terminal: allow undiverting mouse events
Package: gnome-terminal Version: 2.30.2-1 Severity: wishlist Sometimes, programs run in a GNOME terminal window will use xterm control sequences to request mouse events. Unfortunately, this results in it being impossible to use the mouse to select text for either selection or clipboard copy/paste into another program, since the relevant events are being diverted. Having each program support resetting the terminal mouse on user request might be nice, but it would also be nice for the terminal emulator to let the user override this on a temporary basis. (This would probably be provided on the context menu, since right-clicking is the one mouse event that is not diverted.) --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-terminal depends on: ii gnome-terminal-data 2.30.2-1Data files for the GNOME terminal ii libatk1.0-0 1.30.0-1The ATK accessibility toolkit ii libc62.11.2-6Embedded GNU C Library: Shared lib ii libdbus-glib-1-2 0.88-2 simple interprocess messaging syst ii libgconf2-4 2.28.1-4GNOME configuration database syste ii libglib2.0-0 2.24.2-1The GLib library of C routines ii libgtk2.0-0 2.20.1-1+b1 The GTK+ graphical user interface ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library ii libpango1.0-01.26.2-1Layout and rendering of internatio ii libsm6 2:1.1.1-1 X11 Session Management library ii libvte9 1:0.24.3-1 Terminal emulator widget for GTK+ ii libx11-6 2:1.3.3-3 X11 client-side library Versions of packages gnome-terminal recommends: ii gvfs 1.2.3-3 userspace virtual filesystem - ser ii yelp 2.30.1+webkit-1 Help browser for GNOME gnome-terminal 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#598001: youtube-dl: handling CAPTCHA requests
Package: youtube-dl Version: 2010.08.04-1 Severity: wishlist I've had reports of people using proxies to access YouTube that result in frequent CAPTCHA requests due to the high volume of requests received from the same IP range. Successfully acquiring a cookie from the CAPTCHA allows access, but there appears to be no way to propagate the cookie to youtube-dl. Accepting an external cookie jar file and applying it to all requests would be nice. The root cause could also be fixed by providing interactive CAPTCHA scraping (displaying the image and letting the user submit a response, then retrieving the cookie), but I imagine that might be a lot more complicated. In particular, I would expect that to be a superset of the complexity of the above, since due to youtube-dl not accepting multiple URLs, one would want to be able to store the cookie for later invocations. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages youtube-dl depends on: ii python2.6.6-3interactive high-level object-orie youtube-dl recommends no packages. Versions of packages youtube-dl suggests: pn rtmpdump none (no description available) -- 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#517526: IPv6 forwarding can be enabled/disabled per interface
On a system I control, I have:
# (cd /proc/sys/net/ipv6/conf grep . {eth*,default,all}/forwarding)
eth0/forwarding:0
eth1/forwarding:1
eth2/forwarding:1
default/forwarding:1
all/forwarding:0
Some of the interfaces forward and some do not. I wish to use radvd
only on some interfaces, and those happen to forward.
But guess what, it still doesn't start! Even removing the initscript
check doesn't help, because the radvd binary itself vomits profusely
at the idea that forwarding is not enabled for _all_ interfaces:
(from strace)
open(/proc/sys/net/ipv6/conf/all/forwarding, O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
redacted
read(5, 0\n..., 1024) = 2
close(5)= 0
[...]
(stderr output)
[Sep 17 17:41:37] radvd: IPv6 forwarding seems to be disabled, exiting
--- Drake Wilson
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572914: Opening playlist window for the first time reverses order of entries
As a quick note, I believe this is related to a behavior I've experienced where opening the playlist window for the first time will cause the ordering to reverse itself. I was never able to track this down, but it doesn't happen unless the playlist window becomes open. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585838: rubygems1.8: writes gems only readable by root
Package: rubygems1.8 Version: 1.3.6-2 Severity: normal Installing gems with [sudo gem install ...] and a user umask of 0077 seems to create all the files in /var/lib/gems/1.8 with that umask so that they're only readable by root, thus defeating the point of the install. A [chmod -R a+rX] resolves this as far as I know, but that's a potentially fragile solution. I think it would be preferable for 'gem' to explicitly set the umask to 022 in this context, as this would be more consistent with other extant methods of doing systemwide software installation. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rubygems1.8 depends on: ii rdoc1.8 1.8.7.249-2 Generate documentation from Ruby s ii ruby1.8 1.8.7.249-2 Interpreter of object-oriented scr rubygems1.8 recommends no packages. Versions of packages rubygems1.8 suggests: ii build-essential 11.5Informational list of build-essent ii ruby1.8-dev 1.8.7.249-2 Header files for compiling extensi pn rubygems-doc none (no description available) -- 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#582043: libgtk2-ruby1.8: Ruby/GTK+ program spins around when other Ruby threads are executing
Package: libgtk2-ruby1.8
Version: 0.19.3-2
Severity: normal
The following program:
#!/usr/bin/ruby
require 'gtk2'
@window = Gtk::Window.new('Bogosity')
@window.set_default_size(320, 240)
@window.show
def count() i = 0; loop { sleep 1; i += 1 } end
@thread = Thread.new { count() }
Gtk.main
does not properly block when no GTK+ input events are being received
and the other thread is sleeping. It generates strace output (with
strace -etrace=\!rt_sigprocmask) along the lines of the attached file;
observe the repeated flips between select() and poll(), all with zero
timeouts.
Commenting out the @thread creation causes the GTK+ main loop to block
(according to interactive strace) when no input events are coming to
the window, and commenting out the Gtk.main and replacing it with
sleep 0.5; count() causes the Ruby threading engine to block when
both threads are sleeping. Mixing the two causes a furious explosion
of system calls.
--- Drake Wilson
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libgtk2-ruby1.8 depends on:
ii libatk1-ruby1.8 0.19.3-2ATK bindings for the Ruby language
ii libatk1.0-0 1.30.0-1The ATK accessibility toolkit
ii libc62.10.2-7Embedded GNU C Library: Shared lib
ii libcairo21.8.8-2 The Cairo 2D vector graphics libra
ii libfontconfig1 2.8.0-2.1 generic font configuration library
ii libfreetype6 2.3.11-1FreeType 2 font engine, shared lib
ii libgdk-pixbuf2-ruby1.8 0.19.3-2Gdk-Pixbuf 2 bindings for the Ruby
ii libglib2.0-0 2.24.0-1The GLib library of C routines
ii libgtk2.0-0 2.20.0-3The GTK+ graphical user interface
ii libpango1-ruby1.80.19.3-2Pango bindings for the Ruby langua
ii libpango1.0-01.26.2-1Layout and rendering of internatio
ii libruby1.8 1.8.7.249-2 Libraries necessary to run Ruby 1.
libgtk2-ruby1.8 recommends no packages.
libgtk2-ruby1.8 suggests no packages.
-- no debconf information
dpw-20100517-gtk-spin-1.strace.gz
Description: GNU Zip compressed data
Bug#579185: x11-xserver-utils: weird xkeystone executable
Package: x11-xserver-utils
Version: 7.5+1
Severity: normal
The executable /usr/bin/xkeystone has the following properties:
- It refuses to execute at all without nickle installed, and without
cairo-5c installed it immediately dies. Both of these are in the
Suggests list for x11-xserver-utils, but not Recommends or
Depends.
- Running it with both of those packages installed spits out an
apparently-infinite stream of cruft to the terminal along the
lines of
[...]
color = {red = 0, green = 0, blue = 0, alpha = 1}}, {nichrome =
recursive, container = recursive, configure = void func(widget_t
widget, rect_t geometry);, natural = void func(cairo_t cr, label_t
widget);, geometry = {x = 0, y = 56, width = 400, height = 14},
extents = {x = uninit, y = uninit, width = uninit, height =
uninit}, outline = void func(cairo_t cr, label_t widget);, draw =
void func(cairo_t cr, label_t widget);, button = uninit, motion =
uninit, key = uninit, label = , font = sans-9, color = {red =
0, green = 0, blue = 0, alpha = 1}}, recursive, {nichrome =
recursive, container = {resize = void func(box_t box, contained_t
contained);, nichrome = uninit, container = recursive, configure =
uninit, natural = uninit, dir = horizontal = , items = ([4])
[...]
and opens a blank white window titled Keystone Correction that
does not obviously respond to any keyboard or mouse input.
- No xkeystone(1) man page is installed.
This doesn't seem like an ideal situation, but it's hard to tell what
the correct situation would be without more information. Certainly
there should at least be a stub man page for xkeystone if it's
installed in /usr/bin, no?
--- Drake Wilson
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages x11-xserver-utils depends on:
ii cpp 4:4.4.3-1 The GNU C preprocessor (cpp)
ii libc6 2.10.2-7 Embedded GNU C Library: Shared lib
ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library
ii libx11-6 2:1.3.3-3 X11 client-side library
ii libxau6 1:1.0.5-2 X11 authorisation library
ii libxaw7 2:1.0.7-1 X11 Athena Widget library
ii libxext6 2:1.1.1-3 X11 miscellaneous extension librar
ii libxi62:1.3-4X11 Input extension library
ii libxmu6 2:1.0.5-1 X11 miscellaneous utility library
ii libxmuu1 2:1.0.5-1 X11 miscellaneous micro-utility li
ii libxrandr22:1.3.0-3 X11 RandR extension library
ii libxrender1 1:0.9.5-2 X Rendering Extension client libra
ii libxt61:1.0.7-1 X11 toolkit intrinsics library
ii libxxf86vm1 1:1.1.0-2 X11 XFree86 video mode extension l
ii x11-common1:7.5+5X Window System (X.Org) infrastruc
x11-xserver-utils recommends no packages.
Versions of packages x11-xserver-utils suggests:
pn cairo-5c none (no description available)
pn nicklenone (no description available)
ii xorg-docs-core1:1.5-1Core documentation for the X.org X
-- 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#570603: libc6: fallocate and posix_fallocate do weird system calls
Quoth Aurelien Jarno aurel...@aurel32.net, on 2010-02-20 11:38:22 +0100:
On Fri, Feb 19, 2010 at 08:35:59PM -0600, Drake Wilson wrote:
Two C source files are attached. One of them uses Linux fallocate()
They are not.
D'oh. Sorry! *brown paper bag*
Let's try that again, then. *attach*
Your filesystem does not support fallocate, so the glibc is emulating it
with a pwrite.
That makes a certain amount of sense in this context; I originally
assumed I couldn't trust the return value of the syscall due to the
strange parameters (and didn't think ext2 might not have fallocate).
Reassigning.
Thank you for the attention, and sorry for the initial incorrectness.
--- Drake Wilson
#define _GNU_SOURCE
#include unistd.h
#include fcntl.h
int
main(int argc, char *argv[])
{
int const fd = open(file, O_WRONLY | O_CREAT | O_TRUNC, 0666);
if (fd == -1) return 1;
int const err = fallocate(fd, 0, 0, (off_t)(1 20));
if (err == -1) return 1;
return 0;
}
#define _XOPEN_SOURCE 600
#include unistd.h
#include fcntl.h
int
main(int argc, char *argv[])
{
int const fd = open(file, O_WRONLY | O_CREAT | O_TRUNC, 0666);
if (fd == -1) return 1;
int const err = posix_fallocate(fd, 0, (off_t)(1 20));
if (err == -1) return 1;
return 0;
}
Bug#570603: libc6: fallocate and posix_fallocate do weird system calls
Package: libc6 Version: 2.10.2-6 Severity: normal Two C source files are attached. One of them uses Linux fallocate() and one uses posix_fallocate() from POSIX:2001. Both are ostensibly supported by eglibc. I'm running a stock kernel from unstable (some background text removed): $ uname -r 2.6.29-1-amd64 $ dpkg -l linux-image-2.6.29-1-amd64 ii linux-image-2.6.29-1-amd64 2.6.29-3 Linux 2.6.29 image on AMD64 Each of the C programs will attempt to open and truncate a file named file, then allocate one MiB of space for it, changing its size. Here's what happens instead: $ strace ./linux [...] open(file, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 fallocate(3, 0, 4503599627370496, 6895618648722965280) = -1 EOPNOTSUPP (Operation not supported) The hexadecimal representations of those two numbers are 0x0010 and 0x5fb228a05fb10320. And: $ strace ./posix open(file, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 fallocate(3, 0, 4503599627370496, 1048576) = -1 EOPNOTSUPP (Operation not supported) This is followed by an emulation of posix_fallocate using one-byte pwrites. Jesus. This is obviously bogus. This feels like libc screwing up the system call parameters, which is why I'm reporting it here, but I'm not certain of that. It could also potentially be strace or the kernel, in which case please reassign as necessary, as usual. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libc-bin 2.10.2-6 Embedded GNU C Library: Binaries ii libgcc1 1:4.4.3-2 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii glibc-doc 2.10.2-5 Embedded GNU C Library: Documentat ii locales 2.10.2-5 Embedded GNU C Library: National L -- debconf information: glibc/upgrade: true * glibc/disable-screensaver: glibc/restart-failed: * glibc/restart-services: ssh saslauthd rsync openbsd-inetd lprng exim4 cron atd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569517: libc6-dev: sys/stat.h should provide S_ISSOCK with sufficiently recent _POSIX_C_SOURCE
Package: libc6-dev
Version: 2.10.2-6
Severity: wishlist
File issock.c:
#include sys/stat.h
int foo(mode_t mode) { return S_ISSOCK(mode); }
int main(int argc, char *argv[]) { return foo(0); }
Compilation results:
$ gcc -std=c99 -D_POSIX_C_SOURCE=200112L -o issock issock.c
issock.c: In function ‘foo’:
issock.c:2: warning: implicit declaration of function ‘S_ISSOCK’
/tmp/ccUoCGe4.o: In function `foo':
issock.c:(.text+0x16): undefined reference to `S_ISSOCK'
collect2: ld returned 1 exit status
$ gcc -std=c99 -D_POSIX_C_SOURCE=200809L -o issock issock.c
issock.c: In function ‘foo’:
issock.c:2: warning: implicit declaration of function ‘S_ISSOCK’
/tmp/ccsSvaAx.o: In function `foo':
issock.c:(.text+0x16): undefined reference to `S_ISSOCK'
collect2: ld returned 1 exit status
Using gcc -E -dM, it is possible to observe that S_ISSOCK does not get
defined as a macro at any point. With -D_GNU_SOURCE or no feature
test macros at all, issock.c compiles fine. /usr/include/sys/stat.h
on my machine has at line 146:
#if (defined __USE_BSD || defined __USE_UNIX98) \
defined __S_IFSOCK
# define S_ISSOCK(mode) __S_ISTYPE((mode), __S_IFSOCK)
#endif
This seems to be along the lines of only defining S_ISSOCK when BSD or
X/Open features are being selected (my glance at __USE_UNIX98 yielded
vague understanding at best), but according to [1], POSIX:2001
declares that sys/stat.h defines the macro S_ISSOCK without any
extension tags (such as the XSI tag), which would seem to me to make
it a POSIX feature.
[1] http://www.opengroup.org/onlinepubs/95399/basedefs/sys/stat.h.html
--- Drake Wilson
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6-dev depends on:
ii libc-dev-bin 2.10.2-6 Embedded GNU C Library: Developmen
ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib
ii linux-libc-dev2.6.32-6 Linux support headers for userspac
Versions of packages libc6-dev recommends:
ii gcc [c-compiler] 4:4.4.2-3 The GNU C compiler
ii gcc-3.4 [c-compiler] 3.4.6-10 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.4-6The GNU C compiler
ii gcc-4.4 [c-compiler] 4.4.3-2The GNU C compiler
Versions of packages libc6-dev suggests:
ii glibc-doc 2.10.2-5 Embedded GNU C Library: Documentat
ii manpages-dev 3.23-1 Manual pages about using GNU/Linux
-- 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#568489: broken gdbserver does not affect results
Apparently I didn't notice that the gdbserver package hadn't been installed (probably due to normal wobbliness in sid). Installing gdbserver 7.0.1-2 has no obvious effect on this behavior. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568494: gnome-terminal: please provide UI for cursor blink option
Package: gnome-terminal Version: 2.28.2-1 Severity: wishlist The GNOME Terminal source apparently provides for non-blinking cursors via setting cursor_blink_mode to off for the relevant profile. However, this does not appear to be exposed in the GUI. IWBNI this were a documented option available from the relevant options dialog. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-terminal depends on: ii gnome-terminal-data2.28.2-1 Data files for the GNOME terminal ii libatk1.0-01.28.0-1 The ATK accessibility toolkit ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libdbus-glib-1-2 0.84-1simple interprocess messaging syst ii libgconf2-42.28.0-1 GNOME configuration database syste ii libglib2.0-0 2.22.4-1 The GLib library of C routines ii libgtk2.0-02.18.6-1 The GTK+ graphical user interface ii libice62:1.0.6-1 X11 Inter-Client Exchange library ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio ii libsm6 2:1.1.1-1 X11 Session Management library ii libstartup-notification0 0.10-1library for program launch feedbac ii libvte91:0.22.5-1+b1 Terminal emulator widget for GTK+ ii libx11-6 2:1.3.3-1 X11 client-side library Versions of packages gnome-terminal recommends: ii gvfs 1.2.3-3 userspace virtual filesystem - ser ii yelp 2.28.0+webkit-2 Help browser for GNOME gnome-terminal 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#558227: Leaving-actions at the end of a machine
(Pardon my slight laziness with the References header c.)
Quoth Adrian Thurston thurs...@complang.org:
The leaving action becomes an EOF action in the final state of foo. The
goto bar cannot process any data, so simply adding a label and jumping
there would be incorrect. Either an error should be reported, or the
machine should have it's cs set to bar. Which is desired?
Well, I seem to recall that I put the %action there to switch to
another machine on a transition from any final state on either EOF or
any error. If what you say is true, it probably means I'm doing it
wrong (probably should use ! and / actions instead?) and should look
at the manual again. I actually can't find the original file in which
I ran into this, though... I assume I wound up doing something more
Ragel-suitable instead, but now I don't remember which machine it was.
Anyway, I would prefer that Ragel signal an error rather than writing
broken code: something along the lines of impossible fgoto in EOF
action and/or a warning for leaving action transformed into EOF
action. I'm not sure the former is actually possible to determine
reliably, since it may be halting problem complete. I note that if I
use %{fexec ...; fgoto bar;} instead, it becomes possible for the
fgoto to have characters since the input pointer has jumped backwards,
but the target label still doesn't appear (in -G2 mode). I'm not sure
what implications that has either.
--- Drake Wilson
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562491: make: shell-skipping heuristics fail to take some builtins into account
Quoth Manoj Srivastava sriva...@acm.org, on 2009-12-24 16:35:49 -0600: So, a POSIX shell will be called -- or make shall pretend that a POSIX shell is called with the command line. [...] $ make -f ~/tmp/type.mk type ls make: type: Command not found make: *** [all] Error 127 This is because type is part of the X/Open Systems Interfaces option, but not a builtin part of POSIX itself. Nothing states that the POSIX shell invoked by Make supports the XSI option. First of all, thank you for paying attention. :-) Your point is sound. I originally assumed that the shell should be the same one invoked by sh (in this case, /bin/sh, which is dash on my system, and does support the XSI extension type) unless specified otherwise, but you are correct in that nothing seems to say that the sh used by system(3) and the sh invoked from the command line must be the same. I do note that system(type ls) does execve(/bin/sh, ...), so in this case the behavior of make doesn't correspond to the behavior of system(3). I'm not sure what implications that has, if any. I also note that the GNU Make documentation (in section 1, Overview of `make') actually refers to 1003.2-_1992_, which is interesting; I haven't looked at the differences yet. Anyway, the flip side of this is whether it corresponds to the GNU Make documentation, which I also examined when I first encountered this behavior, to see whether it was mentioned anywhere. (The behavior is the same whether I include the .POSIX declaration or not.) Examining it again, I find the following: From the manual for GNU Make 3.81, section 5.3.1 Choosing the Shell: | The program used as the shell is taken from the variable `SHELL'. | If this variable is not set in your makefile, the program `/bin/sh' | is used as the shell. From section 5.3 Command Execution: | When it is time to execute commands to update a target, they are | executed by invoking a new subshell for each command line. (In | practice, `make' may take shortcuts that do not affect the results.) ... but in fact, this shortcut does affect the results as compared specifically to using a /bin/sh subshell on this system. The GNU Make documentation appears to make stronger claims than POSIX in this case. Of course, the set of extensions available for the shell in use is not really predictable by GNU Make, so strictly following that would make the shortcuts nearly impossible to use, and I assume there is a good reason for them if the effort was made to put them in in the first place. I notice that when I set SHELL to /bin/sh explicitly in the Makefile, the behavior stays the same, but when I set it to something else, such as /bin/dash or /bin/bash, the shortcuts are turned off. If the current behavior is considered correct, possibly the manual should mention that it will assume only certain builtins need to be passed to /bin/sh, and/or how to explicitly turn this mechanism off in the case where one wants to use /bin/sh but under the assumption that it will have certain extra properties (which would be a portability constraint imposed by the Makefile writer, but not IMHO something GNU Make should itself exclude). I would also respectfully request that unless this is Debian-specific behavior, this report be demoted to wishlist status but remain open until GNU Make upstream decides on it. (That probably implies forwarding; I will forward the report myself if requested.) manoj --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562491: make: shell-skipping heuristics fail to take some builtins into account
Package: make Version: 3.81-7 Severity: normal I'm not sure whether this qualifies as normal or wishlist; it depends on how much GNU Make cares about POSIX compatibility. In this message, I primarily reference POSIX:2001. POSIX says, regarding make(1): | Command execution shall be as if the makefile command line were the | argument to the system() function. Regarding system(3): | The environment of the executed command shall be as if a child process | were created using fork(), and the child process invoked the sh | utility using execl() as follows: | | execl(shell path, sh, -c, command, (char *)0); | | where shell path is an unspecified pathname for the sh utility. sh -c has no special rules for builtins as opposed to other commands. I interpret this to mean that a command in a Makefile is allowed to contain a single shell builtin invocation, and that this should invoke the builtin. Creating a file type.mk with the contents: .POSIX: all: type ls (with the first character on line 3 being a tab) results in: $ make -f ~/tmp/type.mk type ls make: type: Command not found make: *** [all] Error 127 Adding any shell metacharacters causes the shell to be invoked, and then the type command succeeds properly. Many builtins also have associated executables, but this is not required for all builtins. What to do about this is unclear. I don't see any way to turn off the heuristic other than by working around it with useless metacharacter-y clauses in the Makefile. Possibly detecting the .POSIX target and turning it off then would be suitable, or possibly giving the shell a second try iff a command is not found directly for exec(3) purposes, though the latter still changes the priority between executables and shell builtins. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages make depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries make recommends no packages. Versions of packages make suggests: ii make-doc 3.81-5 Documentation for the GNU version -- 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#560146: kvm: failing to go fullscreen in SDL mode explodes the entire emulator process
Package: kvm Version: 85+dfsg-4.1 Severity: critical Justification: causes serious data loss The situation in which I encountered this involved the OpenSolaris 2009.06 Live CD, after it had entered graphical mode. FWIW, my X configuration is 1280x1024; the graphics window for KVM also appeared to be 1280x1024. The command line was: kvm -name dumbbell -uuid e7c06115-e211-4be5-b7e2-47d1502ed59e \ -m 1024 -hda dumbbell.qcow -vga vmware -net nic,vlan=0 -net user,vlan=0 \ -monitor stdio -no-shutdown -cdrom osol-0906-x86.iso -boot d Pressing C-A-f in the SDL display window to switch to fullscreen mode failed with Could not open SDL display, and the entire emulator process immediately vanished with no chance to checkpoint with a savevm or allow the guest to sync its disks or anything. In this case, I got lucky since it happened early in the OS install stage, but in other circumstances a sudden emulator exit could cause serious data loss, which is why I am filing this as a critical bug, similarly to #537569. (As usual, if this is not the correct severity, please advise as to the correct severity.) --- Drake Wilson -- Package-specific info: selected information from lshal(1): /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping: 2 cpu MHz : 2210.047 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 4420.09 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping: 2 cpu MHz : 2210.047 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 4420.30 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kvm depends on: ii adduser3.111 add and remove users and groups ii bridge-utils 1.4-5 Utilities for configuring the Linu ii iproute20090324-1networking and traffic control too ii libasound2 1.0.21a-1 shared library for ALSA applicatio ii libbluetooth3 4.57-1Library to use the BlueZ Linux Blu ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libgnutls262.8.5-2 the GNU TLS library - runtime libr ii libncurses55.7+20090803-2shared libraries for terminal hand ii libpci31:3.1.4-4 Linux PCI Utilities (shared librar ii libpulse0 0.9.21-1 PulseAudio client libraries ii libsdl1.2debian1.2.13-5 Simple DirectMedia Layer ii libvdeplug22.2.3-3 Virtual Distributed Ethernet - Plu ii libx11-6 2:1.3.2-1 X11 client-side library ii python 2.5.4-2 An interactive high-level object-o ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime Versions of packages kvm recommends: ii linux-image-2.6.27.1 [linux-i drache.1.0 Linux kernel binary image for vers ii linux-image-2.6.29-1-amd64 [l 2.6.29-3 Linux 2.6.29 image on AMD64 Versions of packages kvm suggests: ii debootstrap 1.0.20 Bootstrap a basic Debian system ii hal 0.5.13-6 Hardware Abstraction Layer pn kvm-sourcenone (no description available) pn samba none (no description available) ii
Bug#558227: ragel: emitted C code with -G2 in the presence of fgoto fails to compile
Package: ragel
Version: 6.5-1
Severity: normal
Here's a semi-minimal test machine:
/* */
%%{
machine foobar;
alphtype unsigned char;
bar := 'b' @{fbreak;} ;
foo := 'a' %{fgoto bar;} ;
}%%
%%write data;
void
run(unsigned char const *p, unsigned char const *pe)
{
unsigned char const *const eof = pe;
int cs;
%%write init;
%%write exec;
}
/* */
$ ragel -C -G2 test.rl gcc -c test.c
test.rl: In function ‘run’:
test.rl:6: error: label ‘st2’ used but not defined
This appears to be because the fgoto for some reason doesn't cause a
label to be generated for the target state, even though one is needed.
--- Drake Wilson
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages ragel depends on:
ii libc6 2.10.2-2 GNU C Library: Shared libraries
ii libgcc1 1:4.4.2-3 GCC support library
ii libstdc++64.4.2-3The GNU Standard C++ Library v3
ragel recommends no packages.
ragel 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#554946: strace: sockaddr structure displays are inconsistent
Package: strace
Version: 4.5.19-1
Severity: normal
When displaying a sockaddr_in6 structure passed to a system call, all
the components of the structure have field labels except sin6_addr.
This is inconsistent with the rest of the structure displays, and
particularly is inconsistent with the display of sockaddr_in.
Example:
connect(3, {sa_family=AF_FILE, path=/home/drake/.paneliy}, 110) = 0
Displaying a sockaddr_un structure uses the field name path rather
than sun_path, which is inconsistent with the other sockaddr
structures.
Example (line-wrapped, treat \n[ \t]+ as a single space):
bind(4, {sa_family=AF_INET6, sin6_port=htons(15055),
inet_pton(AF_INET6, ::1, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = 0
--- Drake Wilson
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages strace depends on:
ii libc6 2.10.1-3 GNU C Library: Shared libraries
strace recommends no packages.
strace suggests no packages.
-- debconf-show failed
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550313: From gvfs
This seems to be bug #549330/bug #548343. Upgrading gvfs made this go away (and also destroyed lvm2 due to conflicts). --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550313: inkscape: Open crash
=value optimized out) at ui/dialog/filedialogimpl-gtkmm.h:170 #42 0x0067f93e in FileOpenDialogImplGtk (this=0x4855ea0, parentWindow=..., dir=..., fileTypes=Inkscape::UI::Dialog::SVG_TYPES, title=..., __in_chrg=value optimized out, __vtt_parm=value optimized out) at ui/dialog/filedialogimpl-gtkmm.cpp:695 #43 0x0066d2e3 in Inkscape::UI::Dialog::FileOpenDialog::create (parentWindow=..., path=..., fileTypes=Inkscape::UI::Dialog::SVG_TYPES, title=...) at ui/dialog/filedialog.cpp:40 #44 0x00462b73 in sp_file_open_dialog (parentWindow=...) at file.cpp:406 #45 0x0054b5cb in Inkscape::FileVerb::perform (action=0x156cd90, data=0x3) at verbs.cpp:773 #46 0x00929039 in sp_action_perform (action=0x156cd90, data=0x0) at helper/action.cpp:181 #47 0x0046c8aa in sp_ui_menu_activate (action=0x156cd90) at interface.cpp:367 #48 0x740974bd in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #49 0x740aac8b in ?? () from /usr/lib/libgobject-2.0.so.0 #50 0x740ac032 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #51 0x740ac503 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #52 0x75c6a360 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #53 0x75b6915d in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #54 0x75b6aaeb in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #55 0x75b5b178 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #56 0x740974bd in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #57 0x740aa979 in ?? () from /usr/lib/libgobject-2.0.so.0 #58 0x740abec8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #59 0x740ac503 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #60 0x75c6417e in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #61 0x75b53733 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #62 0x75b5480b in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #63 0x0045188a in snooper (event=0x426db20) at main.cpp:682 #64 0x757c81bc in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #65 0x737f112a in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #66 0x737f4988 in ?? () from /lib/libglib-2.0.so.0 #67 0x737f4e5d in g_main_loop_run () from /lib/libglib-2.0.so.0 #68 0x75b54c07 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #69 0x0045215c in sp_main_gui (argc=1, argv=0x7fffe3d8) at main.cpp:724 #70 0x0062edd0 in Inkscape::NSApplication::Application::run (this=0x7fffe2b0) at application/application.cpp:117 #71 0x0045277d in main (argc=1, argv=0x7fffe3d8) at main.cpp:539 --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages inkscape depends on: ii libatk1.0-01.28.0-1 The ATK accessibility toolkit ii libc6 2.9-27GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libcairomm-1.0-1 1.8.0-1 C++ wrappers for Cairo (shared lib ii libfontconfig1 2.6.0-4 generic font configuration library ii libfreetype6 2.3.9-5 FreeType 2 font engine, shared lib ii libgc1c2 1:6.8-1.2 conservative garbage collector for ii libgcc11:4.4.1-5 GCC support library ii libgconf2-42.26.2-3 GNOME configuration database syste ii libglib2.0-0 2.22.1-1 The GLib library of C routines ii libglibmm-2.4-1c2a 2.22.1-2 C++ wrapper for the GLib toolkit ( ii libgnomevfs2-0 1:2.24.1-4GNOME Virtual File System (runtime ii libgtk2.0-02.18.2-1 The GTK+ graphical user interface ii libgtkmm-2.4-1c2a 1:2.18.2-1C++ wrappers for GTK+ 2.4 (shared ii libgtkspell0 2.0.13-2 a spell-checking addon for GTK's T ii liblcms1 1.18.dfsg-1 Color management library ii libpango1.0-0 1.26.0-1 Layout and rendering of internatio ii libpangomm-1.4-1 2.26.0-1 C++ Wrapper for pango (shared libr ii libpng12-0 1.2.40-1 PNG library - runtime ii libpoppler-glib4 0.10.6-1 PDF rendering library (GLib-based ii libpoppler40.10.6-1 PDF rendering library ii libpopt0 1.15-1lib for parsing cmdline parameters ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++ ii libssl0.9.80.9.8k-5 SSL shared libraries ii libstdc++6
Bug#526088: vlc: VLC windows should have useful window classes
Quoth Christophe Mutricy xto...@chewa.net, on 2009-09-20 00:44:37 +0200:
It might have been improve in 1.0.x. Could you confirm or infirm if this
bug is still present in sid or squeeze
In sid, with vlc 1.0.1-2, running qvlc produces the class {vlc,
Vlc} on the main UI window, which is quite reasonable. So that is
an improvement.
Running cvlc, or running qvlc on a file which displays similar
behavior to that in #362976 (which seems to have changed a bit now; it
says VLC (XVideo output) rather than VLC (X11 Output)) results in
no window class on that window.
Thanks for the heads-up.
--
Xtophe
--- Drake Wilson
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537569: kvm: -no-shutdown exits KVM on guest shutdown
Package: kvm Version: 85+dfsg-4 Severity: critical Justification: causes serious data loss The kvm program is described in its manpage and everywhere else as being based on QEMU. kvm(1) points to kvm-qemu(1) for instructions on invocation. kvm-qemu(1) says: -no-shutdown Don’t exit QEMU on guest shutdown, but instead only stop the emulation. This allows for instance switching to monitor to commit changes to the disk image. On my system, this does not seem to actually do anything. Test set of arguments: $ kvm -drive media=disk,index=0,format=qcow2,file=foo.qcow \ -boot c -m 256 -no-shutdown -snapshot with foo.qcow, in my case, being a bootable image of Debian lenny for AMD64 architecture (same as my host architecture). Creating some files inside the guest, and then running shutdown -h from the guest, causes KVM to exit without giving me any chance to commit the disk changes as the manual page said it would. The disk changes are now apparently gone forever; starting the virtual machine again does not show them. My original command line contained some additional arguments for kvm, namely -no-quit -monitor stdio -net nic,vlan=0 -net user,vlan=0 , but this does not appear to affect the results. Switching the order of the -snapshot and -no-shutdown arguments does not appear to affect the results. I believe that causing written pieces of a virtual disk to disappear when the user expects to be able to input a commit command next constitutes serious loss of user data, which justifies the critical severity at which I am reporting this. Thanks in advance for any attention. --- Drake Wilson -- Package-specific info: selected information from lshal(1): /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping: 2 cpu MHz : 2209.855 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 4419.71 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping: 2 cpu MHz : 2209.855 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 4420.30 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kvm depends on: ii adduser3.110 add and remove users and groups ii bridge-utils 1.4-5 Utilities for configuring the Linu ii iproute20090324-1networking and traffic control too ii libasound2 1.0.20-2 shared library for ALSA applicatio ii libbluetooth3 4.42-2Library to use the BlueZ Linux Blu ii libbrlapi0.5 4.0-6 braille display access via BRLTTY ii libc6 2.9-13GNU C Library: Shared libraries ii libgnutls262.6.6-1 the GNU TLS library - runtime libr ii libncurses55.7+20090607-1shared libraries for terminal hand ii libpci31:3.1.3-1 Linux PCI Utilities (shared librar ii libpulse0 0.9.15-4 PulseAudio client libraries ii libsdl1.2debian1.2.13-4+b1 Simple DirectMedia Layer ii libvdeplug22.2.2-3 Virtual Distributed Ethernet - Plu ii libx11-6 2:1.2.1-1 X11 client-side library ii python 2.5.4-2 An interactive high
Bug#531971: liblua5.1-wsapi1: doesn't load due to missing module 'lfs'
Package: liblua5.1-wsapi1
Version: 1.1.0-3
Severity: grave
Justification: renders package unusable
Based on the information in
/usr/share/doc/liblua5.1-wsapi-doc/doc/us/manual.html, I infer that a
Lua process should, from startup, be able to require 'wsapi.fastcgi'.
However, this doesn't seem to work:
dr...@drache:~/tmp$ lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
require('wsapi.fastcgi')
/usr/share/lua/5.1/wsapi/common.lua:9: module 'lfs' not found:
no field package.preload['lfs']
no file './lfs.lua'
no file '/usr/local/share/lua/5.1/lfs.lua'
no file '/usr/local/share/lua/5.1/lfs/init.lua'
no file '/usr/local/lib/lua/5.1/lfs.lua'
no file '/usr/local/lib/lua/5.1/lfs/init.lua'
no file '/usr/share/lua/5.1/lfs.lua'
no file '/usr/share/lua/5.1/lfs/init.lua'
no file './lfs.so'
no file '/usr/local/lib/lua/5.1/lfs.so'
no file '/usr/lib/lua/5.1/lfs.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
[C]: in function 'require'
/usr/share/lua/5.1/wsapi/common.lua:9: in main chunk
[C]: in function 'require'
/usr/share/lua/5.1/wsapi/fastcgi.lua:12: in main chunk
[C]: in function 'require'
stdin:1: in main chunk
[C]: ?
Reporting against liblua5.1-wsapi1 since the requirement for lfs seems
to be from wsapi/common.lua. Severity grave because the probability
that this bug is system-specific seems rather low. apt-cache search
doesn't report anything obvious in the Debian archive that looks like
a Lua library that would provide 'lfs'.
--- Drake Wilson
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages liblua5.1-wsapi1 depends on:
ii liblua5.1-rings0 1.2.2-1lua state creation and control lib
ii lua5.15.1.4-3Simple, extensible, embeddable pro
liblua5.1-wsapi1 recommends no packages.
Versions of packages liblua5.1-wsapi1 suggests:
pn liblua5.1-cgi0none (no description available)
-- 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#531971: Missing dependency
Of course right after I post that I find the package that provides the module requested. It appears that installing liblua5.1-filesystem0 allows the wsapi files to load, so I suppose liblua5.1-wsapi1 should depend on it. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531396: uuid: -m option does not take effect if followed by -v1
Package: uuid Version: 1.5.1-1.1+b1 Severity: normal Specifying -v1 by itself uses a suitable local Ethernet MAC: $ uuid -v1 c1939184-4e8e-11de-9a09-001a4d677db0 $ uuid -v1 c660bb9c-4e8e-11de-a750-001a4d677db0 Specifying -v1 -m uses a random multicast MAC, per the description of -m: $ uuid -v1 -m d0123cf6-4e8e-11de-91c4-77d0a706d5a4 $ uuid -v1 -m d06f0030-4e8e-11de-b9bb-d3fbd9b76d21 Specifying -m -v1 uses the local MAC again, ignoring the -m: $ uuid -m -v1 d7505c8c-4e8e-11de-9883-001a4d677db0 $ uuid -m -v1 da515abc-4e8e-11de-80d3-001a4d677db0 The manual page does not seem to indicate anything about a subsequent -v option overriding the effect of -m. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages uuid depends on: ii libc6 2.9-13 GNU C Library: Shared libraries ii libossp-uuid15 1.5.1-1.1+b1 OSSP uuid ISO-C and C++ - shared l uuid recommends no packages. uuid 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#530998: libxml2-utils: unhelpful error parsing infinitely recursive parameter entity
Package: libxml2-utils Version: 2.7.3.dfsg-1 Severity: minor Context: a file named loop.xml containing the following text (sans initial vertical bar and space): | !DOCTYPE x [ | !ELEMENT x ANY | !ENTITY % x #37;x; | %x; | ] | x/ Running [xmllint loop.xml] produces the following output: | Entity: line 1: parser error : internal error | %x; | ^ | Entity: line 1: | %x; | ^ | Entity: line 1: parser error : DOCTYPE improperly terminated | %x; | ^ | Entity: line 1: | %x; | ^ | Entity: line 1: parser error : Start tag expected, '' not found | %x; | ^ | Entity: line 1: | %x; | ^ The XML is obviously bogus, but the error messages could be improved: ideally it would result in a graceful detection rather than an internal error. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libxml2-utils depends on: ii libc6 2.9-13 GNU C Library: Shared libraries ii libreadline55.2-4GNU readline and history libraries ii libxml2 2.7.3.dfsg-1 GNOME XML library libxml2-utils recommends no packages. libxml2-utils 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#521275: Embedding terminal control sequences in bash prompts
I believe this is the intended behavior. I don't know of a good way for bash to figure out what exactly constitutes a terminal control sequence given a possible profusion of terminal types. As a result, the user is expected to declare which parts of a prompt do not take up any columns for such reasons. From bash(1), in section PROMPTING: |\[ begin a sequence of non-printing characters, which could be used |to embed a terminal control sequence into the prompt |\] end a sequence of non-printing characters --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515234: bash fails to process files separately with for name in *
The traces you provide show that what's happening is actually that the *, being expanded in a directory with no files, expands to the literal '*', which is somewhat awkward with which to deal but which is mandated by POSIX for /bin/sh: From http://www.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html#tag_02_13, retrieved on 2009-05-10: | If the pattern contains an invalid bracket expression or does not | match any existing filenames or pathnames, the pattern string shall | be left unchanged. So why are all these other filenames appearing in the trace? Simple: because you don't use the correct double-quoting around your use of $f, and so [ -w /sys/module/speakup/parameters/$f ] gets expanded to [ -w /sys/module/speakup/parameters/* ] and then the * gets expanded in that context. Note that this probably means that the script is already broken in the case of filenames in the starting directory that contain whitespace or pattern-matching metacharacters. --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528024: erlang-base: packages in sid are out of date
Package: erlang-base Version: 1:12.b.5-dfsg-3 Severity: wishlist Erlang 5.7.1/OTP R13B is out, but the version of Erlang/OTP in sid is currently stuck at R12B-5, which is from about six months ago according to [1]. The new version supposedly [2] has better SMP performance and Unicode support, among other things. [1] http://www.erlang.org/download.html [2] http://www.erlang.org/documentation/doc-5.7/doc/highlights.html --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages erlang-base depends on: ii libc6 2.9-8 GNU C Library: Shared libraries ii libncurses5 5.7+20090411-1 shared libraries for terminal hand ii procps1:3.2.7-11 /proc file system utilities erlang-base recommends no packages. Versions of packages erlang-base suggests: pn erlang none (no description available) ii erlang-doc-html 1:12.b.5-dfsg-1 Erlang HTML pages pn erlang-manpages none (no description available) ii erlang-nox 1:12.b.5-dfsg-3 Concurrent, real-time, distributed pn erlang-x11 none (no description available) -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526088: vlc: VLC windows should have useful window classes
Package: vlc Version: 0.9.9a-2 Severity: wishlist xprop shows that the XVideo output window from cvlc or qvlc has no WM_CLASS property, and the UI window has a pair of empty strings on the WM_CLASS property. Presumably it would be nicer on an X level for these to name the VLC application somehow. Perhaps vlc, VLC as a default? --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vlc depends on: ii libaa1 1.4p5-38 ascii art library ii libc6 2.9-7 GNU C Library: Shared libraries ii libdbus-1-31.2.12-1 simple interprocess messaging syst ii libfreetype6 2.3.9-4.1 FreeType 2 font engine, shared lib ii libfribidi00.10.9-1 Free Implementation of the Unicode ii libgcc11:4.3.3-8 GCC support library ii libgl1-mesa-glx [libgl 7.4-2 A free implementation of the OpenG ii libglib2.0-0 2.20.1-1 The GLib library of C routines ii libglu1-mesa [libglu1] 7.4-2 The OpenGL utility library (GLU) ii libgtk2.0-02.16.1-2 The GTK+ graphical user interface ii libnotify1 [libnotify1 0.4.5-1 sends desktop notifications to a n ii libqtcore4 4.5.1-1 Qt 4 core module ii libqtgui4 4.5.1-1 Qt 4 GUI module ii libsdl-image1.21.2.6-3 image loading library for Simple D ii libsdl1.2debian1.2.13-4+b1 Simple DirectMedia Layer ii libstdc++6 4.3.3-8 The GNU Standard C++ Library v3 ii libtar 1.2.11-5 C library for manipulating tar arc ii libvlccore00.9.9a-2 base library for VLC and its modul ii libx11-6 2:1.2.1-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxv1 2:1.0.4-1 X11 Video extension library ii libxxf86vm11:1.0.2-1 X11 XFree86 video mode extension l ii ttf-dejavu-core2.29-2Vera font family derivate with add ii vlc-nox0.9.9a-2 multimedia player and streamer (wi ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime vlc recommends no packages. Versions of packages vlc suggests: pn mozilla-plugin-vlcnone (no description available) ii videolan-doc 20070626-1 documentation for the VideoLAN str Versions of packages vlc-nox depends on: ii liba52-0.7.4 0.7.4-11library for decoding ATSC A/52 str ii libasound2 1.0.19-1shared library for ALSA applicatio ii libass3 0.9.6-1 library for SSA/ASS subtitles rend ii libavahi-cli 0.6.25-1Avahi client library ii libavahi-com 0.6.25-1Avahi common library ii libavcodec52 3:0.svn20090303-1 ffmpeg codec library ii libavformat5 3:0.svn20090303-1 ffmpeg file format library ii libavutil49 3:0.svn20090303-1 ffmpeg utility library ii libc62.9-7 GNU C Library: Shared libraries ii libcaca0 0.99.beta16-1 colour ASCII art library ii libcdio7 0.78.2+dfsg1-3 library to read and control CD-ROM ii libdbus-1-3 1.2.12-1simple interprocess messaging syst ii libdca0 0.0.5-2 decoding library for DTS Coherent ii libdvbpsi4 0.1.5-3.1 library for MPEG TS and DVB PSI ta ii libdvdnav4 4.1.3-3 DVD navigation library ii libdvdread4 4.1.3-5 library for reading DVDs ii libebml0 0.7.7-3.1 access library for the EBML format ii libfaad0 2.6.1-3.1 freeware Advanced Audio Decoder - ii libflac8 1.2.1-1.2 Free Lossless Audio Codec - runtim ii libfontconfi 2.6.0-3 generic font configuration library ii libfreetype6 2.3.9-4.1 FreeType 2 font engine, shared lib ii libfribidi0 0.10.9-1Free Implementation of the Unicode ii libgcc1 1:4.3.3-8 GCC support library ii libgcrypt11 1.4.4-2 LGPL Crypto library - runtime libr ii libgnutls26 2.6.5-1 the GNU TLS library - runtime libr ii libhal1 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share ii libid3tag0 0.15.1b-10 ID3 tag reading library from the M ii liblircclien 0.8.3-3 infra-red
Bug#525511: dvdauthor: depends on obsolete package libmagick10
Package: dvdauthor Version: 0.6.14-3+b2 Severity: important Just what it says on the tin: dvdauthor in sid depends on libmagick10, but that package is no longer available in sid. --- Drake Wilson -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.27.1 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dvdauthor depends on: ii libc6 2.9-7GNU C Library: Shared libraries ii libdvdread4 4.1.3-5 library for reading DVDs ii libfreetype62.3.9-4 FreeType 2 font engine, shared lib ii libmagick10 7:6.3.7.9.dfsg2-1+b1 image manipulation library ii libpng12-0 1.2.35-1 PNG library - runtime ii libxml2 2.7.3.dfsg-1 GNOME XML library ii zlib1g 1:1.2.3.3.dfsg-13compression library - runtime dvdauthor recommends no packages. dvdauthor 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#517823: opie-client: strange, non-working -s option in quick usage message
Package: opie-client
Version: 2.32.dfsg.1-0.1
Severity: minor
Tags: patch
$ opiekey
usage: opiekey [-v] [-h] [-f] [-x] [-t type] [-4 | -5 | -s] [-a] [-n count]
sequence_number seed
$ opiekey -s 100 aa
Using the SHA-1 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: [any passphrase]
ODD DEFT FALL A A ABE
Some experimentation with -n and -x and different sequence numbers and
seeds produces only ODD DEFT FALL A A ABE (2E4E 3DF6 ) for
any input parameters whatsoever. Looking at the opiekey(1) man page,
-s doesn't appear anywhere that I can see.
From a cursory glance through the Debianized opie-2.32 source tree,
the opiehashlen function in libopie/hashlen.c seems to mediate all
digest algorithm usage in OPIE, and it contains a case for SHA-1 in
the opiehashlen() function, but it's omitted from compilation with an
#if 0 block. Presumably the solution is to either fully enable the
possibility of SHA-1 usage or strip the broken -s option out of the
opiekey program.
A rough patch is attached that strips the obvious instances of SHA-1
stuff out of opiekey.c; this doesn't hit potential cases of this in
the other client programs and should be reviewed before applying.
--- Drake Wilson
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.27.1 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages opie-client depends on:
ii libc6 2.9-4 GNU C Library: Shared libraries
opie-client recommends no packages.
opie-client suggests no packages.
-- no debconf information
--- opiekey.c.old 2009-03-02 04:40:13.0 -0600
+++ opiekey.c 2009-03-02 04:40:47.0 -0600
@@ -64,7 +64,7 @@
static VOIDRET usage FUNCTION((s), char *s)
{
- fprintf(stderr, usage: %s [-v] [-h] [-f] [-x] [-t type] [-4 | -5 | -s] [-a] [-n count] sequence_number seed\n, s);
+ fprintf(stderr, usage: %s [-v] [-h] [-f] [-x] [-t type] [-4 | -5] [-a] [-n count] sequence_number seed\n, s);
exit(1);
}
@@ -151,9 +151,6 @@
if (strstr(slash, md5))
algorithm = 5;
- if (strstr(slash, sha))
-algorithm = 3;
-
while ((i = getopt(argc, argv, fhvn:x45at:s)) != EOF) {
switch (i) {
case 'v':
@@ -201,10 +198,6 @@
}
break;
-case 's':
- algorithm = 3;
- break;
-
default:
usage(argv[0]);
}
Bug#458646: Seconded
While I probably think the severity is closer to wishlist than the original submitter thinks it is, I'm voting in favor of adding this functionality. ifrename and the like provide logical names for other interfaces; PPP interfaces should be able to have these too, and based on my limited knowledge of Debian network configuration, I see no good way to implement it outside of pppd itself. I have not reviewed the patch submitted by the original submitter, but informationally, it appears that some other GNU/Linux distributions, such as SuSE, apply similar patches to their distributed forms of pppd. (I also see that the report has been sitting in the BTS for over a year with no response. I'm not sure what to make of this. If there's a reason to avoid doing this, I'd like to hear it.) --- Drake Wilson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507951: picp: binary executable shows up in source tree
Package: picp Version: 0.6.7-3 Severity: minor When I retrieve the source for picp 0.6.7-3 using [apt-get source picp], I see a picp file inside the resulting directory which has its executable bit turned on. file claims that it's an ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped. This doesn't seem correct for a source directory. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.27.1 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages picp depends on: ii libc6 2.7-16 GNU C Library: Shared libraries picp recommends no packages. picp suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507952: picp: inappropriate exit status on some failure types
Package: picp
Version: 0.6.7-3
Severity: normal
Tags: patch
When picp encounters some types of errors, such as finding CTS deasserted
(implying that there is no programmer hooked up to the other end of the serial
line), it reports the error to standard error correctly, but then exits with
a zero status, indicating success. This does not seem correct. A patch is
attached that attempts to correct this problem, though it is a fairly quick
patch and should be reviewed more thoroughly by the maintainer before applying.
This patch also causes picp to exit with a nonzero status when receiving an
interrupt signal, and changes a strange exit(1) line in main() to more closely
conform to the error propagation style of the rest of main.c. Apply with
[patch -p1] in the picp-0.6.7 directory.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.27.1 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages picp depends on:
ii libc6 2.7-16 GNU C Library: Shared libraries
picp recommends no packages.
picp suggests no packages.
-- no debconf information
diff -ur picp-0.6.7.old/main.c picp-0.6.7.new/main.c
--- picp-0.6.7.old/main.c 2008-12-05 22:40:18.0 -0600
+++ picp-0.6.7.new/main.c 2008-12-05 22:40:03.0 -0600
@@ -223,7 +223,7 @@
{
fprintf(stderr, exiting...\n);
ResetPICSTART();
- exit(0);
+ exit(1);
}
//-
@@ -3420,10 +3420,10 @@
fprintf(stderr, programmer\n\n);
fflush(stderr);
CloseDevice(serialDevice);
-exit(1);
+fail = true;
}
- if (DoInitPIC(picDevice)) // try to load up the parameters for this device
+ if (!fail DoInitPIC(picDevice)) // try to load up the parameters for this device
{
while (argc !fail) // do as long as we can read some more
{
@@ -3467,6 +3467,7 @@
}
fprintf(stderr, programmer does not support ISP programming\n);
+ fail = true;
}
else
ISPflag = true;
@@ -3499,32 +3500,49 @@
default:
fprintf(stderr, bad argument: '%s'\n, *(argv - 1)); // back up, show the trouble spot
+fail = true;
break;
}
}
}
}
- else // DoInitPIC failed
+ else if (!fail) // DoInitPIC failed
+ {
fprintf(stderr, failed to initialize %s\n, picDevice-name);
+fail = true;
+ }
}
else
+ {
fprintf(stderr, failed to obtain programmer firmware version number\n);
+ fail = true;
+ }
}
else
+ {
fprintf(stderr, failed to connect to programmer\n);
+ fail = true;
+ }
}
else
+{
fprintf(stderr, failed to set up the serial port\n);
+ fail = true;
+}
CloseDevice(serialDevice);
}
else
+ {
fprintf(stderr, failed to open device '%s'\n, deviceName);
+fail = true;
+ }
}
else
{
fprintf(stderr, unrecognized PIC device type: '%s'\n, picName); // don't know that one;
ShowDevices(); // give a helpful list of supported devices
+ fail = true;
}
}
else
Only in picp-0.6.7.new: main.c.~1~
Bug#503663: mp3info: '\0' in -p argument truncates output
Package: mp3info
Version: 0.8.5a-1
Severity: normal
If I run mp3info and specify a -p argument containing the octal escape
'\0', mp3info does not write the zero byte as part of its output,
and it does not write the rest of the output from the format. This
does not appear to be a documented limitation in the man page.
Example:
$ mp3info -p '%t\377%l\377' frungy-party.mp3 | hd
5a 6f 71 2d 46 6f 74 2d 50 69 6b 20 2d 20 46 72 |Zoq-Fot-Pik - Fr|
0010 75 6e 67 79 20 50 61 72 74 79 ff 54 68 65 20 55 |ungy Party.The U|
0020 72 2d 51 75 61 6e 20 4d 61 73 74 65 72 73 ff |r-Quan Masters.|
002f
$ mp3info -p '%t\0%l\0' frungy-party.mp3 | hd
5a 6f 71 2d 46 6f 74 2d 50 69 6b 20 2d 20 46 72 |Zoq-Fot-Pik - Fr|
0010 75 6e 67 79 20 50 61 72 74 79|ungy Party|
001a
--- Drake Wilson
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.27.1 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages mp3info depends on:
ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii libc6 2.7-15 GNU C Library: Shared libraries
ii libncurses5 5.6+20081011-1 shared libraries for terminal hand
mp3info recommends no packages.
mp3info suggests no packages.
-- debconf information:
mp3info/newmp3info:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398351: Draft patch to permit use of Meta instead of Alt
Attached is a draft patch that fixes this in my configuration; I don't
know whether it's good for everyone or not. One problem is that I
don't know whether earlier versions of SDL included the Meta modifier
or mapped it to Alt themselves, which I suspect may be the original
reason that this is now semi-broken for people who have only Meta
keysyms assigned.
--- Drake Wilson
--- sdl.c.orig 2008-01-06 13:38:42.0 -0600
+++ sdl.c 2008-08-06 08:53:32.0 -0500
@@ -40,7 +40,9 @@
static int gui_key_modifier_pressed;
static int gui_keysym;
static int gui_fullscreen_initial_grab;
-static int gui_grab_code = KMOD_LALT | KMOD_LCTRL;
+static int gui_grab_mods = KMOD_LALT | KMOD_LCTRL | KMOD_LMETA;
+static int gui_grab_req_all = KMOD_LCTRL; /* possibly modified on init */
+static int gui_grab_req_any = KMOD_LALT | KMOD_LMETA;
static uint8_t modifiers_state[256];
static int width, height;
static SDL_Cursor *sdl_cursor_normal;
@@ -303,20 +305,20 @@
buttons |= MOUSE_EVENT_MBUTTON;
if (kbd_mouse_is_absolute()) {
- if (!absolute_enabled) {
- sdl_hide_cursor();
- if (gui_grab) {
- sdl_grab_end();
- }
- absolute_enabled = 1;
- }
-
- SDL_GetMouseState(dx, dy);
- dx = dx * 0x7FFF / width;
- dy = dy * 0x7FFF / height;
+if (!absolute_enabled) {
+sdl_hide_cursor();
+if (gui_grab) {
+sdl_grab_end();
+}
+absolute_enabled = 1;
+}
+
+SDL_GetMouseState(dx, dy);
+dx = dx * 0x7FFF / width;
+dy = dy * 0x7FFF / height;
} else if (absolute_enabled) {
- sdl_show_cursor();
- absolute_enabled = 0;
+sdl_show_cursor();
+absolute_enabled = 0;
} else if (guest_cursor) {
SDL_GetMouseState(dx, dy);
dx -= guest_x;
@@ -363,13 +365,10 @@
case SDL_KEYDOWN:
case SDL_KEYUP:
if (ev-type == SDL_KEYDOWN) {
-if (!alt_grab) {
-mod_state = (SDL_GetModState() gui_grab_code) ==
-gui_grab_code;
-} else {
-mod_state = (SDL_GetModState() (gui_grab_code | KMOD_LSHIFT)) ==
-(gui_grab_code | KMOD_LSHIFT);
-}
+SDLMod sdl_mod_state = SDL_GetModState();
+mod_state = (((sdl_mod_state gui_grab_req_all) ==
+ gui_grab_req_all)
+ ((sdl_mod_state gui_grab_req_any) != 0));
gui_key_modifier_pressed = mod_state;
if (gui_key_modifier_pressed) {
int keycode;
@@ -430,12 +429,7 @@
}
}
} else if (ev-type == SDL_KEYUP) {
-if (!alt_grab) {
-mod_state = (ev-key.keysym.mod gui_grab_code);
-} else {
-mod_state = (ev-key.keysym.mod
- (gui_grab_code | KMOD_LSHIFT));
-}
+mod_state = (ev-key.keysym.mod gui_grab_mods);
if (!mod_state) {
if (gui_key_modifier_pressed) {
gui_key_modifier_pressed = 0;
@@ -468,7 +462,7 @@
case SDL_QUIT:
if (!no_quit) {
qemu_system_shutdown_request();
-vm_start(); /* In case we're paused */
+vm_start(); /* In case we're paused */
}
break;
case SDL_MOUSEMOTION:
@@ -630,6 +624,9 @@
SDL_EnableUNICODE(1);
gui_grab = 0;
+if (alt_grab)
+gui_grab_req_all |= KMOD_LSHIFT;
+
sdl_cursor_hidden = SDL_CreateCursor(data, data, 8, 1, 0, 0);
sdl_cursor_normal = SDL_GetCursor();
Bug#398351: Draft patch to permit use of Meta for SDL QEMU GUI
Hello, qemu-devel!
I use QEMU to run virtual machines on a Debian GNU/Linux machine with
AMD64 PC-class hardware. My X keyboard configuration uses Meta
instead of Alt; even though I have a PC-style keyboard whose keys are
labeled Alt, they are assigned to the Meta keysyms. I don't believe
this to be unusual. Unfortunately, it makes it impossible to release
QEMU input grabs, which is likely related to the Debian bug report at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398351 .
I've drafted a patch for QEMU's SDL interface to allow the use of
either Alt or Meta. This appears to work when applied against either
Debianized QEMU 0.9.1 or raw QEMU SVN trunk (r4988) on my machine.
There may be bogosities that I have not noticed, since although it is
a localized change, I have not extensively read the QEMU source code.
This patch is attached in unified diff format, applyable with -p0.
(For those of you reading from the Debian bug, this is slightly
different than my previous posting there, because I noticed that I had
created a few redundant whitespace-changes-only hunks by mistake,
which I have now removed.)
Comments are appreciated from any related source. Thanks for your
attention. :-)
--- Drake Wilson
--- sdl.c.orig 2008-01-06 13:38:42.0 -0600
+++ sdl.c 2008-08-06 08:53:32.0 -0500
@@ -40,7 +40,9 @@
static int gui_key_modifier_pressed;
static int gui_keysym;
static int gui_fullscreen_initial_grab;
-static int gui_grab_code = KMOD_LALT | KMOD_LCTRL;
+static int gui_grab_mods = KMOD_LALT | KMOD_LCTRL | KMOD_LMETA;
+static int gui_grab_req_all = KMOD_LCTRL; /* possibly modified on init */
+static int gui_grab_req_any = KMOD_LALT | KMOD_LMETA;
static uint8_t modifiers_state[256];
static int width, height;
static SDL_Cursor *sdl_cursor_normal;
@@ -363,13 +365,10 @@
case SDL_KEYDOWN:
case SDL_KEYUP:
if (ev-type == SDL_KEYDOWN) {
-if (!alt_grab) {
-mod_state = (SDL_GetModState() gui_grab_code) ==
-gui_grab_code;
-} else {
-mod_state = (SDL_GetModState() (gui_grab_code | KMOD_LSHIFT)) ==
-(gui_grab_code | KMOD_LSHIFT);
-}
+SDLMod sdl_mod_state = SDL_GetModState();
+mod_state = (((sdl_mod_state gui_grab_req_all) ==
+ gui_grab_req_all)
+ ((sdl_mod_state gui_grab_req_any) != 0));
gui_key_modifier_pressed = mod_state;
if (gui_key_modifier_pressed) {
int keycode;
@@ -430,12 +429,7 @@
}
}
} else if (ev-type == SDL_KEYUP) {
-if (!alt_grab) {
-mod_state = (ev-key.keysym.mod gui_grab_code);
-} else {
-mod_state = (ev-key.keysym.mod
- (gui_grab_code | KMOD_LSHIFT));
-}
+mod_state = (ev-key.keysym.mod gui_grab_mods);
if (!mod_state) {
if (gui_key_modifier_pressed) {
gui_key_modifier_pressed = 0;
@@ -630,6 +624,9 @@
SDL_EnableUNICODE(1);
gui_grab = 0;
+if (alt_grab)
+gui_grab_req_all |= KMOD_LSHIFT;
+
sdl_cursor_hidden = SDL_CreateCursor(data, data, 8, 1, 0, 0);
sdl_cursor_normal = SDL_GetCursor();
Bug#490253: Adding --quiet option to emacsclient
Hello, emacs-devel! In the Debian BTS wishlist ticket #490253, I requested a --quiet option for emacsclient; currently, it prints a Waiting for Emacs... message that cannot be turned off, which I found annoying. I have updated the patch I provided in that report to apply against the CVS version of Emacs; it would be nice if this feature could make it into Emacs 23. CVS-based unified diff is attached. Comments would be appreciated. --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493681: fakeroot: does not play well with pax
Package: fakeroot Version: 1.9.5 Severity: normal (Edited for clarity.) $ ls -l foo -rw--- 1 drake drake 0 2008-08-04 01:23 foo $ fakeroot ls -l foo -rw--- 1 root root 0 2008-08-04 01:23 foo $ fakeroot pax -w -x cpio foo foo.cpio; pax -v foo.cpio; cpio -tv foo.cpio -rw--- 1 drakedrake 0 en_GB.UTF-8 foo pax: cpio vol 1, 1 files, 5120 bytes read, 0 bytes written. -rw--- 1 1000 10000 Aug 4 01:23 foo 1 block $ sudo chown root:root foo $ sudo chmod a+r foo $ ls -l foo -rw-r--r-- 1 root root 0 2008-08-04 01:23 foo $ fakeroot ls -l foo -rw-r--r-- 1 root root 0 2008-08-04 01:23 foo $ pax -w -x cpio foo foo.cpio; pax -v foo.cpio; cpio -tv foo.cpio -rw-r--r-- 1 root root 0 en_GB.UTF-8 foo pax: cpio vol 1, 1 files, 5120 bytes read, 0 bytes written. -rw-r--r-- 1 00 0 Aug 4 01:23 foo 1 block $ fakeroot pax -w -x cpio foo foo.cpio; pax -v foo.cpio; cpio -tv foo.cpio -rw-r--r-- 1 root root 0 en_GB.UTF-8 foo pax: cpio vol 1, 1 files, 5120 bytes read, 0 bytes written. -rw-r--r-- 1 00 0 Aug 4 01:23 foo 1 block It would be nice to use fakeroot to create a pax archive where all the files are owned by root; using ls or most other manipulations on files owned by myself show them to be pseudo-owned by root, but pax doesn't see it and writes the archive with my UID in it. My immediate wild guess is that fakeroot is not handling fstat calls or somesuch, based on the output of strace (not shown here), but that's just a wild guess. --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fakeroot depends on: ii libc6 2.7-13 GNU C Library: Shared libraries fakeroot recommends no packages. fakeroot suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452128: Gallery 2 checks one level deep, not just top directory
Apparently Gallery is checking files inside the data directory as well to see whether they're both readable and writable just by opening the directory and iterating over the first N entries it sees. So this means that if you have anything else in the data directory that isn't writable by the webserver, your install breaks. Does Gallery inherently require itself to be able to create arbitrary filenames inside the data directory, or is this futureproofing, or is it arbitrary? Probably a question for upstream. --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490253: /usr/bin/emacsclient.emacs22: --quiet option for emacsclient would be nice
Quoth Sven Joachim [EMAIL PROTECTED], on 2008-07-23 09:21:52 +0200: I see that while gnuclient was silent on success, emacsclient prints a Waiting for Emacs... message. I realize this might be useful in some cases, but it seems irritating. I think the message should be printed by default to inform the user that it's time to switch to Emacs (it may not always be clear that the user is supposed to edit a file). extra-ignorable curiosity Is that really true in the common case? server-raise-frame defaults to t, and I would expect most people using emacsclient to be running X, which means that the behavior should be similar enough to invoking a separate X editor already: a window (Emacs frame) pops to the top of the stack with the file to edit, and there shouldn't need to be a separate notification on the terminal. Searching the Web for gnuclient should print message and the like turns up nothing, so either people didn't care that gnuclient was silent, or they didn't say anything about it. I suppose I can imagine running Emacs inside one part of a Screen session or something, but that seems comparatively uncommon. But I'm not really in touch with the Emacs user community, so I don't know. Anyway, it doesn't matter much so long as the message can be turned on and off (and really it doesn't matter _that_ much anyway---just a minor annoyance). /extra-ignorable curiosity A patch is attached to add a --quiet option. Thanks! Can you please send this upstream, i.e. to [EMAIL PROTECTED] I should probably make sure it applies against the upstream sources, then, right? I'll go look at the Savannah CVS access and try to submit a patch against the latest CVS version or so, probably. Thanks for the response. Kind regards, Sven --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459127: (no subject)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459127: Non-interactive installations with inexact reporting
Note that this might be less annoying if bug listings were exact. As it is, and as the apt-listbugs man page mentions: Note that apt-listbugs can't probe all the critical bug reports that really applies to the package of the version. This means that some bugs are listed because of a conservative reason even if the bugs don't actually apply to the version. You need to review the bug. This is fine for interactive use, and the requirement to add the bug to the ignore list first might be justifiable even for non-interactive use if only bugs marked in the BTS as present in the target version would stop the install. Unfortunately, the inexact matching makes the latter false, so it's quite easy for apt-listbugs to stop an update that _fixes_ a bug from being installed until you manually ignore the bug, which is not ideal. Just a thought. --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490277: rtorrent: IPv6 support would be nice
Package: rtorrent Version: 0.7.9-2+b1 Severity: wishlist Subject mostly says it all. :-) --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rtorrent depends on: ii libc-ares2 1.5.2-2 library for asyncronous name resol ii libc6 2.7-12GNU C Library: Shared libraries ii libcomerr2 1.40.8-2 common error description library ii libcurl3 7.18.1-1+b1 Multi-protocol file transfer libra ii libgcc11:4.3.1-2 GCC support library ii libidn11 1.8-1 GNU libidn library, implementation ii libkrb53 1.6.dfsg.3-2 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.9-1 OpenLDAP libraries ii libncursesw5 5.6+20080614-1Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++ ii libssh2-1 0.18-1SSH2 client-side library ii libssl0.9.80.9.8g-10.1 SSL shared libraries ii libstdc++6 4.3.1-2 The GNU Standard C++ Library v3 ii libtorrent10 0.11.9-1.1a C++ BitTorrent library ii libxmlrpc-c3 1.06.27-1 A lightweight RPC library based on ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime rtorrent recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490253: /usr/bin/emacsclient.emacs22: --quiet option for emacsclient would be nice
Package: emacs22-bin-common
Version: 22.2+2-2
Severity: wishlist
File: /usr/bin/emacsclient.emacs22
Tags: patch
I see that while gnuclient was silent on success, emacsclient prints a
Waiting for Emacs... message. I realize this might be useful in
some cases, but it seems irritating. A patch is attached to add a
--quiet option.
--- Drake Wilson
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages emacs22-bin-common depends on:
ii emacs22-common22.2+2-2 The GNU Emacs editor's shared, arc
ii libc6 2.7-12 GNU C Library: Shared libraries
ii liblockfile1 1.07-1 NFS-safe locking library, includes
emacs22-bin-common recommends no packages.
-- no debconf information
--- emacs22-22.2+2/lib-src/emacsclient.c 2008-01-10 06:15:30.0 -0600
+++ emacs22-new/lib-src/emacsclient.c 2008-07-10 18:34:17.0 -0500
@@ -121,6 +121,9 @@
/* Nonzero means don't wait for a response from Emacs. --no-wait. */
int nowait = 0;
+/* Nonzero means don't print messages for successful operations. --quiet. */
+int quiet = 0;
+
/* Nonzero means args are expressions to be evaluated. --eval. */
int eval = 0;
@@ -145,6 +148,7 @@
struct option longopts[] =
{
{ no-wait, no_argument, NULL, 'n' },
+ { quiet,no_argument, NULL, 'q' },
{ eval, no_argument, NULL, 'e' },
{ help, no_argument, NULL, 'H' },
{ version, no_argument, NULL, 'V' },
@@ -323,9 +327,9 @@
{
int opt = getopt_long (argc, argv,
#ifndef NO_SOCKETS_IN_FILE_SYSTEM
- VHnea:s:f:d:,
+ VHneqa:s:f:d:,
#else
- VHnea:f:d:,
+ VHneqa:f:d:,
#endif
longopts, 0);
@@ -361,6 +365,10 @@
nowait = 1;
break;
+ case 'q':
+ quiet = 1;
+ break;
+
case 'e':
eval = 1;
break;
@@ -396,6 +404,7 @@
-H, --help Print this usage information message\n\
-e, --eval Evaluate FILE arguments as Lisp expressions\n\
-n, --no-wait Don't wait for the server to return\n\
+-q, --quiet Don't display messages on success\n\
-d, --display=DISPLAY Visit the file in the given display\n
#ifndef NO_SOCKETS_IN_FILE_SYSTEM
-s, --socket-name=FILENAME\n\
@@ -769,9 +778,9 @@
if (! get_server_config (server, auth_string))
return INVALID_SOCKET;
- if (server.sin_addr.s_addr != inet_addr (127.0.0.1))
+ if (server.sin_addr.s_addr != inet_addr (127.0.0.1) !quiet)
message (FALSE, %s: connected to remote socket at %s\n,
- progname, inet_ntoa (server.sin_addr));
+ progname, inet_ntoa (server.sin_addr));
/*
* Open up an AF_INET socket
@@ -1170,7 +1179,7 @@
/* Maybe wait for an answer. */
if (!nowait)
{
- if (!eval)
+ if (!eval !quiet)
{
printf (Waiting for Emacs...);
needlf = 2;
--- emacs22-22.2+2/etc/emacsclient.1 2006-11-22 10:37:23.0 -0600
+++ emacs22-new/etc/emacsclient.1 2008-07-10 17:20:45.0 -0500
@@ -52,6 +52,9 @@
returns
immediately without waiting for you to finish the buffer in Emacs.
.TP
+.B \-q, \-\-quiet
+do not display messages for successful editing operations.
+.TP
.B \-e, \-\-eval
do not visit files but instead evaluate the arguments as Emacs
Lisp expressions.
Bug#489978: g15daemon: fails to reacquire keyboard when disconnected and reconnected
Package: g15daemon Version: 1.9.5.3-3 Severity: normal My G11 keyboard seems to be flaking somewhat. This results in unpredictable USB disconnects, followed by near-immediate reconnects on the same port. When this happens, the g15daemon fails to reacquire the keyboard, and the G keys fail to map properly until I restart it. The following log messages are produced: kernel: usb 2-2: USB disconnect, address 102 kernel: usb 2-2.1: USB disconnect, address 103 kernel: usb 2-2.4: USB disconnect, address 104 g15daemon[27604]: Keyboard has gone.. Retrying kernel: usb 2-2: new full speed USB device using ohci_hcd and address 105 kernel: usb 2-2: configuration #1 chosen from 1 choice kernel: hub 2-2:1.0: USB hub found kernel: hub 2-2:1.0: 4 ports detected kernel: usb 2-2.1: new low speed USB device using ohci_hcd and address 106 kernel: usb 2-2.1: configuration #1 chosen from 1 choice kernel: input: Gaming Keyboard as /class/input/input550 kernel: input,hidraw1: USB HID v1.10 Keyboard [Gaming Keyboard] on usb-:00:02.0-2.1 kernel: input: Gaming Keyboard as /class/input/input551 kernel: input,hiddev96,hidraw2: USB HID v1.10 Device [Gaming Keyboard] on usb-:00:02.0-2.1 kernel: usb 2-2.4: new full speed USB device using ohci_hcd and address 107 kernel: usb 2-2.4: configuration #1 chosen from 1 choice kernel: input: G11 Keyboard as /class/input/input552 kernel: input,hiddev97,hidraw3: USB HID v1.11 Keypad [G11 Keyboard] on usb-:00:02.0-2.4 g15daemon[27604]: Keyboard has gone.. Retrying kernel: usb 2-2.4: usbfs: process 27606 (g15daemon) did not claim interface 0 before use kernel: usb 2-2.4: usbfs: process 27606 (g15daemon) did not claim interface 0 before use kernel: usb 2-2.4: usbfs: process 27605 (g15daemon) did not claim interface 0 before use kernel: usb 2-2.4: usbfs: process 27604 (g15daemon) did not claim interface 0 before use The last message is repeated indefinitely until I restart the g15daemon, creating semi-infinite logspam. (If I'm viewing the system console at the time, it overpowers just about anything else on the screen, even, though that's not such a big deal because I'm usually in X and it's possible to turn it off anyway.) Anyway, it'd be nice if the G keys worked after the keyboard reconnected. :-) --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages g15daemon depends on: ii libc6 2.7-12GNU C Library: Shared libraries ii libfreetype6 2.3.5-1+b1FreeType 2 font engine, shared lib ii libg15-1 1.2.6-1 Library for interfacing with the L ii libg15daemon-client1 1.9.5.3-3 Development packages for libg15dae ii libg15render1 1.2.0.svn250-2Library for interfacing with the L ii libusb-0.1-4 2:0.1.12-11 userspace USB programming library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages g15daemon recommends: ii xkb-data 1.3-1 X Keyboard Extension (XKB) configu -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489647: xmms2: Musepack decoder and vocoder effect refuse to talk to each other
Package: xmms2 Version: 0.4DrKosmos-4 Severity: normal From [xmms2 config_list], slightly resorted: vocoder.enabled = 1 vocoder.pitch = 100.0 vocoder.speed = 100.0 vocoder.attack_detection = 0 effect.order.0 = vocoder effect.order.1 = When I play PCM, MPEG, or Vorbis audio, I can control the vocoder effect by changing the vocoder.pitch and vocoder.speed settings; when I play Musepack audio, the vocoder effect does not appear to be applied. A quick scan of the plugin source reveals that the Musepack decoder is outputting floating-point PCM, whereas the other decoders are likely outputting signed 16-bit integer PCM. The vocoder appears to register itself as only accepting signed 16-bit integer PCM; my semi-educated guess is that this is why the effect isn't functioning in that case. I don't know whether this is considered a bug in the vocoder plugin, in the Musepack plugin, or in some central xform chaining that (silently?) fails to recognize that a numeric format conversion before the effects chain to make it resolve, so I'm assigning this to xmms2 and letting the xmms2 maintainer decide where it goes from there. --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xmms2 depends on: ii xmms2-client-cli0.4DrKosmos-4+b2 XMMS2 - cli client ii xmms2-core 0.4DrKosmos-4+b2 XMMS2 - core package ii xmms2-plugin-alsa 0.4DrKosmos-4+b2 XMMS2 - ALSA output ii xmms2-plugin-id3v2 0.4DrKosmos-4+b2 XMMS2 - ID3v2 plugin ii xmms2-plugin-mad0.4DrKosmos-4+b2 XMMS2 - libmad based mp3 decoder ii xmms2-plugin-vorbis 0.4DrKosmos-4+b2 XMMS2 - vorbis decoder xmms2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487317: perl-modules: File::Path::rmtree sets symlink target permissions to 0777
Quoth Russ Allbery [EMAIL PROTECTED], on 2008-06-21 09:29:33 -0700:
There's an lchmod function that avoids this behavior, but I'm not sure
that Perl provides an interface to it without a new XS module. (It's not
portable to all systems, but it is available on Linux.)
I'm basically familiar with lchmod, but is it really available on this
platform? It doesn't seem to be. With Debian GNU/Linux unstable on
AMD64 with Linux 2.6.24.2 and GCC 4.3.1 20080523 (prerelease) (Debian
4.3.0-5), I get the following results (newlines added for clarity):
$ ln -s /dev/null foo
$ ls -l foo
lrwxrwxrwx 1 drake drake 9 2008-06-21 12:27 foo - /dev/null
$ man 2 lchmod
No manual entry for lchmod in section 2
$ man 3 lchmod
No manual entry for lchmod in section 3
$ cat lchmod.c
main() { lchmod(foo, 0700); }
$ gcc -o lchmod lchmod.c
/tmp/cc478IUh.o: In function `main':
lchmod.c:(.text+0x18): warning: warning: lchmod is not implemented and will
always fail
$ ./lchmod
$ ls -l foo
lrwxrwxrwx 1 drake drake 9 2008-06-21 12:27 foo - /dev/null
$ gcc -static -o lchmod lchmod.c
/tmp/ccqjaRGU.o: In function `main':
lchmod.c:(.text+0x18): warning: warning: lchmod is not implemented and will
always fail
$ strace ./lchmod
execve(./lchmod, [./lchmod], [/* 40 vars */]) = 0
uname({sys=Linux, node=drache, ...}) = 0
brk(0) = 0x68b000
brk(0x68bf10) = 0x68bf10
arch_prctl(ARCH_SET_FS, 0x68b850) = 0
brk(0x6acf10) = 0x6acf10
brk(0x6ad000) = 0x6ad000
exit_group(-1) = ?
Process 16730 detached
--- Drake Wilson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487317: perl-modules: File::Path::rmtree sets symlink target permissions to 0777
Quoth Ben Hutchings [EMAIL PROTECTED], on 2008-06-20 23:36:51 +0100:
debsums is doing it:
[strace elided]
It looks like it's unpacking the archive under /tmp, generating
checksums, then deleting the files as it goes. Before unlinking it uses
chmod, presumably to ensure the unlink will succeed. But chmod follows
sym-links, and these sym-links are absolute so it chmods the installed
files!
...and a little investigation shows debsums is just using File::Path::rmtree.
The rmtree implementation actually tries to avoid this, but does it
wrong: it _reads_ the permissions from the symbolic link, then
_applies_ changed permissions through chmod, which affects the target
instead.
It looks like this bug isn't as severe in perl-modules 5.8.8-12. The
relevant lines of code appear to be:
From perl-modules 5.8.8-12 /usr/share/perl/5.8.8/File/Path.pm:
|chmod $rp | 0600, $root
| or carp Can't make file $root writeable: $!
|if $force_writeable;
From perl-modules 5.10.0-10 /usr/share/perl/5.10.0/File/Path.pm:
|my $nperm = $perm 0 | 0600;
|if ($nperm != $perm and not chmod $nperm, $root) {
|if ($Force_Writeable) {
|_error($arg, cannot make file writeable, $canon);
|}
|}
As can be seen above, the version from 5.8.8-12 only does the
erroneous chmod if $force_writeable is turned on, whereas the version
from 5.10.0-10 does the erroneous chmod in all cases where the target
is a symbolic link.
FWIW, I have a live report of this affecting more than terminfo on my
machine, drache (as a partial confirmation of the analysis):
-rwxrwxrwx 1 root root 194924 2008-06-01 06:44
/emul/ia32-linux/lib/libncurses.so.5.6
-rwxrwxrwx 1 root root69560 2008-06-01 06:44
/emul/ia32-linux/lib/libtic.so.5.6
-rwxrwxrwx 1 root root 248288 2008-05-06 07:33 /lib/libncurses.so.5.6
-rwxrwxrwx 1 root root74128 2008-05-06 07:33 /lib/libtic.so.5.6
The other servers I coadminister don't seem to be affected, presumably
because they don't have the new perl-modules.
Possibly it would be a good idea to tell people to run something
similar to [find roots of real filesystems -xdev -not -type l -perm
/o=w] to find files that may have been affected by this if they had a
buggy version of perl-modules installed. Possibly an automated check
for bad permissions on files that exist in Debian packages would be
another improvement (I searched the Web for an existing program that
does that, but didn't find anything).
--- Drake Wilson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486226: ocaml-mode: caml-mode bogusly binds C-c letter combinations
Package: ocaml-mode Version: 3.10.2-3 Severity: normal From the node Coding Conventions from edition 2.9 of the GNU Emacs Lisp Reference Manual, corresponding to GNU Emacs version 22.2: * Please do not define `C-c LETTER' as a key in Lisp programs. Sequences consisting of `C-c' and a letter (either upper or lower case) are reserved for users; they are the *only* sequences reserved for users, so do not block them. Changing all the Emacs major modes to respect this convention was a lot of work; abandoning this convention would make that work go to waste, and inconvenience users. Please comply with it. However, caml-mode defines several C-c letter sequences, including the letters (b f i l m t w). In fact, it appears to try to bind C-c i twice: once as ocaml-add-path on line 303 of caml.el, and once as caml-insert-if-form on line 311, with the latter taking precedence. I have inserted code into my .emacs to work around this by destroying all the errant C-c letter bindings, but Caml mode should be changed to avoid using these. Perhaps a transition period would be necessary so that existing users of those keybindings have time to get used to using different ones, or to set a customize option to enable the old keybindings. I am willing to fix this myself iff it will result in caml-mode no longer binding C-c letter sequences by default. --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ocaml-mode depends on: ii emacs22 [emacsen] 22.2+2-2 The GNU Emacs editor ocaml-mode recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481480: Reproducible here; recommend severity grave
This is reproducible on my system with python-gtk2 2.12.1-3. System information and package versions from reportbug are included below. I recommend upgrading this bug to severity grave. Rationale: makes many programs unusable when run from the command line. For instance, all of the following programs that use python-gtk2 hang on startup when run from an xterm unless their stdin is specifically redirected from /dev/null: driconf gajim gnome-about glchess --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-gtk2 depends on: ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libc6 2.7-11 GNU C Library: Shared libraries ii libcairo2 1.6.4-2The Cairo 2D vector graphics libra ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libgtk2.0-0 2.12.9-4 The GTK+ graphical user interface ii libpango1.0-0 1.20.2-2 Layout and rendering of internatio ii python2.5.2-1An interactive high-level object-o ii python-cairo [python2.5-cairo 1.4.12-1 Python bindings for the Cairo vect ii python-gobject [python2.5-gob 2.14.1-6 Python bindings for the GObject li ii python-numeric [python2.5-num 24.2-8.2 Numerical (matrix-oriented) Mathem ii python-support0.8.1 automated rebuilding support for P pn python2.4-cairo none (no description available) pn python2.4-gobject none (no description available) pn python2.4-numeric none (no description available) python-gtk2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398351: Alt versus Meta confusion
Does the use of Ctrl+Alt in the QEMU documentation refer to Alt in the PC keyboard sense or Alt in the X sense? Often Alt will be mentioned to users because that's what's on PC keyboards nowadays, even though it's commonly assigned to the X keysym Meta. I have this configuration: $ xmodmap xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Meta_L (0x40), Meta_R (0x71) mod2Num_Lock (0x4d) mod3 mod4Super_L (0x73), Super_R (0x74) mod5 and my Alt-labeled keys produce Meta_L and Meta_R; QEMU doesn't respond to Ctrl+Meta. Is this really such a strange configuration that it should be impossible to release a QEMU mouse grab with this keyboard layout? I would propose that QEMU accept Meta everywhere it currently accepts Alt, as a wishlist item, but _particularly_ for the grab release because there's otherwise no way to get input to other X windows without making QEMU go away first. (Or, of course, ideally that the keymaps be arbitrarily configurable, but that's harder, so I'm not holding my breath.) --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478005: findutils: description of -perm /mode in man page fails to take into account functionality change
Package: findutils Version: 4.4.0-2 Severity: minor From find(1), regarding the -perm /mode option: If no permission bits in mode are set, this test currently matches no files. However, it will soon be changed to match any file (the idea is to be more consistent with the behaviour of -perm -000). That doesn't seem to be true anymore; the change has already been made. I believe https://savannah.gnu.org/bugs/index.php?14748 has information regarding that. The man page doesn't seem to have been updated. (Never mind that this behavior is not, in fact, more consistent from a mathematical perspective. But oh well.) --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages findutils depends on: ii libc6 2.7-10 GNU C Library: Shared libraries findutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475138: WINE dependency on CUPS blocks LPRng
Package: libwine-print Version: 0.9.60-2 Severity: wishlist The dependency graph in unstable, as far as I can tell, includes the following: wine (0.9.60-3) Depends: libwine-print (= 0.9.60-3) libwine-print (0.9.60-3) Depends: cupsys-bsd cupsys-bsd (1.3.7-5) Conflicts: lprng Transitively, therefore: wine (0.9.60-3) Conflicts: lprng (This also applies to libwine-print 0.9.60-2, which is the version that added the dependency in the first place.) This means it's impossible to upgrade the WINE package to the newest unstable on a system that uses LPRng. This is kind of suboptimal. Suppose I'm using WINE to run specific trusted programs which happen to be easiest to acquire as Windows binaries, and none of them make any use of printer functionality; I see no reason, then, that I should be prevented from installing whatever print spooler I prefer. --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477305: man-db: -f option destroys process return code of whatis
Package: man-db Version: 2.5.1-3 Severity: minor From the man page for man: -f, --whatis Equivalent to whatis. Display a short description from the manual page, if available. See whatis(1) for details. From the man page for whatis: EXIT STATUS 0Successful program execution. 1Usage, syntax or configuration file error. 2Operational error. 16 No manual pages were found that matched the criteria specified. However, man -f does not use the exit status of whatis; instead, it always returns a zero exit status: $ whatis man; echo $? man (7) - macros to format man pages man (1) - an interface to the on-line reference manuals 0 $ man -f man; echo $? man (7) - macros to format man pages man (1) - an interface to the on-line reference manuals 0 $ whatis foobar; echo $? foobar: nothing appropriate. 16 $ man -f foobar; echo $? foobar: nothing appropriate. 0 The output of [man -f --debug foobar] is attached per the bug-reporting note (but I expect this is a simple case of not propagating the return code). --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages man-db depends on: ii bsdmainutils 6.1.10collection of more utilities from ii debconf [debconf-2.0] 1.5.20Debian configuration management sy ii dpkg 1.14.18 package maintenance system for Deb ii groff-base 1.18.1.1-20 GNU troff text-formatting system ( ii libc6 2.7-10GNU C Library: Shared libraries ii libgdbm3 1.8.3-3 GNU dbm database routines (runtime ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime man-db recommends no packages. -- debconf information: man-db/build-database: true man-db/rebuild-database: true man-db/install-setuid: false ruid=1000, euid=1000 ++priv_drop_count = 1 From the config file /etc/manpath.config: Mandatory mandir `/usr/man'. Mandatory mandir `/usr/share/man'. Mandatory mandir `/usr/local/man'. Path `/bin' mapped to mandir `/usr/share/man'. Path `/usr/bin' mapped to mandir `/usr/share/man'. Path `/sbin' mapped to mandir `/usr/share/man'. Path `/usr/sbin' mapped to mandir `/usr/share/man'. Path `/usr/local/bin' mapped to mandir `/usr/local/man'. Path `/usr/local/bin' mapped to mandir `/usr/local/share/man'. Path `/usr/local/sbin' mapped to mandir `/usr/local/man'. Path `/usr/local/sbin' mapped to mandir `/usr/local/share/man'. Path `/usr/X11R6/bin' mapped to mandir `/usr/X11R6/man'. Path `/usr/bin/X11' mapped to mandir `/usr/X11R6/man'. Path `/usr/games' mapped to mandir `/usr/share/man'. Path `/opt/bin' mapped to mandir `/opt/man'. Path `/opt/sbin' mapped to mandir `/opt/man'. Global mandir `/usr/man', catdir `/var/cache/man/fsstnd'. Global mandir `/usr/share/man', catdir `/var/cache/man'. Global mandir `/usr/local/man', catdir `/var/cache/man/oldlocal'. Global mandir `/usr/local/share/man', catdir `/var/cache/man/local'. Global mandir `/usr/X11R6/man', catdir `/var/cache/man/X11R6'. Global mandir `/opt/man', catdir `/var/cache/man/opt'. Added section `1'. Added section `n'. Added section `l'. Added section `8'. Added section `3'. Added section `2'. Added section `3posix'. Added section `3pm'. Added section `3perl'. Added section `5'. Added section `4'. Added section `9'. Added section `6'. Added section `7'. `/usr/man' `' `1' `/usr/share/man'`' `1' `/usr/local/man'`' `1' `/bin' `/usr/share/man'`0' `/usr/bin' `/usr/share/man'`0' `/sbin' `/usr/share/man'`0' `/usr/sbin' `/usr/share/man'`0' `/usr/local/bin'`/usr/local/man'`0' `/usr/local/bin'`/usr/local/share/man' `0' `/usr/local/sbin' `/usr/local/man'`0' `/usr/local/sbin' `/usr/local/share/man' `0' `/usr/X11R6/bin'`/usr/X11R6/man'`0' `/usr/bin/X11' `/usr/X11R6/man'`0' `/usr/games'`/usr/share/man'`0' `/opt/bin' `/opt/man' `0' `/opt/sbin' `/opt/man' `0' `/usr/man' `/var/cache/man/fsstnd' `-1' `/usr/share/man'`/var/cache/man'`-1' `/usr/local/man'`/var/cache/man/oldlocal' `-1' `/usr/local/share/man' `/var/cache/man/local' `-1' `/usr/X11R6/man'`/var/cache/man/X11R6' `-1' `/opt/man' `/var/cache/man/opt'`-1' `1' `' `-5' `n' `' `-5' `l' `' `-5' `8' `' `-5' `3' `' `-5' `2' `' `-5' `3posix'`' `-5' `3pm' `' `-5' `3perl' `' `-5' `5' `' `-5
Bug#476622: spambayes: postinst fails on Python 2.5
Package: spambayes Version: 1.0.4-4 Severity: normal (Submitting a new report even though this is related to #476274, because since the program now runs, it's probably not grave anymore, and it's somewhat a separate issue.) When I try to install the spambayes 1.0.4-4 package using Aptitude, it now correctly tries to compile the spambayes code for Python 2.5, but gives me an error similar to that reported by Drew Hess in #476274: Setting up spambayes (1.0.4-4) ... Compiling /usr/lib/python2.5/site-packages/spambayes/Corpus.py ... File /usr/lib/python2.5/site-packages/spambayes/Corpus.py, line 82 from __future__ import generators SyntaxError: from __future__ imports must occur at the beginning of the file Compiling /usr/lib/python2.5/site-packages/spambayes/FileCorpus.py ... File /usr/lib/python2.5/site-packages/spambayes/FileCorpus.py, line 85 from __future__ import generators SyntaxError: from __future__ imports must occur at the beginning of the file Compiling /usr/lib/python2.5/site-packages/spambayes/message.py ... File /usr/lib/python2.5/site-packages/spambayes/message.py, line 78 from __future__ import generators SyntaxError: from __future__ imports must occur at the beginning of the file pycentral: pycentral pkginstall: error byte-compiling files (49) pycentral pkginstall: error byte-compiling files (49) dpkg: error processing spambayes (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: spambayes E: Sub-process /usr/bin/dpkg returned an error code (1) My wild guess is that the debian/patches/fix_import_future.dpatch stuff that Drew Hess mentioned re the Ubuntu version might not have been included in this version of the Debian package. When I run sb_filter.py, it seems to function, despite postinst failing. I don't know for sure whether it's actually working or just pretending to work. --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages spambayes depends on: ii python2.5.2-0.1 An interactive high-level object-o ii python-central0.6.2 register and build utility for Pyt spambayes recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476274: spambayes: seems to break completely after Python transition
Package: spambayes Version: 1.0.4-3 Severity: grave Justification: renders package unusable (This has caused data loss for me, but it wasn't purely spambayes's fault; my local MDA scripting wasn't as robust as it should have been.) SpamBayes appears to refuse to run at all with the newly-upgraded Python. I gather it only installs itself into the Python 2.4 directories... ? $ /usr/bin/sb_filter.py Traceback (most recent call last): File /usr/bin/sb_filter.py, line 80, in module from spambayes import hammie, Options, mboxutils, storage ImportError: No module named spambayes --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages spambayes depends on: ii python2.5.2-0.1 An interactive high-level object-o ii python-central0.6.2 register and build utility for Pyt spambayes recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476134: glade: crash when setting name of separator menu item
Package: glade Version: 3.4.3-1 Severity: normal Steps to reproduce: 1. Start Glade. 2. Add a toplevel window. Add a menu bar inside the toplevel window. 3. Activate the context menu of the menu bar (with the right mouse button); select Edit An edit dialog appears for the menu bar. 4. Select any item within one of the menus in the tree to serve as a sibling item. (I selected the gtk-save item.) 5. Press Add. A new menu item appears and is selected. 6. In the edit pane for the menu item, select the Separator type. 7. Enter any new name for the menu item inside the Name entry, then use Tab to move focus away from the entry box. Segmentation fault. I assume that's not supposed to happen. :-) --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages glade depends on: ii libc6 2.7-9 GNU C Library: Shared libraries ii libgladeui-1-73.4.3-1GTK+ User Interface Build core lib ii libglib2.0-0 2.16.1-1 The GLib library of C routines ii libgtk2.0-0 2.12.9-2 The GTK+ graphical user interface Versions of packages glade recommends: ii devhelp 0.19-1 A GNOME developers help program ii libglade2-dev 1:2.6.2-1 development files for libglade ii libgtk2.0-dev 2.12.9-2 Development files for the GTK+ lib -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476210: xbat: game elements do not display properly
Package: xbat Version: 1.11-11 Severity: important When I start xbat, the title screen comes up normally (at least for a while). When I press 's' to start the game, it appears to switch to a running game screen, but the main view only shows a scrolling landscape; none of the other gameplay elements appear, including ships and bullets. The score does not ever seem to increase, though occasionally a life will be lost and the landscape will reset to an earlier position, seeming to indicate that the gameplay logic is at least somewhat running underneath. In the upper left corner, also, various sprites for buildings seem to display on top of each other without any obvious pattern. --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xbat depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar xbat recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476211: xbat: title screen freezes after a certain point
Package: xbat Version: 1.11-11 Severity: important When starting xbat, the title screen's landscape scroll is very fast. When the scrolling reaches a certain point (right after a river scrolls in from the top), the entire process freezes and ceases to draw its display or respond to keystrokes. --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xbat depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar xbat recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476212: tomatoes: does not start
Package: tomatoes Version: 1.55-3 Severity: important (Newlines added for visual clarity.) (~)$ tomatoes Error appeared: - Unable to load config file: ./config.cfg! (~)$ cd /etc/tomatoes (/etc/tomatoes)$ ls -l total 4 -rw-r--r-- 1 root root 315 2004-09-27 04:47 config.cfg (/etc/tomatoes)$ tomatoes Error appeared: - Unable to open 'tomatoes.mpk'. The file either doesn't exist or is corrupted. (/etc/tomatoes)$ cd /usr/share/tomatoes/ (/usr/share/tomatoes)$ ls -l total 9392 drwxr-xr-x 2 root root4096 2007-10-20 07:19 music -rw-r--r-- 1 root root 9594508 2004-09-27 04:45 tomatoes.mpk (/usr/share/tomatoes)$ tomatoes Error appeared: - Unable to load config file: ./config.cfg! (/usr/share/tomatoes)$ It seems to always want its configuration file and its data file to be in the current directory. Copying both sets of files into a new directory and running the game from there seems to work, but it should be looking for its files in the correct locations. (Also, /usr/share/tomatoes should probably be moved to /usr/share/games/tomatoes, FWIW.) --- Drake Wilson -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tomatoes depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-3 GCC support library ii libgl1-mesa-glx [libgl1] 7.0.3-1A free implementation of the OpenG ii libglu1-mesa [libglu1]7.0.3-1The OpenGL utility library (GLU) ii libsdl-image1.2 1.2.6-3image loading library for Simple D ii libsdl-mixer1.2 1.2.8-3mixer library for Simple DirectMed ii libsdl1.2debian 1.2.13-2 Simple DirectMedia Layer ii libstdc++64.3.0-3The GNU Standard C++ Library v3 ii tomatoes-data 1.55-3 I Have No Tomatoes - tomato smashi tomatoes recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474961: Fixed in CVS, I guess
Quoth Pascal Giard [EMAIL PROTECTED], on 2008-04-08 08:15:19 -0400: Indeed this is fixed in upstream CVS. Unless i'm mistaken, 14.1.0 is planned for release soon. (Where did you get that information, out of curiosity? I didn't see it on upstream's website anywhere, or in the mailing list archives, but maybe I wasn't searching very well.) Would you rather have a patched debian version in-between? No hurry; I didn't originally know it had been fixed upstream until I did the secondary research, that's all. If it takes them a long time to release a fix, then it might be nice to have an intermediary package, but I can always do local patches on my own, too, so it's not a big deal. -Pascal --- Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474961: sox: repeats fragment of audio at end of ALSA playback
Package: sox
Version: 14.0.1-2
Severity: normal
I am using sox to play audio files through a Sound Blaster Live!
sound card, through ALSA. When I play a file, either using the play
wrapper or using the sox command directly, the audio plays back
correctly, but after the file is finished, a short fragment of audio
from earlier in the file is erroneously played again (perhaps 50
milliseconds of audio or so).
Multiple types of audio files have been tried, to no effect: a 11025
Hz mono Ogg Vorbis file, 48000 Hz mono and stereo WAVE files, and
44100 Hz stereo MPEG-3 all exhibit the problem, so it doesn't seem to
have anything to do with the decoding or resampling process. (48000
Hz stereo is the native format of this sound card, I believe.)
Here's the relevant part of my .asoundrc:
pcm.!default {
type plug
slave.pcm sblive
}
pcm.sblive {
type hw
card 1
}
The easiest demonstration is to generate a rising sine wave using the
sox synth command:
$ sox -n -r 48000 -c 2 sine.wav synth 3 sine 440-880
Using the resulting file, if I run any of the following:
$ play sine.wav
$ sox sine.wav -t alsa default
$ sox sine.wav -t alsa hw:1
then I can clearly hear the rising sine wave, followed by an erroneous
blip of tone from earlier in the file. The use of plug versus hw
makes no noticeable difference. If I run any of:
$ sox sine.wav -t ossdsp /dev/dsp1
$ aplay sine.wav
$ aplay -Ddefault sine.wav
$ aplay -Dhw:1 sine.wav
then the playback is correct.
Interestingly, if I generate (or even play) the sine file at a lower
sampling rate, the blip seems to come from earlier, indicating that
it's probably offset from the end in samples. Based on that, I'm
imagining a ring buffer being overrun by one chunk and reading a chunk
of data N chunks from the end one more time.
Thanks for your attention.
--- Drake Wilson
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages sox depends on:
ii libc6 2.7-9 GNU C Library: Shared libraries
ii libltdl3 1.5.26-1 A system independent dlopen wrappe
ii libsamplerate00.1.2-5audio rate conversion library
ii libsox-fmt-alsa 14.0.1-2 SoX alsa format I/O library
ii libsox-fmt-ao 14.0.1-2 SoX Libao format I/O library
ii libsox-fmt-base 14.0.1-2 Minimal set of SoX format librarie
ii libsox-fmt-oss14.0.1-2 SoX OSS format I/O library
ii libsox0 14.0.1-2 SoX library
sox recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474961: Fixed in CVS, I guess
(I should append a warning to my previous message: the synth command I
gave will generate a _full scale_ rising sine wave. Be cautious with
your volume controls.)
From line 652 of src/alsa.c:
while (0 frames_of_silence 0) {
...
}
Deleting the 0 makes it fill the remainder of the last period
with silence, which makes playback work without the glitch at the end.
I don't know whether that breaks anything else.
Upon further investigation, that change is similar to a change made in
revision 1.97 of src/alsa.c in upstream CVS. Then revision 1.99
changed the code to use a different method of zeroing out the
remaining frames. See
http://sox.cvs.sourceforge.net/sox/sox/src/alsa.c?revision=1.99view=markup
. Both of these are after the last official upstream release: the
revisions in the repo were on 2008-02-20 and 2008-03-05 according to
the CVS browser, and the release of 14.0.1 was on 2008-01-29 according
to the SourceForge project page.
--- Drake Wilson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
