Re: console-setup + X = broken console
Hi Adam, Adam Majer wrote: Hello, I've just installed the console-setup because X server depends on it. Now, my console is completely unusable. The text does not scroll it just runs off the screen. I'm writing to both maintainers because, 1. Why, why, why is console-setup a dependency of X? X does not function without console-setup? Is it possible to have X only Suggest or Recommend console-setup? Please see http://wiki.debian.org/XStrikeForce/InputHotplugGuide for the rationale and #515214 for more info. 2. What are the settings in console-setup that leave my console alone? I just want to have boot time fonts, with boot time display. The console fonts look rather *bad* and it doesn't matter which ones I try to set. Be it VGA or Terminus or whatever. Is it possible for console-setup to only setup keyboard map and leave the fonts as is? I'm using nvidia drivers which work perfectly until the console-setup dependency broke my console :( - Adam PS. I'm not on the list(s) - CC me in replies As requested. - David Nusinow -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Time to migrate discover1 users to discover v2
On Sat, Jan 12, 2008 at 09:22:07PM +0100, Petter Reinholdtsen wrote: We have discussed migrating discover1 over to discover for a year or so, and I still believe this is a good idea. There is as far as I can see no useful functionality in discover1 that is not covered in discover. Discover v2 on the other hand have the new features to map hardware to debian packages for installation, and this feature should be part of the default Debian installation, I believe. To test it yourself, install discover and run discover-pkginstall as root. Because of this, I have just commited a fix for this in svn+ssh://svn.debian.org/svn/pkg-discover/discover/trunk . I hope I got it right. I implemented two transition packages discover1 and libdiscover1-dev, and added code to remove the /etc/init.d/discover file. Not sure I got the latter right. Any objections to me uploading a new version of discover to take over discover1? If not, I will upload tomorrow. I'm fine with that. The X packages in unstable are done using discover, so whatever path you want to take for the future with the package is ok by me. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Meeting for etch and a half
On Tue, Oct 30, 2007 at 05:36:20PM -0600, dann frazier wrote: On Sun, Oct 28, 2007 at 07:14:06PM -0400, David Nusinow wrote: Would someone please post irc logs for those of us who can't make that date? Yes, we will. Great, thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Meeting for etch and a half
On Sat, Oct 27, 2007 at 06:47:04AM -0600, dann frazier wrote: On Mon, Oct 22, 2007 at 06:24:56PM -0600, dann frazier wrote: (sorry for the nasty cross-posting) hey, Now that 2.6.23 is out and the proposed timeframe for etch 1/2 is just over two months away, its probably a good time to start making some progress on an etch 1/2. Perhaps we should start with an IRC meeting? I've created a wiki page here with an initial stab at an agenda, starting with Is it still a good idea?: http://wiki.debian.org/EtchAndAHalf If we have consensus is to proceed, then I'd like to see if we can come up with a list of next steps. I'll be travelling Thur-Monday of this week, so Wednesday is the only day I can do this week, but next week is pretty open. If you're interested in attending, please mark available times here: http://www.doodle.ch/wa4r43rq55uif8rf Looks like 10/31 @ 18:00 GMT works for most, so lets do that. Would someone please post irc logs for those of us who can't make that date? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scary message on new installations
On Mon, Jul 03, 2006 at 10:03:25AM +0200, Wouter Verhelst wrote: On Sun, Jul 02, 2006 at 11:43:27PM -0700, Steve Langasek wrote: appropriate here than in other cases. Is there some concern about apt-listchanges not listing NEWS files for newly-installed packages? IME, it only lists NEWS.Debian files on upgrades... Mine as well. I had a ton of clueless users early on in the transition to 7.0 because I had documented things in NEWS.Debian, which they were never shown because the package was new. I don't want to go down that road again. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scary message on new installations
On Sat, Jul 01, 2006 at 12:06:16AM -0700, Steve Langasek wrote: On Fri, Jun 30, 2006 at 08:48:31AM -0400, David Nusinow wrote: On Wed, Jun 21, 2006 at 04:05:26PM -0700, Steve Langasek wrote: Since this warning note has been added specifically because the xserver is being removed in situations we don't want it to, and the removal is being caused by a new package that didn't exist in sarge, it is indeed very difficult to detect the difference between an upgrade and a new install. For d-i's purposes, preseeding this d-i note into oblivion is an option, but it would be much nicer if someone could figure out how to keep the xserver from being removed on upgrade in the first place. Would putting back xserver-xfree86 as a transitional package suffice? Since I don't know how to reproduce this problem locally, my best guess is that the server gets removed due to the conflict with x11-common and then nothing is able to install the new one because xserver-xorg doesn't exist to be marked for upgrade. Putting back an empty xserver-xfree86 that pulls in xserver-xorg should suffice in this corner case, letting us remove the note all together. It is still valid for aptitude to remove xserver-xfree86, even as a transitional package, if the old version is conflicted with. There's nothing in our packaging system that lets you mark a particular package as not to be removed on upgrade. A dummy xserver-xfree86 package may fix this for most users, though. Right, but it might be a sufficient hint so that aptitude, and maybe apt, will do the right thing. Ok... I'll lower the priority of the note to medium and add the xserver-xfree86 dummy package. Hopefully that'll be sufficient. As discussed elsewhere, I'd prefer to use NEWS.Debian, but it won't be shown to the user in this case, so a medium priority debconf abusing note should suffice. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scary message on new installations
On Wed, Jun 21, 2006 at 04:05:26PM -0700, Steve Langasek wrote: Since this warning note has been added specifically because the xserver is being removed in situations we don't want it to, and the removal is being caused by a new package that didn't exist in sarge, it is indeed very difficult to detect the difference between an upgrade and a new install. For d-i's purposes, preseeding this d-i note into oblivion is an option, but it would be much nicer if someone could figure out how to keep the xserver from being removed on upgrade in the first place. Would putting back xserver-xfree86 as a transitional package suffice? Since I don't know how to reproduce this problem locally, my best guess is that the server gets removed due to the conflict with x11-common and then nothing is able to install the new one because xserver-xorg doesn't exist to be marked for upgrade. Putting back an empty xserver-xfree86 that pulls in xserver-xorg should suffice in this corner case, letting us remove the note all together. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265016: d-i RC1= keyboard and language not pass to second phase / video / wrong kernel
On Wed, Aug 11, 2004 at 09:03:47AM -0300, Andre Felipe Machado wrote: Output of lspci: :00:00.0 Host bridge: VIA Technologies, Inc. VT8361 [KLE133] Host Bridge :00:01.0 PCI bridge: VIA Technologies, Inc. VT8361 [KLE133] AGP Bridge :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) :00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:07.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 1a) :00:07.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 1a) :00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) :00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50) :00:0f.0 Ethernet controller: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) :01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 The second phase was a bit tricky. The installer did not detect the Trident onboard chipset. Used Vesa. Could you please send the output of lspci -n, as well as the correct X driver to use for your card so we can fix this problem? Thanks. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264963: Installation report for Apple Blue White G3 400 from netinstall CD (powerpc, RC1)
On Wed, Aug 11, 2004 at 12:31:04AM -0500, Evilpig wrote: Output of lspci from my YellowDog install: 00:00.0 Host bridge: Motorola MPC106 [Grackle] (rev 40) 00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 02) 00:10.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE/SG 01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE 1394 Link Layer Controller (rev 02) 01:01.0 IDE interface: CMD Technology Inc PCI0646 (rev 05) 01:02.0 PCI bridge: PicoPower Technology PT86C525 [Nile-II] PCI-to-PCI Bridge (rev 01) 01:03.0 SCSI storage controller: Adaptec AHA-7850 (rev 03) 01:04.0 SCSI storage controller: Adaptec AHA-2940U2/U2W (rev 01) 01:05.0 Class ff00: Apple Computer Inc. Paddington Mac I/O 01:06.0 USB Controller: OPTi Inc. 82C861 (rev 10) 02:08.0 SCSI storage controller: Advanced System Products, Inc ABP940-U / ABP960-U (rev 03) 02:09.0 Multimedia video controller: Zoran Corporation ZR36057PQC Video cutting chipset (rev 02) Output of lspci -n from my YellowDog install: 00:00.0 Class 0600: 1057:0002 (rev 40) 00:0d.0 Class 0604: 1011:0026 (rev 02) 00:10.0 Class 0300: 1002:5245 01:00.0 Class 0c00: 104c:8000 (rev 02) 01:01.0 Class 0101: 1095:0646 (rev 05) 01:02.0 Class 0604: 1066:0004 (rev 01) 01:03.0 Class 0100: 9004:5078 (rev 03) 01:04.0 Class 0100: 9005:0010 (rev 01) 01:05.0 Class ff00: 106b:0017 01:06.0 Class 0c03: 1045:c861 (rev 10) 02:08.0 Class 0100: 10cd:1300 (rev 03) 02:09.0 Class 0400: 11de:6057 (rev 02) Comments/Problems: There were two problems here; the first is pretty minor but the second is more significant. The first issue was that the onboard network card was not detected and I had to choose the BMAC driver from the list myself. Although I realize that not all cards will be autodetected, it seems like this one should be since it was the standard onboard card for the G3 series (at least the blue whites). I can't find your network card in the lspci output at all. Does anyone have any idea why this could be? The installer completed succesfully, but unfortunately wouldn't reboot into Debian. Since this machine doesn't have a serial port I could not capture the output of the boot process in a serial console, so I had to take a picture and type it all out (and I could only get the last screen). From the combination of this output and the lspci, it seems that the problem is related to the firewire module. It's possible that there are minor typos in this since I had to type it by hand, so if you need something verified just ask - it's infinitely reproducable: tsdev: loaded successfully evbug: blacklisted evdev: already loaded input [success] isapnp isapnp [success] net net [success] pci ignoring pci display device on 00:10.0 PCI: Enabling device :01:00.0 (0014 - 0016) pcilynx0: allocated PCL memory 4096 Bytes @ 0xd7f01000 pcilynx0: allocated interrupt 21 pcilynx0: remapped memory spaces reg 0xda1e6000, rom 0xda268000, ram 0xda246000, aux 0xda257000 Machine check in kernel mode. Caused by (from SRR1=41030): Transfer error ack signal Oops: machine check, sig: 7 [#1] NIP: DA1E816C LR: DA1E9CB4 SP: D73FDAE0 REGS: d73fda30 TRAP: 0200Not tainted MSR: 00041030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = d7356cf0[826] 'modprobe' THREAD: d73fc000Last syscall: 128 GPR00: 8200 D73FDAE0 D7356CF0 0200 0002 C02B5CDC GPR08: 000591F5 DA1E6F0C DA1E6000 82088424 1001DD78 GPR16: 10001378 10018850 GPR24: 0020 D73FA000 C1C7CC48 C1C7CC00 D73FBD98 D73FBD9C D73FBD90 9032 NIP [da1e816c] get_phy_reg+0x58/0xf4 [pcilynx] LR [da1e9cb4] add_card+0x4a8/0xbd8 [pcilynx] Call trace: [da1e9cb4] add_card+0x4a8/0xbd8 [pcilynx] [c00b1b80] pci_device_probe_static+0x6c/0x88 [c00b1bec] __pci_device_probe+0x50/0x70 [c00b1c3c] pci_device_probe+0x30/0x60 [c00da81c] bus_match+0x50/0x8c [c00da99c] driver_attach+0x88/0xc8 [c00dacf4] bus_add_driver+0x98/0xec [c00db1a8] driver_register+0x30/0x40 [c00b1f44] pci_register_driver+0x68/0xa4 [da10101c] pcilynx_init+0x1c/0xa8 [pcilynx] [c00365ec] sys_init_module+0x198/0x31c [c0007c40] ret_from_syscall+0x0/0x44 ./pci.agent: line 156: 826 Bus error $MODPROBE $MODULE /dev/null 21 pcilynx: can't be loaded missing kernel or user mode driver pcilynx Looks like a bug in the pcilynx module. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265075: Package: installation-reports
On Wed, Aug 11, 2004 at 09:07:48AM -0700, Nate King wrote: :00:02.0 VGA compatible controller: Intel Corp. 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) It would also be nice to have video auto-detection. I still have to tell the XFree 86 packages what my video hardware is, Could you please send the output of lspci -n as well as the correct X driver to load so we can fix this for you? Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264963: Installation report for Apple Blue White G3 400 from netinstall CD (powerpc, RC1)
On Wed, Aug 11, 2004 at 12:49:02PM -0300, Joey Hess wrote: Evilpig wrote: 00:10.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE/SG 01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE pci ignoring pci display device on 00:10.0 PCI: Enabling device :01:00.0 (0014 - 0016) pcilynx0: allocated PCL memory 4096 Bytes @ 0xd7f01000 You're right about it being the firewire controller module that seems to be crashing. Try booting in emergency mode (linux emergency) and add pcilynx to /etc/hotplug/blacklist. This module is also loaded by discover1-data, so you'll have to add a skip pcilynx line to /etc/discover.conf too. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#264492: NewWorld (G4) PowerPC d-i hardware detect does not see firewire disk
On Tue, Aug 10, 2004 at 04:26:04AM -0400, Rick Thomas wrote: On Monday, August 9, 2004, at 03:55 PM, Rick_Thomas wrote: OK, as I said, output of lspci and lspci -n will be sent tonight, when I can get my hands on the machine in question. Here is the output of lspci ; lspci -n Hope it helps! Ok, I cloned this assigned the clone to discover1-data (I'll fix it in CVS today). Joey or someone else, if you want to load this module by default go for it, otherwise I think it's safe to just close the original install report. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Wish-list: improve instalation manual for non technical people
On Fri, Jun 04, 2004 at 11:58:31AM +0200, Miguel Frasson wrote: Tha manual is written in such way that it seems to say: beginners should avoid Debian or are not good enough to install Debian. Thank you for your suggestions. I've been in the process of reworking the installation manual and I'll definitely take what you say in to account. One of my goals is to make it easier to understand for new users, so hopefully you'll see more of what you need. If you have any more suggestions, feel free to email the list or submit bug reports against the manual. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#252180: libdiscover1-pic: corrupted libdiscover_pic.a
Is d-i even using the -pic lib? Since I'm supremely lazy, if it's not being used I'd just as soon remove the thing than debug it. - David (supremely lazy) Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i daily 040528] Unallowed mount points in root directory
On Sun, May 30, 2004 at 05:49:16PM +1000, Andree Leidenfrost wrote: Right, thanks for letting me know. I checked the discover1 bugs and this doesn't seem to have been reported yet. Would you agree to me filing a bug with severity 'serious' for this against discover1? Please don't bother. We're planning a discover1 upload tomorrow before dinstall, so the fix should be in very soon. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hw-detect and yenta_socket
On Sun, May 30, 2004 at 10:26:33AM -0300, Joey Hess wrote: This is to load the bridge support so discover can scan for devices on the bridge? It looks decidedly dodgy. Why only on 2.6? What is this magic number; Isn't there a clean fix for this, such as running discover again after loading a brdige module? The only fix I can see for discover off the top of my head is basically the same hack. When discover initially loads the modules, check to see if it loads a bridge module. If it does, then re-scan and re-load. I'm not sure how worthwhile this would be to do. Anyone else have a better idea? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sponsor needed for discover1 upload
Hi all, discover1 is in need of an upload. There's a ton of translation fixes, the /media mount point fix for cdroms, and a pretty big fix to prevent segfaults on alpha. Would someone please sponsor the upload I've put together? It's located at http://www.tufts.edu/~dnusin01/discover/ Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: boot logo revisited
On Tue, May 25, 2004 at 07:52:30PM -0700, Joshua Kwan wrote: On Tue, 25 May 2004 22:30:05 -0300, Joey Hess wrote: Would it be ok to go back to the old (klowner) logo? I personally like that one better. AOL - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discover1 upload?
On Thu, May 20, 2004 at 08:16:05AM +0200, Christian Perrier wrote: Is an upload planned for discover1? The last changelog entry is quite huge and not only with translation updates (the /media mount point for instance). I haven't been working on discover1 at all lately, due to real life commitments (which are now, finally eased). Since basically everyone else who's been working on the package has made the modifications as of late, I thought that they could decide when the next upload should be made. I can put together an upload, but it'll take me some time to go through all the changes and whatnot. I'd much rather Gaudenz or Petter did this though, since they're more familiar with what's changed for this new release. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [i10n] Installation Manual Updates
On Thu, May 13, 2004 at 09:07:19AM +0300, Ognyan Kulev wrote: As I'm interested in the Hurd and since you are going to remove Debian GNU/Hurd section, could you also mention somewhere Debian GNU/Hurd, Debian GNU/KNetBSD, and Debian GNU/KFreeBSD? All these are are non-Linux ports[1], and I think there are no such efforts for any of these three outside Debian. All Hurd developers use Debian GNU/Hurd. And I don't know any other distribution that runs glibc on NetBSD or FreeBSD kernel. I may mention these, but the thing is that they're not officially released or supported as of yet. I don't want to clutter a manual that's already filled with information, especially for projects that aren't ready for general users yet. In addition, Debian has about a zillion and a half subprojects, and mentioning them all in the installation manual is insane. Further, the manual is highly specific for a linux install, so it's pointless to talk about non-Linux options when we don't really document how to use them. All in all, it may get a mention in passing, but my ultimate goal is to focus the manual tightly, which is the fundamental goal of any editor. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [i10n] Installation Manual Updates
On Mon, May 10, 2004 at 11:33:05PM +0200, Frans Pop wrote: I agree with Miroslav here. Note that the manual is also likely to be included as a printed document by some Debian CD vendors. I think especially for this use it is very valuable information. And the current text is generally well written. The manual is mainly focussed at Debian newbies. I like the idea of giving them some background info on just what they have downloaded/purchased, especially as Debian is not your run of the mill, pay through your nose piece of software. Here's an alternate approach that I think makes more sense. Rather than give the users a didactic lecture at the beginning of the manual (which most will never read) instead sprinkle the ideas of freedom throughout the manual. Debian's commitment to freedom has allowed it to be ported to multiple architectures. You can find out about these at foo. Things like that. This way, we can emphasize to people throughout why things like Freedom are good for them, and why these are the things that make Debian what they are. Now that I think about it, Gentoo's manual is actually written this way as well, emphasizing choice and flexibility throughout. I'll try and write these as I go, and I'll make a run-through once I'm done with the major edits to add any more in. Hopefully it'll be enough that we can safely remove the majority of Chapter 1 and still retain the spirit of what it tries to accomplish. Thoughts? Please keep these sections in for now. At this stage I think it is more important to get the 'real' content up to date with the installer. I won't remove any of these sections until later, when things are clearer. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [i10n] Installation Manual Updates
Ok, I've finished my general plan for editing up the d-i manual. It's a bit vague at parts, mainly because I won't know how to organize or rewrite parts until I actually start the writing. Since it's fairly large, I posted it to http://www.tufts.edu/~dnusin01/d-i_manual_plan.txt Please let me know if there's any issues with it or other suggestions. I'd like to get started on Chapter 2 soon if possible. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[i10n] Installation Manual Updates
Hi everyone, I'm planning to do some massive hacking on the installation manual, and I'm wondering how the translators would like me to proceed. I plan to do some pretty serious editing, deleting portions completely and adding significant text to other sections, as well as moving lots of what's already there around to reorganize it. Seeing as these changes will be fairly large, how can I help the translators out while I'm doing this work? I can try to focus on one chapter at a time (I have a plan already set up for the first four chapters) and then notify you when that chapter is ready for translation. If there is a better solution, please let me know, I'd appreciate it. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [i10n] Installation Manual Updates
On Mon, May 03, 2004 at 06:46:06AM +0200, Giuseppe Sacco wrote: the Italian translation is about to be started, so it would be perfect if you send an email to [EMAIL PROTECTED] when you complete a chapter. Do you already have a list of chapters that you will not change at all? That's great to hear. I actually plan to change every section of every chapter, as I see a ton of work that needs to be done, although some sections obviously need less work than others. I suppose I can send a mail to each of the l10n lists when a chapter is complete. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new discover-data seems to have problems with many network cards
On Tue, Apr 20, 2004 at 01:25:07AM -0400, Joey Hess wrote: I want to bring bug #243448, which I've just reassigned to discover1-data, to your attention. I'm afraid it may represent a whole class of bugs. It seems that newer versions of discover fail to load modules for many ethernet cards. The reporter of this bug did an excellent isolation of the problem, though the discover-data version he upgraded to was a little old -- it would be nice if he could try again with unstable's discover1-data: Ok, I'll take a look at this as soon as possible. School has gotten insanely busy all of a sudden (I have almost a week's worth of Debian mail backlog already) but I'll try and attack this ASAP. If someone gets a good fix, please feel free to NMU it, maybe even with a higher severity level to make beta4. I'll try and get to it this weekend. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243233: [bruno.majewski@sympatico.ca: Re: Re: Bug#243233: installation report (d-i 20040408)]
- Forwarded message from [EMAIL PROTECTED] - From: [EMAIL PROTECTED] To: David Nusinow [EMAIL PROTECTED] Subject: Re: Re: Bug#243233: installation report (d-i 20040408) Date: Mon, 12 Apr 2004 10:24:26 -0400 Hello -- here it is: [EMAIL PROTECTED]:~$ lspci -n pcilib: Cannot open /sys/bus/pci/devices :00:00.0 Class 0600: 1106:3189 (rev 80) :00:01.0 Class 0604: 1106:b198 :00:0a.0 Class 0100: 9004:7178 (rev 03) :00:0c.0 Class 0400: 109e:036e (rev 11) :00:0c.1 Class 0480: 109e:0878 (rev 11) :00:0f.0 Class 0104: 1106:3149 (rev 80) :00:0f.1 Class 0101: 1106:0571 (rev 06) :00:10.0 Class 0c03: 1106:3038 (rev 81) :00:10.1 Class 0c03: 1106:3038 (rev 81) :00:10.2 Class 0c03: 1106:3038 (rev 81) :00:10.3 Class 0c03: 1106:3038 (rev 81) :00:10.4 Class 0c03: 1106:3104 (rev 86) :00:11.0 Class 0601: 1106:3227 :00:11.5 Class 0401: 1106:3059 (rev 60) :00:13.0 Class 0200: 10ec:8139 (rev 10) :01:00.0 Class 0300: 1002:5157 [EMAIL PROTECTED]:~$ 'hope this helps. /bm De: David Nusinow [EMAIL PROTECTED] Date: 2004/04/12 lun. AM 01:29:32 GMT-04:00 À: Bruno Majewski [EMAIL PROTECTED], [EMAIL PROTECTED] Objet: Re: Bug#243233: installation report (d-i 20040408) On Sun, Apr 11, 2004 at 06:28:33PM -0400, Bruno Majewski wrote: (1) my tv card, an ATI TV WONDER/VE was not detected, nor was the related kernel module loaded. Could you please send the output of lspci -n, as well as the proper kernel module to load? As far as I can tell, your card should have had its module loaded just fine, but I can't be certain without this information. Thanks for testing! - David Nusinow - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#243233: installation report (d-i 20040408)
On Sun, Apr 11, 2004 at 06:28:33PM -0400, Bruno Majewski wrote: (1) my tv card, an ATI TV WONDER/VE was not detected, nor was the related kernel module loaded. Could you please send the output of lspci -n, as well as the proper kernel module to load? As far as I can tell, your card should have had its module loaded just fine, but I can't be certain without this information. Thanks for testing! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241256: possible discover bug ? (Was Re: Bug#241256: Debian-Installer bug report)
On Thu, Apr 01, 2004 at 11:30:47AM +0200, Sven Luther wrote: On Thu, Apr 01, 2004 at 11:34:05AM +0900, Takushi Fujiwara wrote: ps. Installer detect iMac G3(Early 2001) Build in Ethernet but module is not installed. The : GMAC (G4/iBook ethernet) support (OBSOLETE, use Sun GEM) driver has been replaced by the : * Sun GEM Apple GMAC support which should do as fine for you, and is indeed builtin. This should work without problem for you, or else i would like to know about it. The more probable reason for what i seem to understand your problem is, is that discover/discover2 doesn't know about this change, and is not able to load the sungem driver for your hardware, this would be a bugreport against discover if this was the case, but to be certain, we need more info. Right. To fix this, or even check on it, I'll need the output of lspci and lspci -n. Only a couple of things in discover's current database use the sungem driver, so if there are more now, I'd like to get them in. Even if the driver is compiled in to the kernel right now, I'd still like the entry in the database for completeness sake as well as a fallback. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#238472: discover should not load i810-tco
On Sun, Mar 28, 2004 at 03:54:44PM +0200, Andre Tomt wrote: There are many more watchdog drivers in the kernel than i810-tco that may need to be taken care of also. If someone could send me a quick list of these, I'll disable them all in the default discover.conf. I'm not going to release another discover1 update until the current one hits sarge though. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: discover 1 - 2 transition plan for Debian
On Mon, Mar 22, 2004 at 02:48:21AM -0500, David Nusinow wrote: I've attached a patch to the d-i build system that'll have to be applied when both uploads are made to unstable. Now that Petter has uploaded the new disover version, this patch needs to be applied. Since the svn archive no longer allows anonymous access, there's no way I can check to see that he did it, and I can no longer raise him on IRC. Would someone please apply it? Thank you very much. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: discover 1 - 2 transition plan for Debian
On Tue, Mar 23, 2004 at 08:07:43PM -0500, Joey Hess wrote: I'll do this. Awesome, thank you. Don't you have an alioth account? I do (dnusinow-guest) but I haven't been added to the access list for debian-installer though. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: discover 1 - 2 transition plan for Debian
On Tue, Mar 23, 2004 at 08:22:04PM -0500, Joey Hess wrote: Can someone keep an eye on the discover package's progress to testing, and remind us that we need to update hw-detect to install discover1 just before it hits testing? I'll keep an eye on it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#239725: should provide discover-udeb
On Tue, Mar 23, 2004 at 09:25:05PM -0500, Joey Hess wrote: hw-detect depends on discover-udeb, so I think that discover1-udeb should provide it. Currently the d-i initrd build process downloads discover-udeb, but does not put it in the initrd, and in the initrd, hw-detects dependency is unsatisfied. Can a Provides: be the same name as a real package (i.e. discover1 Provides: discover)? It might be better if discover 1 and 2 udebs both provided a third name, like discover, then hw-detect could depend on that. I've got the same question as above for this option :-) - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#239725: should provide discover-udeb
On Tue, Mar 23, 2004 at 10:38:11PM -0500, Joey Hess wrote: David Nusinow wrote: On Tue, Mar 23, 2004 at 09:25:05PM -0500, Joey Hess wrote: It might be better if discover 1 and 2 udebs both provided a third name, like discover, then hw-detect could depend on that. I've got the same question as above for this option :-) This way would work fine, this method is used by many of the virtual packages in d-i. Ok, I'm going to go with this one then. The next upload for discover will have discover1-udeb Provides: discover. Would someone patch discover-udeb to do this too? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#238750: installation-reports
On Thu, Mar 18, 2004 at 07:32:37PM +0100, Patrick Tischler wrote: * At the selection of the desired X server driver there is a wrong(?) preselection, namely vesa. Knoppix and SuSE Linux both recommend the savage driver. Can you please send the output of lspci -n? From what I can tell, your video card's entry in the database is savage, but I can't be certain. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#239151: (no subject)
On Sat, Mar 20, 2004 at 09:54:30PM -0500, Tushar Chandra wrote: System didn't detect my network card. Note that the Beta 2 installer (the previous one) did detect my network card. Odd. Could you please send the output from lspci and lspci -n, as well as the correct module to load for your card? Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6 Development Step 1
On Wed, Mar 17, 2004 at 10:03:53AM +0100, Bastian Blank wrote: On Tue, Mar 16, 2004 at 10:36:31PM -0500, Dan Weber wrote: First mode of action is either merging module-init-tools with busybox or, making a udeb of module-init-tools. Since merging would be sufficiently much cleaner thats my reccomended approach. I need some feedback from Waldi on this one. Upstream already does this, but the debian version currently disabled it. So can this be enabled in the Debian version then? It'd be much nicer to use the upstream code than some custom weirdness. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: discover 1 - 2 transition plan for Debian
On Tue, Mar 16, 2004 at 04:18:26PM +0100, Petter Reinholdtsen wrote:
[Ian Murdock]
That's correct. We can upload Discover 2 whenever you are ready to
do the transition. I actually don't have an up to date key in the
keyring, so Jeff Licquia will be uploading Discover 2 for us for
now.
Sounds good. I'll leave the uploading to Jeff, assuming it happens
fairly fast after the discover1 packages are uploaded. I do not want
the discover1 packages to hit the archive without the discover 2
packages following shortly after. :)
Ok, everything looks good to me on the discover1 front. I haven't looked
at what's going on with discover2, but I'm sure you guys have it well in
hand. All of Petter's changes look good from here, thanks a ton for
handling this. I've attached a patch to the d-i build system that'll
have to be applied when both uploads are made to unstable. Petter
suggested a Tuesday upload time, which I think is a good idea if Progeny
is ready. Is that good for all involved (including someone to apply the
attached patch to the d-i repository)?
- David Nusinow
diff -u -r debian-installer/installer/build/pkg-lists/access/i386
debian-installer.work/installer/build/pkg-lists/access/i386
--- debian-installer/installer/build/pkg-lists/access/i386 2004-03-21
22:53:24.0 -0500
+++ debian-installer.work/installer/build/pkg-lists/access/i386 2004-03-22
02:32:03.0 -0500
@@ -12,7 +12,7 @@
console-keymaps-at
console-keymaps-usb
-discover-udeb
-discover-data-udeb
+discover1-udeb
+discover1-data-udeb
dhcp-client-udeb
diff -u -r debian-installer/installer/build/pkg-lists/cdrom/alpha
debian-installer.work/installer/build/pkg-lists/cdrom/alpha
--- debian-installer/installer/build/pkg-lists/cdrom/alpha 2004-03-21
22:53:24.0 -0500
+++ debian-installer.work/installer/build/pkg-lists/cdrom/alpha 2004-03-22
02:33:35.0 -0500
@@ -3,8 +3,8 @@
socket-modules-${kernel:Version}
console-keymaps-at
console-keymaps-usb
-discover-data-udeb
-discover-udeb
+discover1-data-udeb
+discover1-udeb
cdrom-core-modules-${kernel:Version}
cdrom-modules-${kernel:Version}
ide-modules-${kernel:Version}
diff -u -r debian-installer/installer/build/pkg-lists/cdrom/arm
debian-installer.work/installer/build/pkg-lists/cdrom/arm
--- debian-installer/installer/build/pkg-lists/cdrom/arm2004-03-21
22:53:24.0 -0500
+++ debian-installer.work/installer/build/pkg-lists/cdrom/arm 2004-03-22
02:33:42.0 -0500
@@ -1,6 +1,6 @@
console-keymaps-acorn
console-keymaps-at
console-keymaps-usb
-discover-data-udeb
-discover-udeb
+discover1-data-udeb
+discover1-udeb
kbd-chooser
diff -u -r debian-installer/installer/build/pkg-lists/cdrom/hppa
debian-installer.work/installer/build/pkg-lists/cdrom/hppa
--- debian-installer/installer/build/pkg-lists/cdrom/hppa 2004-03-21
22:53:24.0 -0500
+++ debian-installer.work/installer/build/pkg-lists/cdrom/hppa 2004-03-22
02:34:02.0 -0500
@@ -1,7 +1,7 @@
cdebconf-text-udeb
console-keymaps-at
console-keymaps-usb
-discover-data-udeb
-discover-udeb
+discover1-data-udeb
+discover1-udeb
kbd-chooser
fdisk-udeb
diff -u -r debian-installer/installer/build/pkg-lists/cdrom/i386
debian-installer.work/installer/build/pkg-lists/cdrom/i386
--- debian-installer/installer/build/pkg-lists/cdrom/i386 2004-03-21
22:53:24.0 -0500
+++ debian-installer.work/installer/build/pkg-lists/cdrom/i386 2004-03-22
02:34:09.0 -0500
@@ -2,8 +2,8 @@
socket-modules-${kernel:Version}
console-keymaps-at
console-keymaps-usb
-discover-data-udeb
-discover-udeb
+discover1-data-udeb
+discover1-udeb
floppy-modules-${kernel:Version}
fat-modules-${kernel:Version}
cdrom-core-modules-${kernel:Version}
diff -u -r debian-installer/installer/build/pkg-lists/cdrom/ia64
debian-installer.work/installer/build/pkg-lists/cdrom/ia64
--- debian-installer/installer/build/pkg-lists/cdrom/ia64 2004-03-21
22:53:24.0 -0500
+++ debian-installer.work/installer/build/pkg-lists/cdrom/ia64 2004-03-22
02:34:22.0 -0500
@@ -4,8 +4,8 @@
cdebconf-text-udeb
console-keymaps-at
console-keymaps-usb
-discover-data-udeb
-discover-udeb
+discover1-data-udeb
+discover1-udeb
kbd-chooser
usb-discover
nic-modules-${kernel:Version}
diff -u -r debian-installer/installer/build/pkg-lists/cdrom/m68k
debian-installer.work/installer/build/pkg-lists/cdrom/m68k
--- debian-installer/installer/build/pkg-lists/cdrom/m68k 2004-03-21
22:53:24.0 -0500
+++ debian-installer.work/installer/build/pkg-lists/cdrom/m68k 2004-03-22
02:34:39.0 -0500
@@ -4,8 +4,8 @@
console-keymaps-amiga
console-keymaps-mac
console-keymaps-at
-discover-data-udeb
-discover-udeb
+discover1-data-udeb
+discover1-udeb
kbd-chooser
archdetect
userdevfs
diff -u -r debian-installer/installer/build/pkg-lists/cdrom/powerpc
debian-installer.work/installer/build/pkg-lists/cdrom/powerpc
--- debian-installer/installer/build/pkg-lists/cdrom/powerpc
Re: RFC: discover 1 - 2 transition plan for Debian
On Sat, Mar 20, 2004 at 11:46:29PM +0100, Petter Reinholdtsen wrote: type old name new namedelta - binary discover-udeb - discover1-udeb (NEW) binary dicsover-data-udeb discover1-data-udeb (NEW) binary discover2-udeb discover-udeb (changed, new name existed) binary discover2-data-udeb - discover-data-udeb (changed, new name existed) Petter, we discussed this. I don't think discover2 should be the default discover used in d-i. It's not tested, and in my own private testing I ran up against errors that aren't present in discover1. I do not want to break d-i by using discover2 at this late a date. I'm sorry. discover1 tests fine with kernel 2.6 on my system, and if the user decides to install discover afterwards, they'll get discover2 anyway. I see no point in introducing regressions in the hardware detection system at this point. discover2's database has not been filled out and tested yet. This needs to happen before it's ready for d-i. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: discover 1 - 2 transition plan for Debian
On Sat, Mar 20, 2004 at 08:47:09PM -0500, David Nusinow wrote: On Sat, Mar 20, 2004 at 11:46:29PM +0100, Petter Reinholdtsen wrote: type old name new namedelta - binary discover-udeb - discover1-udeb (NEW) binary dicsover-data-udeb discover1-data-udeb (NEW) binary discover2-udeb discover-udeb (changed, new name existed) binary discover2-data-udeb - discover-data-udeb (changed, new name existed) Petter, we discussed this. I don't think discover2 should be the default discover used in d-i. It's not tested, and in my own private testing I ran up against errors that aren't present in discover1. I do not want to break d-i by using discover2 at this late a date. I'm sorry. discover1 tests fine with kernel 2.6 on my system, and if the user decides to install discover afterwards, they'll get discover2 anyway. I see no point in introducing regressions in the hardware detection system at this point. discover2's database has not been filled out and tested yet. This needs to happen before it's ready for d-i. Sorry, I got a little panicked when I saw the above. I talked to Joey Hess on IRC, and he told me that the plan is to use discover2 as the default for 2.6, which sounds perfect to me. I'll try get some work rollling on that too, if possible. Sorry for misunderstanding. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#238640: sucess
On Wed, Mar 17, 2004 at 11:03:25PM -0600, Jeffrey John Martin wrote: Comments/Problems: It defaulted to vesa instead of nv. VESA didn't work. Could you please send the output of lspci -n? I'll change it to use the nv module instead. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: not releasing powerpc (Re: beta3 released)
On Tue, Mar 16, 2004 at 10:19:59AM +, Colin Watson wrote: Incidentally, do we offer 2.6 on any architecture at the moment? My laptop needs that to be able to run X. (Not a showstopper as such, since I think it still also needs Michel Dänzer's xserver-xfree86-dri-trunk package anyway ...) This is something I'd like to see personally. I had thought that discover1 would have bigger problems with 2.6, but so far in general it seems to be holding up rather well. It'll spit some errors at the user, sure, but it does that anyway right now and shouldn't prove to be a big problem. Are there any other components that people see as holding up 2.6 usage? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: discover 1 - 2 transition plan for Debian
On Tue, Mar 16, 2004 at 02:40:07PM +0100, Petter Reinholdtsen wrote: The alioth CVS for discover1 is updated with my changes. Please review. If the changes are ok, I'll upload today. Please hold off. I may not have time today to review them. Please wait until I've done so before uploading. There's certaintly no rush now that beta3 is out. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discover: all translations commited
On Sat, Mar 13, 2004 at 06:12:05PM +0100, Christian Perrier wrote: As far as I know I commmited and marked pending all discover progra/debconf translations which were waiting in the BTS... Yep, it looks like you got them all. Thanks Christian! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237679: installation-reports
On Fri, Mar 12, 2004 at 07:31:56PM -0500, linux.eqed wrote: There were no network modules loaded according to lsmod... Ok, this is probably because of the dmfe error below. I tried putting in a second NIC card (Linksys 100Tx version 5.1) Did this card work for you? If not, could you send the output of lspci and lspci -n with the card in? Then on the Detecting hardware screen, an error occured while try to load the network modules. Error while running 'modprobe -v dmfe' Removing the Linksys card prevents the error from happening, but also doesn't load the network mods. ps. the on board network card is enabled in the bios, and according to the bios it is a Broadcom Lan Device.. The book for the motherboard says the driver is Davicom Onboard Lan Driver and of course provides the win drivers only. Ok... that looks like it's right. dmfe is, as far as I can see, the Davicom driver for your onboard card. Perhaps it's a problem with the driver itself. I'm going to clone this bug and assign it to the kernel-image package. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New discover1 upload needed
Hello all, I've prepared a new discover upload. The translators have been fantastic lately, so there's tons of new translations in there, as well as a few other fixes including the ash/dash dependency. In addition, I've prepared a discover-data upload to along with it, with a few more pcmcia fixes and some other minor bugs. The sources are located at http://www.tufts.edu/~dnusin01/discover/. If someone would please upload them for me, as I'd like to get these updates in before the next release. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237865: discover: Please apply attached patch to update Brazilian Portuguese po/pt_BR.po translation
tags 237865 pending thanks On Sat, Mar 13, 2004 at 03:17:24PM -0300, Andre Luis Lopes wrote: Please consider applying the attached patch in order to update discover's Brazilian Portuguese translation (it's not the debconf template translation but instead the po/pt_BR.po translation). It was already checked against errors and none were found. Please note that it's important to apply this patch as discover's used in Sarge's second stage installation. Done. It'll be in the next upload. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237880: discover: [INTL:ru] Russian translation
tags 237880 pending quit On Sun, Mar 14, 2004 at 12:56:54AM +0100, Nikolai Prokoschenko wrote: Here an updated, but still uncomplete russian translation. Trying to get at least the debconf templates into the next release Done. It'll be in the next upload. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237894: installation-reports: partman doesn't start and wifi isn't automatically detected on powerbook
On Sun, Mar 14, 2004 at 03:01:31AM +0100, Giuseppe Sacco wrote: After discover showed a list of modules to load (I left all selected) I received an error because sungem, ide-scsi, usb-storage aren't found. I think that all of them are built into the kernel. That's fine. Some people have kernels who don't have these built-in, so I'd rather have discover support them and spit out a few error messages for people who have them built-in. My wifi card (airport) wasn't detected but wifi tools were installed. I did a modprobe airport in tty2 and then configured via DHCP the network. Could you please send the output of lspci and lspci -n? The correct module to load is airport, correct? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237894: installation-reports: partman doesn't start and wifi isn't automatically detected on powerbook
I'm having trouble finding the correct PCI ID in this list. Here's what I think everything is so far. If someone could please shed some light on what I've got wrong, it'd be much appreciated. On Sun, Mar 14, 2004 at 03:43:41AM +0100, Giuseppe Sacco wrote: 00:0b.0 Host bridge: Apple Computer Inc. UniNorth 1.5 AGP AGP controller. Unkown to discover. 00:10.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01) Video card. Unknown to discover. 10:0b.0 Host bridge: Apple Computer Inc. UniNorth 1.5 PCI PCI controller. Unknown to discover. 10:17.0 Class ff00: Apple Computer Inc. KeyLargo Mac I/O (rev 03) Some kind of Mac-specific I/O port. This is actively ignored by discover. 10:18.0 USB Controller: Apple Computer Inc. KeyLargo USB 10:19.0 USB Controller: Apple Computer Inc. KeyLargo USB USB controllers. Discover tries to load usb-ochi. 10:1a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02) PCMCIA controller. Discover tries to load yenta_socket. 24:0b.0 Host bridge: Apple Computer Inc. UniNorth 1.5 Internal PCI PCI controller. Unknown to discover. 24:0e.0 Class : Lucent Microelectronics FW323 (rev ff) I had to Google this. It appears to be the Firewire controller. Unknown to discover. 24:0f.0 Class : Apple Computer Inc. UniNorth GMAC (Sun GEM) (rev ff) Ethernet card. Discover tries to load the sungem module. As far as I know, all the stuff that is unknown to discover is simply built-in to the powerpc kernel, and thus doesn't need to have any modules loaded. If someone who knows more about the airport, or at least has a powerbook to figure this out on, could take a look at what's going on here, I'd appreciate it. Thanks! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237896: discover: Please apply po/ja.po
tags 237896 pending quit On Sun, Mar 14, 2004 at 11:31:03AM +0900, Kenshi Muto wrote: I translated discover-1.5/po/ja.po (Japanese). I believe this message won't be used because normal Linux console don't work with Japanese, but please apply this for future :-) Done. It'll be in the next upload, although I doubt that anyone will ever see it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New discover1 upload needed
On Sun, Mar 14, 2004 at 07:33:19AM +0100, Petter Reinholdtsen wrote: Did you forget to commit it to the alioth CVS? At least I am unable to see the changes. Yeah, I've committed every change that I've made to CVS for both discover1 and discover-data. You can see them when you browse the archive via the alioth cvsweb interface. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New discover1 upload needed
On Sun, Mar 14, 2004 at 08:04:21AM +0100, Petter Reinholdtsen wrote: Strange. I looked for the fix for #237706: discover: Lithuanian translation, and am unable to find it. The debian/po/lt.po file is missing in CVS. Yet the BTS entry claim that it should be commited. That was in my private tree. I guess Christian missed it in his translation commit runthrough. It's in the tree now, although not in the build on my site. Do you want me to upload a fixed version, or are you going to pull it down from CVS? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237679: installation-reports
On Fri, Mar 12, 2004 at 01:03:27PM -0500, linux.eqed wrote: Comments/Problems: Installer did not recognize network, nor gave me options to configure it.. Just failed to find apt sources.. The NIC card is on the motherboard (Soyo P4865PE Plus Dragon2). Did the installer insert the right module for the NIC? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237565: discover: Discover should not depend on ash
On Fri, Mar 12, 2004 at 09:46:59PM +0100, Petter Reinholdtsen wrote: [David Nusinow] That's probably true, but it's a pointless dependancy at this point. I'm just going to switch it to dash and be done with it. discover1 doesn't really need to be built on stable as far as I know. I build it on stable for Debian Edu / Skolelinux. Please do not change the package in such a way that it is unusable in stable. All right, I'll just implement Colin's suggestion then. Thanks for the input. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237679: installation-reports
On Fri, Mar 12, 2004 at 05:03:44PM -0500, linux.eqed wrote: How would I know the correct module is installed? If you can get your network up, or if you know the module you actually need you can check the output of lsmod. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237679: [linux.eqed@comcast.net: Re: Bug#237679: installation-reports]
- Forwarded message from linux.eqed [EMAIL PROTECTED] - Subject: Re: Bug#237679: installation-reports From: linux.eqed [EMAIL PROTECTED] To: David Nusinow [EMAIL PROTECTED] Date: Fri, 12 Mar 2004 17:03:44 -0500 How would I know the correct module is installed? On Fri, 2004-03-12 at 14:19, David Nusinow wrote: On Fri, Mar 12, 2004 at 01:03:27PM -0500, linux.eqed wrote: Comments/Problems: Installer did not recognize network, nor gave me options to configure it.. Just failed to find apt sources.. The NIC card is on the motherboard (Soyo P4865PE Plus Dragon2). Did the installer insert the right module for the NIC? - David Nusinow - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237706: discover: Lithuanian translation
On Sat, Mar 13, 2004 at 01:11:19AM +0200, Kstutis Bilinas wrote: Attached is Lithuanian translation of package discover. Please apply this. Done. It'll be in the next upload. Thank you for the translations! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#236423: discover: sprays lots of daunting error messages during boot
On Sun, Mar 07, 2004 at 07:43:01AM +1000, Andrew Pollock wrote: On Sat, Mar 06, 2004 at 02:03:24PM -0500, David Nusinow wrote: Hi Andrew, Could you please send me the output of lspci and lspci -n? If you also know, or could find the correct module that should be loaded in place of i810_rng I need that as well to fix this. Thank you! Howdy, [EMAIL PROTECTED]:~$ lspci 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 03) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev 12) 00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 12) 00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 12) 00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 12) 00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 12) 00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 12) 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) 03:00.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01) 03:01.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 03:02.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller [EMAIL PROTECTED]:~$ lspci -n 00:00.0 Class 0600: 8086:1a30 (rev 03) 00:01.0 Class 0604: 8086:1a31 (rev 03) 00:1e.0 Class 0604: 8086:244e (rev 12) 00:1f.0 Class 0601: 8086:2440 (rev 12) 00:1f.1 Class 0101: 8086:244b (rev 12) 00:1f.2 Class 0c03: 8086:2442 (rev 12) 00:1f.3 Class 0c05: 8086:2443 (rev 12) 00:1f.4 Class 0c03: 8086:2444 (rev 12) 01:00.0 Class 0300: 10de:0110 (rev b2) 03:00.0 Class 0401: 1274:5000 (rev 01) 03:01.0 Class 0200: 8086:1229 (rev 08) 03:02.0 Class 0c00: 104c:8019 i810_rng's for the random number generator isn't it? Would I need to load anything at all? I don't know. From the rest of discover-data, every single PCI bridge of this type uses the -rng driver, while the ISA bridges use the -tco driver. If you wouldn't mind looking in to this and figuring out which module you actually need, it'd be much appreciated. I can't test it myself witout hardware of course. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discover : how is it maintained?
On Thu, Mar 11, 2004 at 02:54:19PM +0100, Gaudenz Steinlin wrote: I added you to the pkg-discover project. (I hope David does not completely disagree with me on this.) IMO we can also add individual translators if the ask for CVS access. I think that d-i has shown that the probablility of them messing with other files is minimal. That's fine. I'm still not able to access CVS though for some reason, so if you send bug reports via the BTS for now I can add them. All the translations that have been sent so far are in my personal tree and are simply waiting to be uploaded (probably tonight). I'll email Wichert tonight as well and pester him about my CVS errors. Things have been slowly improving there though, so hopefully it's being fixed. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discover-data_1.2004.02.08-2.skolelinux.1_i386.changes ACCEPTED
On Tue, Mar 09, 2004 at 10:31:16PM +0100, Petter Reinholdtsen wrote: Obs. That upload was not supposed to go to the debian archive. It was supposed to go to the skolelinux archive. Sorry about this. Its only change is to add more HW support, so the upload should not break anything. It's fine. Since it probably won't break anything it won't be a big deal. I'm planning on getting one more upload of discover-data together by the end of the week anyway, so I'll incorporate your patch with it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discover : how is it maintained?
On Wed, Mar 10, 2004 at 07:03:48AM +0100, Christian Perrier wrote: Well, I may be wrong (and cannot check, being currently offline), but discover is now maintained by us, D-I Team Where are the package sources (except in the archive..:-))) ? Shouldn't we setup an Alioth project for it as long as we use it in d-i ? This would allow translators to directly commit translations. Those will soon come quickly when we will advertise Seppy's pages for 2nd-stage packages translations. https://alioth.debian.org/projects/pkg-discover/ I suppose we can add you to the access list, but I'd rather just have the standard bug reports with translations sent. It's not like we've had any trouble managing translations in the past this way. If I can get CVS access working properly again I'll get another discover upload ready by the end of the week in addition to the discover-data upload and I'll include whatever translations are necessary (in addition to the ones that are already waiting). - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#236859: Package: installation-reports
Hi Gerald, On Mon, Mar 08, 2004 at 06:42:19PM +0100, Gerald Pichler wrote: The biggest problem of all: My graficcard was not detected. I have a ATI XPert 2000, Mandrake knows this card since I use Mandrake, the XFree86 driver for an ATI Rage 128 TV out fits well, even 3D support works (although unstable sometimes, lockup during tuxracer runs). KNOPPIX also detects my graficcard automatically, so maybe you can look there what needs to be done about this. Could you please send the output of lspci -n, as well as the XFree86 Driver that is supposed to be loaded (I assume that it's ati)? Thank you for testing! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: USB detection problems
On Mon, Mar 08, 2004 at 08:42:57PM -0500, Joey Hess wrote: Santiago Garcia Mantinan wrote: I've been doing more tests now, the problem is that this machine has a intel 82801EB usb controller, and no driver is loaded for it, it could have been uhci, usb-uhci or ehci-hcd, but none is loaded, thus none of the devices atached to it work at all :-( This is what the devices look like for lspci -n: 00:1d.0 Class 0c03: 8086:24d2 (rev 02) Subsystem: 147b:1028 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at bc00 [size=32] 00:1d.1 Class 0c03: 8086:24d4 (rev 02) Subsystem: 147b:1028 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at b000 [size=32] 00:1d.2 Class 0c03: 8086:24d7 (rev 02) Subsystem: 147b:1028 Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at b400 [size=32] 00:1d.3 Class 0c03: 8086:24de (rev 02) Subsystem: 147b:1028 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at b800 [size=32] Looks like we need to add these to discover-data and to usb-discover. I've added it for usb-discover, at least, which should be enough to make the memory stick work. I've added these to discover-data, all using usb-uhci, since that seems to be the precedent at least within the file. As a side note, I've been unable to commit any changes to our alioth CVS repo since the move, so if someone who knows how to fix this would mind contacting me off-list, it'd be much appreciated. 00:1d.7 Class 0c03: 8086:24dd (rev 02) (prog-if 20) Subsystem: 147b:1028 Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at fa10 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] #0a [20a0] Last one is the USB2 thing, the others the USB ones. What is the proper module for the usb2 device? I'll patch this too when the answer appears. - David Nusinow Note: I'm only patching discover1's discover-data right now, this has to be done for discover2 as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sponsor needed for discover-data upload
Hello all, Would someone please sponsor a new upload of discover-data? This update includes a variety of fixes, including a major update of the pcmcia bridge data, which is what around half the bugs we get for this package are about. The package and everything else is located at http://www.tufts.edu/~dnusin01/discover/. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor needed for discover-data upload
On Sun, Mar 07, 2004 at 07:56:20AM -0800, Matt Kraai wrote: Is this the first non-NMU that fixes 187110? If not, you shouldn't use the changelog to close it. You're right. I didn't make that change and I didn't think about it very carefully when I saw it. A new version has been uploaded without that changelog entry. I'll manually close that bug when the upload is made. Thanks Matt! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#236423: discover: sprays lots of daunting error messages during boot
reassign 236423 discover-data quit On Sat, Mar 06, 2004 at 06:48:28PM +1100, Andrew Pollock wrote: This is the output from running discover: Detecting hardware: agpgart eepro100 es1370 i810_rng ich2rom ide-scsi usb-uhci Loading agpgart module. Loading eepro100 module. Loading es1370 module. Loading i810_rng module. /lib/modules/2.4.24-1-686/kernel/drivers/char/i810_rng.o: init_module: No such device snip i810_rng failed Loading ich2rom module. /lib/modules/2.4.24-1-686/kernel/drivers/mtd/maps/ich2rom.o: init_module: No such device Ok, this looks like it's a bug in discover-data, and that it shouldn't be loading these modules on your system. I'm reassigning it accordingly. Thank you for the report! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233147: installation report
Hi Nathan, Could you please send the output of lspci -n, as well as the correct XFree86 driver for your card in the version 4.3 Debian packages? Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#234407: More info
This may have been fixed in #234243 too. Just a note. If we could get the PCI ID's that'd make sure and I can close this with the next upload. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#236423: discover: sprays lots of daunting error messages during boot
Hi Andrew, Could you please send me the output of lspci and lspci -n? If you also know, or could find the correct module that should be loaded in place of i810_rng I need that as well to fix this. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discover == kudzu ?
On Thu, Feb 26, 2004 at 07:32:04PM +1000, Andrew Pollock wrote: I take it that discover is supposed to run all the time on a newly installed sarge system, installed with d-i, not unlike the way kudzu does on a Dead Rat installation? It doesn't run all the time. It runs at bootup, detects the modules to load and loads them, and then is essentially done. If this is the case, can we do something to quieten it down a bit? Often after a new kernel install (or indeed a new install full stop) I like to be able to Shift+PgUp back through the whole boot process to make sure everything was fat and happy. How many lines of output do you get from discover? There shouldn't be all that many. A line telling all the modules to be loaded, and stuff about actually loading them. When discover runs (for me) during the boot process, it spews out a lot of crap (I'll have to see if I can capture it somehow) and makes doing the above impossible. It'd probably also be slightly disconcerting to the average new user to see a lot of error-looking crap scroll across the screen in quick succession. Yes, the output would be useful. Please file a bug report against discover and let us know. Thank you. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release status
On Wed, Feb 25, 2004 at 09:41:57PM +0100, Gaudenz Steinlin wrote: - discover 2 udebs exist, but there are space and testing issues. As some of you may have noticed I did not work much on this in particualr and on debian-installer in general in the last weeks. Until the end of March most of my time will be filled with learning for my university exams (math). I was way to lazy during the semester to have much time left to spend on other things... :-( So I won't have much time to work on discover until the planned beta3 release date. Sorry. I hope I will find more time to work on debian-installer and on Debian in general after the exams. If someone wants to take over the work on the discover package, just go for it. I don't object. You can download the my latest test packages from the pkg-discover website on alioth. Progeny has integrated many of my patches into their svn repo and released 2.0.3 today. I also have to plead guilty here. I've been busy helping out the XSF, trying to rework the xfree86 debconf stuff, hopefully to get some cruft out of base-config as well as provide a much improved X configuration experience for Debian users. I also haven't really sat down and figured out discover2 beyond the very basics. While it looks good right now (and Gaudenz has been doing great work) we've been waiting on Progeny to do an upload, which personally gave me quite a bit of pause. I don't know about the space issues, and from the looks of things, a lot of the benefits of discover2 will be that it can potentially support both 2.4 and 2.6 in the same config file, which discover1 simply can not do. On the other hand, I think a lot of this work still needs to be done, but that can't be done without a ton of bug reports from users with the hardware that needs fixing. So we're kind of in a catch-22 there. Do we put discover2 in to d-i to get as much testing and hardware support as we can before release? Do we go the conservative, if hobbled route, and stick with discover1 at least through the beta3 release and let some of the initial bugs get shaken out in unstable? I don't know. One option is to do the latter, and send a request out to -devel-announce asking for people to please install discover2 and submit bugs so we can get them fixed fast. This, however, requires someone to step in and do the basic grunt work of patching things as the bugs come rolling in, and then to send those reports to Progeny for the next upload. If someone is willing to step in and do this, I feel like this is the best option, because 2.6 support is an often requested feature of d-i, and I'd hate to let people down after all this wait. If we can't get someone to do this work, then I think leaving the known-to-be- functional discover1 in place is probably best. I'd like to have time for this, but I feel like the X debconf stuff is so horribly broken currently that it needs to get fixed fast. All this aside, I don't really know about or understand the space issues with discover2 yet, so I can't comment on that. Someone would also have to figure this out. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lilo troubles
Hi Sam, On Mon, Feb 09, 2004 at 06:50:16PM -0500, Sam Newman wrote: i downloaded the latest sarge (02-08-2004) netinstall image to install debian on a test box to see how i like it. everything runs great until i get to the lilo part. it asks me where to install, but i'm not too sure what to do. i tried installing it to just /dev/hda but that didn't work. this is going to be the only operating system on it, so there aren't any windows conflicts. also, the default install path for lilo doesn't work. i also tried to install the grub boot loader and it froze at 80% (using the default hda0 option). This is a known bug right now. See #231626 all the bugs it is merged with. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i Boot Logo Gallery
On Sun, Feb 08, 2004 at 11:42:59AM +0100, Federico Quagliata wrote: I think the logo by Mark Riedesel (the first in the page[1]), is the best. It's stylish/modern but quite simple, it's nice. The second has the `Debian Linux' write too embossed, while the third looks too much like `Alien'... :P AOL Rock on Klowner! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231626: base-installer: kernel-image is not installed, causing boot loader install to fail
Package: base-installer Severity: normal Hello, I'm not sure if this has been fixed or not, but please see bugs 231573 and all those it is merged with. - David Nusinow -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.0-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Tagging install reports that have been triaged
Hi, So, in an effort to reduce redundant work, should we be tagging the install reports that have been processed in some way? Perhaps with pending? Ideally, there'd be a triaged tag of some kind, but pending seems to be the best solution for now. Are there any objections? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tagging install reports that have been triaged
On Sat, Feb 07, 2004 at 08:46:46PM -0500, Joey Hess wrote: Just close the report, thanking the submitter for his report and mentioning that it's been processed.. Awesome. That's way better. Will do. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: D-I translations: tasksel (Denis Barbier mail to -i18n)
On Wed, Jan 21, 2004 at 09:36:38PM -0500, Joey Hess wrote: Ok then, I have moved tasksel to alioth. At the same time, I have switched it over to using subversion. So the uris to check it out are: While we're requesting new tasks... how about a hardware detection task? Include discover, mdetect, and read-edid in there, at the very least? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: D-I translations: tasksel (Denis Barbier mail to -i18n)
On Sun, Feb 01, 2004 at 01:23:42PM -0500, Joey Hess wrote: discover is installed by default by d-i. base-config goes to great pains to ensure that read-edid and mdetect are installed before X is preconfigured, and to remove them if it turns out the user didn't install X after all. Ah, good to hear. Maybe I should try and do a real full install with d-i then. Sorry about the noise. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unable to load wireless card from beta2
On Fri, Jan 30, 2004 at 10:11:29PM -0500, John Lavin wrote: here are the modules loaded under knoppix when the card works: pcmcia_core yenta_socket orinoco orinoco_cs What happens when you modprobe all of these modules? Are they all present? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i first-stage configuration
On Thu, Jan 29, 2004 at 08:44:28PM +0100, Nikolai Prokoschenko wrote: and he had started one more they-really-should-embrace-gtk discussion Hey, if he wants to write it, let him know he's more than welcome. Maybe we should send out a wide-range call for someone to work on the gtk frontend? If you want it, we do too, so come and code it! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i first-stage configuration
On Thu, Jan 29, 2004 at 09:48:21PM +0100, Nikolai Prokoschenko wrote: And besides, I don't think he has any GTK knowledge at all ;) Well, there's no better time for him to learn! :-) - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: goals for next release
On Wed, Jan 28, 2004 at 02:42:36AM -0500, Joey Hess wrote: That's pretty much the point of this thread. Besides some obvious stuff, I don't really know what we should aim for, and hope some people tell me. :-) Ok, that works for me :-) As for discover2, I'm still sticking with just using discover1 for d-i, unless we can really get discover2 in good shape quickly. For me, it takes a lot of the stress away if we can just stick with discover1 for now, and work towards discover2 eventually. I would very much like to get discover2 in to sid so we can see just how it holds up, in which case it might be a good idea to try it in d-i, but as of now it's really a question mark as I see it. Gaudenz may have other ideas, since he's the one who's actually done all the work on discover2. I really just want to get this thing out though, so sticking with discover1 makes that a bit easier :-) - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229863: Beta 2 boot cd problem with NForce2 MB
On Tue, Jan 27, 2004 at 11:51:50AM -, Dermot Bradley wrote: As the debian-installer CD doesn't seem to have lspci on it I can't provide this (its a brand new machine that has never run Linux before). Do you have a copy of knoppix lying around that you could use instead? Or some other liveCD distro? They should provide lspci for you. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229863: Beta 2 boot cd problem with NForce2 MB
On Tue, Jan 27, 2004 at 10:24:16PM -, Dermot Bradley wrote: Ethernet controller: PCI device 11ab:4320 (Galileo Technology Ltd.) (rev 19). Is this enough info? That's actually plenty right there. Thanks. It'll be patched and fixed in the next discover-data upload. As for the availability of the driver itself, I don't know what to do about that. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: goals for next release
Hi Joey, On Tue, Jan 27, 2004 at 04:18:30PM -0500, Joey Hess wrote: I'm not going to call it beta 3 yet; who knows.. Here are the items from the TODO that are possibilities for the next release, with commentary. I'm trying to get an early sense of what time period to aim for for the next release too. Please add comments and corrections and new items. Just out of curiosity, what are the goals for the sarge release, if any? Just get as much done as possible in time, or is there a more fixed set of goals you'd like to hit? Obviously, sarge is still waiting on some things other than d-i (KDE, X4.3 I hope, etc) but it'd be nice to have some fixed markers to shoot for if you have any in mind. Stopping points are probably good simply because it gives everyone outside the d-i team, including the RM, a better iea of where we stand. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: something for pci.lst
On Mon, Jan 26, 2004 at 09:22:24PM +0100, Gaudenz Steinlin wrote: Discover2 will have a general mechanism to avoid these name conflicts. The hardware database has a field for the kernel version. Beside this (which technically has nothing to do with kernel 2.6) there is nothing I know of which is better suited for 2.6 in discover2 as in discover1. By it's very design either discover1 nor discover2 should depend on the kernel version. Only the discover-data packages could depend on the kernel version. One solution for this problem in discover1 would be to have a discover-data-2.6 package. Ok, I'm willing to set up a discover-data-2.6 package, as well as provide a new version of discover-data where both Provides: discover-data. It's kind of a hack, but I think it'd be worth it for people customizing the sarge version of d-i. I see a few problems with it up front though: 1) When we move to discover2 in sid, we'd have to move the discover-data package to discover-data-2.4. I think I'll actually have both current discover-data packages Provides: discover1-data instead, and the new discover to depend on that. That should help plan for this issue, minimizing its impact. 2) Getting discover-data-2.6 in good enough shape might be difficult in a short time span, but it's certiantly feasible for our current needs. 3) I don't see any clean method to allow the 2.4 and 2.6 packages to coexist. I suppose doing some more hacky garbage with symlinks and a debconf question (the way the *dm packages now do) is an option that I'd be willing to throw together. It sounds really ugly when I weigh it all out, but again, I'm willing to do the work if people will use it. It also gives me extra incentive to help get discover2 in to sid so as to make this mess disappear as quickly as possible :-) Any thoughts? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: something for pci.lst
On Mon, Jan 26, 2004 at 11:42:42PM +0100, Gaudenz Steinlin wrote: I'm not really sure if it's worth the effort. I think we wuld better put our limited time into fixing the already reported discover1 issues and providing discover2 packages (I will work on the latter tomorrow). That's fine with me. Would you mind checking discover2 in to either svn or cvs so I can work on it too? 1) When we move to discover2 in sid, we'd have to move the discover-data package to discover-data-2.4. I think I'll actually have both current discover-data packages Provides: discover1-data instead, and the new discover to depend on that. That should help plan for this issue, minimizing its impact. OK. All right, I'll prep a discover-data-2.6 package tonight if I get some time (I'm in finals right now until the end of the week, so my Debian time is a bit limited for now). Would you like me to check it in to cvs or svn? 3) I don't see any clean method to allow the 2.4 and 2.6 packages to coexist. I suppose doing some more hacky garbage with symlinks and a debconf question (the way the *dm packages now do) is an option that I'd be willing to throw together. I think the easiest would be to make the to packages conflict and document this in README.Debian. Yeah, although I feel like it hurts people who are just testing out 2.6. If I can implement my version quickly and without too much pain then I'll just use that. If not, then the conflicts is definitely the way to go. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: something for pci.lst
On Sun, Jan 25, 2004 at 09:28:33PM +0100, Harald Dunkel wrote: 2.6.1. For 2.4.22 its called ehci-hcd, as it seems. You have to enable the optional development drivers in menuconfig. The naming conflicts between 2.4.x and 2.6.x is something that should be addressed for discover-data. Would it be possible to provide a second pci database for the 2.6.x kernels? Or does discover2 provide a smarter solution? This discover1 fix for 2.6 kernels was a fairly simple way to provide rudimentary support, but it's not meant to be a full solution. 2.6 will be better supported in discover2, although I still don't know the exact mechanism for that (Gaudenz?) since I've been putting all my focus on discover1. Any 2.6-specific fixes will not go in to discover-data while we're using discover1, since the real focus is on 2.4 support, as that's what d-i is using and what sarge will be releasing with. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: something for pci.lst
On Sun, Jan 25, 2004 at 10:21:50PM +0100, Harald Dunkel wrote: What will be the final solution for Sarge: discover or discover2? The plan right now is to use discover1 in the installer, and provide discover2 as well for install later. discover2 may be its own package, or it may be the discover package itself, that has yet to be determined. - David Nusinow p.s. Please don't cc me. I'm on list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#216895: yenta_socket support
Hello, Could you please send me the output of lspci and lspci -n so that I can fix discover to load yenta_socket for your card? Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#203642: I've made the best changes I could
Hello, I've fixed this bug in CVS as best I could. I went through the supported cards list included in /usr/share/doc/xserver-xfree86/status.gz but I am rather limited in that I can't actually test any of these changes myself. Still, the majority of the changes I've made should work fine, if the XFree docs are accurate. The fix will be included in the next upload of discover-data. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229074: discover: [INTL:da] Please add Dansish debconf template
Hello, Could you please resend this as a complete and proper .po file attached to your mail? This makes it so that I can essentially just drop it in to debian/po, which minimizes the number of mistakes I can make with it. Thank you. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229074: discover: [INTL:da] Please add Dansish debconf template
On Sat, Jan 24, 2004 at 08:56:48PM +0100, Claus Hindsgaul wrote: I found the debconf template file on the debian.org/international site. Where can I find a pot or po file? Please, if you can send me or point me to a pot file, I will produce you a proper da.po for inclusion. There is one included in the package. apt-get source discover and then look in discover-1.5/debian/po for the file. There is also one in our CVS repository located in alioth at http://alioth.debian.org/projects/pkg-discover/. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229074: discover: [INTL:da] Please add Dansish debconf template
On Sat, Jan 24, 2004 at 09:22:38PM +0100, Denis Barbier wrote: Here is a da.po obtained by merging your translation with the latest templates.pot file. Great, thank you! It's checked in to CVS now and will be in the next discover upload. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229437: discover: loads module ide-scsi even with kernel 2.6.x
On Sat, Jan 24, 2004 at 09:13:10PM +0100, [EMAIL PROTECTED] wrote: this module is deprecated in 2.6 kernels: - it should not be needed any more - it forces PIO mode instead of DMA Yes, I know about this, but the infrastructure in discover1 doesn't support loading modules per kernel version. Perhaps in discover2. My primary concern for the present with discover1 is to support 2.4 kernels for the new debian-installer as well as the sarge release, so this will have to stay in. A very easy workaround is to put the line skip ide-scsi in to your /etc/discover.conf, and it will not load ide-scsi. I'll document this somewhere in the package in the next upload. Please note that we're also planning on transitioning the discover package in debian to discover2, which will support 2.6 much better. There are preliminary packages available for it if you'd like to test them out. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229442: discover: Module i810_rng does not exist in 2.6 kernels
On Sat, Jan 24, 2004 at 09:33:31PM +0100, [EMAIL PROTECTED] wrote: FATAL: Module i810_rng not found. Skipping i810_rng module; assuming it is compiled into the kernel. This module only exists in 2.4 kernels. Hello, Please see #229437 for an explanation and workaround for this. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#228964: [alex@nibbles.it: Re: Bug#228964: Sarge beta2 installer and LSI Logic MegaRaid controller]
- Forwarded message from Alessandro Polverini [EMAIL PROTECTED] - Subject: Re: Bug#228964: Sarge beta2 installer and LSI Logic MegaRaid controller From: Alessandro Polverini [EMAIL PROTECTED] To: David Nusinow [EMAIL PROTECTED] Date: Sat, 24 Jan 2004 23:15:51 +0100 Hello David, On Fri, 2004-01-23 at 06:38, David Nusinow wrote: On Thu, Jan 22, 2004 at 11:20:30PM +0100, Alessandro Polverini wrote: Here is the relevant rows from lspci and lspci-n: 02:05.0 Ethernet controller: 3Com Corporation 3c940 1000Base? (rev 12) 02:05.0 Class 0200: 10b7:1700 (rev 12) The corrisponding driver is 'sk98lin'. Great. Thank you. I'll fix this right away. Thanks to you! :) What about point #3, related to Megaraid2 driver? Can you give me a few more details? Does the megaraid driver not work? If the device should definitely be using the megaraid2 driver, send me the relevant lspci and lspci -n listings for that too, and I'll fix discover for that as well. Thanks! 02:0b.0 RAID bus controller: LSI Logic / Symbios Logic PowerEdge Expandable RAID Controller 4 (rev 01) 02:0b.0 Class 0104: 1000:1960 (rev 01) I think that it should definitely use the megaraid2 driver, for a number of reasons: - much more modern driver, supporting also very recent controllers - supports /proc/megadrive interface, necessary for monitoring the health of the array Also, beware that in linux 2.6 the old megaraid driver has been dumped and megaraid2 has been renamed megaraid again... So, I think that the installer should be smart enough to use megaraid2 or megaraid depending on the release of the kernel instaling. Last thing: after installing sarge on my server with both raid disks (megaraid) and one ide disk, the system booted and worked well from the raid disk but the ide controller was not detected (piix). I had to put extra modules in /etc/modules to make it work, but in this way /etc/init.d/hdparm does not work because it starts _before_ loading modules from /etc/modules. Thanks for your time, and please tell me if I could be of any help, Alex - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#228964: Sarge beta2 installer and LSI Logic MegaRaid controller
On Sat, Jan 24, 2004 at 11:15:51PM +0100, Alessandro Polverini wrote: 02:0b.0 RAID bus controller: LSI Logic / Symbios Logic PowerEdge Expandable RAID Controller 4 (rev 01) 02:0b.0 Class 0104: 1000:1960 (rev 01) I think that it should definitely use the megaraid2 driver, for a number of reasons: - much more modern driver, supporting also very recent controllers - supports /proc/megadrive interface, necessary for monitoring the health of the array Ok, it sounds like this would be the better choice. I'll change it so that it uses megaraid2. Also, beware that in linux 2.6 the old megaraid driver has been dumped and megaraid2 has been renamed megaraid again... So, I think that the installer should be smart enough to use megaraid2 or megaraid depending on the release of the kernel instaling. Unfortunately, this isn't going to happen right away due to limitations with discover1. See #229437 for an explanation. Last thing: after installing sarge on my server with both raid disks (megaraid) and one ide disk, the system booted and worked well from the raid disk but the ide controller was not detected (piix). I had to put extra modules in /etc/modules to make it work, but in this way /etc/init.d/hdparm does not work because it starts _before_ loading modules from /etc/modules. Discover didn't detect your ide controller either? Ok, you know the drill :-) lspci; lspci -n; and the right module and I'll fix this too. As for the hdparm issue, I really don't know what to tell you. You may simply want to compile a custom kernel with the module built in. Thanks for your time, and please tell me if I could be of any help, My pleasure. Thanks for being prompt with responses. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i and the archive
On Thu, Jan 22, 2004 at 07:30:52PM -0500, Joey Hess wrote: It looks like we have a working testing-proposed-updates queue for debian-installer, so unstable is now open again for developmental uploads. Feel free to upload any udebs to unstable now without worrying about beta 2. Awesome! Thanks Joey and aj and anyone else who was involved in this. Would someone please sponsor an upload of discover? As I previously posted, this includes some major fixes including the module sorting as well as initial 2.6 support. The goods are located at http://www.tufts.edu/~dnusin01/discover/. Thank you! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
