Bug#572869: installation-reports: PowerMac G5 installation report: ofpath doesn't work in the absence of /proc/scsi/scsi
v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:01:0b.0-2.3/input0 [4.936776] [mac] sda1 sda2 sda3 [4.943555] input: Mitsumi Electric Apple Extended USB Keyboard as /devices/pci0001:00/0001:00:08.0/0001:01:0b.0/usb2/2-2/2-2.3/2-2.3:1.1/input/input3 [4.943638] generic-usb 0003:05AC:020B.0003: input,hidraw2: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:01:0b.0-2.3/input1 [4.943680] usbcore: registered new interface driver usbhid [4.943684] usbhid: v2.6:USB HID core driver [4.983909] sd 0:0:0:0: [sda] Attached SCSI disk [5.135196] sat 0 partition c9: c9 6 2 7f ff 2 ff 1 fb bf 0 59 0 20 0 0 0 7 89 37 0 a0 0 0 [5.204418] PM: Starting manual resume from disk [5.308175] kjournald starting. Commit interval 5 seconds [5.318005] EXT3-fs: mounted filesystem with ordered data mode. [5.782780] sat 0 partition c5: c5 4 1 7f a0 12 20 5f ff 55 d7 15 7b 12 0 0 [6.645159] sat 1 partition c8: c8 6 2 7f ff 2 ff 1 fb bf 0 59 0 20 0 0 0 7 89 37 0 a0 0 0 [7.210885] udev: starting version 151 [7.287656] sat 1 partition c4: c4 4 1 7f a0 12 20 5f ff 55 48 15 7b 12 0 0 [8.150283] sat 1 partition c9: c9 6 2 7f ff 2 ff 1 fb bf 0 59 0 20 0 0 0 7 89 37 0 a0 0 0 [8.797169] sat 1 partition c5: c5 4 1 7f a0 12 20 5f ff 55 48 15 7b 12 0 0 [9.195225] irq: irq 28 on host /u...@0,f800/m...@f804 mapped to virtual irq 28 [9.195256] irq: irq 11 on host /u...@0,f800/m...@f804 mapped to virtual irq 25 [9.195274] irq: irq 12 on host /u...@0,f800/m...@f804 mapped to virtual irq 26 [9.195404] irq: irq 30 on host /u...@0,f800/m...@f804 mapped to virtual irq 30 [9.195423] irq: irq 15 on host /u...@0,f800/m...@f804 mapped to virtual irq 29 [9.195443] irq: irq 16 on host /u...@0,f800/m...@f804 mapped to virtual irq 31 [9.204650] snd-aoa-fabric-layout: Using PMF GPIOs [9.228669] snd-aoa-codec-onyx: found pcm3052 [9.229161] snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match! [9.252392] snd-aoa: fabric didn't like codec onyx [9.275411] snd-aoa-codec-onyx: found pcm3052 [9.276123] snd-aoa-fabric-layout: can use this codec [9.332145] snd-aoa-codec-onyx: attached to onyx codec via i2c [9.354902] irq: irq 79 on host /u...@0,f800/m...@f804 mapped to virtual irq 79 [9.354939] irq: irq 75 on host /u...@0,f800/m...@f804 mapped to virtual irq 75 [9.354962] snd-aoa-codec-onyx: created and attached onyx instance [9.432356] windfarm: Backside control loop started. [9.484880] windfarm: Slots control loop started. [9.607033] windfarm: Drive bay control loop started. [ 10.020701] Adding 39536956k swap on /dev/sdb5. Priority:-1 extents:1 across:39536956k [ 10.243954] EXT3 FS on sdb4, internal journal [ 10.460149] loop: module loaded [ 11.272993] irq: irq 8 on host /u...@0,f800/m...@f804 mapped to virtual irq 32 [ 11.315710] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 12.015591] fuse init (API version 7.13) [ 14.486912] tg3: eth0: Link is up at 1000 Mbps, full duplex. [ 14.508833] tg3: eth0: Flow control is on for TX and on for RX. [ 14.525149] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 15.712199] Bluetooth: Core ver 2.15 [ 15.735177] NET: Registered protocol family 31 [ 15.747747] Bluetooth: HCI device and connection manager initialized [ 15.760139] Bluetooth: HCI socket layer initialized [ 15.888025] Bluetooth: L2CAP ver 2.14 [ 15.908962] Bluetooth: L2CAP socket layer initialized [ 16.053963] Bluetooth: RFCOMM TTY layer initialized [ 16.058467] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 16.058472] Bluetooth: BNEP filters: protocol multicast [ 16.076664] Bridge firewalling registered [ 16.132099] Bluetooth: RFCOMM socket layer initialized [ 16.142291] Bluetooth: RFCOMM ver 1.11 [ 16.144935] Bluetooth: SCO (Voice Link) ver 0.6 [ 16.144949] Bluetooth: SCO socket layer initialized [ 18.418932] lp: driver loaded but no devices found [ 19.072287] irq: irq 9 on host /u...@0,f800/m...@f804 mapped to virtual irq 33 [ 19.117427] ADDRCONF(NETDEV_UP): eth1: link is not ready [ 21.709764] Process Xorg (pid:1742) mapped non-existing PCI legacy memory for 0:0a [ 24.632940] eth0: no IPv6 routers present Once you have filled out this report, mail it to sub...@bugs.debian.org. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc64) Kernel: Linux 2.6.32-trunk-powerpc64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- G. Branden Robinson| Free Software Developer| If I have seen further, it is bran...@deadbeast.net | because I am surrounded by midgets. http://deadbeast.net/~branden/ | signature.asc Description: Digital
Re: [RFC] Remove massbuild bashisms
On Tue, Aug 28, 2007 at 05:24:48PM +0200, Jérémy Bobbio wrote:
Hi!
Attached is a patch that will remove bashisms in the massbuild script.
[...]
I don't have a huge personal preference, although I like the idea of
having POSIX compliant shell scripts. If there's no opposition, I'll
commit it in a few days.
[...]
+ BDEP_SOURCE_PREFIX=$(echo $BDEP_SOURCE | head -c 1)
That's a really expensive way of doing that. I recommend POSIX parameter
expansion, which will avoid forks and pipes.
BDEP_SOURCE_PREFIX=${BDEP_SOURCE#?}
--
G. Branden Robinson| It doesn't matter what you are
Debian GNU/Linux | doing, emacs is always overkill.
[EMAIL PROTECTED] | -- Stephen J. Carpenter
http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
Re: [RFC] Remove massbuild bashisms
On Tue, Aug 28, 2007 at 05:24:48PM +0200, Jérémy Bobbio wrote:
+ BDEP_SOURCE_PREFIX=$(echo $BDEP_SOURCE | head -c 1)
My recommendation was wrong -- I left out a step. Try this:
_TMP=${BDEP_SOURCE#?} # everything but the first character
BDEP_SOURCE_PREFIX=${BDEP_SOURCE%$_TMP}
The first expansion gets matches our suffix, and the second removes that
suffix.
Niftily, this works right (for your purposes) even if $_TMP ends up
containing glob characters. They'll be treated literally, and not screw up
your pattern. To stuff a glob pattern to be used as such inside a variable
for use in a later parameter expansion would probably require a clever eval
trick.
Sorry for leading you astray with my first response.
--
G. Branden Robinson| Never attribute to conspiracy that
Debian GNU/Linux | which can be adequately explained
[EMAIL PROTECTED] | by economics.
http://people.debian.org/~branden/ |
signature.asc
Description: Digital signature
Re: Bug#230832: xserver-xfree86: XkbVariant was fi, kb not working in X
On Sat, Nov 27, 2004 at 03:34:48PM +0200, Tapio Lehtonen wrote: I installed Debian GNU/Linux sarge from rc2 netinst cd, not choosing Desktop in the tasksel. After installing, I used aptitude to install Gnome et al. Then when gdm did not start, I noticed xserver-xfree86 was not installed and used aptitude to install also that. Now gdm worked but I could not type some characters. Middle of the keyboard did not work (and it worked OK in console). I saw in /etc/X11/XF86Config-4 that XkbVariant was fi. I had not typed that there, the file was as is from installing xserver. I was not asked during install about keyboard variant. I ran dpkg-reconfigure xserver-xfree86, chose empty to XkbVariant and keyboard started working even in X. I have absolutely no idea how fi magically got poked into the debconf database. If you didn't see any debconf questions about the X server until you ran dpkg-reconfigure, then this must be what happened. The xserver-xfree86 configure script has no logic for automatically populating the keyboard variant parameter. It always defaults to blank[1]. My *only* guess is that language-chooser or some similar mechanism in d-i stuffed this bogus value into the debconf database. I am CCing debian-boot to see if they find that to be a plausible explanation. If they don't, then I have no clue how your debconf database got corrupted in this fashion. It sounds like pure magic. [1] Here's the code, if you're interested: /var/lib/dpkg/info/xserver-xfree86.config: 1644 MAY_BE_NULL=yes validate_string_db_input $(priority_ceil $PRIORITY) xserver-xfree86/config/inputdevice/keyboard/variant (Yup, just that one line.) /usr/bin/dexconf: 230 ### KEYBOARD / INPUTDEVICE 231 232 fetch xserver-xfree86/config/inputdevice/keyboard/rules 233 XKB_RULES=$RET 234 fetch xserver-xfree86/config/inputdevice/keyboard/model 235 XKB_MODEL=$RET 236 fetch xserver-xfree86/config/inputdevice/keyboard/layout 237 XKB_LAYOUT=$RET 238 # XkbVariant and XkbOptions are permitted to be null. 239 db_get xserver-xfree86/config/inputdevice/keyboard/variant 240 XKB_VARIANT=$RET 241 db_get xserver-xfree86/config/inputdevice/keyboard/options 242 XKB_OPTIONS=$RET 243 244 exec 4$DEXCONFTMPDIR/InputDeviceKeyboard 245 cat 4 SECTION 246 Section InputDevice 247 Identifier Generic Keyboard 248 Driver keyboard 249 Option CoreKeyboard 250 Option XkbRules $XKB_RULES 251 Option XkbModel $XKB_MODEL 252 Option XkbLayout $XKB_LAYOUT 253 SECTION 254 if [ -n $XKB_VARIANT ]; then 255 printf \tOption\t\t\XkbVariant\\t\$XKB_VARIANT\\n 4 256 fi 257 if [ -n $XKB_OPTIONS ]; then 258 printf \tOption\t\t\XkbOptions\\t\$XKB_OPTIONS\\n 4 259 fi 260 printf EndSection\n 4 -- G. Branden Robinson| You are not angry with people when Debian GNU/Linux | you laugh at them. Humor teaches [EMAIL PROTECTED] | them tolerance. http://people.debian.org/~branden/ | -- W. Somerset Maugham signature.asc Description: Digital signature
Re: Bug#275492: xserver-xfree86: [debconf] suboptimal driver suggested for Intel Corp. 82852/855GM Integrated Graphics Device rev 2
retitle 275492 discover-data: suboptimal driver suggested for Intel Corp. 82852/855GM Integrated Graphics Device rev 2 (8086:3582 suggests vesa, should be i810) reassign 275492 discover-data clone 275492 -1 retitle -1 discover1-data: suboptimal driver suggested for Intel Corp. 82852/855GM Integrated Graphics Device rev 2 (8086:3582 suggests vesa, should be i810) reassign -1 discover1-data thanks On Sun, Dec 05, 2004 at 11:41:19AM +0100, Lionel Elie Mamane wrote: tag 275492 -moreinfo thanks On Mon, Oct 18, 2004 at 07:09:27AM -0500, Branden Robinson wrote: On Fri, Oct 08, 2004 at 04:27:17PM +0200, Lionel Elie Mamane wrote: Version: 4.3.0.dfsg.1-8 Severity: normal New install; the suggested driver is vesa, instead of i810. When you run: $ discover video What does it say? It says: lp: driver loaded but no devices found Intel Corporation 82852/855GM Integrated Graphics Device Intel Corporation 82852/855GM Integrated Graphics Device Sorry it took me so long to answer; the machine was at IBM's for repair... It took them ONE MONTH AND A HALF to replace the Hard Disk. That much for buying a good brand to have good after-sales service... Okay. Thanks for following up! I am reassigning this bug to discover-data and cloning it for discover1-data. -- G. Branden Robinson| Debian GNU/Linux | Ignorantia judicis est calamitas [EMAIL PROTECTED] | innocentis. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Processed: reassign 265082 to xserver-xfree86
retitle 265082 xserver-xfree86: X-windows was configured incorrectly. [sic] tag 265082 + moreinfo thanks On Thu, Oct 14, 2004 at 01:33:31PM -0700, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.5 reassign 265082 xserver-xfree86 Bug#265082: I cannot find a 'developer' task Bug reassigned from package `installation-reports' to `xserver-xfree86'. Chandler Bing Jeez, could these reassignments *BE* any less useful? /Chandler Bing [The following is a form letter.] Dear bug submitter, Since the XFree86 X server is a large and complex piece of software, some more information is required of you before this bug can be handled. Please run the following commands from a shell prompt to gather and deliver this information to us: $ /usr/share/bug/xserver-xfree86 /tmp/output 31 $ mailx -s Re: Bug#265082 followup [EMAIL PROTECTED] /tmp/output If you do not have a mailx command on your system, you can get it by installing the mailx Debian package; for example, with the aptitude install mailx or apt-get install mailx commands as root. Alternatively, you can also use a mail command that is compatible with mailx's command-line syntax, such as mutt. One very good way to file bugs with the Debian Bug Tracking System is to use the reportbug package and command of the same name. The reportbug program does a lot of automatic information-gathering that helps package maintainers to understand your system configuration, and also ensures that your message to the Debian Bug Tracking System is well-formed so that it is processed correctly by the automated tools that manage the reports. (If you've ever gotten a bounce message from the Debian Bug Tracking System that tells you your message couldn't be processed, you might appreciate this latter feature.) Therefore, I strongly urge you to give reportbug a try as your primary bug reporting tool for the Debian System in the future. If you *did* use reportbug to file your report, then you're receiving this message because the information we expected to see was not present. If you deliberately deleted this information from the report, please don't do that in the future, even if it seems like it makes the mail too large. 50 kB (kilobytes) of configuration and log data is typical. Only if the included information greatly exceeds this amount (more than 100 kB) should you consider omitting it; instead, put it up on the World Wide Web somewhere and provide URLs to it in your report, or in subsequent followup by mailing [EMAIL PROTECTED]. Thank you! -- G. Branden Robinson|It's extremely difficult to govern Debian GNU/Linux |when you control all three branches [EMAIL PROTECTED] |of government. http://people.debian.org/~branden/ |-- John Feehery signature.asc Description: Digital signature
Bug#257478: about your Debian installation report
On Wed, Oct 13, 2004 at 04:54:58PM -0400, Joey Hess wrote: Hello, I'm writing you because you filed an installation report a while ago on an old version of the debian installer. Your installation report was #257478 and can be viewed online at http://bugs.debian.org/257478. [...] If you're unable to do this test for whatever reason, please send a mail to [EMAIL PROTECTED] and let us know, and we will try to look at your report in more detail. I don't have plans to reinstall Debian to the machine in question, but I am planning on testing a newer version of debian-installer on my wife's clamshell iBook. As I recall, the most frustrating things for me were: 1) the lack of a medialess install option; I understand that this is basically a wishlist request and not a bug per se; 2) the RAID partitioning set up confused the hell out of me -- if it has been either fixed or turned off, I don't think anyone else will suffer the confusion I did. -- G. Branden Robinson| To stay young requires unceasing Debian GNU/Linux | cultivation of the ability to [EMAIL PROTECTED] | unlearn old falsehoods. http://people.debian.org/~branden/ | -- Robert Heinlein signature.asc Description: Digital signature
Re: Fresh installation: Keymap broken under X
[Adding -boot and -x to CC list. Sorry for the crossposting. Perhaps this can move away from -devel.] On Thu, Aug 26, 2004 at 08:37:04AM +0200, Christian Perrier wrote: (Joeyh, Kostas, Branden keyboard issues with X when using non-US keyboard...see -devel and bugs 238778 239827 242321 242605) Confuse? This renders the system almost unusable until you fix it by hand. When we have an installer which has become quite usable by non- techies, such a bug is a giant leap backwards. Well, don't try convincing me...rather convince the X team to raise the priority of the keyboard question (that's a possibility)... [...] Plans for synchronizing keyboard settings for X and console are post-sarge...so only workarounds are possible for sarge: -localization-config installed for all non-US installs -X keyboard config question priority raised It wouldn't just need its priority raised; it needs to attempt to calculate a reasonable default based on the value of the debian-installer/keymap debconf template. Theroetically, if that template has a defined answer and the mapping logic is good enough, the priority of the XKB layout question could remain at medium (items which have a reasonable default). BTW, I'm not completely sure this is a backward leap : I don't remember whether a scratch woody install with X in frnech with a french keyboard ends up with a french X keyboard It doesn't. It defaults to us all the time. (the debconf priority is not a drastic change...but that would mean a new upload of the X packages which is certainly not trivial) Eh, well, we've been having to upload it anyway for other reasons. A few translators have raised this problem for a while but we probably didn't make enough noise about it. Most are also culprit because using US keyboard : using local keyboard is not geeky enough...:-) (french ppl are very good at this) This issue is on the TODO list for the debconf-overhaul branch in XSF XFree86 SVN[1], so I'm going to be working on it soon. I still don't know how challenging the mapping from d-i/keymap values to XKB configuration is going to be. If I feel myself getting bogged down, I might do this: * If the answer to d-i/keymap is whatever the value for a typical US PC keyboard is, leave the question priority at medium. * Otherwise, kick the priority up to high. It makes the install more interactive, which people don't like, but only for people'd who likely be even more annoyed by a wrong keymap the first time they start X. Thoughts? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=238778 -- G. Branden Robinson| You are not angry with people when Debian GNU/Linux | you laugh at them. Humor teaches [EMAIL PROTECTED] | them tolerance. http://people.debian.org/~branden/ | -- W. Somerset Maugham signature.asc Description: Digital signature
Bug#255439: Bug#255689: Bug#255439: d-i report
clone 255439 -1 -2 submitter -1 Sven Luther [EMAIL PROTECTED] submitter -2 Sven Luther [EMAIL PROTECTED] retitle -1 xserver-xfree86: [debconf] set subarchitecture-based Macintosh defaults for keyboard on m68k and powerpc Macs retitle -2 xserver-xfree86: [debconf] permit blank answers for monitor sync ranges reassign -1 xserver-xfree86 reassign -2 xserver-xfree86 severity -1 wishlist severity -2 wishlist thanks On Fri, Aug 20, 2004 at 10:11:34AM +0200, Sven Luther wrote: Am checking with the 5964 (Radeon 9200 SE) right now on a cleanly installed d-i install without any of the extra tasksel desktop stuff. A first few comments : 1) i still get proposed a macintosh keyboard by default. i need an pc105 one. Maybe it would be possible to check the subarch, if it is a pmac, then propose macintosh, if not, then propose pcXXX stuff. Yes. Something similar should be done for m68k Macs. They need to use macintosh_old, since 2.4 isn't available for that subarch. Debian 68k guys, is it reasonable to expect 2.6 m68k Mac kernels to use Linux keycodes by default? Cloning a bug for this. 2) it proposed me the us keyboard. Maybe this could be taken from the chosen language used for the console and found in the debconf database ? Yes; there have been several bugs filed about this already, so I'm not cloning a new one. See #238778, #239827, #242321, and #242605. 3) it is not possible to propose an empty monitor lines. I have a DVI connected LCD flat panel, and comenting out the monitor frequencies works best. Cloning a bug for this. d-i guys, I'm done with this bug (#255439) if you want to close it. -- G. Branden Robinson| There is no gravity in space. Debian GNU/Linux | Then how could astronauts walk [EMAIL PROTECTED] | around on the Moon? http://people.debian.org/~branden/ | Because they wore heavy boots. signature.asc Description: Digital signature
Re: Bug#263573: xserver-xfree86: on alpha depends on read-edid which isn't there
reassign 263573 debian-installer thanks On Thu, Aug 05, 2004 at 10:10:37AM +0200, Steffen Grunewald wrote: Package: xserver-xfree86 Severity: normal d-i fails to install Desktop environment due to lack of installation candidate for read-edid. There might be another missing dependency (a string containing openoffice flashed before the dialog window came back) ... may become a separate bug report as soon as I find out about the details. Sounds like a d-i problem; contrary to your bug summary, xserver-xfree86 *doesn't* depend on read-edid, because the package does not exist for the alpha architecture. Package: xserver-xfree86 Status: install ok installed Priority: optional Section: x11 Installed-Size: 15516 Maintainer: Debian X Strike Force [EMAIL PROTECTED] Architecture: powerpc Source: xfree86 Version: 4.3.0.dfsg.1-6+SVN Replaces: xserver-common ( 4.0), libxfont-xtt Provides: xserver Depends: xserver-common (= 4.3.0.dfsg.1-4+SVN), libc6 (= 2.3.2.ds1-4), libgcc1 (= 1:3.4.1-3), zlib1g (= 1:1.2.1), debconf (= 0.5) | debconf-2.0 Suggests: discover, mdetect, read-edid, libglide2 ( 2001.01.26) Conflicts: libxfont-xtt Description: the XFree86 X server The XFree86 X server is an X server for several architectures and operating systems; its architecture was completely redesigned for the 4.0 release, and features a loadable module system in which required modules are loaded on demand by a single server binary as opposed to the video card-specific X servers of the 3.x release. . The XFree86 server supports most modern graphics hardware from most vendors, and supersedes most version 3.x XFree86 X servers. See http://www.xfree86.org/4.3.0/Status.html for information on its support for your particular hardware. . If the discover, mdetect and read-edid packages are installed, this package's configuration script will use them to attempt automatic configuration of the X server based on your information returned by your video card, mouse, and monitor. . Note that on the HP-PA, MIPS, and SuperH architectures, the server's loadable module support is not present, and therefore the XFree86 server is a (very large) single binary. . This package suggests the libglide2 package, which is necessary for the XFree86 X server's glide video driver to work with 3Dfx Interactive's Voodoo Graphics and Voodoo2 cards. Users of other video cards need not install libglide2. (Please ignore the Version: header above.) -- G. Branden Robinson|Beware of and eschew pompous Debian GNU/Linux |prolixity. [EMAIL PROTECTED] |-- Charles A. Beardsley http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#255439: Bug#255689: Bug#255439: d-i report
On Wed, Aug 18, 2004 at 08:41:52AM +0200, Sven Luther wrote: On Tue, Aug 17, 2004 at 07:31:23PM -0700, Daniel Stone wrote: On Tue, Jul 13, 2004 at 11:08:58AM -0500, Branden Robinson wrote: There's the problem. radeon is not a legal value. Use ati instead. Do not use atimisc, r128, or radeon. 'radeon' should be perfectly legal, and just sedded to 'ati' in the XFree86 scripts if they really want to enforce this whole 'only ever use the wrapper' thingo. Problem seems to be that the ati wrapper has some troubles for some of the Radoen 9200 cards, and doesn't load the radeon module appropriately in these cases. That sounds like a bug. I will recheck with both my 5961 and 5964 cards again and confirm this. Okay. Please do, and file a bug if you can still reproduce the problem. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#259525: Bug#255689: Bug#255439: d-i report
On Thu, Jul 15, 2004 at 11:12:33AM +0200, Gaudenz Steinlin wrote: [ cloned bug to discover1-data ] Am Mit, den 14.07.2004 um 11:45 Uhr -0500 schrieb Branden Robinson: On Tue, Jul 13, 2004 at 11:08:58AM -0500, Branden Robinson wrote: There's the problem. radeon is not a legal value. Use ati instead. Do not use atimisc, r128, or radeon. [EMAIL PROTECTED]:~/discover/discover1/discover1-data$ grep Server:XFree86(radeon) pci.lst 1002000bvideo Server:XFree86(radeon) Radeon 7000 [...] 10025c63video Server:XFree86(radeon) RV250 5c63 [Radeon Mobility 9200 M9+] Does that mean, that all these entries should be changed to Server:XFree86(ati)? Yes, please. -- G. Branden Robinson|A celibate clergy is an especially Debian GNU/Linux |good idea, because it tends to [EMAIL PROTECTED] |suppress any hereditary propensity http://people.debian.org/~branden/ |toward fanaticism.-- Carl Sagan signature.asc Description: Digital signature
Bug#257595: Bug#257478: installation-report: PowerMac G4
On Thu, Jul 15, 2004 at 07:09:56PM +0300, Anton Zinoviev wrote: On Sat, Jul 03, 2004 at 01:55:44PM -0500, Branden Robinson wrote: * ugh, this is distressing. d-i created a swap partition but did not construct /etc/fstab such that it would be mounted (the swap partition did not appear at all). I see one reason for this to happen. You specified a swap partition (or d-i did this automatically for you) but then you tried the Guided partitioning tool. In order to start from clean state the first thing this tool does is to set all partitions as unused. Then you canceled the autopartitioning tool and set mount points for the partitions in the way you wanted. The problem is that then you had to specify that you want to use the swap space. I am giving the following title to the cloned bug: When the autopartitioning tool is canceled it should restore the user settings. If you think that there is some other problem, please tell. No; this sounds like a reasonable hypothesis. My memory of this install is getting fuzzy at this point. -- G. Branden Robinson| If you don't think for yourself, Debian GNU/Linux | others will think for you -- to [EMAIL PROTECTED] | their advantage. http://people.debian.org/~branden/ | -- Harold Gordon signature.asc Description: Digital signature
Re: Bug#257302: xfree86: general complaint about XFree86 on Dell Latitude D400
On Tue, Jul 13, 2004 at 01:22:09PM -0400, Joey Hess wrote: Branden Robinson wrote: The debconf reorg is scheduled, but I *don't* have plans to introduce a spurious dependency of xserver-xfree86 on discover, mdetect, or read-edid. Have you considered doing an xfree86-config package that is separate from X and depends on the right set of tools? I like this, because it allows for a xfree86-knoppix-config or whatever. I thought it was agreed a long time ago that it really was the installer's job to get hardware autodetection tools onto the system. That's fine for general purpose hardware detection tools, but for things like read-edid and mdetect, we either end up bloating systems with no X with these tools, or we end up with unresolvable bugs like #250422. On Tue, Jul 13, 2004 at 09:00:21PM +0200, Michael Banck wrote: On Tue, Jul 13, 2004 at 01:22:09PM -0400, Joey Hess wrote: [...] Did the d-i team consider using the xdebconfigurator package? Description: A script used with debconf to autoconfigure xserver-xfree86 A script-package used in conjunction with debconf to autoconfigure xserver-xfree86. This script is supposed to help setup X correctly even with DEBIAN_FRONTEND set to noninteractive. Just a thought, I haven't really seen it in action. I have no objection to this proposal. I'd be happy to work with the xdebconfigurator maintainer to ensure smooth interoperation. -- G. Branden Robinson| Software engineering: that part of Debian GNU/Linux | computer science which is too [EMAIL PROTECTED] | difficult for the computer http://people.debian.org/~branden/ | scientist. signature.asc Description: Digital signature
Bug#255439: Bug#255689: Bug#255439: d-i report
On Tue, Jul 13, 2004 at 11:08:58AM -0500, Branden Robinson wrote: On Mon, Jul 12, 2004 at 02:05:51PM -0300, Cristian Escalante wrote: On Thu, Jul 08, 2004 at 04:09:46PM -0500, Branden Robinson wrote: The XFree86 X server used the driver it was told to use. There are only two ways you can tell the XFree86 X server which driver to use in the d-i environment: 1) Answer a debconf question. 2) Have the question pre-answered by discover. Actually, the question was answered by discover (from config script): mob:/# /sbin/discover --disable=serial,parallel --format=%V %M\t%S\t%D\n video ATI Technologies, Inc. Radeon Mobility U1 XFree86 radeon There's the problem. radeon is not a legal value. Use ati instead. Do not use atimisc, r128, or radeon. Clarification: Discover-data maintainers, This means you! -- G. Branden Robinson| I'm a firm believer in not drawing Debian GNU/Linux | trend lines before you have data [EMAIL PROTECTED] | points. http://people.debian.org/~branden/ | -- Tim Ottinger signature.asc Description: Digital signature
Bug#255439: Bug#255689: Bug#255439: d-i report
On Mon, Jul 12, 2004 at 02:05:51PM -0300, Cristian Escalante wrote: On Thu, Jul 08, 2004 at 04:09:46PM -0500, Branden Robinson wrote: The XFree86 X server used the driver it was told to use. There are only two ways you can tell the XFree86 X server which driver to use in the d-i environment: 1) Answer a debconf question. 2) Have the question pre-answered by discover. Actually, the question was answered by discover (from config script): mob:/# /sbin/discover --disable=serial,parallel --format=%V %M\t%S\t%D\n video ATI Technologies, Inc. Radeon Mobility U1 XFree86 radeon There's the problem. radeon is not a legal value. Use ati instead. Do not use atimisc, r128, or radeon. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#257302: xfree86: general complaint about XFree86 on Dell Latitude D400
On Sun, Jul 11, 2004 at 04:22:35PM -0400, Joey Hess wrote: No, read-edid and mdetect are installed by base-config (but see bug #258690), prior to package installation. They are later removed, iff X was not installed. [...] Since X doesn't declare a dependency on them, selecting them for install at the same time as X does not even guarantee they'll be _unpacked_ when X is conigured. And they will certianly not be available when it's preconfigured. This is why base-config is complicated with the need to mess with read-edid and mdetect itself, and why I'm left with bugs such as #250422 which I cannot fix. There are other, better ways this could be done, but they all require reorganising how X's configuration is done. The debconf reorg is scheduled, but I *don't* have plans to introduce a spurious dependency of xserver-xfree86 on discover, mdetect, or read-edid. I thought it was agreed a long time ago that it really was the installer's job to get hardware autodetection tools onto the system. Has that thinking changed? If so, why? Should Debian's kernel-image packages start depending on hardware detection tools as well? -- G. Branden Robinson| Never attribute to human stupidity Debian GNU/Linux | that which can be adequately [EMAIL PROTECTED] | explained by GNU Libtool. http://people.debian.org/~branden/ | -- Scott James Remnant signature.asc Description: Digital signature
Re: Processed: reassign 257302 to xserver-xfree86
retitle 257302 xfree86: general complaint about XFree86 on Dell Latitude D400 tag 257302 + moreinfo thanks On Fri, Jul 02, 2004 at 10:18:05AM -0700, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.7.95.1 reassign 257302 xserver-xfree86 Bug#257302: Install on DELL Latitude D400 - some X problems Bug reassigned from package `installation-reports' to `xserver-xfree86'. Doesn't d-i install mdetect to autodetect the mouse? If it failed, that's a bug in mdetect. Doesn't d-i install discover to autodetect the video hardware and recommend an appropriate X server and driver? If it failed, that's a bug in discover (probably in discover-data, technically). Finally, even if there is a bug in XFree86 there's nothing I can do about it until I have a *lot* more information. See below. That third OS on your hard drive probably has a QA staff that provides meaningful information to the engineering staff. I wonder what heights Debian could reach if *we* had that... (And by the way, no flames here doesn't magically make a flame message not one; if you don't want to flame, then don't say fiery things.) [The following is a form letter.] Dear bug submitter, Since the XFree86 X server is a large and complex piece of software, some more information is required of you before this bug can be handled. Please run the following commands from a shell prompt to gather and deliver this information to us: $ /usr/share/bug/xserver-xfree86 /tmp/output 31 $ mailx -s Re: Bug#257302 [EMAIL PROTECTED] /tmp/output If you do not have a mailx command on your system, you can get by installing the mailx Debian package; for example, with the aptitude install mailx or apt-get install mailx commands as root. Alternatively, you can also use a mail command that is compatible with mailx's command-line syntax, such as mutt. One very good way to file bugs with the Debian Bug Tracking System is to use the reportbug package and command of the same name. The reportbug program does a lot of automatic information-gathering that helps package maintainers to understand your system configuration, and also ensures that your message to the Debian Bug Tracking System is well-formed so that it is processed correctly by the automated tools that manage the reports. (If you've ever gotten a bounce message from the Debian Bug Tracking System that tells you your message couldn't be processed, you might appreciate this latter feature.) Therefore, I strongly urge you to give reportbug a try as your primary bug reporting tool for the Debian System in the future. If you *did* use reportbug to file your report, then you're receiving this message because the information we expected to see was not present. If you deliberately deleted this information from the report, please don't do that in the future, even if it seems like it makes the mail too large. 50 kB (kilobytes) of configuration and log data is typical. Only if the included information greatly exceeds this amount (more than 100 kB) should you consider omitting it; instead, put it up on the World Wide Web somewhere and provide URLs to it in your report, or in subsequent followup by mailing [EMAIL PROTECTED]. Thank you! -- G. Branden Robinson|When we call others dogmatic, what Debian GNU/Linux |we really object to is their [EMAIL PROTECTED] |holding dogmas that are different http://people.debian.org/~branden/ |from our own. -- Charles Issawi signature.asc Description: Digital signature
Bug#257478: installation-report: PowerMac G4
On Fri, Jul 09, 2004 at 10:58:11AM +0200, Sven Luther wrote: On Fri, Jul 09, 2004 at 01:50:16AM -0500, Branden Robinson wrote: On Sun, Jul 04, 2004 at 03:39:53PM +0100, Colin Watson wrote: I'm aiming to create a new webpage like: http://people.debian.org/~branden/ibook/ I got a pretty good amount of positive feedback on the medialess install concept. Why not contribute to the installation manual instead ? 1) Because there's only so much time in the day; 2) Because the medialess install was an itch I had, and which I could scratch; 3) Because quick installation HOWTOs are preferred by impatient types over big, comprehensive manuals; 4) Because people liked my webpage. -- G. Branden Robinson| The Bible is probably the most Debian GNU/Linux | genocidal book ever written. [EMAIL PROTECTED] | -- Noam Chomsky http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#257478: installation-report: PowerMac G4
On Sun, Jul 04, 2004 at 03:39:53PM +0100, Colin Watson wrote: On Sat, Jul 03, 2004 at 01:55:44PM -0500, Branden Robinson wrote: [...] /dev/hda3 Apple_UNIX_SVR2 untitled 311578126 @ 2018 (148.6G) Linux native [...] The install boot loader step didn't work. I got around this by going to a virtual console and running mkofboot myself. Judging from the size of /dev/hda3, this is the df-on-=100GB problem, fixed in trunk by Martin Michlmayr but not released. I've just uploaded yaboot-installer 0.0.26 containing this fix; a test install in a few days would be appreciated, as my PowerBook doesn't have a disk big enough to test this myself. I don't know how soon I'll be able to get to this, but another install is planned. * want proper hd-media installer image I can't remember if we talked about this on IRC, but how about the netboot images? All you need to add to that is a suitable yaboot and yaboot.conf. Well, yeah, that's kind of the point; I'd like a proper yaboot.conf to be supplied. I'm aiming to create a new webpage like: http://people.debian.org/~branden/ibook/ I got a pretty good amount of positive feedback on the medialess install concept. * RAID1 is hopeless I've never tried it. What's broken? At this point, I don't remember. I just got weird errors on the red screens. It was hard to figure out what I was supposed to do, too. Of course this was my first time trying to configure any kind of RAID on anything. I was flying pretty blind. * want SMP kernels at install time Can you send me your /proc/cpuinfo? Sure. processor : 0 cpu : 7455, altivec supported clock : 1249MHz revision: 3.3 (pvr 8001 0303) bogomips: 1248.46 processor : 1 cpu : 7455, altivec supported clock : 1249MHz revision: 3.3 (pvr 8001 0303) bogomips: 1248.46 total bogomips : 2496.92 machine : PowerMac3,6 motherboard : PowerMac3,6 MacRISC2 MacRISC Power Macintosh board revision : 0001 detected as : 129 (PowerMac G4 Windtunnel) pmac flags : L2 cache: 256K unified memory : 1024MB pmac-generation : NewWorld The main problem with this is that it will stress the already enormously full powerpc CD #1 even further. In order to be able to omit -smp kernels from CD #1, we'll need a good fallback mechanism which doesn't fall over (e.g. install apus kernels by mistake) when confronted with subarchitectures, which I think means that I need to finish off my base-installer rewrite. Yeah. Well, I admit, it's icing. * ugh, this is distressing. d-i created a swap partition but did not construct /etc/fstab such that it would be mounted (the swap partition did not appear at all). partman-basicfilesystems/fstab.d/basic *looks* right ... perhaps you could send /var/log/debian-installer/syslog to the cloned bug? It should have a dump of the partition table somewhere in it. Shortly after filing the bug in the first place, I sent along all my /var/log/debian-installer information, including the syslog. Oh, you said to the cloned bug. -- G. Branden Robinson| Exercise your freedom of religion. Debian GNU/Linux | Set fire to a church of your [EMAIL PROTECTED] | choice. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#255439: d-i report
reassign 255689 discover-data retitle 255689 discover-data: uses 'apm' XFree86 4.x driver for ATI Technologies Inc Radeon Mobility U1 thanks On Tue, Jun 22, 2004 at 02:01:57PM +0100, Martin Michlmayr wrote: clone 255439 -1 retitle -1 Wrong driver chosen for ATI Technologies Inc Radeon Mobility U1 reassign -1 xserver-xfree86 thanks * Cristian Escalante [EMAIL PROTECTED] [2004-06-21 23:22]: - Detect the wrong vga card (apm instead of ati); Can you send your /var/log/XFree86.0.log file please. Sure, I gzipped the XF86Config-4, XFree86.0.log (before updating the driver from *apm* to *ati*) and after the update. In XF86Config-4, you will see (about line 76): Thanks for those logs, I'm cloning this bug and reassigning it to the XFree86 package. The XFree86 X server used the driver it was told to use. There are only two ways you can tell the XFree86 X server which driver to use in the d-i environment: 1) Answer a debconf question. 2) Have the question pre-answered by discover. Consequently, this looks like a discover-data bug to me. Reassigning. Discover-data maintainers, If discover-data doesn't actually report apm as the XFree86 4.x X server driver for the ATI Radeon Mobility U1 (that's Class 0300: 1002:4336), then this must have been user error. Martin, Please keep the above mechanism in mind for future reference. Our XFree86 packages perform *no* autodetection of drivers themselves. -- G. Branden Robinson| If you have the slightest bit of Debian GNU/Linux | intellectual integrity you cannot [EMAIL PROTECTED] | support the government. http://people.debian.org/~branden/ | -- anonymous signature.asc Description: Digital signature
Re: Pre-seeding XFree settings for keyboard in Debian Installer
On Tue, Jun 29, 2004 at 10:52:12PM +0300, Konstantinos Margaritis wrote: conffiles.d/sarge: ispell.preinst xfree86-kbd.preinst conffiles.d/woody: ispell.postinst ktouch.postinst locale.preinstopera6.postinst xfree86-kbd.preinst kde2.postinstlinks.postinst ltsp-xfree86-kbd.? timezone.postinst FYI, as part of the overhaul of xserver-xfree86's debconf (currently scheduled for -7, but which could slip), I'm going to be breaking up the .config script into one functon for each configurable parameter, so it should be fairly easy to slot in whatever you'd like to do. -- G. Branden Robinson| If the jury can count higher than Debian GNU/Linux | two, the case will fail. [EMAIL PROTECTED] | -- Tom Lane, on Forgent's claim of http://people.debian.org/~branden/ |a patent on JPEG signature.asc Description: Digital signature
Bug#257478: installation-report: PowerMac G4
Package: installation-reports Severity: normal INSTALL REPORT Debian-installer-version: 20040621 sarge daily build, from cdimage.d.o uname -a: Linux sisyphus 2.4.25-powerpc-smp #1 SMP mer avr 14 16:31:15 CEST 2004 ppc GNU/Linux Date: 2004-06-21 Method: How did you install? burned CD-R What did you boot off? burned CD-R If network install, from where? n/a Proxied? n/a Machine: Apple PowerMac G4 Processor: PowerPC G4 (x2) Memory: 1GB Root Device: IDE Root Size/partition table: Feel free to paste the full partition table, with notes on which partitions are mounted where. /dev/hda #type name length base ( size ) system /dev/hda1 Apple_partition_map Apple 63 @ 1 ( 31.5k) Partition map /dev/hda2 Apple_Bootstrap untitled1954 @ 64(977.0k) NewWorld bootblock /dev/hda3 Apple_UNIX_SVR2 untitled 311578126 @ 2018 (148.6G) Linux native /dev/hda4 Apple_UNIX_SVR2 swap 1001664 @ 311580144 (489.1M) Linux swap Block size=512, Number of Blocks=312581808 DeviceType=0x0, DeviceId=0x0 Drivers- 1: @ 64 for 23, type=0x1 2: @ 120 for 36, type=0x 3: @ 176 for 21, type=0x701 4: @ 232 for 34, type=0xf8ff /dev/hda3 on / type unknown (rw,errors=remount-ro) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw) Output of lspci and lspci -n: :00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP :00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01) :10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI :10:17.0 Class ff00: Apple Computer Inc. KeyLargo Mac I/O (rev 03) :10:18.0 USB Controller: Apple Computer Inc. KeyLargo USB :10:19.0 USB Controller: Apple Computer Inc. KeyLargo USB :20:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI :20:0d.0 Class ff00: Apple Computer Inc. UniNorth 2 ATA/100 :20:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2 FireWire (rev 01) :20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) :00:0b.0 Class 0600: 106b:0034 :00:10.0 Class 0300: 1002:4966 (rev 01) :10:0b.0 Class 0600: 106b:0035 :10:17.0 Class ff00: 106b:0022 (rev 03) :10:18.0 Class 0c03: 106b:0019 :10:19.0 Class 0c03: 106b:0019 :20:0b.0 Class 0600: 106b:0036 :20:0d.0 Class ff00: 106b:0033 :20:0e.0 Class 0c00: 106b:0031 (rev 01) :20:0f.0 Class 0200: 106b:0032 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[E] Reboot: [O] Comments/Problems: The install boot loader step didn't work. I got around this by going to a virtual console and running mkofboot myself. Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. * want proper hd-media installer image * RAID1 is hopeless * want SMP kernels at install time * ugh, this is distressing. d-i created a swap partition but did not construct /etc/fstab such that it would be mounted (the swap partition did not appear at all). Install logs and other status info is available in /var/log/debian-installer/. Once you have filled out this report, mail it to [EMAIL PROTECTED] -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.4.25-powerpc-smp Locale: LANG=C, LC_CTYPE=en_US.UTF-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#250915: installation-report
On Thu, May 27, 2004 at 12:30:32PM -0300, Martin Michlmayr wrote: * Jason Dobbs [EMAIL PROTECTED] [2004-05-25 21:18]: Unfortunately, I could not get the graphics card working for the version of XFree86 (4.3.0.dfsg.1-1) currently in sarge. It's a PCI Diamond Multimedia Stealth 64 Video 2001 Series card with 1MB ram, which has a S3 Trio 64V+ chipset. I tried S3, VESA VGA drivers, but the best I could come up with was a 640x480 VESA mode. So I installed Woody and got Xfree86 version 3.3.6 running just fine with a 800x600 16bpp mode. However, Sarge no longer supports Xfree86 3.3.6, and I would really prefer to be running Sarge. So I reinstalled Sarge, and tried to build Xfree86 3.3.6 from source. This effort failed, for various reasons (compiler related, I suspect). There are some cards which are no longer supported in 4.x, but I don't know if the S3 Trio is one of them. I'm CCing the debian-x list for more comments. Can you please send the XFree86 logs from 3.3.6? Please see: http://www.xfree86.org/4.3.0/Status29.html -- G. Branden Robinson| The Rehnquist Court has never Debian GNU/Linux | encountered a criminal statute it [EMAIL PROTECTED] | did not like. http://people.debian.org/~branden/ | -- John Dean signature.asc Description: Digital signature
Bug#243233: installation report (d-i 20040408)
On Tue, May 25, 2004 at 04:59:50PM +0200, Fabio Massimo Di Nitto wrote: On Mon, 24 May 2004, Martin Michlmayr wrote: * Bruno Majewski [EMAIL PROTECTED] [2004-04-11 18:28]: (11)Configuring XF86 was painless due to the fact I had read-edid + mdetect installed and rebooted afterwards, before installing XF86. The installer (or is it debconf?) made it possible. The only gripe I would have is the lack, that I remember, of a test button to make sure the chosen settings do look ok. But if you do not have read-edid mdetect installed, ouch. fabbione, any idea about this? afaik the test button is a red hat thingy but I will discuss with the XSF (in CC) and see how complex would it be to have it. It could be done, but I haven't thought carefully about a design for it yet. I'm a little uncomfortable with launching a potentially machine-locking program like the XFree86 X server in the midst of an install. It's a lot nicer to wait until after the machine is installed to do such things. Nevertheless, I am open to suggestions. -- G. Branden Robinson|I just wanted to see what it looked Debian GNU/Linux |like in a spotlight. [EMAIL PROTECTED] |-- Jim Morrison http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Processed: reassign 251020 to xserver-xfree86
reassign 251020 discover retitle 251020 discover: cat /proc/bus/usb/devices hangs, and so discover does thanks On Wed, May 26, 2004 at 06:48:04AM -0700, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.7.95.1 reassign 251020 xserver-xfree86 Bug#251020: xfree86 doesn't recognize horizvert rates + cat /proc/bus/usb/devices hangs, and so discover does Bug reassigned from package `installation-reports' to `xserver-xfree86'. Having caught up on the bug logs: The monitor frequency part of this has already been reported, a fix has been sketched out, and the issue is on the package's TODO list: + #229850: xserver-xfree86: [debconf] monitor selection methods need to be more careful about clobbering autodetected monitor sync ranges; study Jay Berkenbilt's feedback [BR] There seems to be no point cloning this bug just to merge it. Please see #229850 for much more discussion of what's going on. I am therefore reassigning it to discover for the remainder of the issue. I'm pretty sure nothing the XFree86 packages cats /proc/bus/usb/devices, but the xserver-xfree86.config script does invoke discover, so that accounts for the behavior seen. -- G. Branden Robinson| Debian GNU/Linux | // // // / / [EMAIL PROTECTED] | EI 'AANIIGOO 'AHOOT'E http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Processed: Re: Bug#245504: Close bug? (was: Dell GX270 installation report)
On Tue, May 11, 2004 at 02:01:38AM +0100, Colin Watson wrote: On Mon, May 10, 2004 at 05:07:00PM -0500, Branden Robinson wrote: This is almost as bad as just dumping a bug in someone else's lap with no explanation all. PLEASE STOP DOING THIS. I've asked the BTS guys to CC the package address of reassigned bugs by default for years. They either will not do it or it's not a high enough priority to get done. It's not at all trivial to do. The BTS gets two messages: [snip] Thanks for taking the time to explain this. Maybe I just need to write up a boilerplate message for callous reassignment, as I have for certain other pet peeves of mine. -- G. Branden Robinson|You can have my PGP passphrase when Debian GNU/Linux |you pry it from my cold, dead [EMAIL PROTECTED] |brain. http://people.debian.org/~branden/ |-- Adam Thornton signature.asc Description: Digital signature
Re: Processed: Re: Bug#245504: Close bug? (was: Dell GX270 installation report)
reassign 245504 installation-reports thanks The explanation for the cloning and reassignment of this bug to xserver-xfree86 leaves quite a bit to be desired. A) The explanation in the message to the control bot was not CCed to the package maintainer(s), so people have to dig through the bug logs clicking full text links to see the justification. This is almost as bad as just dumping a bug in someone else's lap with no explanation all. PLEASE STOP DOING THIS. I've asked the BTS guys to CC the package address of reassigned bugs by default for years. They either will not do it or it's not a high enough priority to get done. Do not rely on the BTS to do the polite thing. It won't. Take the trouble to tell people why you're foisting a bug off on them. All it costs you is a Cc in your mail to control. B) This particular system has a problem with the display card... Those patches are beyond the scope of the installer of course, but I'll add a wishlist request against xserver-xfree86 anyways. Let's have a look at some of the submitter's text you snipped: This particular system has a problem with the display card which fails to allocate enough memory to start up in anything more than 640x480. The fix is available as a Debian package called 865patch, download from http://www.joepenguin.com (thanks, Joe!) Did you even look at this patch? It's not a patch to XFree86 at all. It's some sort of standalone tool using the Linux Real Mode Interface. In any event, this is far from a proper bug report against xserver-xfree86. xserver-xfree86 has a bug script for a reason. Reassigning this bug to installation-reports. If you're willing to form a coherent case for why there is an XFree86 bug here, please take the time to actually document it instead of cloning bugs and reassigning all over the place. Otherwise, please close the bug. Thanks. -- G. Branden Robinson| The software said it required Debian GNU/Linux | Windows 3.1 or better, so I [EMAIL PROTECTED] | installed Linux. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Full Debian install impressions and facts
On Mon, Apr 19, 2004 at 10:16:40AM +0100, Alastair McKinstry wrote: On 18.IV.2004 at 13:27 (-0500) Branden Robinson wrote: The main challenge here, as I understand it, is that d-i basically uses console-data's paradigm for keyboard description. So what we need is a gigantic mapping table in xserver-xfree86.config to translate console-data keyboard descriptions into XKB Rules/Model/Layout(/Variant?) tuples. [...] One of my post-sarge TODO items for console-tools is to implement xkb keyboard parsing in loadkeys (using X11 libraries). Then merging the two keymap sets, with the X ones being definitive (ie removing separate keymaps for the console). So I would prefer to have the table in console-data and have kbd-chooser / prebaseconfig seed the debconf database for X11. Any comments? That would completely rock. What debconf entries would need to be set? Well, the template names I use for XFree86 are: xserver-xfree86/config/inputdevice/keyboard/rules xserver-xfree86/config/inputdevice/keyboard/model xserver-xfree86/config/inputdevice/keyboard/layout xserver-xfree86/config/inputdevice/keyboard/variant xserver-xfree86/config/inputdevice/keyboard/options These could easily become shared templates. -- G. Branden Robinson| Arguments, like men, are often Debian GNU/Linux | pretenders. [EMAIL PROTECTED] | -- Plato http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Full Debian install impressions and facts
On Fri, Apr 16, 2004 at 10:59:33AM +0200, Christian Perrier wrote: The XFree keyboard was US layout while I had chosen a french layout for the console keyboard during d-i. I think we need some closer interaction between the console-* package settings and the xfree settings. This has been reported many times (see #238778, for example) and the Debian X Strike Force knows it's a problem. I've also communicated with Joey Hess about it. The main challenge here, as I understand it, is that d-i basically uses console-data's paradigm for keyboard description. So what we need is a gigantic mapping table in xserver-xfree86.config to translate console-data keyboard descriptions into XKB Rules/Model/Layout(/Variant?) tuples. -- G. Branden Robinson| Debian GNU/Linux | Ab abusu ad usum non valet [EMAIL PROTECTED] | consequentia. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: why must Debian call Taiwan a Province of China?
On Tue, Apr 06, 2004 at 02:49:27PM +0900, Miles Bader wrote: Branden Robinson [EMAIL PROTECTED] writes: I'm just a naïve gaijin[1], but I'm not sure you're right about that. Written zh_CN and zh_TW look very similar to Western eyes. I've seen a comparison of the two in some Sun documentation, and they really just looked like the exact same glyphs in two different fonts. Like look at English lettering in bold versus normal weight. (Not *exactly* like that, but close). I'm not sure what this has to do with the original question, but the simplified chinese characters used in the PRC can look _very_ different from the traditional forms used in Taiwan (anyway, it's not accurate to say the difference is `close to bold-versus-normal'). Okay. Perhaps the sample I looked at was not truly characteristic. [One easy way to see an example if you use emacs is to view the `hello' buffer (C-h h), and look at the section `Difference among chinese characters' (you need a lot of fonts installed to see them all of course).] Ah, well, I'm a Vim user. ;-) -- G. Branden Robinson|To Republicans, limited government Debian GNU/Linux |means not assisting people they [EMAIL PROTECTED] |would sooner see shoveled into mass http://people.debian.org/~branden/ |graves. -- Kenneth R. Kahn signature.asc Description: Digital signature
Re: why must Debian call Taiwan a Province of China?
On Sun, Apr 04, 2004 at 07:28:49PM -0600, Paul E Condon wrote: Given what I understand of the politics and history of Taiwan/China, I think it is unlikely that the two use the same language *in every detail*. Particularly, I doubt that their usage of technical language jargon is the same. I'm just a naïve gaijin[1], but I'm not sure you're right about that. Written zh_CN and zh_TW look very similar to Western eyes. I've seen a comparison of the two in some Sun documentation, and they really just looked like the exact same glyphs in two different fonts. Like look at English lettering in bold versus normal weight. (Not *exactly* like that, but close). Sun Microsystems has a lot of expertise in this area. We have nothing to gain by taking sides political conflicts like this. The Debian OS can be customized by regional interests if needed. Beijing and Taipei can each make their own politically-correct forks of Debian if they need to, deleting offensive nomenclature about the other country. Similarly, Kurds in Iraq or Turkey may create Kurdistan GNU/Linux, to the irritation of the Turkish government and the U.S. occupation force in Iraq. Chechen rebels or Basque separatists could fork Debian, too. IMO, we should neither try to take a strong position on these politically explosive issues, nor should we try to walk on eggshells. I think we should take a similar approach as we do to package management. If we have developer(s) willing to vouch for legitimacy of a locale, and willing to maintain support for it, we should include it. If some governmental interest needs to bowdlerize our distribution to satisify their political sensibilities, they can go ahead. I think it says a lot about Debian success that we've come as far as we have -- we're a long way from worrying about fortunes-off and the Purity Test. Now we're worried about pissing off governments. :) If any Chinese would like to offer me some education on this subject in private mail, please feel free. I have read the Wikipedia article on the Republic of China[3] already, though. [1] Yes, I know that's not a Chinese word. [2] At the same time, from my modest knowledge of Chinese history since 1949, it's hard to find neutral terminology. Neutral terms about this issue seem to get perverted over time into euphemisms for either unificiation or independence, and then become political footballs. [3] http://en.wikipedia.org/wiki/Republic_of_China -- G. Branden Robinson|I reverse the phrase of Voltaire, Debian GNU/Linux |and say that if God really existed, [EMAIL PROTECTED] |it would be necessary to abolish http://people.debian.org/~branden/ |him. -- Mikhail Bakunin signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Fri, Apr 02, 2004 at 10:16:00AM -0700, Joel Baker wrote: On Fri, Apr 02, 2004 at 02:19:57AM -0500, Branden Robinson wrote: 2-clause BSD, as used by the NetBSD Foundation, would be good, too. Er. Be careful with this statement. The Foundation's policy has varied between at least (that I *know* of) 2 and 4 clause licenses. Their widespread use of the 4-clause for a time is part of the conversations with them about the kernel source, among other things. Not that 2-clause isn't good; more that folks shouldn't assume that just any random thing with the NetBSD copyright on it is 2-clause, unless it does in fact appear to be a 2-clause license. Yes, this *should* be obvious, but I've run into folks who seem to forget this detail... (ah, the joys of trying to hunt down upstreams who haven't been seen in over a decade, some of whom now are now CTOs with battalions of secretaries to keep them from being bothered...) I simply meant as *used* by the NetBSD Foundation (as opposed to some crazy other variant of the 4-clause BSD which, say, might drop clauses 1 and 2 but keep 3 and 4); I wasn't trying to imply that it was the sole license they employed. Thanks for adding more info, though. -- G. Branden Robinson|There is no housing shortage in Debian GNU/Linux |Lincoln today -- just a rumor that [EMAIL PROTECTED] |is put about by people who have http://people.debian.org/~branden/ |nowhere to live.-- G. L. Murfin signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Thu, Apr 01, 2004 at 11:11:43AM +0200, Sven Luther wrote: This would be a good solution. What about the later Apple licence ? If we can get it under the MIT/X11 license it doesn't matter what other licenses it's under. The MIT/X11 license is non-exclusive. Well, i ask, because apple may be more inclined to use a licence they have experience with. 2-clause BSD, as used by the NetBSD Foundation, would be good, too. -- G. Branden Robinson| We either learn from history or, Debian GNU/Linux | uh, well, something bad will [EMAIL PROTECTED] | happen. http://people.debian.org/~branden/ | -- Bob Church signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Thu, Apr 01, 2004 at 09:57:21AM +0200, Wouter Verhelst wrote: On Thu, Apr 01, 2004 at 12:27:09AM -0500, Branden Robinson wrote: IMO we should do a clean-room implementation anyway. 1) Past experiences with Apple have not been very fruitful, just ask the Linux Mac68K hackers. Well, actually, they have been. It is true that Apple has long refused to give out specifications for mac68k hardware, but after many requests, they have given out the requested information to the NetBSD folks, on the condition that they would share it with any interested party. The Linux/mac68k hackers have the information, and are slowly improving drivers with it. Whether history will repeat itself, I do not know... Ah, that's happy news. Does that mean floppy disk support for, say, the Quadra 840AV is just a matter of getting a good C programmer to type something up from the specs in NetBSD's possession? -- G. Branden Robinson| Software engineering: that part of Debian GNU/Linux | computer science which is too [EMAIL PROTECTED] | difficult for the computer http://people.debian.org/~branden/ | scientist. signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Tue, Mar 30, 2004 at 09:03:19AM +0200, Sven Luther wrote: On Mon, Mar 29, 2004 at 01:10:36PM -0800, Jeff Bailey wrote: On Mon, Mar 29, 2004 at 04:05:48PM -0500, Branden Robinson wrote: Hacker #2 affirms that he has never looked at the existing boot sector, and will not do so in the future. He or she understands MacOS well enough to know how to hand-code 1kB worth of assembly (or possibly compilable C code) to create a functionally-identical boot sector from the plain English description. If I understand right from my GNU hacking, it's preferable to take a slightly different approach if possible. Doing some of it in C instead of ASM (if at all possible, obviously) might result in that anyway. Notice that there is 200bytes or so of m68k asm, most of them A-trap calls to the Mac OS rom, concerned. I doubt you have much chance of getting anything but a 100% identical code, whatever the way you go at generating it. If true, and you're confident enough in this that you think we'd have no trouble finding an expert witness (such as a professor of computer science) to testify to this effect, then in the United States, this would be a serious blow to such code being copyrightable in the first place. Under U.S. copyright law, a work has to be expressive and original to enjoy copyright protection. If there's only one way, or an extremely narrow range of ways to accomplish something, copyright does not attach. For example, in the U.S., you cannot copyright your filled-out income tax return. Of course, I speak of the U.S. only. In other jurisdictions, it may be possible to assert a copyright on, for instance, the sequence of prime numbers smaller than 100, in increasing order. Whether we need to be worried about other jurisdictions is a question I will leave to others, as I'm only willing to play armchair lawyer with respect to U.S. law. Anything you may do, these calls are needed, you could add some noop calls in between, or some random stuff, but i doubt that this will be more than smoke and mirrors. I don't think it's necessary to try to obfuscate anything at all. -- G. Branden Robinson| Our ignorance is God; what we Debian GNU/Linux | know is science. [EMAIL PROTECTED] | -- Robert Green Ingersoll http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Tue, Mar 30, 2004 at 10:56:25AM +0200, Sven Luther wrote: On Tue, Mar 30, 2004 at 03:26:20AM -0500, Branden Robinson wrote: You don't need permission to reverse-engineer anything. If we're going to talk to Apple, we should ask them to release the boot sector and anything else we need within the scope of this problem under a DFSG-compatible license. Only problem would be if they don't have the source code for this 10+ year old little bit of code. That's only conceivably a problem if we want to ask them to GPL or LGPL it. We could ask for the stuff to be licensed under the MIT/X11 license, including the source if they can find it. -- G. Branden Robinson| My first priority in any attack is Debian GNU/Linux | to solve the problem - not issue a [EMAIL PROTECTED] | press release. http://people.debian.org/~branden/ | -- Steve McInerney signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Tue, Mar 30, 2004 at 03:38:27PM +0100, Henning Makholm wrote: Scripsit Branden Robinson [EMAIL PROTECTED] On Mon, Mar 29, 2004 at 11:53:49PM +0100, Henning Makholm wrote: Scripsit Branden Robinson [EMAIL PROTECTED] Worse case scenario, this could be clean-room reimplemented. Before doing that, somebody ought to approach Apple and ask explicit permission to reverse-engineer the boot-block code and distribute the reverse-engineered source under a free license. You don't need permission to reverse-engineer anything. If the thing that is being reverse-engineered is covered by copyright, and the reverse-engineering follows it tightly enough that the result is a derivate of the original thing, then some kind of permission *is* needed. I don't think your understanding of reverse-engineering is applicable in the U.S. A copyright is not a patent. If you came by a functionally identical result through independent means (and clean-room reverse-engineering qualifies as such under U.S. court precedent), then you're free and clear of copyright concerns. -- G. Branden Robinson| It's not a matter of alienating Debian GNU/Linux | authors. They have every right to [EMAIL PROTECTED] | license their software however we http://people.debian.org/~branden/ | like. -- Craig Sanders signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Wed, Mar 31, 2004 at 02:00:46PM +0200, Sven Luther wrote: Notice that it is very probable that Apple will probably in this case not assert copyright on this bit of obsolet code. That's not the way I'd bet. U.S. corporations tend to jealously guard everything they possibly can, and grasp for everything else. Do we know someone at apple who may wish to comment on this stuff ? Good question; I do not. Well, can you copyright the usage instructions of a care (like open the door, sit, but your belt on, insert the key, push cloach and a bit of accelerator and then turn the key, ...). Sure. If we independently come up with our set of instructions, and persuasively illustrate that our creation *was* independent, there's no problem here, and to credible threat of copyright infringement. For example, in the U.S., you cannot copyright your filled-out income tax return. Of course, I speak of the U.S. only. In other jurisdictions, it may be possible to assert a copyright on, for instance, the sequence of prime numbers smaller than 100, in increasing order. Well, probably, but as i believe some over 2000 year old dead greek has the copyright over this, ... A) Copyright as a concept only stretches back to widespread use of the printing press. B) I know of no jurisdiction in the world that has retroactively applied copyright to anything antedating publication of the Gutenburg Bible. And in sensible legislations, you cannot copyright algorithms, not the result thereof, so ... Generally true; software patents are used for that instead. Whether we need to be worried about other jurisdictions is a question I will leave to others, as I'm only willing to play armchair lawyer with respect to U.S. law. Well, the US are mostly the most restrictive (unreasonable) juridiction on this kind of issues, so ... That's not my experience. The U.S. is very aggressive about extending the duration of copyrights, and deserves to be criticized for that, but it is far from the worst offender with respect to the *breadth* of copyright. In the U.S., we have consumer protections such as the right of first sale and fair use written into our laws and upheld in the courts. Standing Supreme Court precedent in _Feist v. Rural Telephone Service Company_ also prohibits the application of copyright to factual data (as well as simple collections of factual data).[1] As I understand it, the U.K., for example, has none of the above, and many European jurisdictions recognize droit d'auteur, which -- rightly or wrongly -- imposes further restrictions on what end-users can do with the works of others. [1] It's worth noting that every session of Congress since _Feist_ was decided has seen bills introduced that attempt to extend copyright to mere collections of facts. To date, such bills have not passed, fortunately. -- G. Branden Robinson|Freedom is kind of a hobby with me, Debian GNU/Linux |and I have disposable income that [EMAIL PROTECTED] |I'll spend to find out how to get http://people.debian.org/~branden/ |people more of it. -- Penn Jillette signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Wed, Mar 31, 2004 at 02:06:11PM +0200, Sven Luther wrote: Huh ? If it would be licenced under the MIT/X11 licence, there is no need for the source code for us to distribute it ? I was figuring we'd just disassemble it and call that the source code. As long as that's true in practice for us, and we actually treat it like de facto source code, adding comments to it and modifying it as needed, I don't see a DFSG 2 problem here. This would be a good solution. What about the later Apple licence ? If we can get it under the MIT/X11 license it doesn't matter what other licenses it's under. The MIT/X11 license is non-exclusive. Notice that the DFSG doesn't cope well with lost source code or lost legal paperstuff needed to assertain (and modify) the licence. As was shown in the case of the ocaml old-bignum case, whose licence ownership was lost in the DEC - Compaq - HP mess. I don't think the spirit, intent, or letter of DFSG 2 is breached as long as we have something that *really is* the source code for us. What does violate DFSG 2 is shipping binaries, or obfuscated source, and hand-waving it as Free because it's the best we can do, when it's a hopeless task for us to substatively modify the work. My argument does presume that we have people who are capable of hacking up OldWord PowerMac boot sectors, and who proceed to do it to get d-i working for those machines. From personal experience with some of our developers, I don't think our ability to do can reasonably be questioned. In this case, would a disclaimer from HP as the potential IP holder be enough for freeing the code, at least until someone else with the said IP papers can come out and claim the copyright ? Especially when there is assumption that such papers where irremedially lost. A nice comparative of this is the AROS project, who were told by Amiga Inc to be infringing the Amiga IP or whatever, but where Amiga Inc was never able to come up with the papers supporting their claim, as it seems that the amiga IP rights got lost somehow in the 10+ proprietary chain. Probably someone left with them in their pocket during that time. I don't feel qualified to speak to the ocaml-bignum or AROS cases, and which in any case are not relevant to d-i. I will observe that if the people who claim you're infringing their copyrights publicly admit that they can't susbtantiate their claim, there's probably not much to worry about. But I am not a lawyer and this is not legal advice. -- G. Branden Robinson|Beware of and eschew pompous Debian GNU/Linux |prolixity. [EMAIL PROTECTED] |-- Charles A. Beardsley http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Wed, Mar 31, 2004 at 02:29:22PM +0100, Henning Makholm wrote: Um, sorry for temporarily misplacing my temper here. I see now that I have indeed expressed myself ambguously. I originally wrote something like Before we begin a clean-room reimplementation, we should ask Apple for permission to do foo. Most readers have understood that to mean we cannot do a clean-room reimplementation without permission to do foo, and tried to tell me that this is wrong, which indeed it is. What I really meant was Doing foo is easier and safer than a clean-room reimplementation, but would need permission from Apple. We should not begin spending effort on a clean-room reimplementation until we have reason to believe that Apple won't let us do foo instead. Does that make my subsequent comments clearer? Thanks for the clarification. IMO we should do a clean-room implementation anyway. 1) Past experiences with Apple have not been very fruitful, just ask the Linux Mac68K hackers. 2) I disagree that disassembling the boot ROM is safer. What's safer from a legal perspective is a clean-room reimplementation. -- G. Branden Robinson| Debian GNU/Linux | If encryption is outlawed, only [EMAIL PROTECTED] | outlaws will @goH7Ok=q4fDj]Kz?. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Mon, Mar 29, 2004 at 11:53:49PM +0100, Henning Makholm wrote: Scripsit Branden Robinson [EMAIL PROTECTED] Worse case scenario, this could be clean-room reimplemented. Before doing that, somebody ought to approach Apple and ask explicit permission to reverse-engineer the boot-block code and distribute the reverse-engineered source under a free license. You don't need permission to reverse-engineer anything. If we're going to talk to Apple, we should ask them to release the boot sector and anything else we need within the scope of this problem under a DFSG-compatible license. -- G. Branden Robinson| Debian GNU/Linux | Extra territorium jus dicenti [EMAIL PROTECTED] | impune non paretur. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Sun, Mar 28, 2004 at 07:27:33PM +0200, Sven Luther wrote: On Sun, Mar 28, 2004 at 11:55:03AM -0500, Joey Hess wrote: Jeremie Koenig wrote: The plan was to request a sarge-ignore tag on the d-i build-depends on miboot, which is in contrib, and try to find a better solution for next releases. This is the first I've heard of this. Has the sarge-ignore status of the GFDL docs really created such a slippery slope? I doubt it. Well, we had it in woody boot-floppies, it seems. Ignorance is not precedent. When we learn that non-free stuff is in main, our Social Contract obliges us to act on it, not immediately grandfather what we have found into our definition of Free Software. -- G. Branden Robinson|Computer security is like an onion: Debian GNU/Linux |the more you dig in, the more you [EMAIL PROTECTED] |want to cry. http://people.debian.org/~branden/ |-- Cory Altheide signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Sun, Mar 28, 2004 at 09:16:14AM +0200, Sven Luther wrote: 2) a small file, the boot1 macos ressource, a 1K boot-sector to be copied to the floppy boot sector, is taken from the mac os system file. This is non-free, binary only, altough, well, the file in question only contains some ROM calls to initialize HFS, and load the boot2, open the mac os system file, and load boot2, which is provided by the GPL-free part of miboot mentioned above. Worse case scenario, this could be clean-room reimplemented. To do it, you need two MacOS hackers. Hacker #1 looks at the existing boot sector, writes a complete plain English description of it, and posts it to debian-boot and/or debian-powerpc. Hacker #2 affirms that he has never looked at the existing boot sector, and will not do so in the future. He or she understands MacOS well enough to know how to hand-code 1kB worth of assembly (or possibly compilable C code) to create a functionally-identical boot sector from the plain English description. -- G. Branden Robinson| Religion is excellent stuff for Debian GNU/Linux | keeping common people quiet. [EMAIL PROTECTED] | -- Napoleon Bonaparte http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Bug#236777: xserver-xfree86: Prepost install script mistake (warning, not error, it work)
reassign 236777 discover1-data retitle 236777 discover1-data: bad data causes xserver-xfree86 config script to chatter thanks On Mon, Mar 08, 2004 at 10:39:07AM +0100, Sythos wrote: Package: xserver-xfree86 Version: 4.3.0-5 Severity: minor During upgrade from 4.0.3-3: Preparing to replace xserver-xfree86 4.3.0-3 (using .../xserver-xfree86_4.3.0-5_i386.deb) ... parse error reading X server string `unknown' parse error reading X server string `unknown' Unpacking replacement xserver-xfree86 ... [...] VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 AGP 8x] (rev a1) 01:00.0 Class 0300: 10de:0281 (rev a1) This chatter is from discover, because there is bad data in the discover data file. discover1-data should probably be updated to use the XFree86 X server and nv driver for this card. Reassigning. -- G. Branden Robinson|The errors of great men are Debian GNU/Linux |venerable because they are more [EMAIL PROTECTED] |fruitful than the truths of little http://people.debian.org/~branden/ |men. -- Friedrich Nietzsche signature.asc Description: Digital signature
Re: kernel 2.2 packages cleanup
[huge CC list removed] On Wed, Mar 24, 2004 at 12:07:27AM +0100, Adrian Bunk wrote: On Tue, Mar 23, 2004 at 03:23:42PM -0600, Stephen R Marenka wrote: On Tue, Mar 23, 2004 at 10:06:15PM +0100, Adrian Bunk wrote: On Tue, Mar 23, 2004 at 03:56:05PM -0500, Camm Maguire wrote: Greetings! Pardon my ignorance, but are the raid and SSE patches already backported into 2.2.25? I'm assuming Debian will continue to offer the 2.2 series. If so, and if .25 doesn't already contain them, the raid and SSE patches are important, I think -- the vm-global much less so. I can update these for the last 2.2 kernel if desired. The point of this cleanup is that Debian 3.1 will ship with kernel 2.4 and 2.6, but not with kernel 2.2. The security team has already stated that they will not support three major versions of the kernel in Debian 3.1. I'm sorry, I missed that statement, where did it occur? http://lists.debian.org/debian-devel/2004/debian-devel-200403/msg01495.html Martin Schulze has since made statements amending this. -- G. Branden Robinson| Exercise your freedom of religion. Debian GNU/Linux | Set fire to a church of your [EMAIL PROTECTED] | choice. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Processed: clone to X
reassign 238777 discover-data reassign 238778 xserver-xfree86 retitle 238778 xserver-xfree86: [debconf] pull keyboard defaults from d-i configuration thanks On Thu, Mar 18, 2004 at 01:48:07PM -0800, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: clone 238750 -1 Bug#238750: installation-reports Bug 238750 cloned as bug 238777. retitle -1 defaults to vesa, not savage for S3 Inc. 86C270-294 Savage/MX-MV Bug#238777: installation-reports Changed Bug title. reassign -1 xserver-xfree86 Bug#238777: defaults to vesa, not savage for S3 Inc. 86C270-294 Savage/MX-MV Bug reassigned from package `installation-reports' to `xserver-xfree86'. This is a discover problem. Generic drivers like fbdev, vga, and vesa should not be reported by discover. clone 238750 -2 Bug#238750: installation-reports Bug 238750 cloned as bug 238778. retitle -2 should inherit keyboard layout from d-i (debian-installer/keymap) Bug#238778: installation-reports Changed Bug title. reassign -1 xserver-xfree86 Bug#238777: defaults to vesa, not savage for S3 Inc. 86C270-294 Savage/MX-MV Bug reassigned from package `xserver-xfree86' to `xserver-xfree86'. I think you meant to reassign -2 there, not -1 (again). If someone from d-i could give this bug (#238778) a quick briefing on what d-i keyboard layout info is available, we'll do our best here. -- G. Branden Robinson| You live and learn. Debian GNU/Linux | Or you don't live long. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Bug#234812: 234812 xserver-xfree86: configure script hangs
reassign 234812 discover thanks On Fri, Feb 27, 2004 at 12:14:24AM +0100, Pawe Paucha wrote: In reply to: - tag 234812 + moreinfo retitle 234812 xserver-xfree86: configure script hangs thanks You did not include a description of your problem in the body of your bug report. Are you saying that the discover command hangs? If so, does it hang from the command-line? - Yes, it does. When I run 'apt-get install' processing stops with 'discover --format=... video' process hanged. When I run gdb on this discover process, it looks like it hangs in libc close() function, called from close_serial_port() (libdiscover.so.1). If I enter 'c(ontinue)' discover continues and prints correct video card description. So it looks as a discover bug (I will report it), but why does discover scans for serial ports? I have 'disable serial' in my /etc/discover.conf. No need to report another bug; with this message, I am reassigning this one to discover. Thanks for following up! -- G. Branden Robinson| When I die I want to go peacefully Debian GNU/Linux | in my sleep like my ol' Grand [EMAIL PROTECTED] | Dad...not screaming in terror like http://people.debian.org/~branden/ | his passengers. signature.asc Description: Digital signature
Bug#229333: Small typo in lib/core.c give segfault
tag 229333 + fixed-upstream
thanks
On Sat, Jan 24, 2004 at 12:36:42PM +0100, Petter Reinholdtsen wrote:
I was finally able to trace down a bug in discover2. I hope this is
the segfault error I have seen when using it in d-i on VMWare. This
patch fixes the problem. Someone forgot to make room for the
zero-terminator in the string.
--- lib/core.c.orig 2004-01-24 11:22:05.0 +
+++ lib/core.c 2004-01-24 11:22:07.0 +
@@ -84,7 +84,7 @@
if((*status)-message) {
free((*status)-message);
}
-(*status)-message = _discover_xmalloc(strlen(message));
+(*status)-message = _discover_xmalloc(strlen(message)+1);
strcpy((*status)-message, message);
}
This is reported as Debian bug #229333. Please apply upstream as
well. :)
Committed as r4060. Thanks!
--
Branden Robinson | GPG signed/encrypted mail welcome
[EMAIL PROTECTED] | 1024D/9C0BCBFB
Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C
| 72E8 0F42 191A 9C0B CBFB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discover Debian package maintainer
On Wed, Jan 21, 2004 at 01:48:50PM +0100, Gaudenz Steinlin wrote: Hi The purpose of this mail is to inform discover-workers of the plans the debian-installer team has for discover2 and to give you the possibility to object to out plans. Okay. Current state of discover2 in Debian: I have packaged an udeb only version of discover2 which is in the archive now. This package has successfully built on all autobuilders except mips, mipsel and m68k. It is intended for testing discover2 with the new installer. Glad to hear it. Be sure and lean on those m* guys. :) Further plans: I discussed the future of the discover2 package with pere yesterday. We plan to upload a full version of discover2 (including deb packages). It is not our intent to hijack your package. However, considering that there was no packaging effort done in the last months, we are under the impression, that you are no longer interested in maintaining this package. So we would like to completely takeover the maintenance of discover2. If our impression is wrong and you are still interested in maintaining discover2 then please speak up now and provide finished packages in the near future. It is not true that we are no longer interested; however, it is the case that at present Progeny has more urgent priorities occupying its technical staff. You might have noticed that LinuxWorld is this week. :) Also, I should let you know that I'm no longer the primary POC for Discover; this responsibility has been transferred to Jeff Licquia [EMAIL PROTECTED]. Nevertheless I remain very interested in the project, as I've been involved from the beginning. If we take over the maintenance of discover2 we plan to do the following (IRC excerpt): 17:25 pere Currently, we have two packages: discover (building discover and discover-udeb), and discover2 (building discover2-udeb). If we change this to discover1 (building discover1 and discover-udeb), and discover (building discover and discover2-udeb). 17:26 pere then we can test discover (version 2) in Sid, while still using discover-udeb (version 1) in d-i. 17:29 pere Besides, the discover version 2 package is slightly tested already, and seem to return correct info. With this plan we can get wider testing for discover2 in sid and still have discover1 packages as a fall back option and for sarge if it will be released before discover2 is ready. Would it bother you guys terribly to do this as a pre-approved NMU? We can merge the changes back into our SVN repo. Once LinuxWorld is off our plate, let's see if we can't keep pace with your needs vis a vis Discover 2, and re-evaluate the maintainership issue in 4 weeks or so. Does that sound reasonable? Your plan sounds good to me, and like what was already discussed, so it doesn't sound very disruptive to previous expectations. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discover Debian package maintainer
On Wed, Jan 21, 2004 at 05:11:58PM +0100, Gaudenz Steinlin wrote: Am Mit, den 21.01.2004 schrieb Branden Robinson um 16:17: I did not know whom to personally contact. So I decided to send this mail to [EMAIL PROTECTED] and [EMAIL PROTECTED] in the hope that the relevant people at progeny receive it. discover-workers will suffice. :) Would it bother you guys terribly to do this as a pre-approved NMU? We can merge the changes back into our SVN repo. I would be glad if this is merged back to your SVN repo. Is it possible to arrange write access to it or do you want to merge the changes back yourself? I think our company policy is to manage such things ourselves. The sources should always be available in the Debian archive, but we can provide patches if you like. Patches would be ideal. They're easy to merge. :) Once LinuxWorld is off our plate, let's see if we can't keep pace with your needs vis a vis Discover 2, and re-evaluate the maintainership issue in 4 weeks or so. Does that sound reasonable? Your plan sounds good to me, and like what was already discussed, so it doesn't sound very disruptive to previous expectations. Yes this is OK and reasonable. I just wanted to make sure that this upload is approved by progeny. I have put [EMAIL PROTECTED] in the maintainer field of the udeb-only upload. Should this stay as it is atm or should I put [EMAIL PROTECTED] there? I suggest changing it to [EMAIL PROTECTED]. And one last question: To make the package build on non-i386 archs I had to copy the kernel pcmcia headers into the package source. I have done this in a sperate directory for now, but the most clean solution seem to me to have them in the same directory as the discover pcmcia stuff as normal non-system headers. Would you accept a patch for that? I'd like to get some other opinions on this. Eric, are you still subscribed? -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
directed RFA: discover (1.x)
Hi guys, I'd like to request that the Debian-Installer team, or an interested member thereof, adopt the discover package. For now, all I really request is that an upload be done changing the Maintainer: field. We can continue to work on the transition and renaming issues. As should be clear to those who follow these mailing lists, it is Progeny's intention to maintain Discover 2.x for Debian once the d-i team is prepared for it to be uploaded to unstable (meaning: once we've settled the package namespace issue). Please send any Discover 2.x-related, non-debian-boot-pertinent questions to the discover-workers list. Please CC discover-workers when discussing Discover 2.x-related issues that *are* relevant to debian-boot. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: plans for discover transition (was: plans for d-i string freeze) [progeny.com #2385]
On Mon, Dec 08, 2003 at 12:08:02AM +0100, Gaudenz Steinlin wrote: We are aware of that and did some tests with it. I tried to build the state of the repository as it was on the day the public access was announced, but it failed. After a quick glance over the build system I noticed, that it changed quite a lot. Without the build failure the resulting udeb should be quite good now. (eg. built without curl) There should be one open ticket for the build system of discover-data in your trouble ticket system. I did not notice any progress on this since 11/18. [progeny.com #2385] Progeny's ticket #2385 doesn't talk about build issues: Subject: Discover 2: reduce size of discover udeb http://lists.debian.org/debian-boot/2003/debian-boot-200310/msg00042.html Makefile: - only include needed devicetypes (instead of excluding uneeded ones) - do not install old hwlist in udeb - compress udeb hwlists debian/control - add build dependency on python-xml debian/rules - do not include docs in udeb reduce-xml: - remove entries with kernel module unknown or ignore If you have better python-xml skills, you will probably find a better way to adress this node in the xml-tree. There's also a M$-Excel File in the source tar file (merged_vendor_list.xls). AFAIK debian policy does not allow proprietary data formats in source files. As noted elsewhere on the discover-workers list, almost all of the above is done. The exceptions are the reduce-xml issue, which I've sent a separate mail about, and the .xls file -- I don't feel removal is warranted because this .xls file works fine with the version of Gnumeric in Debian testing. Consequently, I do not feel that the file qualifies as being in a proprietary data format per Debian Policy. If you disagree, please make a case for your position. :) -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#209240: NMU proposal for discover (i18n issues)
On Mon, Nov 17, 2003 at 06:30:56PM +0100, Christian Perrier wrote: Well, nothing really happened on these bugs since I opened themseveral weeks ago. [...] However, discoiver is used by the debian-installer, so I guess we should have it use gettext for debconf templates...and have its templates translated easily (though they don't seem to be used during debian-installer). [...] I thus propose to build and upload a NMU which would combine the fixes for these two bugs. Please feel free to go ahead. Progeny is concentrating on Discover 2.x: http://lists.debian.org/debian-boot/2003/debian-boot-200311/msg00766.html -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#209240: NMU proposal for discover (i18n issues)
[Please CC me on replies.] On Tue, Nov 18, 2003 at 04:38:20PM +0100, Petter Reinholdtsen wrote: [Branden Robinson] Please feel free to go ahead. Progeny is concentrating on Discover 2.x: This sounds very good. When will this result in replies regarding the patches we have been working on in the d-i team to get it to work with d-i. As far as I know, we are now waiting for Progeny to get back to us with comments on the patches so we can make up a plan to continue the transition process to get d-i to use discover 2. The last I heard, Jeff Licquia had applied the patches you needed. Some of those have been reverted in the latest CVS snapshot, but the changelog explains all. For example, it turns out a di-discover tool wasn't needed after all; it was possible to pass arguments to the existing discover utility to get output in the format desired by the d-i team. * discover/discover/Makefile.in discover/discover/didiscover.c Remove didiscover.c. The effects of didiscover --data-path --data-vendor didiscover --data-path --data-model are achieved with discover -t --no-model discover -t --no-vendor Can you please refresh my memory on any other outstanding issues? I will open tickets for them in Progeny's RequestTracker system. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
new website for Discover hardware detection suite
Progeny URL: http://www.progeny.com/ is pleased to announce the launch of a new website for the Discover project URL: http://platform.progeny.com/discover/ . Discover is a set of libraries and utilities for gathering and reporting information about a system's hardware. Version 1.0 of Discover was released with Debian 3.0 (woody) to a very positive response, and was promptly adopted as the hardware-detection technology of choice by the Debian-Installer team, who are reimplementing Debian's installer technology in a highly modular and flexible fashion that will also be easier to maintain. We're delighted that Discover's mettle has been tested against competing technologies such as Kudzu, and found to be a better fit for Debian's needs. However, the impact of Discover 1.0 has been limited due to the narrow expressiveness of its data format, and the perennial problem of distribution of updates about known hardware. Discover 2.0, over a year in the making, addresses both of these problems. First, it uses an XML-based data format that's designed to permit a high degree of flexibility, and to leave open the possibility of associating hardware devices with any sort of software interface. Secondly, it utilizes the CURL library (which can be enabled - or not - at build time) for retrieval of data stores about hardware from anywhere on the Internet. Discover 2.0 can collate the data from multiple resources, whether stored on a local filesystem or on the network, and will use the most up-to-date information it can find. Ian Murdock, founder of Debian and chief strategist for Progeny, likens the Discover 2.0 method of operation to one of Debian's most impressive technologies: Discover is APT for hardware information. Now that Discover 2.0 is stabilizing, Progeny is looking to the free software and open source communities to set the goals for Discover 2.1, 3.0, and beyond. To that end, we have redesigned Discover's website and made available a snapshot of our CVS developments. These are just baby steps, however, toward the big change: In the coming weeks, we anticipate making the development process of Discover (and other enabling technology initiatives) completely public by means of a web-based Subversion repository. We understand how difficult it is to contribute to a project in which the interesting stuff happens behind a curtain, so we're excited to pull back that curtain, reveal the workbench, and let the community see how we really work on Discover (mistakes and all!). Discover was developed primarily by Branden Robinson, Eric Gillespie, Josh Bressers, and John Daily of Progeny, with assistance from a cast of dozens. If Discover excites you as well, we cordially invite you to participate in Progeny's open development initiative. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debconf Templates Style Guide
On Thu, Oct 30, 2003 at 07:07:33AM +0100, Christian Perrier wrote: Someone do this please? :) Branden, no other comment on my document ? I was more or less prepared to several (constructive) comments, or style corrections, coming from you and I'm wondering whether I should be glad of receiving none.. :-) I haven't taken the opportunity to properly review it yet. You hit a lot of pet peeves I share with Joey Hess, though, so you're off to a good start. -- G. Branden Robinson| Eternal vigilance is the price of Debian GNU/Linux | liberty. [EMAIL PROTECTED] | -- Wendell Phillips http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Debconf Templates Style Guide
On Tue, Oct 28, 2003 at 11:43:55PM -0500, Matt Zimmerman wrote: On Wed, Oct 29, 2003 at 03:52:27AM +0100, Henning Makholm wrote: The default choice should always be what the user wants if they are unsure. I'm afraid you need to redesign the entire debconf system then. No, you don't. You just need a command line option to dpkg-reconfigure which says to forget the current/previous configuration. This is a bit shy of redesigning the entire system. Ooh, ooh. +1! This would take a significant thorn out of my side WRT xserver-xfree86.config. Someone do this please? :) -- G. Branden Robinson| The noble soul has reverence for Debian GNU/Linux | itself. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: keyboard mouse problem
On Mon, Jun 23, 2003 at 09:21:24PM -0700, Chris Tillman wrote: If you need more help with X, try [EMAIL PROTECTED] debian-x is not a user support list. Please direct users to debian-user only. -- G. Branden Robinson|Somewhere, there is a .sig so funny Debian GNU/Linux |that reading it will cause an [EMAIL PROTECTED] |aneurysm. This is not that .sig. http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
Re: Discover 1.5-2 pre-release available
On Sat, Mar 29, 2003 at 11:46:48AM +0100, Martin Sj?gren wrote: tis 2003-03-25 klockan 20.46 skrev Branden Robinson: I notice that your discover-data package on hackers.progeny.com/~branden/discover2 also contain the *.lst files, is that for backwards compatability and are actually not used? Yes, the .lst files are there for backwards compatibility so that discover 2.x packages don't have to Conflict with discover-data ( 2). The backwards-compatibility can be dumped once no one needs discover-data anymore. OK, but they are not actually used by the discover program? If what you mean is, is the Disocver 1.x data used by Discover 2.x?, then the answer is no. I don't think there are any udebs that use the discover data instead of calling the discover program, so this shouldn't be a problem. Okay. Let us know what you need in the Discover department, and we'll try to accomodate you. Also, be sure to tell us when you don't need Discover 1.x anymore -- it will then be safe to push Discover 2.x to Debian unstable. Agreed. I think ethdetect is the most critical thing to get working, and I'll try to have a look at it. Cool. As I said before, just let us know what you need. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discover 1.5-2 pre-release available
Glenn McGrath asked why I didn't just prep and upload the Discover 2.x packages to unstable. The answers are in the following bug log: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179048 I will be uploading the Discover 2.x debs to experimental until the debian-installer team doesn't need Discover 1.x anymore. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Discover 1.5-2 pre-release available
A pre-release (source code only) of Discover 1.5-2 is available: http://hackers.progeny.com/~branden/discover-1.5-2pre.tar.gz The reason this isn't a package release is because the GNU autotools have changed sufficiently in unstable to cause problems. If someone from the debian-installer team would like to take this source tarball and prepare some patches for it, I'd be most appreciatve. (Alternatively, if there's something simple I'm overlooking, please let me know.) What we generally do is cvs export (which is what this is), then run autogen.sh to get the source tree in shape for a dpkg-source -b. However, the GNU autotools have moved forward incompatibly over the past several motnhs. Here's the changelog so far: discover (1.5-2) unstable; urgency=low * new upstream version * Thanks to Tollef Fog Heen for all the NMUs! * Acknowledge NMU-fixed bugs: + discover-udeb is now available (Closes: #110461) + discover's postinst does not fail if the init script fails (Closes: #153656) + discover now depends on dash as an alternative to ash (Closes: #162747) + discover-udeb puts the library in /lib, not /usr/lib (Closes: #168858) * discover/Makefile.am: identify the linuxrc script as pkgdata_SCRIPTS and include this variable in EXTRA_DIST (thanks, Petter Reinholdtsen) (Closes: #152604) * discover/discover.init: - Issue warning when unable to link detected CD/DVD devices to numbered mountpoints (e.g., /dev/hdc - /cdrom0) rather than permitting failure to kill the init script. - Make clear that failure to link /cdrom0 to /cdrom is not a fatal error. - Warn, do not fail, if we are unable to link /dev/cdrom to /dev/cdrom0. - Don't bother with all the $CDROM_BASE_MOUNTPOINT linkage if /proc/mounts is not readable for us to determine whether there are already mounted filesystems where we want to work. (Issue warning if this is the case.) - Warn, do not fail, if we learn that there is already a filesystem mounted where we want to create our $CDROM_BASE_MOUNTPOINT/cdrom symlink. (Closes: #169264) - Issue explicit warning if /proc/mounts says something is already mounted at $CDROM_BASE_MOUNTPOINT/cdrom. - Rearrange a potentially confusing control structure. - Clarify the skipping message when a module is unavailable. - Sort the list of cdrom devices detected by discover before creating device mountpoint (thanks, Petter Reinholdtsen). (Closes: #182009) - Use one sed expression instead of a sed|grep|cut pipeline to populate the ARGUMENTS variable. - Simplify construction of the list of modules we're supposed to skip. - Greatly simplify the skip() function, reducing it to a simple echo|grep pipeline. - Previous three fixes courtesy of an anonymous bug submitter. (Closes: #166460) - Disregard ignore or unknown modules. - Drop Discover 0.9.7 compatibility (Discover 1.1 is what was released with woody, so 0.9.7 is *really* ancient). - Consistent style for shell control structures. * lib/cpu.c: - Initialize a previously-uninitialized pointer. - Don't break out of the loop after detecting the first CPU. (Closes: #160658) - Thanks to Thomas Poindessous for this patch. * debian/discover.templates: - Mention that the link manipulation is only done if possible. * debian/rules: remove special handling of the linuxrc script, now handled upstream (by discover/Makefile.am) -- Branden Robinson [EMAIL PROTECTED] Mon, 24 Mar 2003 15:55:31 -0500 -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udebs for more than just installation
On Thu, Feb 27, 2003 at 06:45:23PM -0500, Joey Hess wrote: Branden Robinson wrote: Another approach we're thinking about is regular dpkg support for directory exclusion during package unpack, for things like documentation and localization files. Of course, that's more an issue for debian-dpkg... :) Please Progeny guys, make everyone's day and do this. It shouldn't even be too hard to do; dpkg parses the tars itself to install files as .dpkg-new at first, so you just have to hook into the right places and make it do nothing for some files. (Famous last words.) And there is even dpkg.cfg already to put the exclude regexps in. -- see shy jo, who has a 30 mb (uncompressed) debian install, which was _not_ fun to do Well, I'll definitely bring this up to the other guys on my team. I am concerned about the possible consequences of such a feature though, since it will enable users to break the assumptions of postinst and prerm scripts. Such scripts can generally assume that the package has been unpacked when they run. But with a path pruning feature, some parts of the package may never be unpacked. For such a feature to really float is going to demand that people write their maintainer scripts a little bit differently. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
udebs for more than just installation
[I have set Mail-Followup-To; please To/CC me on replies.] Hi guys, Over here at Progeny we're wondering about the feasibility of using udebs in resource-constrained environments for more than just installation. How feasible would it be to use udebs as real packages? I note that udpkg appears to support maintainer scripts, though I don't know it supports them as comprehensively as regular dpkg (see sections 6.4 and 6.5 of the Debian Policy Manual). Another approach we're thinking about is regular dpkg support for directory exclusion during package unpack, for things like documentation and localization files. Of course, that's more an issue for debian-dpkg... :) Anyway, I thought you guys might have the best insights into udebs since you use them the most. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udebs for more than just installation
On Thu, Feb 27, 2003 at 06:56:09PM +0100, Martin Sj?gren wrote: I'm not quite sure what it is you are asking. Are you asking for how nifty things you can do with udpkg? Right now, udpkg only calls /.../package.config configure /.../package.postinst configure and that's it. I don't see how we would need any *rm scripts in the installer. :) You wouldn't. I see what you mean, though. This can, I guess, be expanded if dpkg being tiny is more important than dpkg being stellar at maintainer scripts. I guess that sort of depends. Isn't that what has been discussed before, for handhelds and stuff? If you're willing to make udebs anyway, you won't need this though, as I don't see why dpkg wouldn't be able to handle udebs. There's nothing magic about udebs, they just happen to have different names and don't follow policy more than they like... Yes. I was just wondering what udpkg's capabilities are. Thanks for the feedback! -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux for blinds
On Wed, Oct 30, 2002 at 09:26:42AM +0100, Sébastien FRANCOIS wrote: You might remember me, I had asked a few months ago concerning the projects that existed for blinds. Just FYI; in English (U.S. English, anyway), the term is the blind. E.g., we have made our distribution more accessible to the blind and visually impaired. Your meaning is clear from context, but in English blinds are appurtenances attached to physical windows. -- G. Branden Robinson|I'm sorry if the following sounds Debian GNU/Linux |combative and excessively personal, [EMAIL PROTECTED] |but that's my general style. http://people.debian.org/~branden/ |-- Ian Jackson msg23082/pgp0.pgp Description: PGP signature
Re: cdebconf and debian-installer compile
On Tue, Jul 23, 2002 at 12:58:51AM +0200, Tollef Fog Heen wrote: | And another question : what will be the default kernel for | debian-installer : 2.2.x or 2.4.x ? It's for | debian-installer/tools/ddetect/lst/*.ids. We can use discover's | *.ids, but they use 2.2.x kernel module names. So ... 2.4. We should get around that somehow -- Branden, got any idea how to? The only solutions for discover 1.x are kludges. The proper solution is to port PGI to discover 2.x, once it's packaged. :) http://hackers.progeny.com/discover/status/ -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Consultant| D5F6 D4C9 E25B 3D37 068C Progeny Linux Systems | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PGI installer [Was: Re: Why XFree86 4.2 Isn't in Woody]
On Tue, Apr 16, 2002 at 06:49:58PM +0200, Grzegorz Prokopski wrote: After that introduction (sorry, just wanted You to know the situation) let me ask You a few questions: First, main one: 0. Is PGI good enough to be used as basic installer for Debian magazine edition which will be pressed in a few thousand of copies? Well, I wouldn't want to make any warranties or guarantees at this point. When the version number has reached 1.0 I'll feel more confident. All I can say is that PGI appears to be much more robust even than Progeny Debian's installer, upon which it was based. Aside from issues with video cards unsupported by XFree86 (see below), I am unaware of any categorial complaints about PGI's robustness. Maybe it is good enough to be secondary installer (maybe on second a CD or sth?) I personally would certainly be comfortable with that. 1. Is this possible to include it along with the basic, textmode installer? Can You say some more deatailed about it? PGI does actually include a text-mode installer. You pass the installer the textmode argument at the SYSLINUX boot prompt. 2. Is PGI localized to Polish? (I don't think so) Is it hard to do? where/who to ask? (I will also be trying to get base-config in Polish, as I belive it's needed to have fully localized installation). PGI is not localized to Polish, and there would be some infrastructural changes necessary to support internationalization. 3. What else should I know ? ;-) Some mailing list? (I can't find anything about PGI on debian-boot) You can read more at http://hackers.progeny.com/pgi/. Huh - it'd be really nice to have PGI as the main installer ;-) But now I really need some good advice in the first place. Any comments are welcomed. I welcome further feedback, especially once you've had a chance to evaluate it. Thanks a lot for giving PGI a look! -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | msg19074/pgp0.pgp Description: PGP signature
Re: Please test this woody cd image
On Fri, Apr 12, 2002 at 09:48:36AM -0400, Michael Stone wrote: On Fri, Apr 12, 2002 at 08:38:00AM -0500, Shyamal Prasad wrote: It failed to boot an IBM Aptiva 2161-C8E desktop with a 1/19/1997 BIOS. This 166Mhz Pentium box has been my trusty machine for 5 years, and boots the potato r3 CD and also another woody netinst ISO (the one Well, I guess the question is do we want to support new machines or old machines; it doesn't seem that we can do both. (I'd vote for the former because we need to move forward, and it's not like we're removing the floppy boot option.) Also, PGI currently uses syslinux and will continue to do past its 1.0 release. PGI works on i386, of course, and may be a good candidate for legacy hardware support when the official Debian installer can't bend over backwards that far anymore. (PGI does not, however, support floppy-disk-based installs.) There's more information about PGI at http://hackers.progeny.com/pgi/. -- G. Branden Robinson| One man's magic is another man's Debian GNU/Linux | engineering. Supernatural is a [EMAIL PROTECTED] | null word. http://people.debian.org/~branden/ | -- Robert Heinlein msg18767/pgp0.pgp Description: PGP signature
feedback wanted alternative Debian installation system
[Please note the Mail-Followup-To header.] Hi folks. I sent an ITP about this package, but thought I would do a more proper announcement now that it's in auric's queue/new. One thing that Debian routinely gets dumped on about is its installer. One thing that Progeny Debian got postitive reviews about was its installer. Because of that, some of us at Progeny have spent some time whipping the installer we used for the Progeny Debian product into something that could be useful to Debian. We decided to call it PGI, which is short for Progeny Graphical Installer. I pronounce it piggy, but you can pronounce it however you want. :) The current version is 0.9.4.1, and I'd like to solicit feedback from Debian Developers to help us determine what needs to be done with PGI to make it worthy of a 1.0 version number. PGI is in a late-beta stage and has been successfully used to install woody systems many times. Currently, PGI supports the i386 and ia64 architectures. I personally am very interested in seeing it support other architectures as well. Note that PGI is not intended to supplant any other Debian installers, but rather to present an alternative to them. I'm especially thinking of it as something that independent CD vendors can use to boost their Debian sales. If people are intimidated by the reputation of Debian's standard installer, perhaps we can get Debian into more people's hands with an alternative installer that uses X. Also please be aware that even though Progeny developed PGI, it is now just as much a part of Debian as any other package with an external upstream (or, it will be as soon as it's approved by the archive maintainers). Until katie has processed the pgi package, you can review the current package at the following URL: http://hackers.progeny.com/pgi/ To give you a better idea of what PGI is supposed to accomplish, I'm attaching a feature list. I have a large personal investment in this project, so I'm very anxious to hear what you guys think of it. Until PGI gets its own BTS page, please feel free to mail me privately with feedback. -- G. Branden Robinson|Somebody once asked me if I thought Debian GNU/Linux |sex was dirty. I said, It is if [EMAIL PROTECTED] |you're doing it right. http://people.debian.org/~branden/ |-- Woody Allen 1.1. Features PGI implements several existing technologies to ensure that it is both flexible enough to deal with a broad range of hardware, and compatible with the official Debian installation system. The latter point is important because it should not matter how the user gets Debian GNU/Linux onto his or her computer; what is important is that the resulting system is compatible with any other Debian GNU/Linux system at the infrastructural level. * PGI uses debootstrap, Debian's official means of retrieving and installing the core components of a Debian GNU/Linux system. Stage 1 of PGI (see [23]Implementing the Second Stage) be thought of as a wrapper around debootstrap; PGI gets the system into a state where debootstrap can be run successfully. * PGI features both text-mode and graphical user interfaces. The latter uses version 4.1.0 of the XFree86 X server, supporting a wide variety of video hardware at reasonable color depths and resolutions. In cases where the graphical interface is not desired or unsupported by XFree86, the text-mode interface is available and provides the user with the same functionality. * PGI's graphical user interface autodetects most pointing devices (mice, trackballs, etc.) and video hardware. In most cases, it is not necessary to answer any configuration questions to use the installer's graphical interface -- it just comes up. In situations where manual configuration is necessary, only a few easily-understood questions are asked of the user, to give GUI the push it needs to get going. Alternatively, you can run the graphical interface even when the target machine's video hardware is not supported by the XFree86 X server; simply set the display boot parameter and run the installer on an X server elsewhere on your local network[24][2]. * Even when the X Window System is unavailable, PGI's text mode spares the Linux novice the intimidation of a shell prompt. The dialog utility is used to provide a friendly, menu-and-button-driven interface to the text-mode installer. * PGI is largely independent of the Linux kernel version. PGI may be built around an extremely broad variety of kernels; only a few kernel configuration options or mandatory for PGI's proper operation (see [25]Kernel and Module Selection). You can create lean-and-mean kernels for use with PGI, or large, featureful kernels for use on a range
installation success using 3.0.16 on iBook Dual USB / HOWTO
On Friday morning I successfully installed woody onto my new iBook. In the process a few bugs in the boot-floppies were found, but nothing that couldn't be recovered from with Ethan Benson and Colin Walters at the ready in IRC. :) I've written up a HOWTO that in part documents my experience, and in part is meant to serve as a guide for anyone else wanting to an install to an iBook. With only a few changes these same instructions should work just fine for most NewWorld machines, I'd think. http://people.debian.org/~branden/ibook.html I'd appreciate any feedback you guys have. Document feedback should go to debian-powerpc; advice for the boot-floppies team should probably go to debian-boot. -- G. Branden Robinson|If you wish to strive for peace of Debian GNU/Linux |soul, then believe; if you wish to [EMAIL PROTECTED] |be a devotee of truth, then http://people.debian.org/~branden/ |inquire. -- Friedrich Nietzsche msg12128/pgp0.pgp Description: PGP signature
Re: debian-installer status
On Fri, Oct 19, 2001 at 08:23:46AM -0700, Randolph Chung wrote: BTW: libdetect0 has no udeb. ethdetect is uninstallable are we still using libdetect? i was told that it is very i386 specific and may not work well at all on other archs. discover 1.0 is pretty portable, at the cost of speaking only PCI, USB, and PCMCIA. I just uploaded 1.1-2 which removes some obsolete build-depends that were causing gratuitous build-failures. -- G. Branden Robinson|One man's theology is another man's Debian GNU/Linux |belly laugh. [EMAIL PROTECTED] |-- Robert Heinlein http://people.debian.org/~branden/ | PGP signature
Re: discover override disparity
On Tue, Aug 28, 2001 at 02:56:36PM -0400, Debian Installer wrote: There are disparities between your recently installed upload and the override file for the following file(s): discover_1.0-2_i386.deb: section is overridden from admin to base. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. Please put discover back into admin until and unless the boot-floppies guys decide it's essential for the installer. debian-boot folks, do you guys have an opinion? -- G. Branden Robinson| Software engineering: that part of Debian GNU/Linux | computer science which is too [EMAIL PROTECTED] | difficult for the computer http://people.debian.org/~branden/ | scientist. PGP signature
Re: discover override disparity
On Sat, Aug 25, 2001 at 02:55:39PM -0400, Debian Installer wrote: There are disparities between your recently installed upload and the override file for the following file(s): discover_1.0-1_i386.deb: section is overridden from admin to base. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. Please put discover back into admin until and unless the boot-floppies guys decide it's essential for the installer. -- G. Branden Robinson|If you make people think they're Debian GNU/Linux |thinking, they'll love you; but if [EMAIL PROTECTED] |you really make them think, they'll http://people.debian.org/~branden/ |hate you. PGP signature
Re: experiences: installing new testing system from network
On Sat, Aug 04, 2001 at 11:52:40AM +1000, Brian May wrote: No, this gives an error saying it requires the mga_hal_drv.o (IIRC) file for the G450, which after I web search, I found on the manufacturers web site. This may have changed for X 4.1.0, but I tried X 4.0.3 in testing. It did change for 4.1.0. The non-free mga_hal_drv.o is no longer required to drive the G450 for basic operations, but either Xv or dual-head operation is unavailable without it (I forget which). -- G. Branden Robinson|You can have my PGP passphrase when Debian GNU/Linux |you pry it from my cold, dead [EMAIL PROTECTED] |brain. http://people.debian.org/~branden/ |-- Adam Thornton PGP signature
Re: cvs commit to tasksel/tasks by joeyh
On Wed, Jul 18, 2001 at 03:21:56PM -0700, [EMAIL PROTECTED] wrote: Repository: tasksel/tasks who:joeyh time: Wed Jul 18 15:21:56 PDT 2001 Log Message: Seems that xfonts-bolkhov-koi8r has split into -75dpi and -misc. I took the former. Any Russians want to test this task and see if it works? You might want to take both. There should be no overlap between the fonts in a -75dpi and a -misc package. (See Policy 12.8.5.) -- G. Branden Robinson| If you have the slightest bit of Debian GNU/Linux | intellectual integrity you cannot [EMAIL PROTECTED] | support the government. http://people.debian.org/~branden/ | -- anonymous PGP signature
Re: sound card detection in base
On Mon, May 28, 2001 at 07:26:10PM -0400, Joey Hess wrote: anXious doesn't exist in woody AFAICT. I think it's now handled by xserver-xfree86 postinst or debconf or whatever it is that runs there. Hmm, this is a bit disturbing since base-config still calls anXious. Well, only if it is installed.. Anyway, if anXious is going away, I'm not sure what we will do for letting the user pick the other things anXios prompted for: window manager, fonts, and terminal emulator. AnXious doesn't have to go away, it can just stop sweating the X server issue. -- G. Branden Robinson |Somebody once asked me if I thought sex Debian GNU/Linux|was dirty. I said, It is if you're [EMAIL PROTECTED] |doing it right. http://www.debian.org/~branden/ |-- Woody Allen PGP signature
Re: tasks: counterproposal (and implimentation)
On Mon, May 14, 2001 at 10:05:22PM -0400, Joey Hess wrote: - With package sets, it is delivered ... ? In a package called package-sets-progeny, and manipulated via binaries in the packages pkgset-tools and pkgset-tools-gnome. -- G. Branden Robinson | What influenced me to atheism was Debian GNU/Linux| reading the Bible cover to cover. [EMAIL PROTECTED] | Twice. http://www.debian.org/~branden/ | -- J. Michael Straczynski PGP signature
Re: tasks: counterproposal (and implimentation)
On Sat, May 12, 2001 at 01:39:43PM -0400, Joey Hess wrote: (BTW, could someone from Progeny PLEASE speak up and give us a summary of how your task analog works?) I'd tell you in IRC, but whoops, for no apparent reason I've been banned from the channel. Probably by someone who has said in the past that #debian-devel should be open to all...gotta love those double standards. We have package sets. Here's an example: /usr/share/package-sets/progeny/xemacs.contents /usr/share/package-sets/progeny/xemacs.description $ cat /usr/share/package-sets/progeny/xemacs.contents xemacs21 xemacs21-bin xemacs21-mule xemacs21-supportel xemacs21-support $ cat /usr/share/package-sets/progeny/xemacs.description XEmacs XEmacs is an enhanced version of Emacs, the extensible, customizable, self-documenting real-time display editor. This package includes XEmacs as well as an updated version of the Gnus news reader that is newer than the version included with XEmacs. You can override the contents (off the top of my head, not sure about the description) by creating a file in, e.g., /etc/package-sets/xemacs.contents . -- G. Branden Robinson | Experience should teach us to be most on Debian GNU/Linux| our guard to protect liberty when the [EMAIL PROTECTED] | government's purposes are beneficent. http://www.debian.org/~branden/ | -- Louis Brandeis PGP signature
Re: Busybox vi
On Thu, May 03, 2001 at 07:55:40AM -0700, Andrew Sharp wrote: The only real downside to uClibc is its limited platform support. Right now I support x86, arm, m68k, sh, and powerpc. The shared ^^ I'm not familiar with the `sh' platform. Did you mean sparc? SuperH. -- G. Branden Robinson |The only way to get rid of a temptation Debian GNU/Linux|is to yield to it. [EMAIL PROTECTED] |-- Oscar Wilde http://www.debian.org/~branden/ | PGP signature
Re: Link cfdisk with libncurses instead of slang?
On Fri, Mar 09, 2001 at 04:09:33PM -0800, Joey Hess wrote: Adrian Bunk wrote: Could anyone tell me if it would cause any problems when I link cfdisk in unstable with ncurses again? AFIAK the boot floppies are completly slang based with no ncurses at all. If so, making a program on them depend on ncurses would completly screw us. What *is it* with you slang bigots? :-P Slang was fine when ncurses wasn't maintained, but ncurses has been well maintained for at LEAST the past couple of years. -- G. Branden Robinson | If a man ate a pound of pasta and a Debian GNU/Linux| pound of antipasto, would they cancel [EMAIL PROTECTED] | out, leaving him still hungry? http://www.debian.org/~branden/ | -- Scott Adams PGP signature
Re: Why .udeb won't work.
[sorry for the CC, but I lust for this fix]
On Thu, Oct 26, 2000 at 03:54:47PM -0700, Joey Hess wrote:
FWIW, the following patch allows my .udeb package to build all the way:
--- /usr/bin/dpkg-genchangesTue Jun 20 08:16:28 2000
+++ dpkg-genchanges Thu Oct 26 15:52:42 2000
@@ -147,7 +147,8 @@
if (!defined($p2f{$p})) {
if ($a eq 'any' || ($a eq 'all' !$archspecific) ||
grep($_ eq $substvar{'Arch'}, split(/\s+/, $a))) {
- error("package $p in control file but not in files list");
+ warn("package $p in control file but not in files list");
+ next;
}
} else {
$p2arch{$p}=$a;
Yes. Let's do this. It will kill another bird, one that I've wanted for a
long time. I want to be able to build extra .debs without being required
to ship them. For instance:
xlibs-dbg
xserver-xfree86-dbg
--
G. Branden Robinson | I just wanted to see what it looked like
Debian GNU/Linux| in a spotlight.
[EMAIL PROTECTED] | -- Jim Morrison
http://www.debian.org/~branden/ |
PGP signature
Re: Red Hat installer via CVS ?
On Sat, Oct 21, 2000 at 10:14:58AM +1100, Glenn McGrath wrote: Looks like Caldera's effort is under the QPL v1, thats the one that is incompatable with the GPL problems isnt it ? That's correct, although when I was looking into Lizard (Caldera's effort) for Progeny, there weren't any manifest license incompatibility problems because it didn't link against any GPL'ed code. We eventually gave up on Lizard for technical reasons. -- G. Branden Robinson | Debian GNU/Linux| If God had intended for man to go about [EMAIL PROTECTED] | naked, we would have been born that way. http://www.debian.org/~branden/ | PGP signature
Re: Netscape in DEbian 2.2
On Wed, Oct 18, 2000 at 04:09:12AM -0500, Roland Bauerschmidt wrote: On Tue, Oct 17, 2000 at 06:26:31PM +0200, Maciej wrote: But now I have some other problem. My Netscape i Debian 2.2 has very big fonts and icons on task bar and menu bar. I was searching thrugh many files to find a solution but failed. Maybe U will help me . Sounds if you are using 100dpi fonts, but want 75dpi ones. Just move the line for 75dpi fonts in /etc/X11/XF86Config before the one for 100dpi one and it should be fine. Or just remove the 100dpi font package... apt-get remove xfonts-100dpi Nothing should depend on it. -- G. Branden Robinson |I must despise the world which does not Debian GNU/Linux|know that music is a higher revelation [EMAIL PROTECTED] |than all wisdom and philosophy. http://www.debian.org/~branden/ |-- Ludwig van Beethoven PGP signature
Re: PCI autodetection
Please don't CC me on replies. A generic svga at 1024x768@60Hz should be a good default in most situations if nothing else is found. Hrm, I'd rather not contribute to workplace violence in the United States by defauling to a refresh rate that is guaranteed to result in psychosis. Consider also that we could detect automatically the monitor model and video frequencies with read-edid, which can be found at: http://web.onetel.net.uk/~elephant/john/programs/linux/read-edid/ Thanks for pointing this out; I will check into it. -- G. Branden Robinson |The key to being a Southern Baptist: Debian GNU/Linux|It ain't a sin if you don't get caught. [EMAIL PROTECTED] |-- Anthony Davidson http://www.debian.org/~branden/ | PGP signature
Re: PCI autodetection
On Thu, Oct 05, 2000 at 07:22:41PM -0400, Will Lowe wrote: That would be cool. You wanna patch dbootstrap -- we could even make that conditional on the pci stuff being there at all.. I'm in the midst of building a patch to dboostrap now. I'll throw in a check to see if /proc/bus/pci exists, and if not we'll skip the "do you want to autodetect PCI devices" question altogether. Please don't commit into mainstream boot-floppies yet -- it needs more help. No prob. I'll send the patch to this list when it's done. While you're at it -- perhaps you could try to come up with some patches against xviddetect so it knows about more cards? It really I'll look at it. I'm using a table of device-driver mappings I stole from RH 6.2, so unless it has the X info, I don't. If you're not a Debian maintainer, I'm happy to do NMU's against Well, it looks like everybody's doing the same thing at the same time. At Progeny, Joseph Carter has been developing a libdetect based program called "discover" which spits out the correct X server (for 3.x) or X server and driver (for 4.x) given the PCI info. I'm writing a program called "dexter" (for Debian X server configurator) which uses this information if it is present. I don't know when Joseph plans to submit his discover program to Debian, but dexter (and modified xserver-* postinst scripts to take advantage of it) will be showing up in phase2v14. Dexter is presently feature-complete for Progeny's purposes. Also, I'm deliberately doing things in such a way that there is no need for a fork between Progeny's X packages and Debian's. If Dexter doesn't find /var/state/discover/video, it prompts the user for the server (or server+driver) to use, which isn't really worse than the present way of doing things. -- G. Branden Robinson | It doesn't matter what you are doing, Debian GNU/Linux| emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://www.debian.org/~branden/ | PGP signature
Re: NMI loops during install on intel VLB system
On Thu, Oct 05, 2000 at 05:58:51PM -0400, David C wrote: I'm trying to install potato on this Intel machine using floppies, and when it gets up to the point where you are supposed to insert the root diskette it goes into a loop that says: NMI received for unknown reason 2c Dazed and confused, but trying to continue. Do you have a strange power saving mode enabled? NMI received for unknown reason 3c (messages repeat...) [...] The machine in question is a 486DX2 CPU on a Soyo 25N VESA Local Bus motherboard with 32MB RAM. The only cards in the system are a Promise EIDE2300+ floppy/hard disk controller and an STB Sprint 1.1 Trident-based video card. The BIOS is an Award 2C4I9S23. You probably want to talk to some kernel wizards about this problem. Be sure you provide the kernel version (I think we used 2.2.17 for the potato boot disks). -- G. Branden Robinson | Debian GNU/Linux| If God had intended for man to go about [EMAIL PROTECTED] | naked, we would have been born that way. http://www.debian.org/~branden/ | PGP signature
Re: Which task package installs gpm?
On Thu, Sep 21, 2000 at 09:25:26AM -0700, Michael S. Fischer wrote: I think that relying on debconf as a catch-all tool for system configuration is a bad idea. The realm of configuration possibilities is just too large for us to rely on package maintainers to make an absolutely perfect configuration tool in every single package. We're learning this in a hurry at Progeny. -- G. Branden Robinson | Optimists believe we live in the best of Debian GNU/Linux| all possible worlds. Pessimists are [EMAIL PROTECTED] | afraid the optimists are right. http://www.debian.org/~branden/ | PGP signature
Re: Which task package installs gpm?
You ignored my header, so I will repeat it as a non-header: X-No-CC: I subscribe to this list; please do not CC me on replies. On Fri, Sep 22, 2000 at 12:23:21AM +0200, J.A. Bezemer wrote: ... and get rid of task-c-dev, task-c++-dev, task-tex (and probably others) at the same time. Or... we did invent these tasks for a reason, didn't we? Perhaps. Standard stuff should be on there, no matter what. At the same time I'm not opposed to getting TeTeX, (pieces of) XFree86, or even emacs out of standard and into optional. However, the latter I have no desire to argue with anyone. BTW, I know the groff maintainer is out there somewhere...do you know that your package is in violation of Policy 5.8?[*] I'm loading up a very large and I am going to blow gxditview to bits if you don't move it by the time I have 4.0.1-1 ready. [*] _Programs that may be configured with support for the X Window System_ must be configured to do so and must declare any package dependencies necessary to satisfy their runtime requirements when using the X Window System, unless the package in question is of standard or higher priority, in which case X-specific binaries may be split into a separate package, or alternative versions of the package with X support may be provided. [...] _Packages using the X Window System should abide by the FHS standard whenever possible_; they should install binaries, libraries, manual pages, and other files in FHS-mandated locations wherever possible. This means that files must not be installed into `/usr/X11R6/bin/', `/usr/X11R6/lib/', or `/usr/X11R6/man/' unless this is necessary for the package to operate properly. Configuration files for window managers and display managers should be placed in a subdirectory of `/etc/X11/' corresponding to the package name due to these programs' tight integration with the mechanisms of the X Window System. Application-level programs should use the `/etc/' directory unless otherwise mandated by policy. The installation of files into subdirectories of `/usr/X11R6/include/X11/' and `/usr/X11R6/lib/X11/' is permitted but discouraged; package maintainers should determine if subdirectories of `/usr/lib/' and `/usr/share/' can be used instead (symlinks from the X11R6 directories to FHS-compliant locations is encouraged if the program is not easily configured to look elsewhere for its files). Packages must not provide -- or install files into -- the directories `/usr/bin/X11/', `/usr/include/X11/', or `/usr/lib/X11/'. Files within a package should, however, make reference to these directories, rather than their X11R6-named counterparts `/usr/X11R6/bin/', `/usr/X11R6/include/X11/', and `/usr/X11R6/lib/X11/', if the resources being referred to have not been moved to FHS-compliant locations. The policy brownshirts are coming to get you... -- G. Branden Robinson |You live and learn. Debian GNU/Linux|Or you don't live long. [EMAIL PROTECTED] |-- Robert Heinlein http://www.debian.org/~branden/ | PGP signature
Re: Which task package installs gpm?
On Mon, Sep 18, 2000 at 03:05:05PM -0700, Joey Hess wrote: Tasksel does support autoselecting required, important, and standard packages via the -r, -i, and -s switches. Currently, though, it is only called with -ri, not -ris. [...] I remember I posted to somewhere for clarification, but I forget if my post was to -devel, -boot, or -policy. Anyway, I got a confusing mishmash of answers, and in the end did not enable tasksel -s. If people think that's wrong, there may be time to fix it for r1. Well, if my opinion counts, please do re-enable -s. -- G. Branden Robinson |It was a typical net.exercise -- a Debian GNU/Linux|screaming mob pounding on a greasy spot [EMAIL PROTECTED] |on the pavement, where used to lie the http://www.debian.org/~branden/ |carcass of a dead horse. PGP signature
Re: newbie question concerning linux install
On Sat, Sep 02, 2000 at 04:46:14PM -0400, Richard Miles wrote: This seems doubtful. The first IDE drives is almost always hda, not hde. Check your kernel startup messages for info. Well, it's quite possible if he's got a 3rd-party IDE controller card, say for ATA/66 or ATA/100. Several of the new Asus MB's actually have four IDE devices built in. That's intriguing -- by "devices" I presume you mean "channels"? (Two devices to a channel). Are the 3rd and 4th channels only available via the PCI bus? If not I smell serious IRQ shortage. -- G. Branden Robinson |America is at that awkward stage. It's Debian GNU/Linux|too late to work within the system, but [EMAIL PROTECTED] |too early to shoot the bastards. http://www.debian.org/~branden/ |--Claire Wolfe PGP signature
Re: regarding xviddetect
On Mon, Aug 21, 2000 at 09:34:05AM -0400, Adam Di Carlo wrote: I know there are still plenty of video cards that xviddetect does not detect. I can see a lot of bug reports to that effect. I think it would be worthwhile to maintain a branch of xviddetect so that anXious could know about more videocards which get updated at Potato point releases. Do you agree? Yes. As to the rest of this thread. I've stated elsewhere[1] that we're going to continue to maintain XFree86 3.x in parallel with 4.x for woody, albeit with the former in a stripped down version that ships only some X servers (and possibly the libc5-compat libraries). Stephen R. Gore is now the maintainer of XFree86 3.x. Here's what I figured we'd do: Have a hardcoded list of video hardware for which support only exists in 3.x. This will be easy because we'll be pruning down the server list and the driver list for the 3.x SVGA server, and will thus have a fairly static idea of what cards are supported thus. If we find any of those cards, select an X server like we always have. Otherwise, choose xserver-xfree86 and see if it can figure out what to do with the card. I'll be shipping all the video driver modules for the 4.x server in the xserver-xfree86 package. xviddetect might need to be extended to select more than one package in the case of certain pieces of hardware. For instance, to use the 4.x glide driver (for running X on a 3D-only Voodoo[12] card), libglide2 *has* to be installed. Likewise, we're going to have to figure out what to do about the agpgart kernel module, and require that for i810 boards and possibly some others. -- G. Branden Robinson | Somewhere, there is a .sig so funny that Debian GNU/Linux| reading it will cause an aneurysm. This [EMAIL PROTECTED] | is not that .sig. http://www.debian.org/~branden/ | PGP signature
