Bug#833182: Info received (ditto, but different resolution)
It should be noted that the general issue involving needing to use libpam-systemd or xserver-xorg-legacy but the errors being vague already has a separate bug report at #890749. The aspects of this bug regarding the Intel video driver remain relevant, though. -- 2. That which causes joy or happiness.
Bug#801401: splitting off distinct issues
retitle 801401 with systemd, cannot start X from the console command line using xinit, only startx clone 801401 -1 severity 801401 normal retitle -1 using startx requires either libpam-systemd or xserver-xorg-legacy submitter -1 James Richardson thanks I just happened to find this bug report after researching #833182... it looks like it had a very generic title, and all sorts of issues got tacked on - but Giuseppe Bilotta's original issue came down to startx vs. xinit, so that should be the title there. The complaints about needing to either use libpam-systemd or xserver-xorg-legacy should be split to a separate bug report. These were first articulated by James Richardson, so I'm resetting submitter. -- 2. That which causes joy or happiness.
Bug#833182: ditto, but different resolution
Hi, I observed something very similar this after a jessie -> stretch dist-upgrade. My whole failing logfile is attached, and the gist of the problem was in these errors: [...] [ 5115.028] (EE) systemd-logind: failed to get session: PID 4398 does not belong to any known session [...] [ 5116.097] (EE) modeset(0): drmSetMaster failed: Permission denied [ 5116.097] (EE) [ 5116.097] (EE) AddScreen/ScreenInit failed for driver 0 [...] The first error appeared to be the root cause - it was caused by not reading through https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#x-no-longer-requires-root where it said that the new way needs libpam-systemd Nothing had installed that package in my dist-upgrade, probably because I didn't choose to observe Recommends. After installing that and rebooting, everything was fine and Xorg runs as my own user, yay. I'll also note here that my first searches for the latter error message had produced a workaround - installing xserver-xorg-legacy and setting needs_root_rights=yes in Xwrapper.config. But that result is obviously inferior. It would be much better if the Xorg modesetting error messages were somewhat clearer as to what actually went wrong. It looks like the defaults excluded the intel driver as such: [ 5115.616] (==) Matched nouveau as autoconfigured driver 0 [ 5115.616] (==) Matched nv as autoconfigured driver 1 [ 5115.616] (==) Matched modesetting as autoconfigured driver 2 [ 5115.616] (==) Matched fbdev as autoconfigured driver 3 [ 5115.616] (==) Matched vesa as autoconfigured driver 4 When it worked, driver 2 actually seems to have reported: [20.775] (II) modeset(0): [DRI2] Setup complete [20.775] (II) modeset(0): [DRI2] DRI driver: i965 [20.775] (II) modeset(0): [DRI2] VDPAU driver: i965 This is counterintuitive given that I have xserver-xorg-video-intel installed. If the intel driver is installed, that should provide at least some sort of a hint to the Xorg server on runtime. Maybe to include it in the list of defaults? I don't have several of the above drivers installed and these particular wrong defaults merely lead to more redundant error output... If not that, then perhaps the modesetting driver should tell the user that it tried to take command over these drivers, but that perhaps its failure should not be completely fatal? Arguably the situation is made complex by the fact that these laptops have two GPUs, the Intel and the Nvidia one, and so both the users and the software are more likely to be confused by default. -- 2. That which causes joy or happiness. Xorg.0.log.old Description: application/trash
Bug#856351: ditto from screen
Hi, I saw this error message when I accidentally ran startx on tty1 from a screen(1) session. For some reason, there's a root-owned /dev/tty0 on the machine. Should there be one? I certainly don't seem to see it - I have six VTs set up, and e.g. /dev/tty1 where I'm running that startx is owned by my user. The only non-comment content of Xwrapper.config is "allowed_users=console" man Xwrapper.config fails to run, oddly enough -- 2. That which causes joy or happiness.
Bug#748944: [Pkg-xfce-devel] Processed: Re: Processed (with 1 errors): on how lightdm does not like it when /etc/X11/Xsession is not executable
reopen 748944 thanks On Fri, Jul 24, 2015 at 10:55:12PM +0200, Julien Cristau wrote: > On Thu, Jul 23, 2015 at 10:06:42 +0200, Josip Rodin wrote: > > > reassign 748944 x11-common > > retitle 748944 lightdm relies on the executability of /etc/X11/Xsession, > > please enforce it > > thanks > > > x11-common installs /etc/X11/Xsession executable. Anything beyond that > is not its responsibility. I'm sure all of our users who hit this bug will be thrilled to see this kind of behavior. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150726093327.ga16...@entuzijast.net
on how lightdm does not like it when /etc/X11/Xsession is not executable
reopen 748944 thanks Hi, I saw the exact same symptoms as the original submitter of #748944. Well, I was switching from wdm, but otherwise the symptoms seem to have been the same. The file was: -rw-r--r-- 1 root root 3517 Mar 8 2008 /etc/X11/Xsession I don't recall fiddling with this myself, though it's a long time period so it could be. Other DMs my system ran have included wdm, slim and gdm, at some point in time between then and now. Since lightdm seems to require for this file is be executable, but doesn't log any useful error when it isn't, it stands to reason that it is at fault at least for not explicitly complaining about this condition. I didn't check the source, does lightdm actually try to exec this file or does it run something else which in turn fails silently? The error is reproducible so it shouldn't be hard to pinpoint the culprit. If it's elsewhere, please feel free to pass the buck. Perhaps the lightdm postinst could fix it, too, but since that is a conffile of x11-common, I'm not sure. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150719115536.ga1...@entuzijast.net
Bug#672644: X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade
On Tue, May 15, 2012 at 09:31:26AM +0200, Michel Dänzer wrote: > > What about the first upgrade issue, the lack of firmware? > > It's hard to say anything about that without seeing at least the dmesg > output and Xorg.0.log corresponding to the problem. (I think I've lost that through the log rotation, I'll try to reproduce the problem.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515090520.gb26...@entuzijast.net
Bug#672644: X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade
On Tue, May 15, 2012 at 09:32:14AM +0200, Michel Dänzer wrote: > In order to alleviate the problem, I made the X driver bail. > > I just don't think it's worth it for a corner case caused by broken > configuration. But if you can guess the parameters of the problem, why not tell the user in the error message to check those parameters, rather than have an error message that talks of something seemingly different and misleads them. Simply integrate the existing C comment into the message. For example: /* Looks like we're trying to start in UMS mode on a KMS kernel. * This can happen if the radeon kernel module wasn't loaded before * X starts. */ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "[dri] RADEONDRIGetVersion failed because of a version mismatch.\n" "[dri] In the UMS code path, this chipset requires a kernel module version\n" "[dri] of %d.%d.%d, but the kernel reports a version of %d.%d.%d.\n", info->dri->pKernelDRMVersion->version_major, info->dri->pKernelDRMVersion->version_minor, info->dri->pKernelDRMVersion->version_patchlevel); if (info->dri->pKernelDRMVersion->version_major > 1) /* or something? */ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "[dri] If you actually want to use KMS rather than UMS, make sure the radeon\n" "[dri] kernel module is loaded prior to starting X (make sure it's not blacklisted),\n" "[dri] and that this driver was built with support for KMS.\n" "[dri] Aborting.\n"); When we know that we have users who didn't cause this to themselves through a PEBCAK, rather, other packages caused it and then left their conffiles to persist with the damage even after the user did everything ages ago, we shouldn't dismiss those user complaints. Heck, in this kind of a case where the potential for breakage is high, I don't think anyone would actually mind if the package also declared: Conflicts: fglrx-driver Breaks: fglrx-driver and did this in its postinst script: if test -f /etc/modprobe.d/fglrx-driver && grep -q ^blacklist\ radeon /etc/modprobe.d/fglrx-driver; then mv /etc/modprobe.d/fglrx-driver /etc/modprobe.d/fglrx-driver.breaks.radeon; display critical priority debconf message saying run modprobe radeon or reboot before (re)starting the X server again, or else fi -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515090433.ga26...@entuzijast.net
Bug#672644: X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade
On Mon, May 14, 2012 at 11:46:45PM +0200, Josip Rodin wrote: > reopen 672644 > thanks > > On Mon, May 14, 2012 at 09:46:43PM +0200, Julien Cristau wrote: > > On Mon, May 14, 2012 at 21:33:21 +0200, Josip Rodin wrote: > > > So it looks like when it's missing, X gets it loaded, but not fast > > > enough to apply to the same session...? > > > > Correct. Closing as not a bug. > > Uhh, what? a) we know that users will be screwed and yet we'll declare the > screwage "not a bug"?! b) you didn't notice my earlier message where I found > it's an open bug upstream (with several submitters)? I see now that Michel also marked that one "resolved wontfix". Well, that's a great way to treat four bug submitters - nobody cares for your problem, and that's not all - your reports are so worthless to us that we also want to make an extra effort to publicly act like complete assholes towards you. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514215318.ga11...@entuzijast.net
Bug#672644: X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade
reopen 672644 thanks On Mon, May 14, 2012 at 09:46:43PM +0200, Julien Cristau wrote: > On Mon, May 14, 2012 at 21:33:21 +0200, Josip Rodin wrote: > > So it looks like when it's missing, X gets it loaded, but not fast > > enough to apply to the same session...? > > Correct. Closing as not a bug. Uhh, what? a) we know that users will be screwed and yet we'll declare the screwage "not a bug"?! b) you didn't notice my earlier message where I found it's an open bug upstream (with several submitters)? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514214645.ga10...@entuzijast.net
Bug#672644: X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade
On Mon, May 14, 2012 at 09:19:02PM +0200, Josip Rodin wrote: > > dmesg can't tell you why the kernel module wasn't loaded by udev. > > But it *was* loaded by udev. I don't run 'modprobe radeon' at any point > between the two tests. After the broken startx, it's loaded, which is why > it is in the dmesg output I sent you. > > > Usually it's due to a stale blacklist entry in the udev/modprobe > > configuration. > > I went looking for that and found fglrx-driver's file, from the removed but > not purged package. I purged it (from the console), then did the first > startx, and the same thing happened again - I had to run startx twice. It didn't apply immediately, but it had effect after the next reboot - during it, radeon was apparently pre-loaded automatically. After that, it only took one startx to start X. So it looks like when it's missing, X gets it loaded, but not fast enough to apply to the same session...? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514193321.ga7...@entuzijast.net
Bug#672644: X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade
On Mon, May 14, 2012 at 12:33:08PM +0200, Michel Dänzer wrote: > On Mon, 2012-05-14 at 10:56 +0200, Josip Rodin wrote: > > On Sun, May 13, 2012 at 11:00:46PM +0200, Julien Cristau wrote: > > > > In any case, I rebooted using SysRq+S+U+B (I think, at least - couldn't > > > > see > > > > anything) and installed firmware-linux-nonfree, rebooted once again for > > > > good > > > > measure, and tried startx again, and now it just aborts X saying: > > > > > > > > [ 137.038] (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because > > > > of a version mismatch. > > > > [dri] This chipset requires a kernel module version of 1.17.0, > > > > [dri] but the kernel reports a version of 2.12.0. > > > > [dri] Make sure your module is loaded prior to starting X, and > > > > [dri] that this driver was built with support for KMS. > > > > [dri] Aborting. > > I'm afraid that's as good as it gets. When using a display manager, it > should automatically try starting the X server again, which should > succeed. What about the first upgrade issue, the lack of firmware? If the unknowing user does something simple and innocuous such as exit their X session for whatever reason, before installing the apparently critical firmware, the display manager will exit the working session and dump them into a broken screen. > > > Means your radeon kernel module is not being properly loaded by udev. > > > You need to figure out why. > > > > There's nothing strange about it, at least none that I can see. > > You can see in the attached dmesg output that it worked fine. > > dmesg can't tell you why the kernel module wasn't loaded by udev. But it *was* loaded by udev. I don't run 'modprobe radeon' at any point between the two tests. After the broken startx, it's loaded, which is why it is in the dmesg output I sent you. > Usually it's due to a stale blacklist entry in the udev/modprobe > configuration. I went looking for that and found fglrx-driver's file, from the removed but not purged package. I purged it (from the console), then did the first startx, and the same thing happened again - I had to run startx twice. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514191902.ga2...@entuzijast.net
Bug#672644: X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade
On Sun, May 13, 2012 at 11:00:46PM +0200, Julien Cristau wrote: > > In any case, I rebooted using SysRq+S+U+B (I think, at least - couldn't see > > anything) and installed firmware-linux-nonfree, rebooted once again for good > > measure, and tried startx again, and now it just aborts X saying: > > > > [ 137.038] (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a > > version mismatch. > > [dri] This chipset requires a kernel module version of 1.17.0, > > [dri] but the kernel reports a version of 2.12.0. > > [dri] Make sure your module is loaded prior to starting X, and > > [dri] that this driver was built with support for KMS. > > [dri] Aborting. > > > Means your radeon kernel module is not being properly loaded by udev. > You need to figure out why. There's nothing strange about it, at least none that I can see. You can see in the attached dmesg output that it worked fine. The X output says it saw a kernel module, but it didn't like the version. The next time it starts, it sees something it likes. This message: [ 135.892] (II) [KMS] drm report modesetting isn't supported. is produced by: ret = drmCheckModesettingSupported(busIdString); I googled that and found: http://lists.x.org/archives/xorg-driver-ati/2009-December/013185.html that is: http://bugs.freedesktop.org/show_bug.cgi?id=25607 -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514085628.ga25...@entuzijast.net
Bug#672644: Acknowledgement (X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade)
On Sat, May 12, 2012 at 05:59:31PM +0200, Josip Rodin wrote: > Hi again, > > Err, another startx attempt a few minutes later - worked! > > I'll try to reboot and reproduce... Reproduced, it works the second time around. Some sort of race condition on the initial run? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120513204520.ga26...@entuzijast.net
Bug#672644: Acknowledgement (X on Mobility Radeon HD 3400 Series (Lenovo T400) broken after wheezy upgrade)
Hi again, Err, another startx attempt a few minutes later - worked! I'll try to reboot and reproduce... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120512155931.ga28...@entuzijast.net
Bug#467040: xserver-xorg-input-kbd: Lag problem on my keyboard - keys repetition
On Fri, Jan 15, 2010 at 09:48:14AM +0100, Josip Rodin wrote: > I seem to have been experiencing the same symptoms as described in #467040 > since the last squeeze upgrade done on 2009-12-31, which may be coupled with > my kernel upgrade from 2.6.30.8 to 2.6.32 on 2009-12-14. > > I've determined that I need to stop the hal daemon (with /etc/init.d/hal stop) > and add Option "AllowEmptyInput" "off" into the ServerFlags in xorg.conf, > and that restores the keyboard to a working state. > > If I just keep the AllowEmptyInput option and start X with the hal daemon > running, I can reproduce the problem. If I start hal again in the middle of > the X session, and then immediately stop it again, the problem reappears and > persists even though hal is not there. Eric, can you try that too? > > It's also messing with the mouse, some button clicks are ignored/duplicated. Hmm. This might actually have been solved in the meantime, because I now just removed AllowEmptyInput and restarted X with hal, and it works just fine. I tried rebooting, and it keeps working. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#467040: xserver-xorg-input-kbd: Lag problem on my keyboard - keys repetition
Hi, I seem to have been experiencing the same symptoms as described in #467040 since the last squeeze upgrade done on 2009-12-31, which may be coupled with my kernel upgrade from 2.6.30.8 to 2.6.32 on 2009-12-14. I've determined that I need to stop the hal daemon (with /etc/init.d/hal stop) and add Option "AllowEmptyInput" "off" into the ServerFlags in xorg.conf, and that restores the keyboard to a working state. If I just keep the AllowEmptyInput option and start X with the hal daemon running, I can reproduce the problem. If I start hal again in the middle of the X session, and then immediately stop it again, the problem reappears and persists even though hal is not there. Eric, can you try that too? It's also messing with the mouse, some button clicks are ignored/duplicated. In my 2009-12-31 upgrade log, I see only these related packages: Preparing to replace hal 0.5.13-6 (using .../hal_0.5.14-1_amd64.deb) ... Preparing to replace x11-xserver-utils 7.4+2 (using .../x11-xserver-utils_7.5+1_amd64.deb) ... Previously I upgraded on 2009-12-16 and there I had: Preparing to replace hal 0.5.13-4 (using .../hal_0.5.13-6_amd64.deb) ... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524185: ditto
On Mon, Sep 28, 2009 at 12:53:08AM +0200, Julien Cristau wrote: > On Mon, Sep 28, 2009 at 00:26:19 +0200, Josip Rodin wrote: > > > I've checked the Kconfig default (2.6.30) - it's still set to N. So, even > > if we disregard all other things already discussed, for that reason alone > > this is not a user error. > > > $ zcat /usr/share/doc/xserver-xorg/NEWS.Debian.gz |sed -e '/^ --/q' > * Linux kernel configuration requirement > > If the above isn't clear enough, patches welcome. The Debian kernels > have had INPUT_EVDEV enabled since pretty much forever afaict. Given that this results in killing normal input to the computer, something as optional as a note in the NEWS.Debian file is a weak recourse in comparison. But the best fix is to preempt this situation on run-time, even for people with evdev - if the server doesn't see a mouse or a keyboard, but has them in xorg.conf, it has every reason to complain loudly. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524185: ditto
On Thu, Sep 24, 2009 at 10:03:38PM +0200, Julien Cristau wrote: > No input devices in this list. Does your kernel have > CONFIG_INPUT_EVDEV enabled? It didn't have that. Once I compiled the evdev module, X started and found the keyboard and mouse. It thinks the keyboard is a pc101, but still. > If not, that's user error and probably not what Bastian reported. I've checked the Kconfig default (2.6.30) - it's still set to N. So, even if we disregard all other things already discussed, for that reason alone this is not a user error. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Processed: tidyup Re: Processed (with 1 errors): another one with the same symptoms
On Fri, Sep 25, 2009 at 12:12:33PM +0200, Julien Cristau wrote: > > > severity 543446 important > > Bug #543446 [xserver-xorg-core] xserver-xorg: no keyboard or mouse after > > upgrade > > Severity set to 'important' from 'normal' > > > > > merge 543446 524185 > > Bug#524185: xserver-xorg - No keyboard/mouse after upgrade > > Bug#543446: xserver-xorg: no keyboard or mouse after upgrade > > Merged 524185 543446. > > > There's absolutely no evidence that these are the same thing... The essential symptoms are the same, so until they are all decyphered, it's best to point all the other people who may want to submit a duplicate to the same place, so they can review the same options that the others already did. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524185: ditto
On Thu, Sep 24, 2009 at 10:00:33PM +0200, Julien Cristau wrote: > On Thu, Sep 24, 2009 at 20:47:35 +0200, Josip Rodin wrote: > > In any case this is a really bizarre behavior. Surely the program should > > first successfully detect and enable at least one keyboard and/or mouse > > device via HAL, and *only if that went well* decide to ignore completely > > valid xorg.conf settings? > > xorg.conf parsing happens before we connect to hal, so no. Also hal can > be started after the server, and devices can be plugged in later still, > so there's no way to know that. Why would someone program the defaults for use cases which can't be widespread (because they weren't supported in previous releases)? Do you really think the users care about the technical details of when some parsing happens in the current implementation? Besides, any previously obtained state can be cached and interpreted later, at the point when the HAL connection fails. *Anything* is better than a system whose entire array of configured input methods have been intentionally killed without any obvious recourse for the normal user. This is just plain wrong, and it saddens me that I'm even having to have this discussion... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524185: ditto
On Thu, Sep 24, 2009 at 10:03:38PM +0200, Julien Cristau wrote: > severity 524185 important > tag 524185 unreproducible > kthxbye > > On Thu, Sep 24, 2009 at 20:36:55 +0200, Josip Rodin wrote: > > > Dumping 107 device(s) from the Global Device List: > > - > [...] > > No input devices in this list. Does your kernel have > CONFIG_INPUT_EVDEV enabled? If not, that's user error and probably not > what Bastian reported. I'll check, but regardless, why in heaven's name are users supposed to have some random non-essential kernel option enabled, lest they lose functionality that actually *still exists* in the shipped binary? Why would you insist on defending a policy that is so clearly bent against the user? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524185: ditto
On Thu, Sep 24, 2009 at 08:36:55PM +0200, Josip Rodin wrote: > severity 524185 serious > thanks > > This just happened to me after an upgrade from lenny to current sid, > and it's damned annoying. I've logged into the machine over the network > and did a sudo killall xfce4-session which seems to have brought X down > gracefully, but after another startx, it's again dead. > > The four requested files are attached. > > I'll be fiddling with AllowEmptyInput now... Yep, X seems to work just fine after I've added that option to ServerFlags and restarted it. (I'm typing this through that machine again :) This is the log change: --- /var/log/Xorg.0.log.old 2009-09-24 20:35:32.0 +0200 +++ /var/log/Xorg.0.log 2009-09-24 20:39:51.0 +0200 @@ -19,7 +19,7 @@ Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. -(==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 24 20:35:32 2009 +(==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 24 20:39:50 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Screen 0" (0) @@ -28,6 +28,7 @@ (**) |-->Input Device "Genius ErgoMedia 700 Keyboard" (**) |-->Input Device "Logitech M-S48a/M-BJ69" (**) Option "AIGLX" "off" +(**) Option "AllowEmptyInput" "off" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. @@ -50,9 +51,6 @@ /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" -(WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. -(WW) Disabling Genius ErgoMedia 700 Keyboard -(WW) Disabling Logitech M-S48a/M-BJ69 (II) Loader magic: 0xdc0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 @@ -177,6 +175,18 @@ compiled for 1.6.2.901, module version = 2.1.14 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 +(II) LoadModule: "kbd" +(II) Loading /usr/lib/xorg/modules/input//kbd_drv.so +(II) Module kbd: vendor="X.Org Foundation" + compiled for 1.6.3, module version = 1.3.2 + Module class: X.Org XInput Driver + ABI class: X.Org XInput driver, version 4.0 +(II) LoadModule: "mouse" +(II) Loading /usr/lib/xorg/modules/input//mouse_drv.so +(II) Module mouse: vendor="X.Org Foundation" + compiled for 1.6.3, module version = 1.4.0 + Module class: X.Org XInput Driver + ABI class: X.Org XInput driver, version 4.0 (II) NV: driver for NVIDIA chipsets: RIVA 128, RIVA TNT, RIVA TNT2, Unknown TNT2, Vanta, RIVA TNT2 Ultra, RIVA TNT2 Model 64, Aladdin TNT2, GeForce 256, GeForce DDR, Quadro, GeForce2 MX/MX 400, @@ -648,3 +658,35 @@ SELinux: Disabled on system, not enabling in X server (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 +(**) Option "CoreKeyboard" +(**) Genius ErgoMedia 700 Keyboard: always reports core events +(**) Option "Protocol" "standard" +(**) Genius ErgoMedia 700 Keyboard: Protocol: standard +(**) Option "AutoRepeat" "500 30" +(**) Option "XkbRules" "base" +(**) Genius ErgoMedia 700 Keyboard: XkbRules: "base" +(**) Option "XkbModel" "pc105" +(**) Genius ErgoMedia 700 Keyboard: XkbModel: "pc105" +(**) Option "XkbLayout" "hr" +(**) Genius ErgoMedia 700 Keyboard: XkbLayout: "hr" +(**) Option "CustomKeycodes" "off" +(**) Genius ErgoMedia 700 Keyboard: CustomKeycodes disabled +(II) XINPUT: Adding extended input device "Genius ErgoMedia 700 Keyboard" (type: KEYBOARD) +(**) Option "Protocol" "IntelliMouse" +(**) Logitech M-S48a/M-BJ69: Device: "/dev/gpmdata" +(**) Logitech M-S48a/M-BJ69: Protocol: "IntelliMouse" +(**) Option "CorePointer" +(**) Logitech M-S48a/M-BJ69: always reports core events +(**) Option "Device" "/dev/gpmdata" +(==) Logitech M-S48a/M-BJ69: Emulate3Buttons, Emulate3Timeout: 50 +(**) Option "ZAxisMapping" "4 5" +(**) Logitech M-S48a/M-BJ69: ZAxisMapping: buttons 4 and 5 +(**) Logitech M-S48a/M-BJ69: Buttons: 9 +(**) Logitech M-S48a/M-BJ69: Sensitivity: 1 +(**) Option "BaudRate" "1200" +(**) Logitech M-S48a/M-BJ69: BaudRate: 1200 +(II) XINPUT: Adding extended input device "Logitech M-S48a/M-BJ69" (type: MOUSE
Bug#486330: just saw this now
On Tue, Aug 04, 2009 at 06:06:23PM +0200, Josip Rodin wrote:
> > (EE) Error compiling keymap (server-0)
> > (EE) XKB: Couldn't compile keymap
>
> Oh, ffs, I figured it out. The machine had no free space (for users) on
> the root partition, more exactly the partition holding /var/tmp, and yet
> these XKB tools didn't seem to think that the inability to write files
> was a useful thing to report. Let's go with the generic error message
> instead, yay. >:<
Part of the culprit is in xorg-server-*/xkb/ddxLoad.c function
XkbDDXCompileKeymapByNames() where our code path says:
out= Popen(buf,"w");
if (out!=NULL) {
XkbWriteXKBKeymapForNames(out,names,NULL,xkb,want,need);
if (fclose(out)==0 && System(buf) >= 0)
{
...
else
LogMessage(X_ERROR, "Error compiling keymap (%s)\n", keymap);
}
else {
LogMessage(X_ERROR, "XKB: Could not invoke xkbcomp\n");
}
The inner error message needs to say that it was invoking xkbcomp as well,
also how it was doing it (include 'buf'), and obviously also it should
record the actual exit code from System(buf) and include that as well.
This code is the same in 1.4.2 (lenny) and 1.6.3 (current sid).
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#486330: just saw this now
On Tue, Aug 04, 2009 at 05:50:49PM +0200, Josip Rodin wrote: > I just started my machine and X a few minutes ago, after no obvious > X-related upgrades, and my keyboard is pretty broken, many keys and > combinations no longer work. Xorg.0.log says: > > ... > (EE) Error compiling keymap (server-0) > (EE) XKB: Couldn't compile keymap > % setxkbmap > Error loading new keyboard description Oh, ffs, I figured it out. The machine had no free space (for users) on the root partition, more exactly the partition holding /var/tmp, and yet these XKB tools didn't seem to think that the inability to write files was a useful thing to report. Let's go with the generic error message instead, yay. >:< It's easy to reproduce, for example: % sudo chattr +i /var/tmp/ % setxkbmap Error loading new keyboard description % sudo chattr -i /var/tmp/ % setxkbmap % -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#486330: just saw this now
Hi,
I just started my machine and X a few minutes ago, after no obvious
X-related upgrades, and my keyboard is pretty broken, many keys and
combinations no longer work. Xorg.0.log says:
...
(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap
(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
(**) Option "CoreKeyboard"
(**) Genius ErgoMedia 700 Keyboard: always reports core events
(**) Option "Protocol" "standard"
(**) Genius ErgoMedia 700 Keyboard: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "base"
(**) Genius ErgoMedia 700 Keyboard: XkbRules: "base"
(**) Option "XkbModel" "pc105"
(**) Genius ErgoMedia 700 Keyboard: XkbModel: "pc105"
(**) Option "XkbLayout" "hr"
(**) Genius ErgoMedia 700 Keyboard: XkbLayout: "hr"
(**) Option "CustomKeycodes" "off"
(**) Genius ErgoMedia 700 Keyboard: CustomKeycodes disabled
...
(II) evaluating device (Genius ErgoMedia 700 Keyboard)
(II) XINPUT: Adding extended input device "Genius ErgoMedia 700 Keyboard"
(type: KEYBOARD)
(II) evaluating device (Logitech M-S48a/M-BJ69)
(II) XINPUT: Adding extended input device "Logitech M-S48a/M-BJ69" (type: MOUSE)
(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap
(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
Could not init font path element /usr/share/fonts/X11/cyrillic, removing from
list!
Could not init font path element /usr/share/fonts/X11/Type1, removing from list!
[config/hal] couldn't initialise context: (null) ((null))
...
SetClientVersion: 0 9
SetKbdSettings - type: 0 rate: 30 delay: 500 snumlk: 0
(II) 3rd Button detected: disabling emulate3Button
...
When I tried to run setxkbmap, I got:
% setxkbmap
Error loading new keyboard description
and Xorg.0.log just got another iteration of the generic error.
Here is the relevant part of xorg.conf:
Section "InputDevice"
Identifier "Genius ErgoMedia 700 Keyboard"
Driver "keyboard"
Option "CoreKeyboard"
Option "XkbRules" "base"
Option "XkbModel" "pc105"
Option "XkbLayout" "hr"
EndSection
And here's how it looks:
% setxkbmap -print
xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwertz)" };
xkb_types { include "complete" };
xkb_compat{ include "complete" };
xkb_symbols { include "pc+hr" };
xkb_geometry { include "pc(pc105)" };
};
% xkbcomp :0 -
Warning: Could not load keyboard geometry for :0
BadName (named color or font does not exist)
Resulting keymap file will not describe geometry
xkb_keymap {
xkb_keycodes "unknown" {
minimum = 8;
maximum = 255;
indicator 1 = "Caps Lock";
indicator 2 = "Num Lock";
indicator 3 = "Shift Lock";
virtual indicator 4 = "Mouse Keys";
virtual indicator 5 = "Scroll Lock";
virtual indicator 6 = "Group 2";
};
xkb_types "unknown" {
virtual_modifiers NumLock,Alt,ModeSwitch;
type "ONE_LEVEL" {
modifiers= none;
level_name[Level1]= "Any";
};
type "TWO_LEVEL" {
modifiers= Shift;
map[Shift]= Level2;
level_name[Level1]= "Base";
level_name[Level2]= "Shift";
};
type "ALPHABETIC" {
modifiers= Shift+Lock;
map[Shift]= Level2;
map[Lock]= Level1;
preserve[Lock]= Lock;
level_name[Level1]= "Base";
level_name[Level2]= "Caps";
};
type "KEYPAD" {
modifiers= Shift+NumLock;
map[Shift]= Level2;
map[NumLock]= Level2;
level_name[Level1]= "Base";
level_name[Level2]= "Number";
};
type "PC_BREAK" {
modifiers= Control;
map[Control]= Level2;
level_name[Level1]= "Base";
level_name[Level2]= "Control";
};
type "PC_SYSRQ" {
modifiers= Alt;
map[Alt]= Level2;
level_name[Level1]= "Base";
level_name[Level2]= "Alt";
};
type "CTRL+ALT" {
modifiers= Control+Alt;
map[Control+Alt]= Level2;
level_name[Level1]= "Base";
level_name[Level2]= "Ctrl+Alt";
};
type "THREE_LEVEL" {
modifiers= Shift+2;
map[Shift]= Level2;
map[2]= Level3;
map[Shift+2]= Level3;
level_name[Level1]= "Base";
level_name[Level2]= "Shift";
level_name[Level3]= "Level3";
};
type "SHIFT+ALT" {
modifiers= Shift+Alt;
map[Shift+Alt]= Level2;
level_name[Level1]= "Base";
level_name[Level2]= "Shift+Alt";
};
};
xkb_compatibility "unknown" {
virtual_modifiers NumLock,Alt,ModeSwitch;
interpret.useModMapMods= AnyLevel;
interpret.repeat= False;
interpret.locking= False;
interpret ISO_Level2_Latch+Exactly(Shift) {
useModMapMods=level1;
action= LatchMods(modifiers=Shift,clearLocks,latchToLock);
};
interpret Eisu_Shift+Exactly(Lock) {
a
Bug#500358: Fix found
On Tue, Nov 04, 2008 at 11:20:09PM +0300, Max Dmitrichenko wrote:
> I've rolled back to the lenny's X.org and applied both patches to the
> kernel. It works!
>
> The final patch which incorporates both patches against 2.6.26.6 (i.e.
> sid's current kernel) is attached.
I'm typing this from working X again on my Ultra 5, thanks :)
I'm attaching the exact version used, amended for current sparc-next-2.6,
just in case anyone cares. Also the working Xorg.0.log for comparison.
--
2. That which causes joy or happiness.
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index bdb7c0a..e998c66 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -244,7 +244,8 @@ static void pci_parse_of_addrs(struct of_device *op,
static struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
struct device_node *node,
- struct pci_bus *bus, int devfn)
+ struct pci_bus *bus, int devfn,
+ int host_controller)
{
struct dev_archdata *sd;
struct of_device *op;
@@ -287,28 +288,45 @@ static struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
dev->devfn = devfn;
dev->multifunction = 0; /* maybe a lie? */
- dev->vendor = of_getintprop_default(node, "vendor-id", 0x);
- dev->device = of_getintprop_default(node, "device-id", 0x);
- dev->subsystem_vendor =
- of_getintprop_default(node, "subsystem-vendor-id", 0);
- dev->subsystem_device =
- of_getintprop_default(node, "subsystem-id", 0);
-
- dev->cfg_size = pci_cfg_space_size(dev);
-
- /* We can't actually use the firmware value, we have
- * to read what is in the register right now. One
- * reason is that in the case of IDE interfaces the
- * firmware can sample the value before the the IDE
- * interface is programmed into native mode.
- */
- pci_read_config_dword(dev, PCI_CLASS_REVISION, &class);
- dev->class = class >> 8;
- dev->revision = class & 0xff;
-
- dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(bus),
- dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
-
+ if (host_controller) {
+ if (tlb_type != hypervisor) {
+ pci_read_config_word(dev, PCI_VENDOR_ID,
+ &dev->vendor);
+ pci_read_config_word(dev, PCI_DEVICE_ID,
+ &dev->device);
+ } else {
+ dev->vendor = PCI_VENDOR_ID_SUN;
+ dev->device = 0x80f0;
+ }
+ dev->cfg_size = 256;
+ dev->class = PCI_CLASS_BRIDGE_HOST << 8;
+ dev->bus->number = 0x00;
+ dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(bus),
+ dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
+ } else {
+ dev->vendor = of_getintprop_default(node, "vendor-id", 0x);
+ dev->device = of_getintprop_default(node, "device-id", 0x);
+ dev->subsystem_vendor =
+ of_getintprop_default(node, "subsystem-vendor-id", 0);
+ dev->subsystem_device =
+ of_getintprop_default(node, "subsystem-id", 0);
+
+ dev->cfg_size = pci_cfg_space_size(dev);
+
+ /* We can't actually use the firmware value, we have
+ * to read what is in the register right now. One
+ * reason is that in the case of IDE interfaces the
+ * firmware can sample the value before the the IDE
+ * interface is programmed into native mode.
+ */
+ pci_read_config_dword(dev, PCI_CLASS_REVISION, &class);
+ dev->class = class >> 8;
+ dev->revision = class & 0xff;
+
+ dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(bus),
+ dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
+ }
+
if (ofpci_verbose)
printk("class: 0x%x device name: %s\n",
dev->class, pci_name(dev));
@@ -323,21 +341,26 @@ static struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
dev->current_state = 4; /* unknown power state */
dev->error_state = pci_channel_io_normal;
- if (!strcmp(node->name, "pci")) {
- /* a PCI-PCI bridge */
+ if (host_controller) {
dev->hdr_type = PCI_HEADER_TYPE_BRIDGE;
dev->rom_base_reg = PCI_ROM_ADDRESS1;
- } else if (!strcmp(type, "cardbus")) {
- dev->hdr_type = PCI_HEADER_TYPE_CARDBUS;
+ dev->irq = PCI_IRQ_NONE;
} else {
- dev->hdr_type = PCI_HEADER_TYPE_NORMAL;
- dev->rom_base_reg = PCI_ROM_ADDRESS;
+ if (!strcmp(type, "pci") || !strcmp(type, "pciex")) {
+ /* a PCI-PCI bridge */
+ dev->hdr_type = PCI_HEADER_TYPE_BRIDGE;
+ dev->rom_base_reg = PCI_ROM_ADDRESS1;
+ } else if (!strcmp(type, "cardbus")) {
+ dev->hdr_type = PCI_HEADER_TYPE_CARDBUS;
+ } else {
+ dev->hdr_type = PCI_HEADER_TYPE_NORMAL;
+ dev->rom_base_reg = PCI_ROM_ADDRESS;
- dev->irq = sd->op->irqs[0];
- if (dev->irq == 0x)
- dev->irq = PCI_IRQ_NONE;
+ dev->irq = sd->op->irqs[0];
+ if (dev->irq == 0x)
+dev->irq = PCI_IRQ_NONE;
+ }
}
-
pci_parse_of_addrs(sd->op, node, dev);
if (ofpci_verbose)
@@ -626,7 +649,7 @@ static void __devinit pci_of_scan_bus(struct pci_pbm_info *pbm,
prev_devfn = devfn;
/* create a new pci_dev for this device */
- dev = of_create_pci_dev(pbm, child, bus, devfn);
+ dev = of_create_pci_dev(pbm, child, bus, devfn, 0);
if (!dev)
continue;
Bug#488669: resolving X Server crashes on SPARC (bugs #488669 and #500358)
On Mon, Oct 27, 2008 at 09:36:39AM +0100, Gaudenz Steinlin wrote: > 1. Install the kernel package from http://people.debian.org/~gaudenz/sparc >and test if this fixes the problem. This is the same kernel as currently >in unstable with the problematic change removed. Please also test this >kernel if you are not affected by the change to see if the removal of the >problematic change has any ill side effects. Could you extract the relevant patch from that package and send it over? I've no idea if our modern packaged kernels work on my machine, and I don't see any point in having to test both of those at once. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500358: Xorg with ATI driver and Linux 2.6.25 (on Ultra 5)
On Sat, Sep 27, 2008 at 02:53:46PM +0200, Julien Cristau wrote: > On Sat, Sep 27, 2008 at 14:48:42 +0200, Josip Rodin wrote: > > Oh, and we already have one in 488669, but it's filed against the core > > X server package. I'll leave it to the X guys to decide where to merge. > > In any case it's a clear regression from etch. :( > > > Feel free to provide a patch, or revert the kernel changes that broke X. > The X guys are not sparc porters, don't have access to sparc hardware, > and the affected code is very much arch-specific. All of them? Nobody upstream? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500358: Xorg with ATI driver and Linux 2.6.25 (on Ultra 5)
On Sat, Sep 27, 2008 at 02:38:04PM +0200, Josip Rodin wrote: > On Mon, Aug 11, 2008 at 01:16:35PM +0200, Ludovic Court?s wrote: > > Jim Watson <[EMAIL PROTECTED]> writes: > > > Ludovic Court?s wrote: > > >> The current Xorg and ATI driver appear to not work when used with > > >> `linux-image-2.6.25-2-sparc64' on an Ultra 5: > > >> > > >> X.Org X Server 1.4.2 > > >> > > > ... > > >> Any hint? > > >> > > > Could be this thread? > > > http://marc.info/?l=linux-sparc&m=121727663529005&w=2 > > > > Possibly. I guess I'll have to wait for Lenny to be released before > > upgrading the kernel. > > Unfortunately that won't help either, because apparently lenny only > has 1.4.2. 1.5.x is still in experimental. I've just happened to file > an RC bug on xserver-xorg-video-mach64 because of this, Cc:ed now. Oh, and we already have one in 488669, but it's filed against the core X server package. I'll leave it to the X guys to decide where to merge. In any case it's a clear regression from etch. :( -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500358: Xorg with ATI driver and Linux 2.6.25 (on Ultra 5)
On Mon, Aug 11, 2008 at 01:16:35PM +0200, Ludovic Court?s wrote: > Jim Watson <[EMAIL PROTECTED]> writes: > > Ludovic Court?s wrote: > >> The current Xorg and ATI driver appear to not work when used with > >> `linux-image-2.6.25-2-sparc64' on an Ultra 5: > >> > >> X.Org X Server 1.4.2 > >> > > ... > >> Any hint? > >> > > Could be this thread? > > http://marc.info/?l=linux-sparc&m=121727663529005&w=2 > > Possibly. I guess I'll have to wait for Lenny to be released before > upgrading the kernel. Unfortunately that won't help either, because apparently lenny only has 1.4.2. 1.5.x is still in experimental. I've just happened to file an RC bug on xserver-xorg-video-mach64 because of this, Cc:ed now. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500358: mach64 stopped working on the Sun Ultra 5 graphics card after upgrade
Package: xserver-xorg-video-mach64 Version: 6.8.0-1 Severity: grave Hi, With an older kernel, the old version of this driver worked fine. After a kernel upgrade, it stopped working, with a couple of error messages screaming something about memory allocation. Hearing something about how I have to upgrade Xorg driver to match, I did that, got this package from lenny, and tried again, but it didn't work, either :( This time it "just" warns about memory allocation, but still fails to actually load X properly. I'm attaching /var/log/Xorg.0.log from the machine. If you need any more information, please feel free to ask. TIA. -- 2. That which causes joy or happiness. X.Org X Server 1.4.2 Release Date: 11 June 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.2-6) Current Operating System: Linux arion 2.6.27-rc4 #2 Sat Sep 6 19:05:51 CEST 2008 sparc64 Build Date: 15 September 2008 07:23:42PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Sep 27 14:25:02 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Generic Monitor" (**) | |-->Device "ATI Technologies 3D Rage Pro or similar (ATY,GT-C)" (**) |-->Input Device "Generic Keyboard" (**) |-->Input Device "Configured Mouse" (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/misc". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/misc"). (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/cyrillic" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/100dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/100dpi/"). (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/75dpi/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/75dpi/"). (WW) The directory "/usr/share/fonts/X11/Type1" does not exist. Entry deleted from font path. (WW) The directory "/usr/X11R6/lib/X11/fonts/Type1" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/100dpi". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/100dpi"). (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/75dpi". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/75dpi"). (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist. Entry deleted from font path. (==) Including the default font path /usr/share/fonts/X11/misc,/usr/share/fonts/X11/cyrillic,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType. (**) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/cyrillic, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to "/etc/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (II) No APM support in BIOS or kernel (II) Loader magic: 0x1c0c78 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:01:0: chip 108e,5000 card , rev 13 class 06,04,00 hdr 81 (II) PCI: 00:01:1: chip 108e,5000 card , rev 13 class 06,04,00 hdr 81 (II) PCI: 01:01:0: chip 108e,1000 card , rev 01 class 06,80,00 hdr 80 (II) PCI: 01:01:1: chip 108e,1001 card
Re: xserver-xorg-video-all vs. -1.0 distinction breaks on upgrades to -2
On Sun, Sep 07, 2008 at 11:58:25PM +0100, Julien Cristau wrote: > > The Lintian laboratory on l.d.o can't find me any other packages' postinsts > > referencing shared/default-x-server. And xserver-xfree86 was actually > > a transitional package in etch already. So I have no idea why this whole > > complication exists in there. > > Hysterical raisins. It should be removed at some point; patches > welcome, although not for lenny. Well, it's severely impairing my upgrade *to* lenny, so I wager it's an issue for lenny :) Are there any external packages known to provide the symlink? ISTR some external X server software, but I don't know if it has deb packages. If not, is there any reason why this couldn't be a symlink shipped by xserver-xorg-core, or an ln -s invocation in its postinst? IIRC we stopped supporting 'jumping' upgrades (e.g. sarge->lenny) so we don't really care if we break that old xserver-xfree86. My point being - in that case, the patches are pretty simple. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xorg-video-all vs. -1.0 distinction breaks on upgrades to -2
On Sun, Sep 07, 2008 at 10:43:34PM +0200, Josip Rodin wrote: > > As a workaround, I'd just purge xserver-xorg and be done with it. > > But xserver-xorg-core depends on it for some reason. The reason seems > > to be http://bugs.debian.org/392295 Surely this could have been fixed > > by putting that part of code into the xserver-xorg-core package instead > > of creating a dependency which is circular? > > Apparently this is discussed in http://bugs.debian.org/362313 > and there's also http://bugs.debian.org/396613 > > I don't seem to see any reason for all that $SERVER_SYMLINK code. Why do we > still have shared/default-x-server debconf stuff if xserver-xfree86 has been > removed from lenny? > > And even so, wouldn't it be wiser to (also) handle that symlink in > the xserver-xorg-core package which actually provides the > /usr/bin/Xorg binary the link points to, rather than the meta package? The Lintian laboratory on l.d.o can't find me any other packages' postinsts referencing shared/default-x-server. And xserver-xfree86 was actually a transitional package in etch already. So I have no idea why this whole complication exists in there. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xorg-video-all vs. -1.0 distinction breaks on upgrades to -2
On Sun, Sep 07, 2008 at 10:32:29PM +0200, Josip Rodin wrote: > xserver-xorg-video-nv used to provide the xserver-xorg-video-1.0 virtual > package, and now the new version provides the xserver-xorg-video-2 virtual > package. But apt isn't catching on to the idea - it's ignoring the fact > that it can obtain xserver-xorg-video-2 simply by upgrading > xserver-xorg-video-nv. Instead it is parsing the dependency list as if it's > in a vacuum, seeing that xserver-xorg-video-2 isn't there, and therefore > installing xserver-xorg-video-all. > > In a simple A | B dependency, package A clearly takes precedence, that's > what the rules say. But that is oriented towards the new installs. > On upgrades, if B is obtained a) from an already installed package, just > a new version of it b) at a visibly smaller cost -- then that should be > taken into consideration. > > As a workaround, I'd just purge xserver-xorg and be done with it. > But xserver-xorg-core depends on it for some reason. The reason seems > to be http://bugs.debian.org/392295 Surely this could have been fixed > by putting that part of code into the xserver-xorg-core package instead > of creating a dependency which is circular? Apparently this is discussed in http://bugs.debian.org/362313 and there's also http://bugs.debian.org/396613 I don't seem to see any reason for all that $SERVER_SYMLINK code. Why do we still have shared/default-x-server debconf stuff if xserver-xfree86 has been removed from lenny? And even so, wouldn't it be wiser to (also) handle that symlink in the xserver-xorg-core package which actually provides the /usr/bin/Xorg binary the link points to, rather than the meta package? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xserver-xorg-video-all vs. -1.0 distinction breaks on upgrades to -2
Hi, I have xserver-xorg-video-nv installed, because that's the only xorg video driver that I need. I don't have all the other driver packages installed, because there's unnecessary. The etch->lenny upgrade nevertheless says: The following NEW packages will be installed: [...] xserver-xorg-video-all xserver-xorg-video-apm xserver-xorg-video-ark xserver-xorg-video-ati xserver-xorg-video-chips xserver-xorg-video-cirrus xserver-xorg-video-cyrix xserver-xorg-video-dummy xserver-xorg-video-fbdev xserver-xorg-video-glint xserver-xorg-video-i128 xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic xserver-xorg-video-openchrome xserver-xorg-video-r128 xserver-xorg-video-radeon xserver-xorg-video-radeonhd xserver-xorg-video-rendition xserver-xorg-video-s3 xserver-xorg-video-s3virge xserver-xorg-video-savage xserver-xorg-video-siliconmotion xserver-xorg-video-sis xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-tga xserver-xorg-video-trident xserver-xorg-video-tseng xserver-xorg-video-v4l xserver-xorg-video-vesa xserver-xorg-video-vga xserver-xorg-video-vmware xserver-xorg-video-voodoo xulrunner-1.9 The following packages will be upgraded: [...] xserver-xorg xserver-xorg-core xserver-xorg-input-evdev xserver-xorg-input-kbd xserver-xorg-input-mouse xserver-xorg-video-nv [...] This is bad because: Package: xserver-xorg Version: 1:7.3+15 Depends: xserver-xorg-core (>= 2:1.4-3), xserver-xorg-video-all | xserver-xorg-video-2, [...] xserver-xorg-video-nv used to provide the xserver-xorg-video-1.0 virtual package, and now the new version provides the xserver-xorg-video-2 virtual package. But apt isn't catching on to the idea - it's ignoring the fact that it can obtain xserver-xorg-video-2 simply by upgrading xserver-xorg-video-nv. Instead it is parsing the dependency list as if it's in a vacuum, seeing that xserver-xorg-video-2 isn't there, and therefore installing xserver-xorg-video-all. In a simple A | B dependency, package A clearly takes precedence, that's what the rules say. But that is oriented towards the new installs. On upgrades, if B is obtained a) from an already installed package, just a new version of it b) at a visibly smaller cost -- then that should be taken into consideration. As a workaround, I'd just purge xserver-xorg and be done with it. But xserver-xorg-core depends on it for some reason. The reason seems to be http://bugs.debian.org/392295 Surely this could have been fixed by putting that part of code into the xserver-xorg-core package instead of creating a dependency which is circular? (The same behaviour seems to apply to both apt-get and aptitude.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498054: xorg 1:7.3+12: Please update debconf PO translation for the package xorg
Package: xorg
Severity: wishlist
Tags: l10n
On Mon, Jun 16, 2008 at 07:01:58AM +0200, Christian Perrier wrote:
> Please send the updated file as a wishlist bug against xorg.
>
> The deadline for receiving the updated translation is
> Thu, 19 Jun 2008 06:47:26 +0200 even though the upload might happen
> anytime soon. So, please hurry, such package is not uploaded every two
> weeks
If this was in a version control system somewhere where I could just update,
edit and commit, I would have made the deadline ages ago, this procedure is
cumbersome...
--
2. That which causes joy or happiness.
msgid ""
msgstr ""
"Project-Id-Version: Debian installer HR\n"
"Report-Msgid-Bugs-To: [EMAIL PROTECTED]"
"POT-Creation-Date: 2008-06-08 22:20+0200\n"
"PO-Revision-Date: 2008-09-06 19:15+0200\n"
"Last-Translator: Josip Rodin <[EMAIL PROTECTED]>\n"
"Language-Team: Croatian <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=iso-8859-2\n"
"Content-Transfer-Encoding: 8bit\n"
#. Type: select
#. Description
#: ../xserver-xorg.templates:2001
msgid "X server driver:"
msgstr "Upravljački program X servera:"
#. Type: select
#. Description
#: ../xserver-xorg.templates:2001
msgid ""
"For the X Window System graphical user interface to operate correctly, it is "
"necessary to select a video card driver for the X server."
msgstr ""
"Kako bi grafičko korisničko sučelje X Window System radilo ispravno, "
"potrebno je odabrati upravljački program grafičke kartice za X server."
#. Type: select
#. Description
#: ../xserver-xorg.templates:2001
msgid ""
"Drivers are typically named for the video card or chipset manufacturer, or "
"for a specific model or family of chipsets."
msgstr ""
"Upravljački programi su obično imenovani po proizvođaču kartice ili "
"chipseta, ili po konkretnom modelu ili obitelji chipseta."
#. Type: boolean
#. Description
#: ../xserver-xorg.templates:3001
msgid "Use kernel framebuffer device interface?"
msgstr "Koristiti framebuffer sučelje iz jezgre OS-a?"
#. Type: boolean
#. Description
#: ../xserver-xorg.templates:3001
msgid ""
"Rather than communicating directly with the video hardware, the X server may "
"be configured to perform some operations, such as video mode switching, via "
"the kernel's framebuffer driver."
msgstr ""
"Umjesto da komunicira direktno s grafičkim sklopovljem, X server može biti "
"podešen tako da radi neke operacije, npr. prebacivanje video modova, putem "
"framebuffer upravljačkog programa u jezgri operacijskog sustava."
#. Type: boolean
#. Description
#: ../xserver-xorg.templates:3001
msgid ""
"In theory, either approach should work, but in practice, sometimes one does "
"and the other does not. Enabling this option is the safe bet, but feel free "
"to turn it off if it appears to cause problems."
msgstr ""
"Teoretski bi oba pristupa trebala raditi, ali u praksi nekad jedan radi a "
"drugi ne radi. Uključivanje ove opcije je siguran izbor, ali je slobodno "
"isključite ako vam prouzrokuje ikakve probleme."
#. Type: string
#. Description
#: ../xserver-xorg.templates:4001
msgid "Video card's bus identifier:"
msgstr "Oznaka grafičke kartice na sabirnici:"
#. Type: string
#. Description
#: ../xserver-xorg.templates:4001
msgid ""
"Users of PowerPC machines, and users of any computer with multiple video "
"devices, should specify the BusID of the video card in an accepted bus-"
"specific format."
msgstr ""
"Korisnici PowerPC strojeva, i korisnici bilo kojeg računala s više grafičkih "
"uređaja, trebaju odrediti BusID grafičke kartice u obliku prihvatljivom za "
"vašu sabirnicu."
#. Type: string
#. Description
#: ../xserver-xorg.templates:4001
msgid "Examples:"
msgstr "Primjeri:"
#. Type: string
#. Description
#: ../xserver-xorg.templates:4001
msgid ""
"For users of multi-head setups, this option will configure only one of the "
"heads. Further configuration will have to be done manually in the X server "
"configuration file, /etc/X11/xorg.conf."
msgstr ""
"Za korisnike postavki s više prikaza ('multi-head'), ova opcija će podesiti "
"samo jedan od prikaza. Daljnje postavke će trebati napraviti ručno u "
"datoteci postavki X servera, /etc/X11/xorg.conf."
#. Type: string
#. Description
#: ../xserver-xorg.templates:4001
msgid ""
"You may wish to use the \"l
Bug#373723: Adding menu entries back to xbase-clients
On Sun, Aug 19, 2007 at 04:13:55PM +0200, Brice Goglin wrote: > >> x11-apps: > >> oclock?? > >> xclock ?? > >> > > > > Put the clocks directly into Applications/System? > > Unfortunately, /usr/share/doc/menu/menu.txt.gz says > "Packages must be placed in leaf sections." > > thanks for the feedback anyway. Well, then I suggest you fix this obviously ill-conceived aspect of the new menu policy, or allocate new sections for these purposes. I'm sure the new policy wasn't meant to break stuff. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373723: Adding menu entries back to xbase-clients
On Sat, Aug 18, 2007 at 10:07:34AM +0200, Brice Goglin wrote: > x11-apps: > oclock?? > xclock ?? Put the clocks directly into Applications/System? > xclipboard Application/System/Administration ?? This is hardly sysadmin stuff... put it into Applications/Editors or Application/System, I guess. > xditview Application/Viewers ?? > xwd Applications/Graphics ?? Yep. > x11-utils > editres Applications/System/Administration ?? > xev Applications/System/Monitoring ?? > xfontsel Applications/System/Administration ?? > xkill Applications/System/Administration ?? I'd put all of those directly into Applications/System. > x11-xserver-utils > xrefresh Applications/System/Administration ?? > xsetroot Applications/System/Administration ?? > xvidtune Applications/System/Administration ?? Ditto. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434288: closed by Julien Cristau <[EMAIL PROTECTED]> (Bug#434288: fixed in xfonts-base 1:1.0.0-5)
On Tue, Jul 24, 2007 at 05:39:04PM +, Debian Bug Tracking System wrote:
> xfonts-base (1:1.0.0-5) unstable; urgency=low
> .
>[ Branden Robinson ]
>* Update package description.
> + Stop claiming that the package also provides font file manipulation
>utilities. It no longer does; those moved to xfonts-utils. (To aid
>transitions, xfonts-base should have grown a dependency on
> xfonts-utils,
>but etch is out now and it's too late to help people upgrading from
>sarge.)
> + Stop documenting the dependency on xutils; debhelper now worries about
>this for us via dh_installxfonts and ${misc:Depends}, so the dependency
>is no longer directly our responsibility.
> .
>[ Julien Cristau ]
>* Add upstream URL to debian/copyright (closes: #434288). Thanks, Josip
> Rodin!
It would be good if someone also addressed the description problems I
mentioned in my mail to debian-x the other day - particularly this
paragraph which still exists in 1.0.0-5:
This package contains primarily fonts in the ISO 10646-1 and ISO 8859-1
encodings, to conserve disk space. (A small selection of fonts in ISO
8859-8, JIS-X0208.1983, JIS-X0208.1976, and GB2312.1980 fonts are also
included.) For other encodings, see the xfonts-base-transcoded package.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434286: lacks upstream URL in the copyright file
Package: xfonts-100dpi-transcoded,xfonts-100dpi
Version: 1:1.0.0-3
Severity: serious
Hi,
The copyright file in this package does not include
the location of the upstream sources, which is a violation of
http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
("the copyright file must say where the upstream sources (if any) were
obtained").
Julien Cristau told me that "the xfonts-* packages include a bunch of
different fonts from http://xorg.freedesktop.org/releases/individual/font/
I'll fix the copyright file, thanks for noticing." :)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434290: lacks upstream URL in the copyright file
Package: xfonts-encodings
Version: 1:1.0.2-1
Severity: serious
Hi,
The copyright file in this package does not include
the location of the upstream sources, which is a violation of
http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
("the copyright file must say where the upstream sources (if any) were
obtained").
Julien Cristau told me that "the xfonts-* packages include a bunch of
different fonts from http://xorg.freedesktop.org/releases/individual/font/
I'll fix the copyright file, thanks for noticing." :)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434289: lacks upstream URL in the copyright file
Package: xfonts-utils
Version: 1:1.0.1-1
Severity: serious
Hi,
The copyright file in this package does not include
the location of the upstream sources, which is a violation of
http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
("the copyright file must say where the upstream sources (if any) were
obtained").
Julien Cristau told me that "the xfonts-* packages include a bunch of
different fonts from http://xorg.freedesktop.org/releases/individual/font/
I'll fix the copyright file, thanks for noticing." :)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434288: lacks upstream URL in the copyright file
Package: xfonts-base
Version: 1:1.0.0-4
Severity: serious
Hi,
The copyright file in this package does not include
the location of the upstream sources, which is a violation of
http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
("the copyright file must say where the upstream sources (if any) were
obtained").
Julien Cristau told me that "the xfonts-* packages include a bunch of
different fonts from http://xorg.freedesktop.org/releases/individual/font/
I'll fix the copyright file, thanks for noticing." :)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434287: lacks upstream URL in the copyright file
Package: xfonts-75dpi-transcoded,xfonts-75dpi
Version: 1:1.0.0-3
Severity: serious
Hi,
The copyright file in this package does not include
the location of the upstream sources, which is a violation of
http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
("the copyright file must say where the upstream sources (if any) were
obtained").
Julien Cristau told me that "the xfonts-* packages include a bunch of
different fonts from http://xorg.freedesktop.org/releases/individual/font/
I'll fix the copyright file, thanks for noticing." :)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfonts-base-transcoded went missing in etch
On Sun, Jul 22, 2007 at 11:34:54PM +0200, Josip Rodin wrote: > > > In reality, it's a strange situation whereby the rxvt started from within > > > a window manager (wmaker, xfce) started from within a desktop manager > > > (gdm) > > > doesn't accept inputted letters which have special characters (those I > > > need > > > Latin 2 for). But, if I start another rxvt from within that rxvt, that > > > next instance *does* accept those characters and shows them using the > > > right > > > font. > > > > > > Is that bug known, has anyone filed anything like that? > > > > > Maybe a locale problem? If I run 'LC_CTYPE=C rxvt' it doesn't seem to > > accept non-ascii characters, whereas it does with 'LC_CTYPE=fr_FR rxvt'. > > If your window manager doesn't run in the right locale, but the shell's > > startup scripts setup the locale, that could explain what you're seeing? > > But what does the shell locale have to do with it? I have the equivalent of > 'setxkbmap hr' in all cases, because xorg.conf is set up so. If I didn't, > the second instance of rxvt couldn't know the Croatian keyboard layout, > either. Sounds like a bug in rxvt? Oh, OTOH, maybe it's the *shell* that doesn't let me input those keys without the locale set. I don't see why it would do that, but still. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfonts-base-transcoded went missing in etch
On Sun, Jul 22, 2007 at 11:22:17PM +0200, Julien Cristau wrote: > > In reality, it's a strange situation whereby the rxvt started from within > > a window manager (wmaker, xfce) started from within a desktop manager (gdm) > > doesn't accept inputted letters which have special characters (those I need > > Latin 2 for). But, if I start another rxvt from within that rxvt, that > > next instance *does* accept those characters and shows them using the right > > font. > > > > Is that bug known, has anyone filed anything like that? > > > Maybe a locale problem? If I run 'LC_CTYPE=C rxvt' it doesn't seem to > accept non-ascii characters, whereas it does with 'LC_CTYPE=fr_FR rxvt'. > If your window manager doesn't run in the right locale, but the shell's > startup scripts setup the locale, that could explain what you're seeing? But what does the shell locale have to do with it? I have the equivalent of 'setxkbmap hr' in all cases, because xorg.conf is set up so. If I didn't, the second instance of rxvt couldn't know the Croatian keyboard layout, either. Sounds like a bug in rxvt? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfonts-base-transcoded went missing in etch
On Sun, Jul 22, 2007 at 05:15:34PM +0200, Julien Cristau wrote:
> > I have been using the following setting in ~/.Xresources for years now:
> >
> > XTerm*font: -misc-fixed-*-*-*-*-20-*-*-*-*-*-iso8859-2
> >
> > That font used to be in xfonts-base-transcoded, but that package is now
> > missing. removals.txt lists it, but both its listings are "NVIU", which is
> > clearly not true in this case. http://wiki.debian.org/NewInEtch says "Etch
> > is the first fully UTF-8 Debian release, so there's no version of
> > xfonts-base with legacy encodings anymore" - but is not an explanation,
> > because the existence of UTF-8 stuff simply does not preclude the
> > existence of ISO 8859-2 stuff.
> >
> Looking at the relevant fonts.dir file, I see:
> 10x20-ISO8859-2.pcf.gz
> -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-2
>
> and then:
> $ dpkg -S 10x20-ISO8859-2.pcf.gz
> xfonts-base: /usr/share/fonts/X11/misc/10x20-ISO8859-2.pcf.gz
Oh, I'm so sorry, I misinterpreted the bug I saw as the lack of font.
In reality, it's a strange situation whereby the rxvt started from within
a window manager (wmaker, xfce) started from within a desktop manager (gdm)
doesn't accept inputted letters which have special characters (those I need
Latin 2 for). But, if I start another rxvt from within that rxvt, that
next instance *does* accept those characters and shows them using the right
font.
Is that bug known, has anyone filed anything like that?
> > I found bug #363991, where it is claimed that the transcoded fonts are
> > included in the original font package, but that is apparently not true,
> > and the version of xfonts-base is the same in etch and in sid (1:1.0.0-4).
> > Indeed, its description says:
> >
> > | This package contains primarily fonts in the ISO 10646-1 and ISO 8859-1
> > | encodings, to conserve disk space. (A small selection of fonts in ISO
> > | 8859-8, JIS-X0208.1983, JIS-X0208.1976, and GB2312.1980 fonts are also
> > | included.) For other encodings, see the xfonts-base-transcoded package.
>
> That description is probably inaccurate.
Definitely, given that this is definitely an ISO 8859-2 font, and there is
no xfonts-base-transcoded package :)
> > Can we please have this sarge->etch regression fixed? This fix alone
> > would be harmless enough to be included in a point release, even.
> >
> > BTW, the copyright file in xfonts-75dpi-transcoded does not mention
> > the location of the upstream sources, which is a violation of
> > http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
> > ("the copyright file must say where the upstream sources (if any) were
> > obtained"). That also makes it harder to check if these files can be found
> > somewhere upstream (and repackaged).
>
> The xfonts-* packages include a bunch of different fonts from
> http://xorg.freedesktop.org/releases/individual/font/
> I'll fix the copyright file, thanks for noticing.
Thanks. Do you want me to file this as a separate set of bug reports?
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xfonts-base-transcoded went missing in etch
reopen 363991
done
Hi,
I have been using the following setting in ~/.Xresources for years now:
XTerm*font: -misc-fixed-*-*-*-*-20-*-*-*-*-*-iso8859-2
That font used to be in xfonts-base-transcoded, but that package is now
missing. removals.txt lists it, but both its listings are "NVIU", which is
clearly not true in this case. http://wiki.debian.org/NewInEtch says "Etch
is the first fully UTF-8 Debian release, so there's no version of
xfonts-base with legacy encodings anymore" - but is not an explanation,
because the existence of UTF-8 stuff simply does not preclude the
existence of ISO 8859-2 stuff.
I found bug #363991, where it is claimed that the transcoded fonts are
included in the original font package, but that is apparently not true,
and the version of xfonts-base is the same in etch and in sid (1:1.0.0-4).
Indeed, its description says:
| This package contains primarily fonts in the ISO 10646-1 and ISO 8859-1
| encodings, to conserve disk space. (A small selection of fonts in ISO
| 8859-8, JIS-X0208.1983, JIS-X0208.1976, and GB2312.1980 fonts are also
| included.) For other encodings, see the xfonts-base-transcoded package.
Can we please have this sarge->etch regression fixed? This fix alone
would be harmless enough to be included in a point release, even.
BTW, the copyright file in xfonts-75dpi-transcoded does not mention
the location of the upstream sources, which is a violation of
http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
("the copyright file must say where the upstream sources (if any) were
obtained"). That also makes it harder to check if these files can be found
somewhere upstream (and repackaged).
Please Cc: replies. TIA.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#151613: xauth
On Tue, May 08, 2007 at 02:23:37AM +0200, Brice Goglin wrote: > > Given that these days both the drivers and the libraries are split, I think > > that we would actually do the world a service if we stopped scheming how to > > bump several programs into a smaller number of packages, and just Xu'ed the > > whole thing. Pseudo-packages can exist to bump associated binary packages > > together for the users' benefit, but there's no real reason to keep anything > > else together. > > Maintenance cost is actually a real reason here. More source packages > implies more work to do, but it does unfortunately not imply more people > and time to do it :/ But they all follow the same pattern as the existing split packages. They all have analogous build systems and analogous release dates. Yes, it's a bit more tedious to run downloads and builds in loops :) but it's doable, because you can also split the load between more people. There's some initial work, sorting out the existing bug reports, but that's also something we're used to doing and which can also wait until any later point in time. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#151613: xauth
On Tue, May 08, 2007 at 01:47:07AM +0200, Brice Goglin wrote: > > Maybe xbase-clients in general could be further split to separate things > > that don't need all this font and OpenGL stuff. But xauth should be the > > first to go. > > It's being discussed these days and might be done in the "near" future. > xauth is planned to be in its own package. > See > http://people.debian.org/~terpstra/message/20070505.002151.a200d96f.en.html > and the current split plan at > http://users.tkk.fi/~tjaalton/xbase-clients-split.txt Is there any particular reason why this isn't Cc:ed to the BTS? :) One thing that I would add is that it's not clear whether this would be a source+binary split, or just binary. I went looking upstream, and noticed that these programs are each in their own subtree under git.freedesktop.org/xorg/app/ (list visible at http://gitweb.freedesktop.org/ ) xbase-clients currently appears to be a semi-random subset of those. Given that these days both the drivers and the libraries are split, I think that we would actually do the world a service if we stopped scheming how to bump several programs into a smaller number of packages, and just Xu'ed the whole thing. Pseudo-packages can exist to bump associated binary packages together for the users' benefit, but there's no real reason to keep anything else together. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#151613: xauth
Hi, To get xauth, one currently has to get (but note that I had previously pulled in libxp6 libxt6 libxtst6 and their dependencies): % sudo aptitude --without-recommends install xbase-clients [...] The following NEW packages will be installed: fontconfig-config libdrm2 libfontconfig1 libfs6 libgl1-mesa-glx libxaw7 libxcursor1 libxfixes3 libxft2 libxi6 libxkbfile1 libxmu6 libxmuu1 libxpm4 libxrandr2 libxrender1 libxss1 libxtrap6 libxv1 libxxf86dga1 libxxf86vm1 xbase-clients 0 packages upgraded, 22 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/2269kB of archives. After unpacking 6590kB will be used. It's not as large as it used to be, but it's a bit more annoying :) Splitting out xauth would be a Good Idea(TM). In this particular case, I just want to run an X program over an ssh session; that's a legitimate, even a relatively common use case, I think. Maybe xbase-clients in general could be further split to separate things that don't need all this font and OpenGL stuff. But xauth should be the first to go. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373723: ...
On Sun, May 06, 2007 at 03:12:29PM +0200, Brice Goglin wrote: > > I filed this on June 15th last year, and it's still not fixed, and it's in > > etch now :( > > Sorry about that. I saw this bug a while ago while cleaning the BTS, and > I even added it to the list of easy things to fix soon, but we didn't > find some time to work on it since then. I fetched the menu file from the oldstable xbase-clients package, verified that all command entries still exist, and they do seem to. I'm attaching the unmodified old file. Just put it in /usr/share/menu/xbase-clients and run update-menus (if it exists) in postinst and postrm. (You may also wish to check if there are any new xbase-clients programs nowadays that might need to go into the menu, but I doubt there are.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373723: ...
Hi, I filed this on June 15th last year, and it's still not fixed, and it's in etch now :( -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
On Sat, Apr 14, 2007 at 10:25:31AM -0400, David Nusinow wrote: > > 1) active probing of video cards to allow a more dynamic setting and > > resetting of video modes used. This work is mostly complete already > > (available in experimental xserver-xorg-video-intel, soon to appear in > > unstable). > > To expand on Drew's excellent summary further, there is support in a > development branch for the -ati driver for this as well, but it's not ready > yet. BTW, is there any chance that the -ati driver is going to include support for newer cards, the Radeon X series? It's sort of pointless for any newer machine, it won't even start X... I recently actually got sufficiently pissed off at both the ati and fglrx drivers that I went out and bought an nv/nvidia card, both of whose drivers actually work properly. (Please Cc: responses, I'm not subscribed to -x.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395090: hr translation (d-i level3)
Package: xorg Severity: wishlist Hi, A Croatian (hr) translation is attached, as part of the Debian Installer translation (hi bubulle! :). -- 2. That which causes joy or happiness. msgid "" msgstr "" "Project-Id-Version: Debian installer HR\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2006-10-21 11:30+0200\n" "PO-Revision-Date: 2006-10-24 22:15+0200\n" "Last-Translator: Josip Rodin <[EMAIL PROTECTED]>\n" "Language-Team: Croatian <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=iso-8859-2\n" "Content-Transfer-Encoding: 8bit\n" #. Type: multiselect #. Description #: ../xserver-xorg.templates:1001 msgid "Video modes to be used by the X server:" msgstr "Grafički modovi koje će koristiti X server:" #. Type: multiselect #. Description #: ../xserver-xorg.templates:1001 msgid "" "Please keep only the resolutions you would like the X server to use. " "Removing all of them is the same as removing none, since in both cases the X " "server will attempt to use the highest possible resolution." msgstr "" "Zadržite samo razlučivosti koje želite da X server koristi. Ako obrišete " "sve, to je isto kao da ne obrišete nijednu, jer će u oba slučaja X server " "pokušati koristiti najvišu moguću razlučivost." #. Type: boolean #. Description #: ../xserver-xorg.templates:2001 msgid "Attempt to autodetect video hardware?" msgstr "Pokušati automatsko prepoznavanje grafičkog sklopovlja?" #. Type: boolean #. Description #: ../xserver-xorg.templates:2001 msgid "" "You should choose this option if you would like to attempt to autodetect the " "recommended X server and driver module for your video card. If the " "autodetection fails, you will be asked to specify the desired X server and/" "or driver module. If it succeeds, further configuration questions about " "your video hardware will be pre-answered." msgstr "" "Ovu opciju trebate odabrati ako želite pokušati automatsko prepoznavanje " "preporučenog X servera i modula upravljačkog programa za vašu grafičku " "karticu. Ako automatsko prepoznavanje ne uspije, trebat ćete sami odrediti " "željeni X server i/ili modul upravljačkog programa. Ako pak uspije, daljnja " "pitanja o postavkama vašeg grafičkog hardvera će biti unaprijed odgovorena." #. Type: boolean #. Description #: ../xserver-xorg.templates:2001 msgid "" "If you would rather select the X server and driver module yourself, do not " "choose this option. You will not be asked to select the X server if there " "is only one available." msgstr "" "Ako biste rađe sami odabrali X server i modul upravljačkog programa, nemojte " "odabrati ovu opciju. Nećete dobiti odabir X servera ako je samo jedan " "dostupan." #. Type: note #. Description #: ../xserver-xorg.templates:3001 msgid "No X server known for your video hardware" msgstr "Nema poznatog X servera za vaše grafičko sklopovlje" #. Type: note #. Description #: ../xserver-xorg.templates:3001 msgid "" "There is either no video hardware installed on this machine (e.g. serial " "console only), or the \"discover\" program was unable to determine which X " "server is appropriate for the video hardware. This could be due to " "incomplete information in discover's hardware database, or because your " "video hardware is not supported by the available X servers." msgstr "" "Na ovom računalu ili nema instaliranog grafičkog sklopovlja (npr. koristi " "se samo serijska konzola), ili program \"discover\" nije uspio odrediti " "koji je X server prikladan za grafičko sklopovlje. To se može dogoditi zbog " "nepotpunih informacija u discoverovoj bazi sklopovlja, ili zbog toga što " "vaša grafička kartica nije podržana od X servera koji su dostupni." #. Type: note #. Description #: ../xserver-xorg.templates:4001 msgid "Multiple potential default X servers for your hardware" msgstr "Nekoliko potencijalnih X servera za vaše sklopovlje" #. Type: note #. Description #. Type: note #. Description #: ../xserver-xorg.templates:4001 ../xserver-xorg.templates:8001 msgid "" "Multiple video cards have been detected, and different X servers are " "required to support the various devices. It is thus not possible to " "automatically select a default X server." msgstr "" "Pronađeno je više grafičkih kartica, a za njihovu podršku su potrebni " "različiti X serveri. Zato
Bug#332521: vote for splitting
Hi, Here's another vote for the splitup of xbase-clients. Not least because, on a clean system, this happens: % apt-get install xbase-clients [...] The following NEW packages will be installed: defoma file fontconfig-config libdb4.4 libdrm2 libexpat1 libfontconfig1 libfs6 libgl1-mesa-glx libice6 libmagic1 libpng12-0 libsm6 libxaw7 libxcursor1 libxfixes3 libxft2 libxkbfile1 libxmu6 libxmuu1 libxpm4 libxrandr2 libxrender1 libxss1 libxt6 libxtrap6 libxtst6 libxv1 libxxf86dga1 libxxf86vm1 perl perl-modules ttf-dejavu ucf xbase-clients [...] 0 upgraded, 35 newly installed, 0 to remove and 0 not upgraded. Need to get 14,0MB of archives. After unpacking 49,2MB of additional disk space will be used. That's just horrible. The meaning of "base" in xbase-clients has been lost a long time ago, I guess. The split as outlined by Elrond in the submission of bug #332521 looks much better than this. The split off of mesa-utils helped, but not sufficiently, I guess. I noticed that it's just xclock that pulls in all the font* stuff. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379292: xkb-data hr layout broke the normal AltGr+numbers behaviour
On Sun, Aug 27, 2006 at 10:15:54PM +0200, Denis Barbier wrote: > > While such a condensation was probably a decent idea since it makes the > > files more logical, it was probably the root of this whole problem. > > Since cs(cyralpha) includes its own version of level3 which is more like > > English, this change propagated into hr, si, ba so that they now started > > to have AltGr'ed keys like on an English keyboard, which is incorrect. > > Right, it looks like we did not check carefully enough and some unwanted > changes have been introduced. By the way, I accidentally stumbled upon a similar issue that happened before: #236604. There could be more, too. It would help if you could keep a reminder somewhere in the back of your head to get one or both of these things done: * implement some sort of regression testing for the keyboard layouts * make sure people using some layouts are notified when something happens in an upper-level layout (template) That will go a long way in preventing these kinds of errors in the future. Thanks. In advance. :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379292: xkb-data hr layout broke the normal AltGr+numbers behaviour
On Sun, Aug 27, 2006 at 06:27:11PM +0200, Vedran Furač wrote: > > That's fine, but I don't just want the tilde, I want the caret back to two > > keypresses, too. And the backtick, and sometimes the double acute, and all > > the others. > > I asked about this change on hcol group back in april but no one > cared/complained. I don't think that h.c.o.l is indicative of much really these days... > I would just like that shift+ remains mapped to tilde so I could get > it with one hand. That's like it is with the latest version of Denis' patch. I concur too. > > The compose functionality is nifty, I agree, but it's simply not a feature > > of the standard Croatian keyboard layout and should be relegated back to an > > option. > > According to symbols/hr this is not compose, but deadkeys functionality. > See symbols/cs lines 153-165 (AE01-AE12). Columns 3 (altgr/ralt) and 4 > (altgr/ralt+shift) should be swaped. > > Denis, please redefine the whole row then (AE01 - AE12), not just 1,3,5 and 7. That would be fine by me, presuming this is what fully restores the layout to the one from old X. Curiously enough, only some of those keys act the old way under MS Windows. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379292: xkb-data hr layout broke the normal AltGr+numbers behaviour
On Sat, Aug 26, 2006 at 09:52:46PM +0200, Denis Barbier wrote: > > You missed the 7 key. AE07? That one had the backtick (`) with AltGr. > > Oh, right. > > Ok, I will then forward this new patch to upstream. Please file another > bug report later if you believe that the TLDE key has to be modified. Okay, that works. Thanks. BTW, a note on organization of files. It seems to me that the upstream went generalizing, and created a new file "cs" (country code for Serbia and Montenegro), and then went on to base ba, hr and si on it because the layouts are mostly equal. While such a condensation was probably a decent idea since it makes the files more logical, it was probably the root of this whole problem. Since cs(cyralpha) includes its own version of level3 which is more like English, this change propagated into hr, si, ba so that they now started to have AltGr'ed keys like on an English keyboard, which is incorrect. Another problem cropped up earlier this year, when the state union of Serbia and Montenegro ceased to exist. This made their provisional country code (cs) defunct, too. So the file name will need to be changed anyway. The commonality in keyboards between Slovenian, Croatian, Bosnian and Serbian (Latin) alphabets can be grouped under the linguistically recognized grouping called the Western branch of the South Slavic languages. Perhaps the common file should be called "wsslavic"? On related note, the optimization/generalization should also encompass cz(basic) and sk(basic) which differ in only six keys, and could be similarly merged. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379292: xkb-data hr layout broke the normal AltGr+numbers behaviour
On Sat, Aug 26, 2006 at 03:01:15PM +0200, Denis Barbier wrote:
> > On a standard Croatian keyboard, the AltGr (right Alt) key is not used as
> > a "compose" key in combination with the second row of the qwertz keyboard.
>
> The attached patch has been applied, please tell me if I missed something.
> Thanks for your report.
> include "cs(latin)"
> +// Redefine these keys to match XFree86 Croatian layout
> +key { [ 1, exclam, asciitilde, dead_tilde ] };
> +key { [ 3, numbersign, asciicircum, dead_circumflex ] };
> +key { [ 5,percent, degree, dead_abovering ] };
> +key { [dead_cedilla, dead_diaeresis, notsign, notsign ] };
> +key { [ minus, underscore, dead_belowdot, dead_abovedot ] };
> };
Ah, you just redefined them the hard way around. I guess that will work.
You missed the 7 key. AE07? That one had the backtick (`) with AltGr.
I can't test AB10 because I have a pc101 :)
I have mixed feelings about the key TLDE (the one left of "1").
The key is very rarely used because both in MS Windows and in X it has the
meaning of cedilla/diaeresis, and the Croatian alphabet does not include
these diacritics. Granted, if someone wants to type e.g. German or Turkish
words, it's useful. Otherwise, it's useless.
On my old keyboard, which dates from 1993 and has both English and Croatian
engravings on it (the good old days :), the engravings on the left hand
side of that key are ~/` for English, and on the right hand side they are
_/- for Croatian. I think that's actually a mistake, since the actual common
_/- is on the key just left of my right shift key. But it probably
illustrates how confusing that key is on the Croatian keyboard layout. :)
We should probably make some sort of a poll on linux.hr to figure out if
that key's worth changing to the English version...
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379292: xkb-data hr layout broke the normal AltGr+numbers behaviour
NB: when mailing @bugs.debian.org, you only mail the BTS and the
package maintainer. You need to mail [EMAIL PROTECTED] in order
to talk to the submitter.
On Sat, Aug 26, 2006 at 10:48:48AM +0200, Vedran Furač wrote:
> >>> This change annoys me to no end, because right now in order for me to get
> >>> the characters tilde (~) or caret (^) I have to make three keypresses
> >>> instead of two like everywhere else.
> >>
> >> /usr/share/X11/xkb/symbols/hr does not contain any such definition, this
> >> is a configuration problem on your side. Can you please check?
> >
> > I don't understand what you are saying. If you have a PC keyboard with
> > AltGr,
> > what happens once you run 'setxkbmap hr' and then type AltGr+3?
>
> You can get tilde with shift and that key left of 1/!.
That's fine, but I don't just want the tilde, I want the caret back to two
keypresses, too. And the backtick, and sometimes the double acute, and all
the others.
The compose functionality is nifty, I agree, but it's simply not a feature
of the standard Croatian keyboard layout and should be relegated back to an
option.
> If you want to go back, just add:
>
> key { [ 1, exclam, asciitilde, dead_tilde ] };
>
> after include "cs(latin)" in your symbols/hr. It should look like this:
>
> xkb_symbols "basic" {
> name[Group1]="Croatia";
> include "cs(latin)"
> key { [ 1, exclam, asciitilde, dead_tilde ] };
> };
> [...]
That idea is lacking for several reasons - first of all, that file is now in
/usr/share/X11/xkb/symbols/hr, and is no longer marked as a configuration
file. Secondly, the fix would only affect my machine, and not all the others
where people also expect the old behaviour to continue working.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379292: xkb-data hr layout broke the normal AltGr+numbers behaviour
On Thu, Aug 10, 2006 at 08:55:23AM +0200, Denis Barbier wrote: > > On a standard Croatian keyboard, the AltGr (right Alt) key is not used as > > a "compose" key in combination with the second row of the qwertz keyboard. > > > > This change annoys me to no end, because right now in order for me to get > > the characters tilde (~) or caret (^) I have to make three keypresses > > instead of two like everywhere else. > > > > The change needs to be reverted and the compose thing relegated to an > > option. I'll try to find a way to patch this and submit it. > > Hi Josip, > > /usr/share/X11/xkb/symbols/hr does not contain any such definition, this > is a configuration problem on your side. Can you please check? I don't understand what you are saying. If you have a PC keyboard with AltGr, what happens once you run 'setxkbmap hr' and then type AltGr+3? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379292: xkb-data hr layout broke the normal AltGr+numbers behaviour
Package: xkb-data Version: 0.8-5 Hi, On a standard Croatian keyboard, the AltGr (right Alt) key is not used as a "compose" key in combination with the second row of the qwertz keyboard. This change annoys me to no end, because right now in order for me to get the characters tilde (~) or caret (^) I have to make three keypresses instead of two like everywhere else. The change needs to be reverted and the compose thing relegated to an option. I'll try to find a way to patch this and submit it. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373723: xbase-clients lost its menu entries
Package: xbase-clients Version: 7.0.1-2 % dpkg -L xbase-clients | grep menu % dpkg -s xbase-clients | grep Version Version: 1:7.0.1-2 Please reinstate the menu entries. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362889: xbase-clients: /usr/lib/X11/xinit/xinitrc tries to use (possibly non-existant) twm/xterm
Hi, You wrote: > xinitrc tries to run twm/xterm (which may not exist) from > /usr/lib/X11/xinit/xinitrc Since 7.0.0-5, xinit no longer tries to read that location nor does it ship any files there. Instead, that is now once again the same as it was on sarge: % grep '^[^#]' /etc/X11/xinit/xinitrc . /etc/X11/Xsession This bug report should probably be closed. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#236604: xlibs: [XKB] symbols file for hr (pc/latin/type3) lost minus and underscore at AB10
On Mon, Mar 08, 2004 at 03:54:15PM -0500, Branden Robinson wrote: > tag 236604 + help > thanks > > On Sun, Mar 07, 2004 at 02:01:00PM +0100, Josip Rodin wrote: > > I guess the immediate solution is to restore the AB10 in hr, investigate > > whether pl2 is also broken, and ask the upstream to verify whether sr > > supercedes the old yu file (the newer file's author is native so it's > > probably more accurate). > > > > (One could also investigate al because it might just have been broken for > > a while without anyone fixing it... the author doesn't look like a native.) > > Would someone prepare a patch, please? You can just insert the line anywhere in such a file, I think, at least everything worked fine when I did that, on several machines differently (randomly fixing :). I don't know where exactly each such file is in the xfree86 source, sorry. -- 2. That which causes joy or happiness.
Bug#236604: xlibs: [XKB] symbols file for hr (pc/latin/type3) lost minus and underscore at AB10
On Sun, Mar 07, 2004 at 01:44:31PM +0100, joy wrote:
> Either /etc/X11/xkb/symbols/pc/hr, or the whole type3 section of
> /etc/X11/xkb/symbols/pc/latin lacks this line:
>
> key { [ minus, underscore, dead_belowdot, dead_abovedot ] };
>
> I checked other type3 keyboards and noticed that:
> * al and si define it themselves
> * pl2 and yu (and hr before my change) don't define it
>
> One could probably check in earlier X versions to see if it was erroneously
> excluded from the type3 template...
I checked 4.1.0-16woody3 xlibs and there:
si:key { [ minus,underscore ] };
hr:key { [ minus,underscore ] };
sr: key { [ slash, question],
(yu =~ sr)
al doesn't exist
pl2 doesn't exist
So it looks like only sr (yu) stands out there...
I also checked in the same directory with the new X over here, and got:
al:key { [ slash,question] };
hr:key { [ minus,underscore ] };
hr.dpkg-dist:key { [ minus,underscore ] };
pl2:key { [ minus, underscore ] };
si:key { [ minus,underscore ] };
yu:key { [ minus,underscore ] };
And here it's only al that stands out.
I guess the immediate solution is to restore the AB10 in hr, investigate
whether pl2 is also broken, and ask the upstream to verify whether sr
supercedes the old yu file (the newer file's author is native so it's
probably more accurate).
(One could also investigate al because it might just have been broken for
a while without anyone fixing it... the author doesn't look like a native.)
--
2. That which causes joy or happiness.
Bug#236604: xlibs: [XKB] symbols file for hr (pc/latin/type3) lost minus and underscore at AB10
Package: xlibs
Version: 4.3.0-5
On Sun, Feb 29, 2004 at 04:18:07PM -0800, Debian Bug Tracking System wrote:
> /etc/X11/xkb/symbols/pc/latin defines for the section included by hr:
> key { [ comma, semicolon, less, multiply ] };
> key { [period, colon, greater, division ] };
>
> So XFree86 4.3 should work out of the box, I am closing this bug.
Oh yeah, that's all fine and dandy, but X 4.3 introduced ANOTHER bug
regarding this -- now the minus and the underscore don't work any more!
Either /etc/X11/xkb/symbols/pc/hr, or the whole type3 section of
/etc/X11/xkb/symbols/pc/latin lacks this line:
key { [ minus, underscore, dead_belowdot, dead_abovedot ] };
I checked other type3 keyboards and noticed that:
* al and si define it themselves
* pl2 and yu (and hr before my change) don't define it
One could probably check in earlier X versions to see if it was erroneously
excluded from the type3 template...
Please fix this blunder ASAP.
--
2. That which causes joy or happiness.
Bug#233933: acknowledged by developer (closing 233933 :-])
retitle 233933 document that use of ImPS/2+gpmdata with imps2+raw causes pauses clone 233933 -1 severity -1 normal reassign -1 gpm thanks On Mon, Feb 23, 2004 at 01:49:53PM +0100, Josip Rodin wrote: > That said, I didn't even verify that it's the same bug as the other > submitters have said, and my settings happen to be (slightly) different than > theirs. It wouldn't have killed either of you Debian maintainers to show > some common courtesy towards the initial submitters and get them to ACK that > they don't indeed still exhibit the problem before dismissing the bug report > as an error on the part of those people. > > I'll test the 4.3.0-2 package shortly and then see if I should rephrase the > bug report's title into a request for proper documentation and/or clone > another copy over to gpm with similar intent. Heck, who are we to say that > the behaviour shouldn't actually try to be *gasp* fixed upstream? > It would still be a normal bug in any event. Confirmed the same behaviour. -- 2. That which causes joy or happiness.
Bug#233933: acknowledged by developer (closing 233933 :-])
reopen 233933 thanks On Sun, Feb 22, 2004 at 09:48:15PM -0800, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > #233933: X server 4.3 stalls for a few seconds when switching from console > back to X, > which was filed against the xserver-xfree86 package. > > It has been marked as closed by one of the developers, namely > Raphael Zimmerer <[EMAIL PROTECTED]>. Umm, this bug was improperly closed here, I never got Branden's initial message to -done, but that wasn't a proper closing either. After wading through the obnoxiously long bug log due to extraneous log files attached inline (d'oh), I'll note that I'm using X mouse protocol "ImPS/2" for my /dev/gpmdata and GPM is set to repeat "raw" from "imps2". Further, it's entirely bollocks to say that a problem like this can be easily closed as a "user configuration error" when the exact same thing works perfectly with the same version of gpm and an older version of X, and neither of the programs/packages provided any clue whatsoever that they could have a problem. I am also entirely unimpressed by mindless rants from the gpm maintainer about how he's "said it MANY times, and [he] will say it again" when his very package has continuously offered this configuration option over the last several years (cf. gpm(8)), and it has actually worked well until the latest X. I have no reason to believe that the problem is due to anything other but an minor, possibly revertible, change in the behaviour of the X server. That said, I didn't even verify that it's the same bug as the other submitters have said, and my settings happen to be (slightly) different than theirs. It wouldn't have killed either of you Debian maintainers to show some common courtesy towards the initial submitters and get them to ACK that they don't indeed still exhibit the problem before dismissing the bug report as an error on the part of those people. I'll test the 4.3.0-2 package shortly and then see if I should rephrase the bug report's title into a request for proper documentation and/or clone another copy over to gpm with similar intent. Heck, who are we to say that the behaviour shouldn't actually try to be *gasp* fixed upstream? It would still be a normal bug in any event. -- 2. That which causes joy or happiness.
Bug#233933: X server 4.3 stalls for a few seconds when switching from console back to X
Package: xserver-xfree86 Version: 4.3.0-0pre1v5 Hi, The new (4.3) X server seems to have a nasty habit of stalling transitions from the console (640x400) to X (1024x768). Everything on the X display sits there for five or six seconds, at which point it resumes normally. Everything except the xawtv overlay part of the screen which is unaffected (I see the TV normally, presuming it wasn't behind another window when I switched to console initially). With my ATI card (both ati from XFree86 and firegl from ATI), I see a half-correct snapshot of the screen during the pause. Half-correct meaning that for example I can see the windows, the background and the WindowMaker docklets, but I can't see some of the textboxes or the dots on the dock that indicate whether a program is started. Semi-random small things like that. With my Matrox card (with the mga driver from XFree86), I see a blank black screen during the pause. Sometimes the cursor is also visible on the black screen (it's black with a white outline, normal). There seem to be no pertinent log messages regarding this in the log file, only several instances of what seems to be the usual fodder: (II) 3rd Button detected: disabling emulate3Button (WW) Open APM failed (/dev/apm_bios) (No such file or directory) The problem disappears upon reverting to xserver-xfree86 4.2.1-16. That is, the pause after switching back from console reverts to being minute (adj.), probably as long as the time needed to actually re-render the screen. There also seemed to be a similar longer pause when the X server would be started for the first time, but I can't say whether this is just a subjective observation. I also seem to recall seeing it on some of the other machines where I've installed X 4.3 from experimental, but I'm not sure. I will probably upgrade to the X 4.3 from unstable soon enough but I doubt that something like this changed in just the handful of Debian revisions. No other X-related packages (including xserver-common, even) were changed after I upgraded to xserver-xfree86 4.3 and after I downgraded it back to 4.2. Please fix this. TIA. -- 2. That which causes joy or happiness.
Re: [branden@debian.org: Re: libXft.so.2 dependency changed in experimental]
On Thu, Dec 04, 2003 at 01:45:59AM -0500, Branden Robinson wrote: > You didn't reply to this message, so I assume you're not subscribed to > the list. Nope, please Cc:... > On Tue, Nov 18, 2003 at 06:38:06PM +0100, Josip Rodin wrote: > > After upgrading to xserver-xfree86 from experimental, I could no longer > > start evolution or synaptic because libXft.so.2 gave an undefined symbol, > > something about rendering (sorry, forgot the exact name :/) so I tried > > upgrading xlibs, and that solved the problem. Shouldn't the versioned > > dependency in the xlibs shlibs file be upgraded? > > Can you be more specific, please? > > Knowing what symbol got complained about would be most helpful. I figure it will be easy to reproduce, but I'm not near that laptop right now. If it helps, I believe the graphics card is ATI Rage Mobility M6 I think. -- 2. That which causes joy or happiness.
libXft.so.2 dependency changed in experimental
Hi, After upgrading to xserver-xfree86 from experimental, I could no longer start evolution or synaptic because libXft.so.2 gave an undefined symbol, something about rendering (sorry, forgot the exact name :/) so I tried upgrading xlibs, and that solved the problem. Shouldn't the versioned dependency in the xlibs shlibs file be upgraded? -- 2. That which causes joy or happiness.
Re: [experimental pre-release] I'm blocked my system with glxgears
(Please Cc: responses, I'm not subscribed.) On Tue, Jan 14, 2003 at 11:20:17PM +0100, Antoni Bella Perez wrote: > > Regards > Toni > -- > > 2. That which causes joy or happiness. Oi! That's my .signature! Give it back! :) -- This space intentionally left blank.
Re: [experimental pre-release] I'm blocked my system with glxgears
(Please Cc: responses, I'm not subscribed.) On Tue, Jan 14, 2003 at 11:20:17PM +0100, Antoni Bella Perez wrote: > > Regards > Toni > -- > > 2. That which causes joy or happiness. Oi! That's my .signature! Give it back! :) -- This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#84720: [XKB] patch for the symbols file for Croatian (hr)
tag 84720 patch
thanks
Hi,
For some reason, I never got your message to me asking for the patch, and
this seems to have gotten ignored because I didn't know you wanted it. :(
The patch I've been using, that makes the hr layout consistent with Windows
and with console-tools, just changes the AltGr+. and AltGr+, bindings:
--- hr.dpkg-dist2002-10-04 22:49:16.0 +0200
+++ hr 2001-08-08 19:57:02.0 +0200
@@ -79,9 +79,10 @@
[ braceright] };
key { [ m,M ],
[ section ] };
-key { [ comma,semicolon ] };
+key { [ comma,semicolon ],
+ [ less ] };
key { [period,colon ],
- [ periodcentered] };
+ [ greater ] };
key { [ minus,underscore ] };
key { [ zcaron, Zcaron ],
[ currency ] };
Nobody I know has ever used AltGr+. to get |, because, well, because nobody
uses that, it doesn't work. :) I have no idea why the Slovenians use that,
but us Croats sure don't. We get | by pressing AltGr+w.
In addition, I'd note that some English layouts I've seen use Shift+, and
Shift+. to get < and > respectively, so it's pretty much obvious why we're
binding them to the right Alt, for consistency.
(Please let me know if you need any more evidence that this patch is not
just my silly wish and that it doesn't actually break anything. It's been
almost two years since I submitted it and I'd hate to see it ignored even
further just because I failed to produce enough arguments for it.)
--
2. That which causes joy or happiness.
Bug#84720: [XKB] patch for the symbols file for Croatian (hr)
tag 84720 patch
thanks
Hi,
For some reason, I never got your message to me asking for the patch, and
this seems to have gotten ignored because I didn't know you wanted it. :(
The patch I've been using, that makes the hr layout consistent with Windows
and with console-tools, just changes the AltGr+. and AltGr+, bindings:
--- hr.dpkg-dist2002-10-04 22:49:16.0 +0200
+++ hr 2001-08-08 19:57:02.0 +0200
@@ -79,9 +79,10 @@
[ braceright] };
key { [ m,M ],
[ section ] };
-key { [ comma,semicolon ] };
+key { [ comma,semicolon ],
+ [ less ] };
key { [period,colon ],
- [ periodcentered] };
+ [ greater ] };
key { [ minus,underscore ] };
key { [ zcaron, Zcaron ],
[ currency ] };
Nobody I know has ever used AltGr+. to get |, because, well, because nobody
uses that, it doesn't work. :) I have no idea why the Slovenians use that,
but us Croats sure don't. We get | by pressing AltGr+w.
In addition, I'd note that some English layouts I've seen use Shift+, and
Shift+. to get < and > respectively, so it's pretty much obvious why we're
binding them to the right Alt, for consistency.
(Please let me know if you need any more evidence that this patch is not
just my silly wish and that it doesn't actually break anything. It's been
almost two years since I submitted it and I'd hate to see it ignored even
further just because I failed to produce enough arguments for it.)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian should warn about /usr/X11R6 usage being disallowed
Hi,
I think I'm going to make a Lintian check for all packages that use
/usr/X11R6 except those where $source{$binpkg} eq "xfree86"
(half-pseudo-code there).
AIUI, Overfiend only added the imake exception into policy so that less
packages need immediate fixing (policy-is-not-a-stick policy :), not because
they don't actually need fixing to get out of the X-version-specific
hierarchy and into the normal places.
Lintian should simply barf on these packages since fixing Imakefiles in
build systems that aren't monstrous like X's own isn't really all that hard.
Comments?
--
2. That which causes joy or happiness.
Re: lintian should warn about /usr/X11R6 usage being disallowed
Hi,
I think I'm going to make a Lintian check for all packages that use
/usr/X11R6 except those where $source{$binpkg} eq "xfree86"
(half-pseudo-code there).
AIUI, Overfiend only added the imake exception into policy so that less
packages need immediate fixing (policy-is-not-a-stick policy :), not because
they don't actually need fixing to get out of the X-version-specific
hierarchy and into the normal places.
Lintian should simply barf on these packages since fixing Imakefiles in
build systems that aren't monstrous like X's own isn't really all that hard.
Comments?
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#163837: startx: hostname version is displayed
Hi, The patch suggested in this bug is flawed on Debian -- startx checks for GNU in the version string and uses hostname -f, else just hostname, which means it's expecting the FQDN by default, and if it's GNU (a flawed presumption), then it explicitely states it wants the FQDN. The correct fix would be to rip out the whole block: case `uname` in Linux*) if [ -z "`hostname --version | grep GNU`" ]; then hostname=`hostname -f` else hostname=`hostname` fi ;; *) hostname=`hostname` ;; esac and replace it with simply hostname=`hostname -f`, which will work properly on all Debian systems. (The whole block is redundant anyhow, it can be reduced significantly.) If you want to send the patch upstream, try something like this: hostname=`hostname` case `uname` in Linux*) if hostname --help 2>&1 | grep -- -f >/dev/null 2>&1; then hostname=`hostname -f` fi ;; esac That means, default to just hostname, and if it's Linux, grep for -f in the help output -- if there's no help, we can safely assume that there'll be no -f in the error message and the test will fail; if there's a help and no -f listed in it, the test will fail as well. Otherwise, it'll succeed and hostname will be set accordingly. -- 2. That which causes joy or happiness.
Bug#163837: startx: hostname version is displayed
Hi, The patch suggested in this bug is flawed on Debian -- startx checks for GNU in the version string and uses hostname -f, else just hostname, which means it's expecting the FQDN by default, and if it's GNU (a flawed presumption), then it explicitely states it wants the FQDN. The correct fix would be to rip out the whole block: case `uname` in Linux*) if [ -z "`hostname --version | grep GNU`" ]; then hostname=`hostname -f` else hostname=`hostname` fi ;; *) hostname=`hostname` ;; esac and replace it with simply hostname=`hostname -f`, which will work properly on all Debian systems. (The whole block is redundant anyhow, it can be reduced significantly.) If you want to send the patch upstream, try something like this: hostname=`hostname` case `uname` in Linux*) if hostname --help 2>&1 | grep -- -f >/dev/null 2>&1; then hostname=`hostname -f` fi ;; esac That means, default to just hostname, and if it's Linux, grep for -f in the help output -- if there's no help, we can safely assume that there'll be no -f in the error message and the test will fail; if there's a help and no -f listed in it, the test will fail as well. Otherwise, it'll succeed and hostname will be set accordingly. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: testers wanted for xfree86 4.1.0-14pre15v1
On Sun, Mar 24, 2002 at 03:45:47PM -0500, Branden Robinson wrote: > Thanks for the reports, folks! I see the election looms >;) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: testers wanted for xfree86 4.1.0-14pre15v1
On Sun, Mar 24, 2002 at 03:45:47PM -0500, Branden Robinson wrote: > Thanks for the reports, folks! I see the election looms >;) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#118173: xmms: playlist fonts screwed up, shows empty squares instead of text
On Sat, Nov 03, 2001 at 04:33:08PM -0500, rj fleck wrote: > Package: xmms > Version: 1.2.5-2 > Severity: important > > seems to have only started happening on newer versions of the x-libraries > > ii xlibs 4.1.0-7X Window System client libraries I've got xlibs 4.1.0-5 here and it's fine. WTF? :) -- 2. That which causes joy or happiness.
Re: Bug#118173: xmms: playlist fonts screwed up, shows empty squares instead of text
On Sat, Nov 03, 2001 at 04:33:08PM -0500, rj fleck wrote: > Package: xmms > Version: 1.2.5-2 > Severity: important > > seems to have only started happening on newer versions of the x-libraries > > ii xlibs 4.1.0-7X Window System client libraries I've got xlibs 4.1.0-5 here and it's fine. WTF? :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSED: new package: xinit
On Thu, Oct 25, 2001 at 03:30:56AM +0900, Junichi Uekawa wrote: > Actually, I've noticed in the way that the apt in woody successfully upgrades > the > system without removing X. However, doing the upgrade using apt in > potato would fail. > > Thus, doing > > # apt-get install apt dpkg > # apt-get dist-upgrade > > before doing the upgrade would be successful, but just doing > > # apt-get dist-upgrade > > will be quite unsuccessful :P (something to add to the release notes?) It's already in the release notes, AFAIR. -- 2. That which causes joy or happiness.
Re: PROPOSED: new package: xinit
On Thu, Oct 25, 2001 at 03:30:56AM +0900, Junichi Uekawa wrote: > Actually, I've noticed in the way that the apt in woody successfully upgrades the > system without removing X. However, doing the upgrade using apt in > potato would fail. > > Thus, doing > > # apt-get install apt dpkg > # apt-get dist-upgrade > > before doing the upgrade would be successful, but just doing > > # apt-get dist-upgrade > > will be quite unsuccessful :P (something to add to the release notes?) It's already in the release notes, AFAIR. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: x-terminal-emulator
On Mon, Oct 30, 2000 at 08:26:28PM -0600, sam th wrote: > > 4) Maybe, *maybe* we should require -ls (login shell) support, but even that > > is pushing it, I think. > > To follow up on my earlier research: > xterm, rxvt, kterm, [g,k,c]rxvt, gnome-terminal, Eterm > all support 1, 2, 3, 4 > > but with wildly differing options: > - -ls : xvt, xterm, kterm, *rxvt > > - --login : Eterm, gnome-terminal > > - --loginShell : *rxvt > > curiously, -ls is supported on Eterm, and does the right thing, but only > because -l is --login, and -s is turn on the scrollbar, which is the > default. However, relying on that is probably a mistake. There probably wouldn't be any problem with an option for the login shell if it used only one letter, or several letters but with two dashes. AFAICT things using newer getopt stuff can't implement any -??* options, they'll try to interpret each letter as a separate option... :| -- Digital Electronic Being Intended for Assassination and Nullification
Re: x-terminal-emulator
On Mon, Oct 30, 2000 at 08:26:28PM -0600, sam th wrote: > > 4) Maybe, *maybe* we should require -ls (login shell) support, but even that > > is pushing it, I think. > > To follow up on my earlier research: > xterm, rxvt, kterm, [g,k,c]rxvt, gnome-terminal, Eterm > all support 1, 2, 3, 4 > > but with wildly differing options: > - -ls : xvt, xterm, kterm, *rxvt > > - --login : Eterm, gnome-terminal > > - --loginShell : *rxvt > > curiously, -ls is supported on Eterm, and does the right thing, but only > because -l is --login, and -s is turn on the scrollbar, which is the > default. However, relying on that is probably a mistake. There probably wouldn't be any problem with an option for the login shell if it used only one letter, or several letters but with two dashes. AFAICT things using newer getopt stuff can't implement any -??* options, they'll try to interpret each letter as a separate option... :| -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [off topic] Where's the debian-x mail folder for september?
On Thu, Sep 28, 2000 at 02:48:01AM -0500, Branden Robinson wrote: > > > > /org/lists.debian.org/lists/debian-x-0009 > > > > > > Apparently it took no more than 9 months and 26 days to forget a very > > > important lesson. :-P > > > > What? > > Reread all of the above text in the message body and think very hard. Are you referring to 00 being used instead of 2000, perhaps? This isn't my fault, I wasn't involved in lists archives at the time we should have switched to 4-digit numbering. We could switch now, but it seems like a lot of hassle for little gain, as most (if not all; there aren't any more of them filed in the BTS) of the Y2K bugs regarding searching and sorting the archives have been fixed with the current setup. -- Digital Electronic Being Intended for Assassination and Nullification
Re: [off topic] Where's the debian-x mail folder for september?
On Thu, Sep 28, 2000 at 02:48:01AM -0500, Branden Robinson wrote: > > > > /org/lists.debian.org/lists/debian-x-0009 > > > > > > Apparently it took no more than 9 months and 26 days to forget a very > > > important lesson. :-P > > > > What? > > Reread all of the above text in the message body and think very hard. Are you referring to 00 being used instead of 2000, perhaps? This isn't my fault, I wasn't involved in lists archives at the time we should have switched to 4-digit numbering. We could switch now, but it seems like a lot of hassle for little gain, as most (if not all; there aren't any more of them filed in the BTS) of the Y2K bugs regarding searching and sorting the archives have been fixed with the current setup. -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xterm (4.0.1-0phase2v11) depends on libc6 (>= 2.1.93)
On Wed, Sep 27, 2000 at 11:27:21PM +0200, Kresimir Kukulj wrote: > > > Current unstable libc6 is 2.1.3-10. Is 2.1.93 an error or what? > > > xlibs 4.0.1-0phase2v11 for example depends on libc6 (>= 2.1.2) > > > > Actually, current unstable libc6 is 2.1.94-*, the mirror you're using is > > out of date. > > Oh, is it ? I used http://www.debian.org/Packages/ but that is out of date ? Yes, our CVS and WWW server had some issues recently so the web pages didn't get updated properly, too. It should be back to normal by tomorrow. > I just checked ftp.debian.org. libc6_2.1.94-1.deb is there. Yes. And don't install it :) it might break anything depending on libdb2... -- Digital Electronic Being Intended for Assassination and Nullification
Re: xterm (4.0.1-0phase2v11) depends on libc6 (>= 2.1.93)
On Wed, Sep 27, 2000 at 10:59:31PM +0200, Kresimir Kukulj wrote: > Current unstable libc6 is 2.1.3-10. Is 2.1.93 an error or what? > xlibs 4.0.1-0phase2v11 for example depends on libc6 (>= 2.1.2) Actually, current unstable libc6 is 2.1.94-*, the mirror you're using is out of date. -- Digital Electronic Being Intended for Assassination and Nullification
Re: xterm (4.0.1-0phase2v11) depends on libc6 (>= 2.1.93)
On Wed, Sep 27, 2000 at 11:27:21PM +0200, Kresimir Kukulj wrote: > > > Current unstable libc6 is 2.1.3-10. Is 2.1.93 an error or what? > > > xlibs 4.0.1-0phase2v11 for example depends on libc6 (>= 2.1.2) > > > > Actually, current unstable libc6 is 2.1.94-*, the mirror you're using is > > out of date. > > Oh, is it ? I used http://www.debian.org/Packages/ but that is out of date ? Yes, our CVS and WWW server had some issues recently so the web pages didn't get updated properly, too. It should be back to normal by tomorrow. > I just checked ftp.debian.org. libc6_2.1.94-1.deb is there. Yes. And don't install it :) it might break anything depending on libdb2... -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xterm (4.0.1-0phase2v11) depends on libc6 (>= 2.1.93)
On Wed, Sep 27, 2000 at 10:59:31PM +0200, Kresimir Kukulj wrote: > Current unstable libc6 is 2.1.3-10. Is 2.1.93 an error or what? > xlibs 4.0.1-0phase2v11 for example depends on libc6 (>= 2.1.2) Actually, current unstable libc6 is 2.1.94-*, the mirror you're using is out of date. -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [off topic] Where's the debian-x mail folder for september?
On Wed, Sep 27, 2000 at 10:24:00AM +0200, Christian T. Steigies wrote: > > > /org/lists.debian.org/lists/debian-x-0009 > > I knew it looked like this on va, but not on master. What is > master:/debian/home/debian/lists/debian-x > and why is it different (gzipped except the latest, but the latest it not > really "the" latest anymore)? That was another working archive, until someone (either listmaster or admin) broke it. -- Digital Electronic Being Intended for Assassination and Nullification
Re: [off topic] Where's the debian-x mail folder for september?
On Tue, Sep 26, 2000 at 11:56:16PM -0500, Branden Robinson wrote: > > /org/lists.debian.org/lists/debian-x-0009 > > Apparently it took no more than 9 months and 26 days to forget a very > important lesson. :-P What? -- Digital Electronic Being Intended for Assassination and Nullification
Re: [off topic] Where's the debian-x mail folder for september?
On Wed, Sep 27, 2000 at 10:24:00AM +0200, Christian T. Steigies wrote: > > > /org/lists.debian.org/lists/debian-x-0009 > > I knew it looked like this on va, but not on master. What is > master:/debian/home/debian/lists/debian-x > and why is it different (gzipped except the latest, but the latest it not > really "the" latest anymore)? That was another working archive, until someone (either listmaster or admin) broke it. -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [off topic] Where's the debian-x mail folder for september?
On Tue, Sep 26, 2000 at 11:56:16PM -0500, Branden Robinson wrote: > > /org/lists.debian.org/lists/debian-x-0009 > > Apparently it took no more than 9 months and 26 days to forget a very > important lesson. :-P What? -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
