Bug#384248: installation-report: Almost successful Etch installation with di-beta3
Just FYI. D-Link DSL-200 (rev.B1) was distributed for free _as officially supported modem_ for new ADSL users during the last months by one popular ADSL provider in Saint-Petersburg and suburbia. So, I think several thousands of users are currently using it here. Of course most of them work under Windows, but as you see not everyone. So, eciadsl package is quite important for us. Maybe it's still time to try working to support such modems from the installer, through the ppp-udeb and all that kind of stuff. There has been some increased interest in PPPoE support for the installer in the very few last days.we should maybe try to avoid letting this vanishing. I really encourage people interested in this to subscribe to [EMAIL PROTECTED], join the #debian-boot IRC channel andtry. Eddy Petrisor did some work with Marco for a working ppp-udeb package. That work mostly needs to be completed to make it an official feature of D-I. That can maybe be done on time for Etch.or anyway, it would be good to have this working for post-etch. (of course, the tricky part will certainly be these firmware issues one usually faces with the USB DSL modems, unfortunately) I personnally know nothing about this stuff (or very few.I very quickly dropped the USB modem offerred by my ISP when I got DSL, 4 years ago).and I can just encourage you people to try working on all this. signature.asc Description: Digital signature
Bug#380105: Show current hour in hardware clock question
There has been such kind of suggestion last weeks but it has been ruled out. I guess that the rationale is mostly avoiding features that are only available in some D-I flavours. Ruled out ? Oh well. ... Which explains the rather harsh reply of this question only being 'noise'. Hey, Sven. Aren't you the one who very often insists on difficulties faces by non-English speakers ? :-) In the abve paragraph, what I intended to say is: Cette suggestion a déjà été fait dans les dernières semaines mais elle a pour l'instant été écartée car nou spréférons en général éviter les fonctionnalités disponibles seulement dans certaines versions de l'installateur. So, I translated écartée (which is, in French, a quite non rude word) by ruled outwhich is indeed the *only* English expression that comes to my mind o roughly express the same idea. It is very possible that rule out is stronger than my real intent (anyway, I'm not the one who ruled this out). So, please, don't put in my mouth the words you often seem to see in other people's mouth. What has been ruled out is a feature with a clock showing up in the corner of the G-I screen (indeed something similar to the extra games you discussed abut in January). So, if a method to set the clock is offerred, it has to work for all interfaces. Well, the .udeb could be common to everything, and the clock button could only be a shortcut to it. That would be an interesting feature, yes. signature.asc Description: Digital signature
Re: Processed: Re: HAL needed by Konqueror in kde-desktop
Quoting Debian Bug Tracking System ([EMAIL PROTECTED]): Processing commands for [EMAIL PROTECTED]: reassign 384663 konqueror Bug#384663: HAL needed by Konqueror in kde-desktop Bug reassigned from package `tasksel' to `konqueror'. I wholeheartedly support this. I took me ages before I understood that I needed to aptitude install hal in order to have automatic recognition of my inserted USB keys by my KDE environment. Such feature is naturally expected by ordinary users. Who would expect to be forced to do some magic incantation to access a USB key, memory card, CD, whatever ? signature.asc Description: Digital signature
Re: r40201 - in trunk/packages/partman/partman-crypto: . active_partition/crypto_type debian
= --- trunk/packages/partman/partman-crypto/debian/partman-crypto.templates (original) +++ trunk/packages/partman/partman-crypto/debian/partman-crypto.templates Fri Aug 25 21:04:17 2006 @@ -363,6 +363,18 @@ be destroyed upon each reboot. This should only be used for swap partitions. +Template: partman-crypto/install_udebs_failure +Type: error +_Description: Failed to download crypto components + An error occurred trying to download additional crypto components. + +Template: partman-crypto/install_udebs_low_mem +Type: boolean +_Description: Proceed to install crypto components despite insufficient memory? + There does not seem to be sufficient memory available to install + additional crypto components. Would you like to go ahead and try + anyway? Note that this may crash the installation process. + I reworded this slightly because double questioning should be avoided (see DevRef). signature.asc Description: Digital signature
Como pudo una historia
Como pudo una historiacaminar sin tu sonrisasin tu voz de amanecersin tus labios de placersin tus luceros ardiendo en fuegocomo pudieron las estrellas avecinarse en tal auroraen que momento el destino huyo febril de tumi universo volcó su suelo, encendió emperoun sol siniestro¿en que latitud estas?oh dulce amor mío¿que lugar del infinito se engrandece con tu aleteo?
Bug#380105: Show current hour in hardware clock question
On Sat, Aug 26, 2006 at 09:01:39AM +0200, Christian Perrier wrote: There has been such kind of suggestion last weeks but it has been ruled out. I guess that the rationale is mostly avoiding features that are only available in some D-I flavours. Ruled out ? Oh well. ... Which explains the rather harsh reply of this question only being 'noise'. Hey, Sven. Aren't you the one who very often insists on difficulties faces by non-English speakers ? :-) I was refering to the rather harsh original reply from Geert. In the abve paragraph, what I intended to say is: Cette suggestion a déjà été fait dans les dernières semaines mais elle a pour l'instant été écartée car nou spréférons en général éviter les fonctionnalités disponibles seulement dans certaines versions de l'installateur. Yeah, but it has been my experience that the d-i leadership has some rather dogmatic approach to this kind of things, and ones something has been decided by the powers that be, even mentioning it is putting oneself as risk of becoming the target of a hate campaign, as i was over the kernel .udeb issue (altough i am also partly at fault, but only partly). So, I translated écartée (which is, in French, a quite non rude word) by ruled outwhich is indeed the *only* English expression that comes to my mind o roughly express the same idea. It is very possible that rule out is stronger than my real intent (anyway, I'm not the one who ruled this out). Indeed, i had no comment on what you said, but it shows clearly the futility of trying to propose or discuss ideas about it, since doing so will attire me the ire of frans and co, which i wanted to avoid in the first place. Too late now. So, please, don't put in my mouth the words you often seem to see in other people's mouth. What has been ruled out is a feature with a clock showing up in the corner of the G-I screen (indeed something similar to the extra games you discussed abut in January). Indeed. I do believe it is a small-minded ruling lacknig vision and temerity. I am bitter about this whole issue, and this may reflect and color my attitude over this, but since it has been ruled out, i will not insist further, because i know what it is going to cost me once frans is back. So, if a method to set the clock is offerred, it has to work for all interfaces. Well, the .udeb could be common to everything, and the clock button could only be a shortcut to it. That would be an interesting feature, yes. Indeed, but as you said, it has been ruled out, so anything coming from me will be seen as further defiance of the d-i team authority, let's not push this further, others may feel to develop these ideas more. Friendly, Sven Luther
Bug#384248: installation-report: Almost successful Etch installation with di-beta3
On Aug 26, Christian Perrier [EMAIL PROTECTED] wrote: Maybe it's still time to try working to support such modems from the installer, through the ppp-udeb and all that kind of stuff. It's not practical. Either it can work in the installer without fiddling or it's easier for the user to install base and start from there. -- ciao, Marco signature.asc Description: Digital signature
Re: Preseeded RAIDed installs again
On Tue, Aug 22, 2006 at 11:56:06PM +0200, David Härdeman wrote: On Tue, Aug 22, 2006 at 03:02:49PM +0100, Simon Huggins wrote: On Wed, Aug 16, 2006 at 05:11:47PM +0100, Simon Huggins wrote: On Wed, Aug 16, 2006 at 02:15:00PM +0200, Frans Pop wrote: I will try to look at it over the next few days. Maybe David Härdeman will be willing to take a look as well. Great. Did either of you manage this yet? I've tested it against an up to date daily and with more than just two partitions (i.e. adapting the multi recipe from partman-auto) and it's still working fine here. I was kinda hoping that I'd be able to finish that so that I'd be able to give input on how the partman-auto-raid stuff could be hooked into the UI as well so it not only allows preseeding but also manual action. Interesting. What would you hope to achieve this way though? There is already a RAID interface via the menus. On Wed, Aug 23, 2006 at 02:50:47PM +0200, David Härdeman wrote: One comment and one question so far: partman-auto-raid/init.d/initial_auto_raid seems to contain a copy of confirm_changes() from partman-base/definitions.sh Quite probably. Do you mean I should try and source that then? I took a copy so I was working with something static that wouldn't change under me. Would it be possible to use lvm on top of the md device? The reason that I'm asking is that it would allow all the existing recipies to be used, no separate recipe format would be necessary for RAID (just preseed disk and raid level) and much of the heavy lifting could be done by partman-auto-lvm once partman-auto-raid has setup the md device. That would involve LVM however and my goal was to set up RAID without LVM. I realised at the time that there could well be some useful work to do both and to put LVM on top of an MD device for further carving up. At the moment the partman-auto-raid stuff will give you automatic RAID devices but I suspect some of the -auto-raid and/or -auto-lvm code would need to be rejigged in terms of priorities at least in order to do this. I see that as additional work on top of what I've already written though; I think it's useful as is or I wouldn't have written it but I'm open to suggestions and at least one of the server configs I install Debian on requires some RAIDed partitions and then LVM on one of the RAIDed partitions. Let me know what you think needs to be done before this can go in. -- Simon [ [EMAIL PROTECTED] ] *\ 1 girl was just abducted. - Mulder \** ** ]-+-+-+-+-+-+-+-+-[ **\Kidnapped. - Scully Potato, \* ** [ Htag.pl 0.0.22 ] ***\potato.. - Mulder \ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384395: closed by Christian Perrier [EMAIL PROTECTED] (Re: Bug#384395: non-ascii chars broken on VT2)
From my tests, this is fixed. it is indeed. regards, Davide signature.asc Description: Digital signature
Bug#384771: installation report d-i amd64 20060826
Package: installation-reports Boot method: Network-install CD Image version: Saturday August 26th, from the official site. Date: saturday august 26th, 15:00 GMT+1 Machine: AMD 64bit machine, using Abit KN9-SLI motherboard and Nvidia GPU Processor: AMD 64X2 AM2 4200+ cpu Memory: 2gb Partitions: n/a Output of lspci and lspci -n: Not really able to provide, the system never got it's network up and running. Network part is: (typed by hand) 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [E] Config network: [E] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] Comments/Problems: The network is detected by the forcedeth kernel module, but no traffic goes over it. DHCP didn't work, setting static IP does work, but I can't ping the IP (and I can't get to the debian mirrors to complete my installation). The module does detect link states, so that part is ok. (On a site comment: using the ubuntu installation CD (which uses a more recent kernel, 2.6.17.something) does work. So maybe the module needs upgrading?) Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preseeded RAIDed installs again
On Sat, Aug 26, 2006 at 11:46:54AM +0100, Simon Huggins wrote: On Tue, Aug 22, 2006 at 11:56:06PM +0200, David Härdeman wrote: I was kinda hoping that I'd be able to finish that so that I'd be able to give input on how the partman-auto-raid stuff could be hooked into the UI as well so it not only allows preseeding but also manual action. Interesting. What would you hope to achieve this way though? There is already a RAID interface via the menus. A RAID option in the partman-auto menu was what I was referring to. However, I realise that it would require much more work than just hooking it up (like integration with partman-auto-lvm) so it would probably be wise to postpone that feature for now. On Wed, Aug 23, 2006 at 02:50:47PM +0200, David Härdeman wrote: One comment and one question so far: partman-auto-raid/init.d/initial_auto_raid seems to contain a copy of confirm_changes() from partman-base/definitions.sh Quite probably. Do you mean I should try and source that then? I took a copy so I was working with something static that wouldn't change under me. Yeah, I think you should source it, it would reduce the size of initial_auto_raid by two thirds. Would it be possible to use lvm on top of the md device? The reason that I'm asking is that it would allow all the existing recipies to be used, no separate recipe format would be necessary for RAID (just preseed disk and raid level) and much of the heavy lifting could be done by partman-auto-lvm once partman-auto-raid has setup the md device. That would involve LVM however and my goal was to set up RAID without LVM. I realised at the time that there could well be some useful work to do both and to put LVM on top of an MD device for further carving up. At the moment the partman-auto-raid stuff will give you automatic RAID devices but I suspect some of the -auto-raid and/or -auto-lvm code would need to be rejigged in terms of priorities at least in order to do this. Yes, I agree, most code can be reused quite easily but a solution would still be needed for a proper /boot partition etc. This would perhaps involve adding a flag similar to $lvmok to the partman-auto recipies etc, but it sounds like something that would be suitable for post-Etch. I see that as additional work on top of what I've already written though; I think it's useful as is or I wouldn't have written it but I'm open to suggestions and at least one of the server configs I install Debian on requires some RAIDed partitions and then LVM on one of the RAIDed partitions. Let me know what you think needs to be done before this can go in. It's a pretty low amount of code and it doesn't touch anything else, I think it could go in (with the duplicate confirm_changes() fixed). We can always work on further integration post-Etch. In the end it's not my decision though, it's FJP's (and perhaps joeyh's while acting as interim RM), I only looked at the code :) Regards, David
Bug#380105: Show current hour in hardware clock question
On Fri, Aug 25, 2006 at 09:10:27PM +0200, Sven Luther wrote: On Fri, Aug 25, 2006 at 04:57:17PM +0200, Christian Perrier wrote: I am not sure, but in the graphical installer, we could add a clock widget somewhere from the start, and do clock setting pretty early one (we probably only need hwclock and a little menu thingy), it can even be done before base-install and partman, since there are no extra dependencies. There has been such kind of suggestion last weeks but it has been ruled out. I guess that the rationale is mostly avoiding features that are only available in some D-I flavours. Personally, I find this a pity. I'd think that the graphical installer could benefit from some changes to improve usability, some of which would not make any sense in the textual interface. As an example, one place where I personally feel that the graphical version of the installer does not work very well, is in the partitioner; using different graphical paradigms to display the partitioning being in progress would most likely allow for a more usable interface. However, such an interface would need information that is not necessarily available in the text-based version of the installer. (No, I'm not willing to suggest how to do this, simply because I'm not a graphical guy; but the above is my opinion on the subject) Ruled out ? Oh well. ... Which explains the rather harsh reply of this question only being 'noise'. So, if a method to set the clock is offerred, it has to work for all interfaces. Well, the .udeb could be common to everything, and the clock button could only be a shortcut to it. ... with a main menu option to allow for invoking it from the text version, if there is interest. That being said, of course, it should be so that no important feature must ever be implemented that can only be accessed from one particular interface; as important, I would classify anything which cannot be enabled and/or fixed after the installation has been finished. Thus, I personally would not see any harm in having the ability to set the clock from the graphical installer, but not from the text-based one; of course, YMMV. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380105: Show current hour in hardware clock question
On Sat, Aug 26, 2006 at 07:37:13AM +0200, Wouter Verhelst wrote: On Fri, Aug 25, 2006 at 09:10:27PM +0200, Sven Luther wrote: On Fri, Aug 25, 2006 at 04:57:17PM +0200, Christian Perrier wrote: I am not sure, but in the graphical installer, we could add a clock widget somewhere from the start, and do clock setting pretty early one (we probably only need hwclock and a little menu thingy), it can even be done before base-install and partman, since there are no extra dependencies. There has been such kind of suggestion last weeks but it has been ruled out. I guess that the rationale is mostly avoiding features that are only available in some D-I flavours. Personally, I find this a pity. I'd think that the graphical installer could benefit from some changes to improve usability, some of which would not make any sense in the textual interface. As an example, one place where I personally feel that the graphical version of the installer does not work very well, is in the partitioner; using different graphical paradigms to display the partitioning being in progress would most likely allow for a more usable interface. However, such an interface would need information that is not necessarily available in the text-based version of the installer. (No, I'm not willing to suggest how to do this, simply because I'm not a graphical guy; but the above is my opinion on the subject) The work started by Xavier Oswald was to address just this, but sadly, we lost month in the no-C++ dogma war, and as a consequence, the resulting C reimplementation is naturally less mature than the original gparted we were wanting to use. The code is there though, in the parted alioth repository, for anyone to continue with Xavier's work, as a previous post was saying here. I still believe that going with the C++ gparted would have been more productive, since the upstream gparted maintainer is both active and cooperative. Again a case where too much conservatism in the d-i leadership and active oposition to newer ideas and experiments did stop what may have been. Ruled out ? Oh well. ... Which explains the rather harsh reply of this question only being 'noise'. So, if a method to set the clock is offerred, it has to work for all interfaces. Well, the .udeb could be common to everything, and the clock button could only be a shortcut to it. ... with a main menu option to allow for invoking it from the text version, if there is interest. Indeed, would be pretty enough, we just need to add a new set of graphic-only hooks or whatever to the package who can make use of it. That being said, of course, it should be so that no important feature must ever be implemented that can only be accessed from one particular interface; as important, I would classify anything which cannot be enabled and/or fixed after the installation has been finished. Thus, I personally would not see any harm in having the ability to set the clock from the graphical installer, but not from the text-based one; of course, YMMV. Well, once the rest of the stuff is there, adding the ability to set the clock from the text-based installer is trivial. A few debconf dialog boxes and that's it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380105: Show current hour in hardware clock question
Indeed. I do believe it is a small-minded ruling lacknig vision and temerity. I am bitter about this whole issue, and this may reflect and color my attitude over this, but since it has been ruled out, i will not insist further, because i know what it is going to cost me once frans is back. It has been écarté, put as low priority, not critical stuff.if someone comes up with a nice working patch, I see no reason for us to reconsider that question, whoever the patch come from. signature.asc Description: Digital signature
Bug#384543: Confirmation: No mouse in GUI with Logitech receiver
I also have the same issue (reported at http://lists.debian.org/debian-boot/2006/08/msg00230.html). Using a hard-wired mouse is a *temporary* solution, but is not satisfactory for a release. Joel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384740: installation-report: Some remarks on Russian support in d-i beta3
User/password setup offers to create an ordinary user account. An attemp to enter the real name in Russian in text mode installer failed: instead of russian letters the text field is filled with sequences like C3D8D5. This happens because the loaded Russian keyboard layout (located in file /usr/share/keymaps/i386/qwerty/ru.kmap.gz on the initrd image) uses KOI8-R encoding. And I have chosen the ru_RU.UTF-8 locale when installer prompted. Obvious solution is to replace current keymap with UTF-8 one like it is done for Ukrainian language. But that way another problem arise: what to do with other locales (ru_RU.KOI8-R, ru_RU.CP-1251 and ru_RU) because they won't have usable russian layout. Does anybody know why all other Russian keymaps (for various encodings) from console-data package are symlinks to the ru.kmap.gz on the installer initrd image? -- Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384543: No mouse in GUI with Logitech receiver
Quoting Attilio Fiandrotti ([EMAIL PROTECTED]): Philipp Kern wrote: On Fri, 2006-08-25 at 10:36 +0200, Attilio Fiandrotti wrote: have you tried using a separate usb mouse instead of logitech mouse to see if the problem is still reproducible? I just tried with a separate USB receiver, an older one which is only capable to serve a mouse. Nothing changes, still no mouse support. I don't have a USB-wired mouse. i think you should try to use a ps2 or a usb cable mouse to see if it works (it should). OK, someone else confirmed that bug. We should think about assigning it to the right package. Attilio, you're way much more aware of this stuff than me. Do you have a suggestion? signature.asc Description: Digital signature
