Bug#789029: winbind: first connection attempt fails / getpwuid failed
Package: winbind Version: 4.1.17+dfsg-2 Severity: normal Tags: upstream Server is a dist-upgraded box from Debian 7 to 8 (Jessie), now running samba 4.1.17+dfsg-2. When connecting to a samba share the connection initially fails. On a second try the connection attempt is successful. In the logs one can see getpwuid failed messages and finally NT_STATUS_UNSUCCESSFUL Stopping winbindd eliminates this behavior. This bug is known to upstream, the upstream bug report is located at https://bugzilla.samba.org/show_bug.cgi?id=10604 Please backport the appropriate patches -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages winbind depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.25 ii libc6 2.19-18 ii libcap2 1:2.24-8 ii libcomerr21.42.12-1.1 ii libgssapi-krb5-2 1.12.1+dfsg-19 ii libk5crypto3 1.12.1+dfsg-19 ii libkrb5-3 1.12.1+dfsg-19 ii libldap-2.4-2 2.4.40+dfsg-1 ii libpam0g 1.1.8-3.1 ii libpopt0 1.16-10 ii libtalloc22.1.1-2 ii libtdb1 1.3.1-1 ii libwbclient0 2:4.1.17+dfsg-2 ii lsb-base 4.1+Debian13+nmu1 ii samba-common 2:4.1.17+dfsg-2 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages winbind recommends: pn libnss-winbind none pn libpam-winbind none winbind suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659580: roxterm: Disable menu access key (F10 by default) does not work
Package: roxterm Version: 1.22.2-1+b1 Severity: normal Tags: upstream The option Preferences-Edit current profile-Keyboard-Disable menu access key (F10 by default) does not work. When checking the box roxterm still catches if F10 is pressed and shows the menu. This conflicts with the keybinding of other programs, in my case I use F10 usually to quit Midnight Commander. I have View-Show Menubar turned off. It seems that this bug is not Debian specific, I found a report at http://sourceforge.net/projects/roxterm/forums/forum/422638/topic/4965123 that a user of Arch Linux has the same problem. Additionally I found no way to change the menu access key, although the wording F10 by default suggests that the key can be changed. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages roxterm depends on: ii libc6 2.13-26 ii libdbus-1-3 1.4.16-1 ii libdbus-glib-1-20.98-1 ii libgdk-pixbuf2.0-0 2.24.0-2 ii libglade2-0 1:2.6.4-1 ii libglib2.0-02.30.2-6 ii libgtk2.0-0 2.24.8-3 ii libice6 2:1.0.7-2 ii libpango1.0-0 1.29.4-2 ii librsvg2-common 2.34.2-2 ii libsm6 2:1.2.0-2 ii libvte9 1:0.28.2-4 ii libx11-62:1.4.4-4 Versions of packages roxterm recommends: ii openssh-client 1:5.9p1-2 roxterm suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639807: fetchmail: message Server certificate: should be written to stdout
Package: fetchmail
Version: 6.3.18-2
Severity: minor
Tags: patch
When using fetchmail in verbose SSL mode, fetchmail writes the message Server
certificate: to stderr.
Since this message is not an error (an it is not consistent with the ususal
behaviour of fetchmail) it
should be written to stdout instead.
Since I run fetchmail crom a cronjob this behaviour becomes particular
annoying, because cron is
sending the output of stderr every time fetchmail runs.
Patch:
diff -urN fetchmail-6.3.18.orig//socket.c fetchmail-6.3.18//socket.c
--- fetchmail-6.3.18.orig//socket.c 2010-10-09 10:26:22.0 +0200
+++ fetchmail-6.3.18//socket.c 2011-08-30 14:15:50.0 +0200
@@ -618,7 +618,7 @@
if (outlevel = O_VERBOSE) {
if (depth == 0 SSLverbose)
- report(stderr, GT_(Server certificate:\n));
+ report(stdout, GT_(Server certificate:\n));
else {
if (_firstrun) {
_firstrun = 0;
-- System Information:
Debian Release: 6.0.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages fetchmail depends on:
ii adduser 3.112+nmu2 add and remove users and groups
ii debianutils 3.4 Miscellaneous utilities specific t
ii libc6 2.11.2-10Embedded GNU C Library: Shared lib
ii libcomerr2 1.41.12-4stable1 common error description library
ii libgssapi-krb5-21.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries - k
ii libkrb5-3 1.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries
ii libssl0.9.8 0.9.8o-4squeeze1 SSL shared libraries
ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
Versions of packages fetchmail recommends:
ii ca-certificates20090814+nmu2 Common CA certificates
Versions of packages fetchmail suggests:
ii exim4-daemon-heavy [mail 4.72-6+squeeze2 Exim MTA (v4) daemon with extended
pn fetchmailconfnone (no description available)
pn resolvconf none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477077: dansguardian: segmentation fault crash
Same problem here, several lines kernel: [1187805.536334] dansguardian[4820]: segfault at 410 ip 08051994 sp bf823560 error 4 in dansguardian[8048000+a1000] This problem exists since I have upgraded from Etch to Lenny. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506586: linux-2.6: Kernel BUG, possibly related
Hello, the bug froze my system almost reproducible. I wanted to use LVM snapshots on our samba server for hot backup purposes. We have a cluster of two servers, DRBD is used for replicating the data. The two servers are connected via a separate GBit wire. The plan was to create a snapshot on the secondary node every hour and keep them for 3 hours (in case a colleague destroys accidentally a document he was working on the whole day - so a whole day's work could be saved). I used a script to create LVM-snapshots with a size of 20 GB every hour. The size of the snapshotted LVM-partition is 2500 GB (2.44 TB). After the third snapshot was created, the load got high up to 5. Then the system froze with a kernel error: Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [ cut here ] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] kernel BUG at mm/slab.c:601! Jul 29 16:23:42 cifs2 kernel: [2369743.510965] invalid opcode: [#1] SMP Jul 29 16:23:42 cifs2 kernel: [2369743.510965] Modules linked in: dm_snapshot dm_mod ipv6 drbd cn loop snd_pcm snd_timer snd soundcore snd_page_alloc iTC O_wdt pcspkr rng_core i2c_i801 i2c_core shpchp pci_hotplug button intel_agp agpgart evdev ext3 jbd mbcache ide_cd_mod cdrom ide_pci_generic sd_mod ata_pi ix piix ide_core floppy ahci ata_generic 3w_9xxx e1000 libata scsi_mod ehci_hcd uhci_hcd dock usbcore thermal processor fan thermal_sys Jul 29 16:23:42 cifs2 kernel: [2369743.510965] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] Pid: 17626, comm: kcopyd Not tainted (2.6.26-2-686 #1) Jul 29 16:23:42 cifs2 kernel: [2369743.510965] EIP: 0060:[c0171556] EFLAGS: 00010046 CPU: 0 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] EIP is at free_block+0x4e/0xf4 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] EAX: EBX: 003c ECX: f0161d48 EDX: c1602c20 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] ESI: f4597000 EDI: e1d4dc40 EBP: f6d49c00 ESP: c489deb0 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] Process kcopyd (pid: 17626, ti=c489c000 task=f7785560 task.ti=c489c000) Jul 29 16:23:42 cifs2 kernel: [2369743.510965] Stack: 0003 003c f6cc7414 0036 003c 01e0 f6d49c00 Jul 29 16:23:42 cifs2 kernel: [2369743.510965]e1d4dc40 c017137a f6cc7400 f6cc7400 0246 f01c6248 Jul 29 16:23:42 cifs2 kernel: [2369743.510965]c0171460 e1d4d780 f01c6248 f4791e80 c0158bf1 c49fb948 f01c6248 f4791e80 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] Call Trace: Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c017137a] cache_flusharray+0x65/0x89 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c0171460] kmem_cache_free+0x36/0x4f Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c0158bf1] mempool_free+0x63/0x67 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [f89deb87] pending_complete+0xdd/0x138 [dm_snapshot] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [f89df873] persistent_commit+0xdc/0xf0 [dm_snapshot] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [f89dec0a] copy_callback+0x28/0x2c [dm_snapshot] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [f8b9feed] run_complete_job+0x46/0x6f [dm_mod] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [f89debe2] copy_callback+0x0/0x2c [dm_snapshot] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [f8b9fd19] process_jobs+0x1f/0xaa [dm_mod] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [f8b9fea7] run_complete_job+0x0/0x6f [dm_mod] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [f8b9fda4] do_work+0x0/0x38 [dm_mod] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [f8b9fdba] do_work+0x16/0x38 [dm_mod] Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c012efae] run_workqueue+0x74/0xf2 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c012f689] worker_thread+0x0/0xbd Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c012f73c] worker_thread+0xb3/0xbd Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c013194c] autoremove_wake_function+0x0/0x2d Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c013188b] kthread+0x38/0x5d Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c0131853] kthread+0x0/0x5d Jul 29 16:23:42 cifs2 kernel: [2369743.510965] [c01044f3] kernel_thread_helper+0x7/0x10 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] === Jul 29 16:23:42 cifs2 kernel: [2369743.510965] Code: 54 24 0c 8b 0c 82 8d 91 00 00 00 40 c1 ea 0c c1 e2 05 03 15 e0 04 41 c0 8b 02 25 00 40 00 00 85 c0 7 4 03 8b 52 0c 80 3a 00 78 04 0f 0b eb fe 8b 72 1c 8b 44 24 28 8b 16 8b 7c 85 68 8b 46 04 89 Jul 29 16:23:42 cifs2 kernel: [2369743.510965] EIP: [c0171556] free_block+0x4e/0xf4 SS:ESP 0068:c489deb0 The following related packages are installed: ii drbd8-modules-2.6.26-2-6862.6.26+8.0.14-6+lenny1 ii drbd8-utils 2:8.0.14-2 ii lvm2 2.02.39-7 ii linux-image-2.6.26-2-686 2.6.26-17 ii samba
Bug#500732: CUPS overrides settings when printing from Windows
Hello, i ran into this problem today, when I upgraded our print server from etch to lenny. We use it to print from windows clients. ii bjfiltercups 2.2-2 CUPS add-on module for Canon Bubble Jet Printer. 2.2.1 ii cups 1.3.8-1+lenny6 Common UNIX Printing System(tm) - server ii cups-client1.3.8-1+lenny6 Common UNIX Printing System(tm) - client programs (SysV) ii cups-common1.3.8-1+lenny6 Common UNIX Printing System(tm) - common files ii cups-pdf 2.4.8-3PDF printer for CUPS ii cupsddk1.2.3-5CUPS Driver Development Kit ii cupsddk-drivers1.2.3-5CUPS Driver Development Kit - Driver files ii cupsys 1.3.8-1+lenny6 Common UNIX Printing System (transitional package) ii cupsys-client 1.3.8-1+lenny6 Common UNIX Printing System (transitional package) ii cupsys-common 1.3.8-1+lenny6 Common UNIX Printing System (transitional package) ii libcups2 1.3.8-1+lenny6 Common UNIX Printing System(tm) - libs ii libcupsimage2 1.3.8-1+lenny6 Common UNIX Printing System(tm) - image libs ii libcupsys2 1.3.8-1+lenny6 Common UNIX Printing System (transitional package) ii libcupsys2-gnutls101.2.7-4etch7 Common UNIX Printing System(tm) - dummy libs for transition ii samba 2:3.2.5-4lenny6a LanManager-like file and printer server for Unix ii samba-common 2:3.2.5-4lenny6Samba common files used by both the server and the client Postscript is produced by the Adobe PS driver which is the printer driver backend for the XP clients: print:~# rpcclient -U root -c 'getdriver og1-ost-lasercolor' print [Windows NT x86] Printer Driver Info 3: Version: [2] Driver Name: [kyocera-fs-c5020n-adobe] Architecture: [Windows NT x86] Driver Path: [\\PRINT\print$\W32X86\2\ADOBEPS5.DLL] Datafile: [\\PRINT\print$\W32X86\2\kyocera-fs-c5020n.ppd] Configfile: [\\PRINT\print$\W32X86\2\ADOBEPSU.DLL] Helpfile: [\\PRINT\print$\W32X86\2\ADOBEPSU.HLP] Dependentfiles: [\\PRINT\print$\W32X86\2\ADOBEPSU.HLP] Dependentfiles: [\\PRINT\print$\W32X86\2\ADOBEPS5.NTF] Dependentfiles: [\\PRINT\print$\W32X86\2\ADOBEPSU.DLL] Dependentfiles: [\\PRINT\print$\W32X86\2\ADOBEPS5.DLL] Dependentfiles: [\\PRINT\print$\W32X86\2\kyocera-fs-c5020n.ppd] Monitorname: [] Defaultdatatype: [RAW] After the upgrade we couldn't use duplex printing or selecting a specified printer tray, the printer took paper only from the default tray, no matter what was selected. After some reading the pstops filter was identified as the part that gave us this trouble. I copied /usr/lib/cups/pstops from an Etch installation to /usr/lib/cups/pstopsold at our printserver. Further I modified /etc/cups/mime.convs: #application/postscript application/vnd.cups-postscript 66 pstops application/postscript application/vnd.cups-postscript 66 pstopsold After that, everything worked as expected. Now, it seems that is a bug in the pstops filter. Is upstream informed? Or is this a Debian specific bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#427497: libnss-ldap doesn't find all groups
Package: libnss-ldap Version: 251-7.5 Severity: important libnss-ldap doesn't seem to get all groups from ldap. E. g. when I do as user: $ id -G 513 1027 1029 1073 1112 14091 19901 22150 43236 55873 60223 But when I do as root: # id -G user 513 22150 43236 19901 1027 1029 1073 1112 As you can see some groups are missing in the second request. This happens after the upgrade from Sarge to Etch. It has wider effects in the sense that e. g. Group-ACLs in Samba are no longer working in some cases. It also seems that only newer groups which were added after the upgrade to Etch are affected. Here are some relevant parts of config files: /etc/nsswitch.conf: passwd: compat ldap group: compat ldap shadow: compat ldap /etc/libnss_ldap.conf: host 192.168.1.12 192.168.1.17 base dc=test,dc=de ldap_version 3 rootbinddn cn=admin,dc=test,dc=de /etc/ldap/slapd.conf from the ldap server: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema schemacheck on pidfile /var/run/slapd/slapd.pid argsfile/var/run/slapd/slapd.args loglevel0 modulepath /usr/lib/ldap moduleload back_bdb backend bdb checkpoint 512 30 databasebdb suffix dc=test,dc=de directory /var/lib/ldap index objectClass eq lastmod on access to attrs=userPassword by dn=cn=admin,dc=test,dc=de write by anonymous auth by self write by * none access to dn.base= by * read access to * by dn=cn=admin,dc=test,dc=de write by * read ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412977: slapd segfaults with certain ACL's
Package: slapd
Version: 2.3.30-4
Severity: important
I test the latest egroupware trunk on Etch. When I apply the suggested
acl_addressbook.conf
to slapd.conf slapd segfaults (as do slapadd and possibly other slapd-tools)
$ slapd -g openldap -u openldap -d 16383
[...]
line 21 (access to
dn.regex=cn=([^,]+),ou=personal,ou=contacts,o=([^,]+),dc=iww-test,dc=local$
attrs=entry,@inetOrgPerson,@mozillaAbPersonAlpha,@evolutionPerson by
dn.regex=uid=$1,ou=accounts,o=$2,dc=iww-test,dc=local write by users none)
Segmentation fault
I use Etch with linux-image-2.6.18-3-686 2.6.18-7 and libc6 2.3.6.ds1-11.
IMHO slapd shouldn't crash like this, no matter how ill-configured the ACL's
maybe.
My slapd.conf:
allow bind_v2
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/rfc2307bis.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile/var/run/slapd/slapd.args
loglevel 0
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit 500
tool-threads 1
backend bdb
checkpoint 512 30
databasebdb
suffix dc=iww-test,dc=local
rootdn cn=admin,dc=iww-test,dc=local
rootpw {MD5}verysecrethash
directory /var/lib/ldap
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
password-hash {MD5}
index default eq
index objectClass eq
index uidNumber pres,eq
lastmod on
access to attrs=userPassword,shadowLastChange
by dn=cn=admin,dc=iww-test,dc=local write
by anonymous auth
by self write
by * none
include /etc/ldap/acl_addressbook.conf
access to dn.base= by * read
access to *
by dn=cn=admin,dc=iww-test,dc=local write
by * read
The content of acl_addressbook.conf is:
# Access to users personal addressbooks
# allow read of addressbook by owner and egwadmin account
access to
dn.regex=^cn=([^,]+),ou=personal,ou=contacts,o=([^,]+),dc=iww-test,dc=local$
attrs=entry
by dn.regex=uid=$1,ou=accounts,o=$2,dc=iww-test,dc=local read
by dn.regex=cn=egwadmin,o=$2,dc=iww-test,dc=local write
by users none
# allow user to create entries in own addressbook; no-one else can access it
# needs write access to the entries ENTRY attribute ...
access to
dn.regex=cn=([^,]+),ou=personal,ou=contacts,o=([^,]+),dc=iww-test,dc=local$
attrs=children
by dn.regex=uid=$1,ou=accounts,o=$2,dc=iww-test,dc=local write
by users none
# ... and the entries CHILDREN
access to
dn.regex=cn=([^,]+),ou=personal,ou=contacts,o=([^,]+),dc=iww-test,dc=local$
attrs=entry,@inetOrgPerson,@mozillaAbPersonAlpha,@evolutionPerson
by dn.regex=uid=$1,ou=accounts,o=$2,dc=iww-test,dc=local write
by users none
# Access to groups addressbooks
# allow read of addressbook by members and egwadmin account
access to
dn.regex=^cn=([^,]+),ou=shared,ou=contacts,o=([^,]+),dc=iww-test,dc=local$
attrs=entry
by group.expand=cn=$1,ou=groups,o=$2,dc=iww-test,dc=local read
by dn.regex=cn=egwadmin,o=$2,dc=iww-test,dc=local write
by users none
# allow members to create entries in there group addressbooks; no-one else can
access it
# needs write access to the entries ENTRY attribute ...
access to
dn.regex=cn=([^,]+),ou=shared,ou=contacts,o=([^,]+),dc=iww-test,dc=local$
attrs=children
by group.expand=cn=$1,ou=groups,o=$2,dc=iww-test,dc=local write
by users none
# ... and the entries CHILDREN
access to
dn.regex=cn=([^,]+),ou=shared,ou=contacts,o=([^,]+),dc=iww-test,dc=local$
attrs=entry,@inetOrgPerson,@mozillaAbPersonAlpha,@evolutionPerson
by group.expand=cn=$1,ou=groups,o=$2,dc=iww-test,dc=local write
by users none
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379174: shadow: CVE-2006-3378
Package: passwd Version: 1:4.0.3-31sarge5 Severity: grave I just checked the source. From there it seems that the Debian passwd is affected by CVE-2006-3378 (USN-308-1 in Ubuntu), too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323580: found 323580 238-1.1
found 323580 238-1.1 thanks I can confirm this problem in 238-1.1 However, this bug seems to be fixed in 244 from upstream. At least I can't reproduce it with nss_ldap-244 (self made package with debian patches applied). Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334709: libc6 2.3.5-7: FTBFS on i386 - forced unwind support is required
Package: libc6 Version: 2.3.5-7 Severity: serious The build of libc6 on i386 in a fresh sid chroot fails. I build the packages with nice -19 dpkg-buildpackage -rfakeroot -uc -us The build fails with the following error: configure_build=i486-linux-gnu; \ if [ x86_64-linux = $configure_build ]; then \ echo Checking that we're running at least kernel version: 2.6.0; \ if ! (minimum=$((`echo 2.6.0 | sed 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 65536 + \2 \* 256 + \3/'`)); current=$((`echo 2.6.11-1-k7 | sed 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 65536 + \2 \* 256 + \3/'`)); if [ $current -lt $minimum ]; then false; fi); then \ configure_build=`echo $configure_build | sed 's/^\([^-]*\)-\([^-]*\)$/\1-dummy-\2/'`; \ echo No. Forcing cross-compile by setting build to $configure_build.; \ fi; \ fi; \ (exec 31; exit `( ( ( cd build-tree/i386-amd64 CC=gcc-4.0 -m64 -D__x86_64__ AUTOCONF=false /source-etch/glibc-2.3.5/build-tree/glibc-2.3.5/configure --host=x86_64-linux --build=$configure_build --prefix=/usr --without-cvs --enable-add-ons=nptl --without-selinux --with-headers=/source-etch/glibc-2.3.5/debian/include --enable-kernel=2.6.0 --disable-profile --includedir=/usr/include/x86_64-linux-gnu ) 21 3-; echo $? 4) | tee -a /source-etch/glibc-2.3.5/log-build-x86_64-linux-amd64 3) 41`) checking build system type... i486-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu running configure fragment for add-on nptl checking sysdep dirs... sysdeps/x86_64/elf nptl/sysdeps/unix/sysv/linux/x86_64 nptl/sysdeps/unix/sysv/linux nptl/sysdeps/pthread sysdeps/pthread nptl/sysdeps/unix/sysv nptl/sysdeps/unix nptl/sysdeps/x86_64 sysdeps/unix/sysv/linux/x86_64 sysdeps/unix/sysv/linux/wordsize-64 sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet sysdeps/unix/sysv sysdeps/unix/x86_64 sysdeps/unix sysdeps/posix sysdeps/x86_64/fpu sysdeps/x86_64 sysdeps/wordsize-64 sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for x86_64-linux-gcc... gcc-4.0 -m64 -D__x86_64__ checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc-4.0 -m64 -D__x86_64__ accepts -g... yes checking for gcc-4.0 -m64 -D__x86_64__ option to accept ANSI C... none needed checking for gcc... gcc checking how to run the C preprocessor... gcc-4.0 -m64 -D__x86_64__ -E checking for x86_64-linux-g++... no checking for x86_64-linux-c++... no checking for x86_64-linux-gpp... no checking for x86_64-linux-aCC... no checking for x86_64-linux-CC... no checking for x86_64-linux-cxx... no checking for x86_64-linux-cc++... no checking for x86_64-linux-cl... no checking for x86_64-linux-FCC... no checking for x86_64-linux-KCC... no checking for x86_64-linux-RCC... no checking for x86_64-linux-xlC_r... no checking for x86_64-linux-xlC... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for x86_64-linux-ranlib... no checking for ranlib... ranlib checking whether as is GNU as... yes checking whether ld is GNU ld... yes checking for as... as checking version of as... 2.16.91, ok checking for ld... ld checking version of ld... 2.16.91, ok checking for pwd... /bin/pwd checking for x86_64-linux-gcc... (cached) gcc-4.0 -m64 -D__x86_64__ checking version of gcc-4.0 -m64 -D__x86_64__... 4.0.2, ok checking for gnumake... no checking for gmake... no checking for make... make checking version of make... 3.80, ok checking for gnumsgfmt... no checking for gmsgfmt... no checking for msgfmt... msgfmt checking version of msgfmt... 0.14.5, ok checking for makeinfo... makeinfo checking version of makeinfo... 4.8, ok checking for sed... sed checking version of sed... 4.1.4, ok checking for autoconf... false checking whether false works... no checking whether ranlib is necessary... no checking LD_LIBRARY_PATH variable... ok checking whether GCC supports -static-libgcc... -static-libgcc checking for bash... /bin/sh checking for gawk... gawk checking for perl... /usr/bin/perl checking for install-info... /usr/sbin/install-info checking for bison... no checking for signed size_t type... no checking for libc-friendly stddef.h... yes checking whether we need to use -P to assemble .S files... no checking whether .text pseudo-op must be used... yes checking for assembler global-symbol directive... .globl checking for .set assembler directive... yes checking for assembler .type directive prefix... @ checking for .symver assembler directive... yes checking for ld --version-script... yes checking for .previous assembler directive... yes checking for .protected and .hidden assembler directive... yes checking whether __attribute__((visibility())) is supported... yes checking for broken
Bug#320751: Problem is known on bugzilla.gnome.org
This matter is discussed on http://bugzilla.gnome.org/show_bug.cgi?id=312075 According to the pango developers, changes to pango-layout.c caused this bugs in anjuta and scite. The changes to pango-layout.c fixed a bug in pango. Unfortunately this changes broke backward-compatibility. I attach a patch that reverts the changes between pango-layout.c in 1.8.1 and 1.8.2. With this patch applied, anjuta and scite will work again. Regards, Henry pango-layout-revert.patch Description: Binary data
Bug#248201: Patches don't work
The patches supplied by Thierry Reding [EMAIL PROTECTED] caused build failure: [...] gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -g -O2 -g -c freeglut_init.c -MT libglut_la-freeglut_init.lo -MD -MP -MF .deps/libglut_la-freeglut_init.TPlo -fPIC -DPIC -o .libs/libglut_la-freeglut_init.lo freeglut_init.c:32:25: GL/freeglut.h: No such file or directory freeglut_init.c:60: error: `GLUT_RGBA' undeclared here (not in a function) freeglut_init.c:60: error: `GLUT_SINGLE' undeclared here (not in a function) freeglut_init.c:60: error: `GLUT_DEPTH' undeclared here (not in a function) freeglut_init.c:60: error: initializer element is not constant freeglut_init.c:60: error: (near initialization for `fgState.DisplayMode') freeglut_init.c:76: error: initializer element is not constant freeglut_init.c:76: error: (near initialization for `fgState.Time.Value') freeglut_init.c:76: error: initializer element is not constant freeglut_init.c:76: error: (near initialization for `fgState.Time') freeglut_init.c:78: error: initializer element is not constant freeglut_init.c:78: error: (near initialization for `fgState.Timers') freeglut_init.c:79: error: initializer element is not constant freeglut_init.c:79: error: (near initialization for `fgState.FreeTimers') freeglut_init.c:84: error: initializer element is not constant freeglut_init.c:84: error: (near initialization for `fgState.GameModeSize') freeglut_init.c:87: error: `GLUT_ACTION_EXIT' undeclared here (not in a function) freeglut_init.c:87: error: initializer element is not constant freeglut_init.c:87: error: (near initialization for `fgState.ActionOnWindowClose') freeglut_init.c: In function `fgDeinitialize': freeglut_init.c:264: error: `GLUT_RGBA' undeclared (first use in this function) freeglut_init.c:264: error: (Each undeclared identifier is reported only once freeglut_init.c:264: error: for each function it appears in.) freeglut_init.c:264: error: `GLUT_SINGLE' undeclared (first use in this function) freeglut_init.c:264: error: `GLUT_DEPTH' undeclared (first use in this function) freeglut_init.c:272: error: `GLUT_ACTION_EXIT' undeclared (first use in this function) freeglut_init.c: At top level: freeglut_init.c:497: error: parse error before glutInit freeglut_init.c:498: warning: return type defaults to `int' freeglut_init.c:650: error: parse error before glutInitWindowPosition freeglut_init.c:651: warning: return type defaults to `int' freeglut_init.c:664: error: parse error before glutInitWindowSize freeglut_init.c:665: warning: return type defaults to `int' freeglut_init.c:678: error: parse error before glutInitDisplayMode freeglut_init.c:679: warning: return type defaults to `int' freeglut_init.c:708: error: parse error before glutInitDisplayString freeglut_init.c:709: warning: return type defaults to `int' freeglut_init.c: In function `glutInitDisplayString': freeglut_init.c:736: error: `GLUT_ALPHA' undeclared (first use in this function) freeglut_init.c:745: error: `GLUT_ACCUM' undeclared (first use in this function) freeglut_init.c:760: error: `GLUT_DEPTH' undeclared (first use in this function) freeglut_init.c:765: error: `GLUT_DOUBLE' undeclared (first use in this function) freeglut_init.c:773: error: `GLUT_INDEX' undeclared (first use in this function) freeglut_init.c:786: error: `GLUT_RGBA' undeclared (first use in this function) freeglut_init.c:791: error: `GLUT_RGB' undeclared (first use in this function) freeglut_init.c:797: error: `GLUT_LUMINANCE' undeclared (first use in this function) freeglut_init.c:801: error: `GLUT_STENCIL' undeclared (first use in this function) freeglut_init.c:806: error: `GLUT_SINGLE' undeclared (first use in this function) freeglut_init.c:811: error: `GLUT_STEREO' undeclared (first use in this function) freeglut_init.c:817: error: `GLUT_MULTISAMPLE' undeclared (first use in this function) make[3]: *** [libglut_la-freeglut_init.lo] Error 1 make[3]: Leaving directory `/source-etch/freeglut-2.2.0/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/source-etch/freeglut-2.2.0' make[1]: *** [all] Error 2 make[1]: Leaving directory `/source-etch/freeglut-2.2.0' make: *** [build-stamp] Error 2 Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329333: FTBFS on i386
On Sat, 01 Oct 2005 13:14:50 -0700 Ben Pfaff [EMAIL PROTECTED] wrote: Could you please provide complete build logs for Autoconf with and without automake1.8 installed? I have a feeling that something early in the build is different from what I'm getting here. I attached the logs. BTW: I had the opportunity now to test this on another system, but I couldn't reproduce it there. Regards, Henry build-with-am1.8.log.gz Description: Binary data build-without-am1.8.log.gz Description: Binary data config-with-am1.8.log.gz Description: Binary data config-without-am1.8.log.gz Description: Binary data
Bug#328365: temporary file race in texindex
Hello, I've adapted the OpenBSD stuff and created a patch. Maybe you want to look at it if this works. Regards, Henry texindex-racecondition.patch Description: Binary data
Bug#114909: notfound 114909 2.8.5-2
notfound 114909 2.8.5-2 thanks I can't reproduce the bug with lynx 2.8.5-2. I think this four year old bug can be closed now. Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328737: the total for ls -l (and df too) is miscalculated
Hello, I don't think this is a bug, look at this: [EMAIL PROTECTED]:~/bla$ ls -lh total 0 -rw-r--r-- 1 henry henry 512M Sep 28 10:29 a.img -rw-r--r-- 1 henry henry 512M Sep 28 10:29 b.img -rw-r--r-- 1 henry henry 512M Sep 28 10:29 c.img -rw-r--r-- 1 henry henry 512M Sep 28 10:29 d.img [EMAIL PROTECTED]:~/bla$ du -h 4.0K. [EMAIL PROTECTED]:~/bla$ ls -lhs total 0 0 -rw-r--r-- 1 henry henry 512M Sep 28 10:29 a.img 0 -rw-r--r-- 1 henry henry 512M Sep 28 10:29 b.img 0 -rw-r--r-- 1 henry henry 512M Sep 28 10:29 c.img 0 -rw-r--r-- 1 henry henry 512M Sep 28 10:29 d.img The files were created with qemu-img. Note, that the first column in the ls -lhs command prints the disk allocation of each file which can differ from the file size. du prints also the disk allocation, and so does df. info coreutils ls says about this: `--size' Print the disk allocation of each file to the left of the file name. This is the amount of disk space used by the file, which is usually a bit more than the file's size, but it can be less if the file has holes. I'm no filesystem expert, but I think this may be the reason of the bug you discovered. Just do a ls -lhs and compare the first column with the total statement of ls. Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329333: FTBFS on i386
Hi, On Mon, 26 Sep 2005 22:27:01 -0700 Ben Pfaff [EMAIL PROTECTED] wrote: I thought the problem would be obvious with some testing, once you pointed that out, but it wasn't. Still, I came up with something that might fix the problem. Could you please try building autoconf_2.95a-5 that I've uploaded temporarily to here: http://footstool.stanford.edu/~blp/ Sorry, same error again: [...] Making all in bin make[2]: Entering directory `/source-etch/autoconf-2.59a/bin' rm -f autom4te autom4te.tmp sed -e 's,@SHELL\@,/bin/sh,g' -e 's,@PERL\@,/usr/bin/perl,g' -e 's,@bindir\@,/usr/bin,g' -e 's,@datadir\@,/usr/share/autoconf,g' -e 's,@prefix\@,/usr,g' -e 's,@autoconf-name\@,'`echo autoconf | sed 's,x,x,'`',g' -e 's,@autoheader-name\@,'`echo autoheader | sed 's,x,x,'`',g' -e 's,@autom4te-name\@,'`echo autom4te | sed 's,x,x,'`',g' -e 's,@M4\@,/usr/bin/m4,g' -e 's,@AWK\@,gawk,g' -e 's,@VERSION\@,2.59,g' -e 's,@PACKAGE_NAME\@,GNU Autoconf,g' -e 's,@configure_input\@,Generated from autom4te.in; do not edit by hand.,g' ./autom4te.in autom4te.tmp chmod +x autom4te.tmp chmod -w autom4te.tmp mv -f autom4te.tmp autom4te ../tests/autom4te --language M4sh --cache '' ./autoconf.as -o autoconf.in autom4te: cannot open /source-etch/autoconf-2.59a/tests/.././lib/autom4te.cfg: No such file or directory make[2]: *** [autoconf.in] Error 1 make[2]: Leaving directory `/source-etch/autoconf-2.59a/bin' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/source-etch/autoconf-2.59a' make: *** [build-stamp] Error 2 dpkg -l|grep automake ii automake1.71.7.9-7 A tool for generating GNU Standards-complian ii automake1.81.8.5-3 A tool for generating GNU Standards-complian ii automake1.91.9.5-1 A tool for generating GNU Standards-complian After removing and purging automake1.8 it builds. Maybe a Build-Conflicts: automake1.8 would help? Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329333: FTBFS on i386
On Thu, 22 Sep 2005 11:57:37 -0700 Ben Pfaff [EMAIL PROTECTED] wrote: What kind of environment are you using for the build? I cannot reproduce your problem either on a native system or using pbuilder? Well, I tracked it down. The problem was, that I had automake1.8 installed. (and automake1.4 and automake 1.7). Once I purged and removed automake1.8 the package builds fine. Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329333: FTBFS on i386
Package: autoconf Version: 2.59a-4 Severity: important Justification: renders package unusable autoconf 2.59a-4 doesn't build from source. I'm using gcc 3.3.5. autoconf 2.59a-3 builds fine. It fails like this: [...] dh_testdir make make[1]: Entering directory `/source-etch/autoconf-2.59a' Making all in bin make[2]: Entering directory `/source-etch/autoconf-2.59a/bin' rm -f autom4te autom4te.tmp sed -e 's,@SHELL\@,/bin/sh,g' -e 's,@PERL\@,/usr/bin/perl,g' -e 's,@bindir\@,/usr/bin,g' -e 's,@datadir\@,/usr/share/autoconf,g' -e 's,@prefix\@,/usr,g' -e 's,@autoconf-name\@,'`echo autoconf | sed 's,x,x,'`',g' -e 's,@autoheader-name\@,'`echo autoheader | sed 's,x,x,'`',g' -e 's,@autom4te-name\@,'`echo autom4te | sed 's,x,x,'`',g' -e 's,@M4\@,/usr/bin/m4,g' -e 's,@AWK\@,awk,g' -e 's,@VERSION\@,2.59,g' -e 's,@PACKAGE_NAME\@,GNU Autoconf,g' -e 's,@configure_input\@,Generated from autom4te.in; do not edit by hand.,g' ./autom4te.in autom4te.tmp chmod +x autom4te.tmp chmod -w autom4te.tmp mv -f autom4te.tmp autom4te ../tests/autom4te --language M4sh --cache '' ./autoconf.as -o autoconf.in autom4te: cannot open /source-etch/autoconf-2.59a/tests/.././lib/autom4te.cfg: No such file or directory make[2]: *** [autoconf.in] Error 1 make[2]: Leaving directory `/source-etch/autoconf-2.59a/bin' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/source-etch/autoconf-2.59a' make: *** [build-stamp] Error 2 Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329333: FTBFS on i386
Well, I can only compare the builds of 2.59a-3 and 2.59a-4.
2.59a-3:
[...]
dh_testdir
make
make[1]: Entering directory `/source-orig/autoconf-2.59a'
Making all in bin
make[2]: Entering directory `/source-orig/autoconf-2.59a/bin'
rm -f autom4te autom4te.tmp
sed -e 's,@SHELL\@,/bin/sh,g' -e 's,@PERL\@,/usr/bin/perl,g' -e
's,@bindir\@,/usr/bin,g' -e 's,@datadir\@,/usr/share/autoconf,g' -e
's,@prefix\@,/usr,g' -e 's,@autoconf-name\@,'`echo autoconf | sed 's,x,x,'`',g'
-e 's,@autoheader-name\@,'`echo autoheader | sed 's,x,x,'`',g' -e
's,@autom4te-name\@,'`echo autom4te | sed 's,x,x,'`',g' -e
's,@M4\@,/usr/bin/m4,g' -e 's,@AWK\@,awk,g' -e 's,@VERSION\@,2.59,g' -e
's,@PACKAGE_NAME\@,GNU Autoconf,g' -e 's,@configure_input\@,Generated from
autom4te.in; do not edit by hand.,g' ./autom4te.in autom4te.tmp
chmod +x autom4te.tmp
chmod -w autom4te.tmp
mv -f autom4te.tmp autom4te
rm -f autoconf autoconf.tmp
[...]
2.59a-4:
dh_testdir
make
make[1]: Entering directory `/source-etch/autoconf-2.59a'
Making all in bin
make[2]: Entering directory `/source-etch/autoconf-2.59a/bin'
rm -f autom4te autom4te.tmp
sed -e 's,@SHELL\@,/bin/sh,g' -e 's,@PERL\@,/usr/bin/perl,g' -e
's,@bindir\@,/usr/bin,g' -e 's,@datadir\@,/usr/share/autoconf,g' -e
's,@prefix\@,/usr,g' -e 's,@autoconf-name\@,'`echo autoconf | sed 's,x,x,'`',g'
-e 's,@autoheader-name\@,'`echo autoheader | sed 's,x,x,'`',g' -e
's,@autom4te-name\@,'`echo autom4te | sed 's,x,x,'`',g' -e
's,@M4\@,/usr/bin/m4,g' -e 's,@AWK\@,awk,g' -e 's,@VERSION\@,2.59,g' -e
's,@PACKAGE_NAME\@,GNU Autoconf,g' -e 's,@configure_input\@,Generated from
autom4te.in; do not edit by hand.,g' ./autom4te.in autom4te.tmp
chmod +x autom4te.tmp
chmod -w autom4te.tmp
mv -f autom4te.tmp autom4te
../tests/autom4te --language M4sh --cache '' ./autoconf.as -o autoconf.in
autom4te: cannot open /source-etch/autoconf-2.59a/tests/.././lib/autom4te.cfg:
No such file or directory
Obviuosly something changed between 2.59a-3 and -4.
After mv -f autom4te.tmp autom4te the command
../tests/autom4te --language M4sh --cache '' ./autoconf.as -o autoconf.in
occur, which complains about not finding
autoconf-2.59a/tests/.././lib/autom4te.cfg. This doesn't happen in 2.59a-3.
A diff of the two configure scripts give me this:
@@ -2910,11 +2910,6 @@
*) ac_INSTALL=$ac_top_builddir$INSTALL ;;
esac
- if test x$ac_file != x-; then
-{ echo $as_me:$LINENO: creating $ac_file 5
-echo $as_me: creating $ac_file 6;}
-rm -f $ac_file
- fi
# Let's still pretend it is `configure' which instantiates (i.e., don't
# use $as_me), people would be surprised to read:
#/* config.h. Generated by config.status. */
@@ -2953,6 +2948,12 @@
fi;;
esac
done` || { (exit 1); exit 1; }
+
+ if test x$ac_file != x-; then
+{ echo $as_me:$LINENO: creating $ac_file 5
+echo $as_me: creating $ac_file 6;}
+rm -f $ac_file
+ fi
_ACEOF
cat $CONFIG_STATUS _ACEOF
I would suspect that this change had some strange side effect.
Regards,
Henry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#125171: Bugs #125171, #127656 not found in ssh 3.8.1p1-8.sarge.4
notfound 125171 3.8.1p1-8.sarge.4 thanks I couldn't reproduce this bug with ssh 3.8.1p1-8.sarge.4 and putty 0.57 Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#101055: Only in woody?
Hello, I believe that this bug only affects woody, since sarge and newer are shipped with qt3 which uses libxft2. Therefore a can't even compile the test program to reproduce the bug on sarge. Seems to me that this bug can be closed. Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#163634: Only in woody?
Hello, I believe that this bug only affects woody, since /etc/X11/XftConfig and xftcache don't exist anymore in sarge and newer. Seems to me that this bug can be closed. Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265228: grub-installer: should be smart enough to guess that /dev/hdb is hd0 at boot time
reassign 265228 grub-installer retitle 265228 grub-installer: should be smart enough to guess that /dev/hdb is hd0 at boot time submitter [EMAIL PROTECTED] thanks I think the problem is located in grub-installer. When, in expert mode, grub ist told to install to /dev/hdb ist executes grub-install hd1. But it is a good guess, that /dev/hdb ist hd0 at boot time (otherwise the MBR will not be accessed at boot time). So grub-installer should guess or at least ask the user, if /dev/hdb is the first boot HD in the system. and modify /boot/grub/device.map. Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271384: Found in 4.0.2-4.1
found 271384 4.0.2-4.1 tags 271384 confirmed thanks I found this bug in 4.0.2-4.1 on sarge and etch. You can call me narrow-minded, but I don't think, that increasing MAXSTR from 256 to 512 is an appropriate fix for this. What, if one has a teminal which is more than 512 chars wide? (Hey, there are already 30 inch monitors out there;-)) Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265228: Maybe wrong _disk_
Hello, Lionel Elie Mamane [EMAIL PROTECTED] wrote: I think the *disk* is wrong. The thing is that grub gets the list of disks from the *BIOS* and Linux gets it directly from the IDE controller. Yes, this makes sense. I can't test this anymore, since I have only one hd left, but in retrospective I think you're right. Just one other thing: If grub is to be installed on the MBR on /dev/hdb, maybe d-i should be smart enough to guess, that /dev/hdb is hd0 at boot time and should rewrite /boot/grub/device.map. Maybe this bug should reassigned to d-i then. Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#272115: /usr/X11R6/bin/xedit: Xedit crashes when language is set to tr_TR
Hello, I can reproduce this bug like this: - dpkg-reconfigure locales - choose tr_TR.UTF-8 and let it generate - run LANG=tr_TR.UTF-8 xedit A gdb backtrace gives me this: #0 0x4022f7c1 in kill () from /lib/libc.so.6 #1 0x4022f545 in raise () from /lib/libc.so.6 #2 0x40230a88 in abort () from /lib/libc.so.6 #3 0x0805a02d in realpath () #4 0x0805c741 in LispFree () #5 0x0805d0b9 in LispFree () #6 0x0806284c in LispFree () #7 0x08059901 in realpath () I attached a ltrace, perhaps someone with more knowledge than me can examine this. Regards, Henry xedit.ltrace.gz Description: Binary data
Bug#170825: Checking if old version's dependencies break on update
Hello
On Wed, 17 Aug 2005 19:54:27 +0300
[EMAIL PROTECTED] (Kari Pahula) wrote:
dpkg: ../../src/packages.c:191: process_queue: Assertion `dependtry = 4'
failed.
E: Sub-process /usr/bin/dpkg exited unexpectedly
Tried with patched dpkg 1.10.28 and 1.13.10
How did you run dpkg? What was the command line?
apt-get install [somepackage]
At least I didn't get that error with the test cases I ran on the patched
dpkg.
Like I said, I got it in all cases, both with 1.10.28 and 1.13.10.
What compiler did you use? I still use gcc 3.3.5 here.
I attach an strace from dpkg --configure -a
Regards,
Henry
--
-
| Henry Jensen| |
| ScanPlus GmbH |Tel +49 731 92013 115 |
| Koenigstr. 78 D 89077 Ulm |Fax +49 731 92013 290 |
| http://www.scan-plus.de/| Amtsgericht Ulm HRB 3220 |
| [EMAIL PROTECTED] | Geschaeftsf.: Juergen Hoermann |
-
execve(/usr/bin/dpkg, [dpkg, --configure, -a], [/* 28 vars */]) = 0
uname({sys=Linux, node=jensen, ...}) = 0
brk(0) = 0x80fa000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40017000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=35015, ...}) = 0
old_mmap(NULL, 35015, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40018000
close(4)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/libc.so.6, O_RDONLY)= 4
read(4, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0755, st_size=1254468, ...}) = 0
old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40021000
old_mmap(0x4014b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4,
0x129000) = 0x4014b000
old_mmap(0x40154000, 7308, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40154000
close(4)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40156000
set_thread_area({entry_number:-1 - 6, base_addr:0x401562a0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0x40018000, 35015) = 0
brk(0) = 0x80fa000
brk(0x811b000) = 0x811b000
brk(0) = 0x811b000
umask(022) = 022
open(/etc/dpkg/dpkg.cfg, O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=293, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40018000
read(4, # dpkg configuration file\n#\n# Th..., 4096) = 293
read(4, , 4096) = 0
close(4)= 0
munmap(0x40018000, 4096)= 0
open(/root/.dpkg.cfg, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
getuid32() = 0
geteuid32() = 0
access(/var/lib/dpkg, W_OK) = 0
open(/var/lib/dpkg/lock, O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0660) = 4
fcntl64(4, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0},
0xb870) = 0
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
open(/var/lib/dpkg/status, O_RDONLY|O_LARGEFILE) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=448638, ...}) = 0
mmap2(NULL, 448638, PROT_READ, MAP_SHARED, 6, 0) = 0x40157000
brk(0) = 0x811b000
brk(0x813c000) = 0x813c000
brk(0) = 0x813c000
brk(0x815e000) = 0x815e000
brk(0) = 0x815e000
brk(0x818) = 0x818
brk(0) = 0x818
brk(0x81a2000) = 0x81a2000
brk(0) = 0x81a2000
brk(0x81c4000) = 0x81c4000
munmap(0x40157000, 448638) = 0
close(6)= 0
open(/var/lib/dpkg/updates/, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 6
fstat64(6, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
getdents64(6, /* 3 entries */, 4096)= 80
getdents64(6, /* 0 entries */, 4096)= 0
close(6)= 0
open(/var/lib/dpkg/available, O_RDONLY|O_LARGEFILE) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=407986, ...}) = 0
mmap2(NULL, 407986, PROT_READ, MAP_SHARED, 6, 0) = 0x40157000
brk(0
Bug#323808: iputils-tracepath: traceroute6 doesn't work
Package: iputils-tracepath
Version: 3:20020927-2
Severity: important
When I read about Bug #293985 I tried to reproduce it. But traceroute6
doesn't work at all:
traceroute6 -vn www.kame.net
traceroute: bind sending socket: Invalid argument
uname -a
Linux jensen 2.6.8-2-k7 #1 Thu May 19 18:03:29 JST 2005 i686 GNU/Linux
cat /etc/debian_version
testing/unstable
Output of strace traceroute6 -vn www.kame.net is attached.
Regards,
Henry
execve(/usr/sbin/traceroute6, [traceroute6, -vn, www.kame.net], [/* 24
vars */]) = 0
uname({sys=Linux, node=jensen, ...}) = 0
brk(0) = 0x804c000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40017000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=67597, ...}) = 0
old_mmap(NULL, 67597, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libresolv.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220)\0..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=64924, ...}) = 0
old_mmap(NULL, 73640, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40029000
old_mmap(0x40038000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xf000) = 0x40038000
old_mmap(0x40039000, 8104, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40039000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1254500, ...}) = 0
old_mmap(NULL, 1264812, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4003b000
old_mmap(0x40165000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x129000) = 0x40165000
old_mmap(0x4016e000, 7340, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4016e000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4017
set_thread_area({entry_number:-1 - 6, base_addr:0x40170580, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0x40018000, 67597) = 0
socket(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6) = 3
getuid32() = 0
setuid32(0) = 0
brk(0) = 0x804c000
brk(0x806d000) = 0x806d000
brk(0) = 0x806d000
gettimeofday({1124378741, 656501}, NULL) = 0
getpid()= 14361
open(/etc/resolv.conf, O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=98, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40018000
read(4, search koe.ulm.scan-plus.de\nname..., 4096) = 98
read(4, , 4096) = 0
close(4)= 0
munmap(0x40018000, 4096)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 4
connect(4, {sa_family=AF_FILE, path=/var/run/.nscd_socket}, 110) = 0
writev(4, [{\2\0\0\0\5\0\0\0\r\0\0\0, 12}, {www.kame.net\0, 13}], 2) = 25
read(4, \2\0\0\0\1\0\0\0\r\0\0\0\0\0\0\0\2\0\0\0\4\0\0\0\1\0\0..., 32) = 32
readv(4, [{www.kame.net\0, 13}, {, 0}, {\313\262\215\302, 4},
{\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, 16}], 4) = 17
close(4)= 0
open(/etc/nsswitch.conf, O_RDONLY)= 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40018000
read(4, # /etc/nsswitch.conf\n#\n# Example..., 4096) = 465
read(4, , 4096) = 0
close(4)= 0
munmap(0x40018000, 4096)= 0
open(/etc/ld.so.cache, O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=67597, ...}) = 0
old_mmap(NULL, 67597, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40018000
close(4)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libnss_files.so.2, O_RDONLY) = 4
read(4, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\35..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0644, st_size=34716, ...}) = 0
old_mmap(NULL, 38012, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40171000
old_mmap(0x4017a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4,
0x8000) = 0x4017a000
close(4)= 0
munmap(0x40018000, 67597) = 0
open(/etc/host.conf, O_RDONLY)= 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=26, ...}) = 0
mmap2(NULL, 4096,
Bug#323808: iputils-tracepath: traceroute6 doesn't work
On Thu, 18 Aug 2005 11:57:58 -0400 Noah Meyerhans [EMAIL PROTECTED] wrote: Strangely enough, it does work fine for me, using the same kernel, even: spider:~$ traceroute6 -vn www.kame.net traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2002:121a:12:1e1c:2a0:ccff:fe57:a34e, 30 hops max, 16 byte packets 1 2002:121a:12:1e1c::3 0.416 ms 0.243 ms 0.214 ms 2 2002:801e:1::801e:1 0.4 ms !N 0.277 ms !N 0.29 ms !N Linux spider 2.6.8-2-k7 #1 Thu May 19 18:03:29 JST 2005 i686 GNU/Linux I suspect a local problem of some sort. If you traceroute6 to a specific numeric IPv6 address do things behave any better? traceroute6 2001:200:0:8002:203:47ff:fea5:3085 traceroute: bind sending socket: Invalid argument No, that doesn't work either. Maybe it's a local problem, I don't know much about IPv6, so it's possible, that something is wrong here. Regards, Henry -- - | Henry Jensen| | | ScanPlus GmbH |Tel +49 731 92013 115 | | Koenigstr. 78 D 89077 Ulm |Fax +49 731 92013 290 | | http://www.scan-plus.de/| Amtsgericht Ulm HRB 3220 | | [EMAIL PROTECTED] | Geschaeftsf.: Juergen Hoermann | - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#170825: Checking if old version's dependencies break on update
Hello, the patch caused the following Error: dpkg: ../../src/packages.c:191: process_queue: Assertion `dependtry = 4' failed. E: Sub-process /usr/bin/dpkg exited unexpectedly Tried with patched dpkg 1.10.28 and 1.13.10 Kind regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322976: text files starting with '!!' wrongly identified as 'Assembler source'
A single beginning ! is enough for file to identify as Assembler source: echo '!' TestFile file TestFile TestFile: Assembler source You must remind that file is a very simple program and it's conclusions are not always right. Another 'bug' that falls in the same category: echo 'MZ' TestFile file TestFile TestFile: MS-DOS executable (EXE) Regards, Henry -- - | Henry Jensen| | | ScanPlus GmbH |Tel +49 731 92013 115 | | Koenigstr. 78 D 89077 Ulm |Fax +49 731 92013 290 | | http://www.scan-plus.de/| Amtsgericht Ulm HRB 3220 | | [EMAIL PROTECTED] | Geschaeftsf.: Juergen Hoermann | - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#195922: Patch doesn't work
Hello, Grzegorz Janoszka [EMAIL PROTECTED] wrote: There is also available patch which seems to work well: That patch doesn't work for me, neither on the original source or on the Debian patched source (lots of HUNK FAILED messages). At what point do you insert the patch? Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321166: Strange error (bash: ELF: command not found) while trying source file
Package: bash Version: 2.05b-26 Severity: important *** Please type your report below this line *** I can't do source file, but can do it with other file name: [EMAIL PROTECTED]:~$ cat file echo hello [EMAIL PROTECTED]:~$ cp file file1 [EMAIL PROTECTED]:~$ source file bash: ELF: command not found [EMAIL PROTECTED]:~$ source file1 hello Obviously source tries to source /usr/bin/file from package file. instead of $PWD/file. From bash(1): source filename [arguments] Read and execute commands from filename in the current shell environment and return the exit status of the last command executed from filename. If filename does not contain a slash, file names in PATH are used to find the directory containing filename. Try source $PWD/file Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312649: gcc-3.4 doesn't build on sarge
Package: gcc-3.4 Version: 3.4.3 Severity: normal gcc-3.4, respectively libstdc++6-0, doesn't build, it fails in stage2. This is what I do: sh-2.05b$ apt-get source libstdc++6-0 sh-2.05b$ cd gcc-3.4-3.4.3 sh-2.05b$ dpkg-buildpackage -rfakeroot -uc -us [build begins] ... make[5]: Entering directory `/spdeb/pub/source/gcc-3.4-3.4.3/build/gcc' ../../src/gcc/p/Make-lang.in:725: warning: overriding commands for target `p/version.o' ../../src/gcc/p/Make-lang.in:719: warning: ignoring old commands for target `p/version.o' /usr/bin/make CC= stage2/xgcc -Bstage2/ -B/usr/i486-linux/bin/ CC_FOR_BUILD= stage2/xgcc -Bstage2/ -B/usr/i486-linux/bin/ \ STAGE_PREFIX=stage2/ \ ADAFLAGS=-gnatpg -gnata CFLAGS=-O2 LDFLAGS= WARN_CFLAGS=\$(GCC_WARN_CFLAGS) STRICT_WARN=-pedantic -Wno-long-long -Wold-style-definition libdir=/usr/lib LANGUAGES=c gcov gcov-dump ada c++ f77 java objc pascal treelang MAKEINFO=makeinfo MAKEINFOFLAGS= MAKEOVERRIDES= OUTPUT_OPTION=-o \$@ \ CFLAGS=-O2 WERROR= make[6]: Entering directory `/spdeb/pub/source/gcc-3.4-3.4.3/build/gcc' ../../src/gcc/p/Make-lang.in:725: warning: overriding commands for target `p/version.o' ../../src/gcc/p/Make-lang.in:719: warning: ignoring old commands for target `p/version.o' stage2/gnatbind -C -I- -I. -Iada -I../../src/gcc/ada -o ada/b_gnat1.c -n ada/gnat1drv.ali make[6]: stage2/gnatbind: Command not found make[6]: *** [ada/b_gnat1.c] Error 127 make[6]: Leaving directory `/spdeb/pub/source/gcc-3.4-3.4.3/build/gcc' make[5]: *** [stage3_build] Error 2 make[5]: Leaving directory `/spdeb/pub/source/gcc-3.4-3.4.3/build/gcc' make[4]: *** [quickstrap] Error 2 make[4]: Leaving directory `/spdeb/pub/source/gcc-3.4-3.4.3/build/gcc' make[3]: *** [all-gcc] Error 2 make[3]: Leaving directory `/spdeb/pub/source/gcc-3.4-3.4.3/build' make[2]: *** [bootstrap-lean] Error 2 make[2]: Leaving directory `/spdeb/pub/source/gcc-3.4-3.4.3/build' s=`cat status`; rm -f status; test $s -eq 0 make[1]: *** [stamps/05-build-stamp] Error 1 make[1]: Leaving directory `/spdeb/pub/source/gcc-3.4-3.4.3' make: *** [stamps/05-build-stamp] Error 2 My System: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Sempron(tm) 2200+ stepping: 1 cpu MHz : 1512.272 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow bogomips: 3006.46 Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265228: Partition is right - I think
Jonas Meurer [EMAIL PROTECTED] wrote: do you have some disk at /dev/hda at all? grub's partition counting works different from the one in linux. I know that. if you're unsure, please send you complete harddisk setup. My hdd setup was: /dev/hda1 - swap /dev/hda2 - linux /dev/hdb1 - swap /dev/hdb2 - linux /dev/hdb3 - linux - Debian is there /dev/hdb4 - linux The BIOS is setup to boot from /dev/hdb first. I haven't this hdd anymore (it was not broken, it lives happily in my sisters computer), and I got a bigger one. Since I switched to LILO in the meantime, I didn't tried it with GRUB again. Regards, Henry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
