Bug#515685: console-setup: needs to read xorg.conf on install to get xkb settings
On Mon, Feb 16, 2009 at 11:33:25PM +0100, Julien Cristau wrote: Package: console-setup Version: 1.28 Severity: normal Blocks: 508244 Why is this bug blocking #508244? on upgrade from lenny to squeeze, console-setup will get installed as dependency of xserver-xorg, and the keyboard layout for X will be read from /etc/default/console-setup (unless for some reason that plan doesn't work out, but so far it seems ok). In order to make the upgrade path work, and avoid prompting users or unexpectedly changing their X kbd layout, console-setup will thus need to read xorg.conf, with something like the following patch. This is only lightly tested at the moment (thus no patch tag), but I'm filing this early in case people have comments already :) Basically, I scan xorg.conf for the first InputDevice section with an XkbLayout option, and use the options from that section. This is not quite complete (if you have multiple InputDevice sections with different layouts, all but the first will be ignored), but should cover most cases. One question though, it looks like it's not possible to set multiple layouts using console-setup's debconf interface? Is there another way to preserve this kind of settings when they're set that way in xorg.conf? Thanks for your work. I will finish it. Console-setup's debconf interface doesn't support multiple layouts (unless the language is non-latin in which case latin+non-latin combination is supported). However console-setup supports any combination of layouts in its configuration file so I think it shouldn't be a problem to read arbitrary configuration from xorg.conf. However I am not sure that it is OK for X to use the configuration of console-setup when the system is upgraded (of course this is OK when X is installed for first time). First, there are some meaningless for the console options, for example XkbGeometry. Does this mean that XKBGEOMETRY has to be added in /etc/default/console-setup? If the configuration of console-setup is used only when X is installed for first time and not when X is only upgraded then it would be unnecessary to support XKBGEOMETRY in /etc/default/console-setup. Suppose also that the user has installed both console-setup and X and she wants different keyboard configurations on the console and in X. In this case after the upgrade the old settings for X will be ignored. Another complication is that the user may have specified XkbSymbols instead of XkbLayout, XkbVariant and XkbOptions. This also is not supported by console-setup's debconf but can be easily supported in /etc/default/console-setup. If you want I can change the next version of console-setup to be able to read XkbSymbols from xorg.conf and to ignore XKBLAYOUT, XKBVARIANT and XKBOPTIONS in /etc/default/console-setup if there is also XKBSYMBOLS. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515685: console-setup: needs to read xorg.conf on install to get xkb settings
On Tue, 2009-02-17 at 14:43 +0200, Anton Zinoviev wrote: On Mon, Feb 16, 2009 at 11:33:25PM +0100, Julien Cristau wrote: Package: console-setup Version: 1.28 Severity: normal Blocks: 508244 Why is this bug blocking #508244? Because new versions of X, when using input hotplug, get information about input devices from hal instead of xorg.conf. As such, the keyboard configuration in xorg.conf is ignored, and we need to migrate it somewhere else for hal to read. console-setup seems like the obvious choice, so we don't have to keep configuring keyboard layouts twice. on upgrade from lenny to squeeze, console-setup will get installed as dependency of xserver-xorg, and the keyboard layout for X will be read from /etc/default/console-setup (unless for some reason that plan doesn't work out, but so far it seems ok). In order to make the upgrade path work, and avoid prompting users or unexpectedly changing their X kbd layout, console-setup will thus need to read xorg.conf, with something like the following patch. This is only lightly tested at the moment (thus no patch tag), but I'm filing this early in case people have comments already :) Basically, I scan xorg.conf for the first InputDevice section with an XkbLayout option, and use the options from that section. This is not quite complete (if you have multiple InputDevice sections with different layouts, all but the first will be ignored), but should cover most cases. One question though, it looks like it's not possible to set multiple layouts using console-setup's debconf interface? Is there another way to preserve this kind of settings when they're set that way in xorg.conf? Thanks for your work. I will finish it. Console-setup's debconf interface doesn't support multiple layouts (unless the language is non-latin in which case latin+non-latin combination is supported). However console-setup supports any combination of layouts in its configuration file so I think it shouldn't be a problem to read arbitrary configuration from xorg.conf. I looked at writing directly to /etc/default/console-setup so the settings could be picked up later, but since I have no idea what to put for the other variables there it didn't look like it would trivially work. What I'd like the logic to look like is something like if this is the initial console-setup install and there's an xorg.conf, use the model/layout/variant/options from there directly (bypassing debconf so multiple layouts can be preserved), and setup the rest as usual'. Does this sound sane/feasible? However I am not sure that it is OK for X to use the configuration of console-setup when the system is upgraded (of course this is OK when X is installed for first time). First, there are some meaningless for the console options, for example XkbGeometry. Does this mean that XKBGEOMETRY has to be added in /etc/default/console-setup? If the configuration of console-setup is used only when X is installed for first time and not when X is only upgraded then it would be unnecessary to support XKBGEOMETRY in /etc/default/console-setup. See below. Suppose also that the user has installed both console-setup and X and she wants different keyboard configurations on the console and in X. In this case after the upgrade the old settings for X will be ignored. I'm ok with that. We'll document it, and people will have the option of configuring that stuff directly in hal if they want to have different console and X setups, but I think the default case should be to share them. Another complication is that the user may have specified XkbSymbols instead of XkbLayout, XkbVariant and XkbOptions. This also is not supported by console-setup's debconf but can be easily supported in /etc/default/console-setup. If you want I can change the next version of console-setup to be able to read XkbSymbols from xorg.conf and to ignore XKBLAYOUT, XKBVARIANT and XKBOPTIONS in /etc/default/console-setup if there is also XKBSYMBOLS. The evdev driver (which is pretty much the only relevant one for linux going forward), as well as new (well, future) versions of the kbd driver, only look at rmlvo, and ignore XkbSymbols and XkbGeometry, so that should be ok. Thanks for looking at this! Cheers, Julien -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515685: console-setup: needs to read xorg.conf on install to get xkb settings
On Tue, Feb 17, 2009 at 02:31:07PM +0100, Julien Cristau wrote: I looked at writing directly to /etc/default/console-setup so the settings could be picked up later, but since I have no idea what to put for the other variables there it didn't look like it would trivially work. What I'd like the logic to look like is something like if this is the initial console-setup install and there's an xorg.conf, use the model/layout/variant/options from there directly If only model, layout, variant, options are necessary then the config script of console-setup only needs to copy the settings from xorg.conf to /etc/default/console-setup without any changes (regardless of how many layouts). I will modify your patch to do this. Why does your patch ignore XkbRules? (bypassing debconf so multiple layouts can be preserved), and setup the rest as usual'. Does this sound sane/feasible? Unlike dexconf console-setup completely ignores its settings in the Debconf database. When I wrote that debconf doesn't support multiple layouts I meant that in this case dpkg-reconfigure will not ask questions about the layout. Instead the user will be informed that the keyboard settings in /etc/default/console-setup have to be edited manualy. We'll document it, and people will have the option of configuring that stuff directly in hal if they want to have different setups, but I think the default case should be to share them. Yes, in most cases it is desirable to share the configuration. Another thing that would require a little more work would be to create a separate keyboard configuration package (= current debconf configuration of console-setup minus questions about encoding, codeset and font) that creates a /etc/default/keyboard file that is used by console-setup, console-setup-mini and X. In this way X won't have to depend on console-setup. If you agree and if it is not too difficult, then when I have time I will make such package. Anton Zinoviev -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515685: console-setup: needs to read xorg.conf on install to get xkb settings
On Tue, 2009-02-17 at 17:10 +0200, Anton Zinoviev wrote: On Tue, Feb 17, 2009 at 02:31:07PM +0100, Julien Cristau wrote: I looked at writing directly to /etc/default/console-setup so the settings could be picked up later, but since I have no idea what to put for the other variables there it didn't look like it would trivially work. What I'd like the logic to look like is something like if this is the initial console-setup install and there's an xorg.conf, use the model/layout/variant/options from there directly If only model, layout, variant, options are necessary then the config script of console-setup only needs to copy the settings from xorg.conf to /etc/default/console-setup without any changes (regardless of how many layouts). I will modify your patch to do this. Why does your patch ignore XkbRules? It probably shouldn't. I ignored it because it doesn't matter as far as X is concerned: we'll use the evdev rules on linux. The other rules files are xfree98 and base, and I have no idea what the former is about. We used to have 'sun', but nowadays sun keyboards use the base rules too. (bypassing debconf so multiple layouts can be preserved), and setup the rest as usual'. Does this sound sane/feasible? Unlike dexconf console-setup completely ignores its settings in the Debconf database. When I wrote that debconf doesn't support multiple layouts I meant that in this case dpkg-reconfigure will not ask questions about the layout. Instead the user will be informed that the keyboard settings in /etc/default/console-setup have to be edited manualy. ok, sounds good. We'll document it, and people will have the option of configuring that stuff directly in hal if they want to have different setups, but I think the default case should be to share them. Yes, in most cases it is desirable to share the configuration. Another thing that would require a little more work would be to create a separate keyboard configuration package (= current debconf configuration of console-setup minus questions about encoding, codeset and font) that creates a /etc/default/keyboard file that is used by console-setup, console-setup-mini and X. In this way X won't have to depend on console-setup. If you agree and if it is not too difficult, then when I have time I will make such package. I have no preference on that, both solutions work for me. Let me know if I can help. Cheers, Julien -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515695: installation-reports: USB Install fails when too many ISOs are found
Frans Pop elen...@planet.nl writes: On Tuesday 17 February 2009, Rohan Dhruva wrote: My /dev/hda5 is a vfat partition having many (upwards of 15) ISOs. They are all present in a single directory in the root, so debian installer did check them. Possibly there are ways to improve this issues, but I'm not sure it will receive a very high priority. Reassigning to the correct package. As it seems, the problem is that umount can't free the loop devices, because /etc/mtab is symlinked to /proc/mounts (cf man mount). Why is /etc/mtab a symlink in the installer environment? -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515311: fixed
We believe that the bug you reported is now fixed; the following package(s) have been removed from unstable: glantank |1.9 | source glantank-utils |1.9 | arm, armel Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive (ftp-master.debian.org) and will not propagate to any mirrors (ftp.debian.org included) until the next cron.daily run at the earliest. Packages are never removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. Bugs which have been reported against this package are not automatically removed from the Bug Tracking System. Please check all open bugs and close them or re-assign them to another package if the removed package was superseded by another one. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 515...@bugs.debian.org. The full log for this bug can be viewed at http://bugs.debian.org/515311 This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org. Debian distribution maintenance software pp. Frank Lichtenheld (the ftpmaster behind the curtain) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515826:
Package: installation-reports Boot method: CD Image version: debian-500-alpha-netinst.iso Date: 2009.02.17 17:53 CET Machine: Digital Alpha AXP 150 (DEC 2000 model 300 - Jensen) Processor: DIgital Alpha EV4 - 150 Mhz Memory: 128 MB Partitions: N/A Output of lspci -knn (or lspci -nn): N/A Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [E] Detect CD: [E] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Trying to boot the Debian 5.0 netboot install image fails to detect CD and/or network card (DE422). It boots up to the install screen just fine, but without CD/network card support unable to install base system. (scsi controller- aha1742 (eisa), network card - de422 (eisa) As far as I can recall from my memory Jensen needed a special kernel (CONFIG_ALPHA_JENSEN=y). Thanks in advance, -- frts
Bug#175686: Best way to turn her on affondasse
Nothing will come between you and your success with girls. aedierp http://geocities.com/kingdrainvyz3417/ affaersvaerlden aggennad afspelde afoogste agused agodien aetismus affiniteten afkrabbelden -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#352758: Never be infirm with her afstreken
Proper answer for your age, if it's trying to spoil your romantic fun. aetropal http://geocities.com/martinreedhih1475/ aeusseru afstoot agarskap afmieheg aficom agrat aggi aeromexico africa-l -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[D-I Manual] Build log for en (17 Feb 2009)
A build of the Debian Installer Manual was triggered by an update to SVN.
There were no errors during the build process.
The new version of the manual has been uploaded successfully.
A log of the build is available at:
- http://d-i.alioth.debian.org/manual/logs/en.log
===
It is possible to use RSS to track changes to the manual.
For more information, see:
http://d-i.alioth.debian.org/manual/translators.html
===
Note: PDF output is not yet supported for some languages; help
with this would be appreciated.
===
If you have any questions about the build or this message, feel
free to contact me at faw AT funlabs DOT org.
===
Updated files ('svn up')
Uen/install-methods/boot-usb-files.xml
Updated to revision 57600.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
GTK+ 2.14 and directFB
Hi again, thanks to Sven Neumann who jumped in very quickly to resolve this issue, we now have a set of GTK+ 2.14 packages that are supposed to have a working DirectFB backend. I have just uploaded this version (2.14.7-2) to experimental. The packages should install fine on unstable, so there is no need to upgrade anything else. What I need now is volunteers to test them, so that’s where debian-boot is welcome to have a look. If you meet any major issues with this version, please send the relevant debugging information or a test program with instructions. Thanks, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Unable to install Lenny
Hi, I'm trying to install lenny on my machine (tried both amd64 and i386), but the installer won't recognize the partitions on my HD. I tried to boot with the rescue option, and found out that it does find the partitions, but for some reason doesn't show it on the selection screen (it simply shows my disk as 250GB of unpartitioned space). My motherboard is a Foxconn A6VMX, and my HD is a 250gbSamsung SataII disk (can't remember the model now, will provide later if needed). Going through the log messages of the installer, I've found an interesting line: main-menu[1441]: INFO: menu item 'partman-base' succeeded but requested to be left uncofigured I don't if this has anything to do with the problem, but after some fiddling with the command-line I've found that partmap does know there are partitions on the disk, and partman crashes if ran after running part*_server (can't remember the whole command now :/ ). Also, I tried the amd64-kde, amd64-netinst, i386-netinst, weekly and daily builds of the lenny netinst image, and all have the same issue. I'm trying now the etchnhalf disk, to install and update afterwards. Any ideas? TIA, Khristian -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
