Bug#369890: silo: build-depends on gcc-2.95, which may be removed for etch
On Thursday 08 June 2006 09:08, Jurij Smakov wrote: > I've prepared updated silo package (patch attached), including a fix > for this bug. It has been updated to the latest available upstream, > built with gcc-4.1 in pbuilder, and tested on both sparc32 and sparc64. > +++ b/debian/control 2006-06-07 23:02:30.0 -0700 [...] > +Build-Depends: e2fslibs-dev (>= 1.28-1), debhelper (>= 5.0), gcc-4.1, ^^^ > bzip2, sparc-utils, perl Shouldn't silo just depend on "current gcc" instead of on an explicit version no that the need to depend on 2.95 is gone? pgp69xQRcoygu.pgp Description: PGP signature
Bug#373567: etch d-i i386 beta 2 failed to finish installation correctly
On Wednesday 14 June 2006 13:51, Frans Pop wrote: > This is probably the result of prebaseconfig being removed from testing > and being replaced by finish-install. Hmm. Looks like the finish-install postinst uses sort in a way unsupported by the busybox version used in beta2 initrds... main-menu[3044]: (process:23199): sort main-menu[3044]: (process:23199): -n main-menu[3044]: (process:23199): -k3 main-menu[3044]: (process:23199): -t/ main-menu[3044]: (process:23199): main-menu[3044]: (process:23199): sort: invalid option -- k main-menu[3044]: (process:23199): BusyBox v1.01 (Debian 1:1.01-4) multi-call binary main-menu[3044]: (process:23199): main-menu[3044]: (process:23199): Usage: sort [-n] [FILE]... pgpYHZUQHykyQ.pgp Description: PGP signature
Bug#366504: vim-runtime: Overwrites /usr/share/vim/vimcurrent in vim-common
Hi, I'm not sure if this bug is really totally fixed now, although I'm seeing it in reverse... During an upgrade today of an unstable box that had not been updated in a while, I got the following situation: Preparing to replace vim 1:6.4-007+1 (using .../vim_1%3a7.0-017+5_sparc.deb) ... Unpacking replacement vim ... Preparing to replace vim-common 1:6.4-007+1 (using .../vim-common_1%3a7.0-017+5_sparc.deb) ... Unpacking replacement vim-common ... dpkg: error processing /var/cache/apt/archives/vim-common_1%3a7.0-017+5_sparc.deb (--unpack): trying to overwrite `/usr/share/vim/vimcurrent', which is also in package vim-runtime dpkg: considering removing vim-common in favour of vim-runtime ... dpkg: yes, will remove vim-common in favour of vim-runtime. Preparing to replace vim-runtime 1:6.4-007+1 (using .../vim-runtime_1%3a7.0-017+5_all.deb) ... Unpacking replacement vim-runtime ... [...] Errors were encountered while processing: /var/cache/apt/archives/vim-common_1%3a7.0-017+5_sparc.deb E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: [...] dpkg: dependency problems prevent configuration of vim: vim depends on vim-common (= 1:7.0-017+5); however: Package vim-common is not installed. dpkg: error processing vim (--configure): dependency problems - leaving unconfigured [...] Setting up vim-runtime (7.0-017+5) ... [...] Errors were encountered while processing: vim Press return to continue. This left vim in a broken state. Running aptitude again did solve the problem: Unpacking vim-common (from .../vim-common_1%3a7.0-017+5_sparc.deb) ... Setting up vim-common (7.0-017+5) ... Installing new version of config file /etc/vim/vimrc ... Setting up vim (7.0-017+5) ... rmdir: /usr/share/doc/vim: Directory not empty Press return to continue. All in all not a very clean upgrade. Cheers, FJP P.S. Note that this bug is closed. I'll leave it to you if you want to reopen based on this report. pgpL5F2QOdwlu.pgp Description: PGP signature
Bug#373567: etch d-i i386 beta 2 failed to finish installation correctly
On Wednesday 14 June 2006 20:19, Bastian Blank wrote: > The version in unstable support it. Ack. Otherwise the bug would have also shown in daily builds... This does not help with this BR though which concerns images built using Beta2 initrds which contain an older version of busybox. So, even though the busybox udeb has (accidentally) migrated to testing now, any Beta2 images that load finish-install from the mirrors will break as they were built using the previous busybox. pgpaROc8b0Qw7.pgp Description: PGP signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Sunday 11 June 2006 20:04, Steinar H. Gunderson wrote: > I'm unable to reproduce this with 0.102 in a normal (ie. non-d-i) > environment: I can still reproduce the problem during an installation though... > configdb is here set up to be my normal debconf database (so I have > some source data to test with), but I can't understand why this would > work outside d-i but not from pkgsel... any ideas? I have a few very wild ideas, but no idea how valid they are. One idea is the encoding (installer is running with nl_NL.UTF8, although the pkgsel postinst sets and exports LANG=C). Another is busybox. A third is the way debconf-copydb is called within d-i; maybe broken handling if the target is target_configdb? The full call is: debconf-copydb -p \ "^(debian-installer/language|debian-installer/country| debian-installer/keymap|passwd/username)$" \ configdb target_configdb pgpTwCoUpSRnT.pgp Description: PGP signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Thursday 15 June 2006 21:33, Steinar H. Gunderson wrote: > > Another is busybox. > > How would this influence anything? Told you they were _wild_ guesses ;-) > Do you have a copy of the source and target databases, as well as the > cdebconf.conf used? It might be something specific about the data in > the destination that makes cdebconf discard it... The relevant files (hope the filenames speak for themselves) and an strace are available from: http://people.debian.org/~fjp/d-i/debconf-copydb.tgz (uploaded instead of attached because of size) If you want other files too, just ask. I have the testcase saved in vmware. Thanks for looking into this. pgpWxx5h0nTGO.pgp Description: PGP signature
Bug#350444: partman-auto-lvm: Creates two /boot partitions if the scheme already contains one
Package: partman-auto-lvm Version: 8 Severity: serious While testing partman-auto-lvm on sparc, which has default /boot partition in its schemes, partman-auto-lvm created two /boot partitions. Reason is that the following line is broken: if ! echo $normalscheme | grep -eq "[[:space:]]/boot[[:space:]]"; then this should be: if ! echo "$normalscheme" | grep -q "[[:space:]]/boot[[:space:]]"; then pgpeX3lHGPLIO.pgp Description: PGP signature
Bug#350797: openjade: Fails on entity definitions in xml-iso-entities-*
Package: openjade Version: 1.4devel1-15 Severity: grave Justification: renders package unusable I normally build the Debian Installation Guide in a Sarge environment, except when I upload the package. In current unstable the build of the PDF version of the manual fails when openjade is being run: /usr/bin/openjade -t tex -b utf-8 -o build.tmp/install.en.tex \ -d /home/fjp/projects/manual-build/manual/build/stylesheets/style-print.dsl \ -V tex-backend build.tmp/install.en.profiled.xml /usr/bin/openjade:/usr/share/xml/docbook/schema/dtd/4.2/docbookx.dtd:112:17:E: "X20AC" is not a function name /usr/bin/openjade:/usr/share/xml/entities/xml-iso-entities-8879.1986/ISOamsa.ent:40:19:E: "X21B6" is not a function name /usr/bin/openjade:/usr/share/xml/entities/xml-iso-entities-8879.1986/ISOamsa.ent:41:19:E: "X21B7" is not a function name /usr/bin/openjade:/usr/share/xml/entities/xml-iso-entities-8879.1986/ISOamsa.ent:42:17:E: "X21D3" is not a function name [... continues for all entities in xml-iso-entities* files...] There have been a lot of changes recently in TeX as well, so maybe the root of the problem is there; I really have no idea. This problem did not exist on Januari 2, which is when I last uploaded the Installation Guide. Please let me know if I can provide any further information. I will try downgrading and follow up if I get useful results. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-em64t-p4-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages openjade depends on: ii libc6 2.3.5-12 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-8GCC support library ii libosp5 1.5.2-1 Runtime library for OpenJade group ii libostyle1c21.4devel1-15 Runtime libraries for OpenJade ii libstdc++6 4.0.2-8 The GNU Standard C++ Library v3 ii sgml-base 1.26 SGML infrastructure and SGML catal openjade recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350797: openjade: Fails on entity definitions in xml-iso-entities-*
After downgrading the following three packages, the build completes without errors again: ii libosp4c2 1.5.1.0-4 Runtime library for OpenJade group's SP suite ii libostyle1c2 1.4devel1-14 Runtime libraries for OpenJade ii openjade 1.4devel1-14 Implementation of the DSSSL language (Note: Not downgrading libostyle1c2 resulted in the following error: /usr/bin/openjade: symbol lookup error: /usr/lib/libostyle.so.1: undefined symbol: _ZN6OpenSP17StorageObjectSpecaSERKS0_ Error: build of pdf failed with error code 127 ) Hope this helps. pgpOypb7LwRVb.pgp Description: PGP signature
Bug#346085: Please fix outstanding afbinit bugs
On Wednesday 01 February 2006 07:14, Ben Collins wrote: > > I'm bumping the severity up a bit. It would be very nice to upload a > > new afbinit, fixing this bug and #250619. > > Would be even nice if I could do the upload. Someone will have to NMU > it. Will do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350797: openjade: Fails on entity definitions in xml-iso-entities-*
severity 350797 minor thanks Thanks for your quick reaction. On Wednesday 01 February 2006 04:26, you wrote: > The problem is that in order to resolve a long standing performance > problem, I turned off DTDDECL handling in the the libosp5 package on > which openjade depends. What this means is that you need to explicitly > specify the XML declaration before the document: > > /usr/bin/openjade -t tex -b utf-8 -o build.tmp/install.en.tex \ >-d > /home/fjp/projects/manual-build/manual/build/stylesheets/style-print.dsl \ >-V tex-backend declaration/xml.dcl build.tmp/install.en.profiled.xml > ^^^ This works for me. > This is a reversion back to an older (pre-Sarge) form of the command. > I think this is a small price to pay for the huge performance gain (a > factor of 10-20), but let me know if it is not an option for you; if > so, I'll consider reinstating the behavior as it was in Sarge. Please consider documenting this change in NEWS.Debian with your next upload. Leaving the report open for that. The performance gain is indeed impressive. Here are some results for the Installation Guide: $ time ./buildone.sh i386 en pdf Info: creating temporary profiled .xml file... Info: creating temporary .tex file... Info: creating temporary .dvi file... Info: creating .pdf file... real0m45.286s user0m43.041s sys 0m2.427s $ time ./buildone.sh i386 en pdf Info: creating temporary profiled .xml file... Info: creating temporary .tex file... Info: creating temporary .dvi file... Info: creating .pdf file... real0m24.491s user0m24.252s sys 0m0.451s -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346085: Patch as applied in NMU
Here's the full patch that I applied. This includes an update of debhelper
compatibility.
Cheers,
FJP
diff -u afbinit-1.0/debian/changelog afbinit-1.0/debian/changelog
--- afbinit-1.0/debian/changelog
+++ afbinit-1.0/debian/changelog
@@ -1,3 +1,12 @@
+afbinit (1.0-1.1) unstable; urgency=low
+
+ * Non Maintainer Upload.
+ * Change the mmap() of the card's registers to use MAP_SHARED instead
+of MAP_PRIVATE. Closes: #346085.
+ * Update debhelper compatibitily to version 5.
+
+ -- Frans Pop <[EMAIL PROTECTED]> Wed, 1 Feb 2006 14:20:57 +0100
+
afbinit (1.0-1) unstable; urgency=low
* Initial Release.
diff -u afbinit-1.0/debian/rules afbinit-1.0/debian/rules
--- afbinit-1.0/debian/rules
+++ afbinit-1.0/debian/rules
@@ -1,7 +1,5 @@
#!/usr/bin/make -f
-export DH_COMPAT=3
-
build: build-stamp
build-stamp:
dh_testdir
diff -u afbinit-1.0/debian/control afbinit-1.0/debian/control
--- afbinit-1.0/debian/control
+++ afbinit-1.0/debian/control
@@ -2,7 +2,7 @@
Section: contrib/utils
Priority: optional
Maintainer: Ben Collins <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>> 3.0.0)
+Build-Depends: debhelper (>= 5.0.0)
Standards-Version: 3.5.2
Package: afbinit
only in patch2:
unchanged:
--- afbinit-1.0.orig/afbinit.c
+++ afbinit-1.0/afbinit.c
@@ -236,7 +236,7 @@
/* MMAP the registers. */
uregs = mmap(0, 0x2000,
PROT_READ | PROT_WRITE,
- MAP_PRIVATE,
+ MAP_SHARED,
afb_fd,
0x0400);
if (uregs == (void *)-1L) {
@@ -246,7 +246,7 @@
kregs = mmap(0, 0x2000,
PROT_READ | PROT_WRITE,
- MAP_PRIVATE,
+ MAP_SHARED,
afb_fd,
0x0bc04000);
if (kregs == (void *)-1L) {
only in patch2:
unchanged:
--- afbinit-1.0.orig/debian/compat
+++ afbinit-1.0/debian/compat
@@ -0,0 +1 @@
+5
pgpyyP6SMgVHe.pgp
Description: PGP signature
Bug#345931: grub 0.97 doesn't work on several machines
retitle 345931 System fails to boot after updating boot sector from grub interactive shell thanks I have managed to reproduce this in vmware using the following procedure: - new Sarge install (has grub 0.95+cvs20040624-17) - change sources list to unstable and upgrade After grub is upgraded (to 0.97-4), but without re-installing its boot sector, the system reboots without problem. Now there are two methods to reinstall the grub boot sector to the new version. 1) Run the grub-install script # grub-install /dev/sda1 Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script 'grub-install'. (hd0) /dev/sda # reboot => system reboots without any problems 2) Run the grub shell interactively as in the original report # grub grub> find /boot/grub/menu.lst (hd0,0) grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded. succeeded Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 /grub/menu..lst"... succeeded Done. grub> quit # reboot => Grub menu is not shown (screen remains blank); system fails to boot Conclusions: - grub-install does the right thing - the setup command in the grub interactive shell checks if the stage files exist, but apparently its setup command fails to check if they are compatible with the current version of grub I will keep the image I created this way in vmware for a while in case additional information is wanted. Cheers, Frans Pop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351692: mips-tools doesn't build on powerpc and hppa
On Monday 06 February 2006 22:25, Martin Michlmayr wrote: > > architecture.mk convert the architecture name in case the name in > > Debian and the name in the kernel tree is different, which is the > > case for powerpc (ppc), and hppa (parisc). > > Manoj, maybe you can take a look at the build failures on powerpc and > hppa at > http://buildd.debian.org/build.php?arch=&pkg=kernel-patch-2.4.27-mips I seem to remember that this was restructured fairly recently by Sven for official kernel builds. Apparently it was not taken into account that other packages might use the same files... I would guess that mips-tools will need to adapt to the new setup. pgpIIuU7gfdQM.pgp Description: PGP signature
Bug#347479: Seems to not handle VG creation correctly
tags 347479 + patch thanks The attached patch adds some basic checks so we do not "just go ahead" in situations the code is not ready to handle. Basically, partman-auto-lvm will now fail if the device selected for autopartioning already contains an LVM physical device. Also, the check if the name for the volume group is already in use has been improved. This patch introduces some new templates and may thus show untranslated messages if included in Beta2. However, the new strings are only shown on error situations and should not come into play during most installations using partman-auto-lvm. Comments on the patch very welcome. diff -Naurd partman-auto-lvm-9.orig/automatically_partition/some_device_lvm/do_option partman-auto-lvm-9/automatically_partition/some_device_lvm/do_option --- partman-auto-lvm-9.orig/automatically_partition/some_device_lvm/do_option 2006-01-29 19:33:38.0 +0100 +++ partman-auto-lvm-9/automatically_partition/some_device_lvm/do_option 2006-02-01 11:53:19.0 +0100 @@ -96,11 +96,17 @@ db_get partman-auto-lvm/new_vg_name VG_name="$RET" -if VG_create "$VG_name" $pv_devices; then break; fi +# check if the volume group name is not in use +if [ -z "$(VG_list | grep "$VG_name")" ]; then break; fi noninteractive="exit 1" done -perform_recipe_by_lvm $VG_name $recipe +if VG_create "$VG_name" $pv_devices; then + perform_recipe_by_lvm $VG_name $recipe +else + ## should we show an error message here? + exit 1 +fi # default to accepting the autopartitioning menudir_default_choice /lib/partman/choose_partition finish finish || true pgpu9fJQuSoHj.pgp Description: PGP signature
Bug#347479: Seems to not handle VG creation correctly
On Tuesday 07 February 2006 18:31, you wrote:
> The attached patch adds some basic checks so we do not "just go ahead"
Sorry. Attached the wrong patch. This one is better.
Index: automatically_partition/some_device_lvm/do_option
===
--- automatically_partition/some_device_lvm/do_option (revision 34764)
+++ automatically_partition/some_device_lvm/do_option (working copy)
@@ -5,12 +5,33 @@
. /lib/partman/lvm_tools.sh
. /lib/partman/auto-shared.sh
+bail_out() {
+db_input critical partman-auto-lvm/$1 || true
+db_go || true
+exit 1
+}
+
+
dev=$1
[ -f $dev/size ] || exit 1
free_size=$(cat $dev/size)
free_size=$(expr 000"$free_size" : '0*\(..*\)..$') # convert to megabytes
+# be sure the modules are loaded
+modprobe dm-mod >/dev/null 2>&1 || true
+modprobe lvm-mod >/dev/null 2>&1 || true
+
+if type update-dev >/dev/null 2>&1; then
+log-output -t update-dev update-dev
+fi
+
+# check if the device already contains any physical volumes
+realdev=$(mapdevfs "$(cat $dev/device)")
+if PV_list | grep -q "$realdev" ; then
+bail_out pv_on_device
+fi
+
# we need to be sure we can perform the selected receipe and be able to add /boot.
# virtually remove 200Mb from the free space. Perhaps a reiteration over the recipe
# would be more accurate, but for now this is more than fine.
@@ -26,9 +47,7 @@
# check if the recipe contains lvmok tags otherwise fail
if [ -z "$(echo "$scheme" | grep "lvmok")" ]; then
- db_input critical partman-auto-lvm/unusable_recipe || true
- db_go || true
- exit 1
+ bail_out unusable_recipe
fi
### situation:
@@ -74,14 +93,6 @@
now we have the container! yeppa!!!
-# be sure the modules are loaded
-modprobe dm-mod >/dev/null 2>&1 || true
-modprobe lvm-mod >/dev/null 2>&1 || true
-
-if type update-dev >/dev/null 2>&1; then
-log-output -t update-dev update-dev
-fi
-
# lvm doesn't like devfs paths.
for pv in $devfspv_devices; do
realpath="$(mapdevfs "$pv")"
@@ -96,11 +107,17 @@
db_get partman-auto-lvm/new_vg_name
VG_name="$RET"
-if VG_create "$VG_name" $pv_devices; then break; fi
-noninteractive="exit 1"
+# check if the volume group name is not in use
+if [ -z "$(VG_list | grep " $VG_name${TAB}")" ]; then break; fi
+noninteractive="bail_out vg_exists"
+db_register partman-auto-lvm/new_vg_name_exists partman-auto-lvm/new_vg_name
done
-perform_recipe_by_lvm $VG_name $recipe
+if VG_create "$VG_name" $pv_devices; then
+perform_recipe_by_lvm $VG_name $recipe
+else
+bail_out vg_create_error
+fi
# default to accepting the autopartitioning
menudir_default_choice /lib/partman/choose_partition finish finish || true
Index: debian/partman-auto-lvm.templates
===
--- debian/partman-auto-lvm.templates (revision 34764)
+++ debian/partman-auto-lvm.templates (working copy)
@@ -11,8 +11,35 @@
Default: Debian
_Description: Name of the volume group for the new system:
+Template: partman-auto-lvm/new_vg_name_exists
+Type: string
+_Description: Name of the volume group for the new system:
+ The name selected for the volume group is already in use on your system.
+ Please enter a different name.
+
Template: partman-auto-lvm/unusable_recipe
Type: error
_Description: Failed to partition the selected disk
This happened because the selected recipe does not contain any partition
that can be created on LVM volumes.
+
+Template: partman-auto-lvm/pv_on_device
+Type: error
+_Description: Selected device already contains a physical volume
+ The device you selected already contains one or more physical volumes. It
+ is not possible to automatically partition the device using LVM.
+
+Template: partman-auto-lvm/vg_exists
+Type: error
+_Description: Volume group name already in use
+ The volume group name used to automatically partition using LVM is already
+ in use. It is possible to specify an alternative name by running the
+ installation at medium or low priority.
+
+Template: partman-auto-lvm/vg_create_error
+Type: error
+_Description: Unexpected error while creating volume group
+ Autopartitioning using LVM failed because an error occurred while creating
+ the volume group.
+ .
+ Check /var/log/syslog or see virtual console 4 for the details.
Index: debian/changelog
===
--- debian/changelog (revision 34764)
+++ debian/changelog (working copy)
@@ -1,9 +1,11 @@
partman-auto-lvm (9) UNRELEASED; urgency=low
* Fix code that checks if a /boot partition is already present in the
-selected scheme. Closes: #350444.
+selected scheme. Closes: #350444.
+ * Improve handling
Bug#351871: sysvinit: installs incorrect default /etc/inittab for S/390
Package: sysvinit Severity: serious Version: 2.86.ds1-11 Tags: d-i, patch S/390 has for a long time not been installable due to an issue with parted support, so I guess that's why nobody noticed this before. After installing a new system, the system fails to boot correctly. After cron is started, messages appear: INIT: Id "[1-6]" respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel Reason is that a "regular" inittab is installed instead of the special S/390 one for dumb terminal. The problem has probably been there since: sysvinit (2.83-2) unstable; urgency=high * Install inittab.$(arch) as default inittab in the installation process, if it exists. Add inittab.s390 (closes: #113495) In the source we have: debian/share/inittab.s390-linux However: $ dpkg-architecture -qDEB_HOST_GNU_TYPE s390-linux-gnu So, please rename inittab.s390-linux to inittab.s390-linux-gnu. This should solve the problem. A prompt upload with high urgency would be very much appreciated as we're currently preparing the Etch Beta2 release of Debian Installer and this is the only issue keeping S/390 from being supported again in this release. Cheers, Frans Pop pgp73xxw1lQTH.pgp Description: PGP signature
Bug#347479: Seems to not handle VG creation correctly
On Wednesday 08 February 2006 22:07, Christian Perrier wrote: > Well, even though I'm not fond of new strings so late in the release > process, I guess we can't avoid it (I wouldn't say so if this was a > real final release with a hard string freeze). I agree, but as: - this is a new component - it really improves error handling in a critical component (partitioning can easily destroy data after all) - the templates are very unlikely to be shown anyway - we are not really in a string freeze I think we need to do this. We can wait a few days for translations, but IMO should _not_ press translators to update. > Proposal: > _Description: Existing physical volume in the selected device > LVM cannot automatically partition devices which already contain > one or more more physical volumes. There is a big difference between "LVM cannot autopartion" and "Autopartitioning using LVM is not possible" though... I'll think of something. > > +Template: partman-auto-lvm/vg_exists > > +Type: error > > +_Description: Volume group name already in use > > + The volume group name used to automatically partition using LVM is > > + already in use. It is possible to specify an alternative name by > > + running the installation at medium or low priority. > > Fineeven though I'm not fond of referring to another package which > could cause consistency problems in the future if something is changed > regarding priorities. Hm? Which other package? It's just that the question is not asked at high/critical priority with current code. Alternative of course would be to scratch that and, if there is a name conflict, always ask the user to enter an alternative name for the VG (i.e. at critical priority). I thought of doing that, but did not really want to change current functionality at this moment. Thanks for your comments. pgp2JvEx3GNhX.pgp Description: PGP signature
Bug#364217: klibc: [sparc] run-init: statfs /: invalid parameter (again)
Package: klibc Severity: serious Version: 1.3.3-3 After an upgrade in unstable on sparc a reboot resulted in: run-init: statfs /: invalid parameter I'm inclined to blame klibc as that was also the cause the previous time (#347902), but everything involved was upgraded. From /var/log/aptitude: [UPGRADE] klibc-utils 1.2.4-1 -> 1.3.3-3 [UPGRADE] libklibc 1.2.4-1 -> 1.3.3-3 [UPGRADE] initramfs-tools 0.59b -> 0.60 [UPGRADE] linux-image-2.6.16-1-sparc64 2.6.16-6 -> 2.6.16-8 As you can see I skipped a few upgrades, so I'm not sure where the regression started. pgphedAbfd77h.pgp Description: PGP signature
Bug#365418: console-tools: new console-screen.sh fails to start on S/390
Package: console-tools Version: 0.2.3dbs-61 Severity: serious Upgrade of console-tools (and therefore console-common) fails because console-screen.sh throws an error when started: $ ./console-screen.sh start || echo "FAIL $?" + '[' -r /etc/console-tools/config ']' + . /etc/console-tools/config ++ BLANK_TIME=30 ++ BLANK_DPMS=off ++ POWERDOWN_TIME=30 + '[' -d /etc/console-tools/config.d ']' + PATH=/sbin:/bin:/usr/sbin:/usr/bin + SETFONT=/usr/bin/consolechars + SETFONT_OPT= + CHARSET=/usr/bin/charset + VCSTIME=/usr/sbin/vcstime ++ uname -r ++ cut -f 2 -d . + '[' 4 = 6 ']' + VCSTIME_OPT= + '[' -d /dev/vc ']' + DEVICE_PREFIX=/dev/tty + case "$1" in + setup + '[' -x /usr/bin/consolechars ']' + VT=no ++ fgconsole + CONSOLE_TYPE= + return FAIL 1 Replacing: # If we can't access the console, quit CONSOLE_TYPE=`fgconsole 2>/dev/null` || return with: # If we can't access the console, quit CONSOLE_TYPE=`fgconsole 2>/dev/null` || return 0 may fix the problem. Note that there are other cases as well where "|| return" is used. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: s390 Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-s390 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages console-tools depends on: pn console-common (no description available) ii debconf [debconf-2.0] 1.5.0 Debian configuration management sy ii libc6 2.3.6-7 GNU C Library: Shared libraries ii libconsole 1:0.2.3dbs-61 Shared libraries for Linux console ii sysvinit 2.86.ds1-14 System-V-like init utilities Versions of packages console-tools recommends: ii console-data 20060421 Keymaps, fonts, charset maps, fall -- no debconf information pgpHD3UpA6HPH.pgp Description: PGP signature
Bug#362800: debian-installer: cd-rom installer requires online repository
On Thursday 04 May 2006 13:17, you wrote: > Frans Pop say that this bug is done in images after 15/04/2006, but I > burn the 3 *DVDs* of Debian Etch (17/04/2006) and I found the same > problem: The installer work ONLY with internet conection (online > repository is necessary!) I try use workarround available in ERRATA, > but don't work in version of day 17/04/2006 (images DVD)... the oprion > "Ignore" don't appear! > This bug is done in *DVD* images of Debian Etch? I'm very sorry, but after the fix I did on April 16, it turned out another fix was needed. This meant that the images of 17-4 were also broken, which was documented on: http://wiki.debian.org/DebianInstaller/Today If you download the new DVD, I would suggest you start with only the first one. That should contain all software you are likely to use. DVD 2 and 3 contain software that is much less commonly used. Sorry for the confusion. Good luck, Frans Pop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367783: busybox-udeb: segfaults on 'tr'
Package: busybox-udeb Version: 1:1.1.2-1 Severity: critical # echo "Create" | tr '[A-Z]' '[a-z]' Segmentation fault pgpuZaaO4XE6d.pgp Description: PGP signature
Bug#340935: netcfg: hotplugging interfaces no longer works; no network after reboot
Package: netcfg Version: 1.17 Severity: serious Justification: Makes package unsuitable for release Now that udev is enabled in d-i for kernel 2.6.14, regular interfaces get recognized as being "hotpluggable". However, as udev no longer uses hotplug, the current configuration set up by netcfg no longer works for hotplugging interfaces. Reason is that ifup is no longer called as (AFAICT) ifup eth0=hotplug but rather ifup --allow=hotplug eth0 This results in the system having no external networking after the reboot. I see this for example in a default vmware installation that has a pcnet32 eth0 interface. After some testing I've determined that the following configuration (in /etc/network/interfaces) does work: mapping eth0 script grep map eth0 allow-hotplug eth0 iface eth0 inet dhcp NOTE: I'm not sure if this is the correct/optimal solution. This new config will probably not work if package hotplug _is_ installed. Question is if netcfg should also still support that situation. Can a configuration be found that will work for both situations? pgpVaKSWQANt0.pgp Description: PGP signature
Bug#340935: Netcfg - hotplugging config no longer works with 2.6.14 + udev
Hi Thomas, I've seen that you were involved in the part of netcfg that sets this up. With 2.6.14 and udev enabled, normal interfaces are now recognized as hotpluggable. This works fine during installation, but the interface does not come up after reboot. I've put the details in [1]. Could you please have a look at that? It's rather a blocker for the new daily images, so if we cannot find a proper solution soon, I think we'll have to temporarily disable the hotplugging config (which should be fairly easy to to). Colin Watson also pointed me to some preliminary ideas for Ubuntu regarding this [2], but I'm not sure that also applies for Debian. Cheers, Frans Pop [1] http://bugs.debian.org/340935 [2] https://wiki.ubuntu.com/NetworkMagic pgp1MQ11QL9G9.pgp Description: PGP signature
Bug#341286: mismatch between the kernel used by installer and included in the archive
reassign 341286 installation-reports severity 341286 normal tags 341286 - d-i sid thanks On Tuesday 29 November 2005 22:07, Jeffrey Hundstad wrote: > 1. put cd-rom '20051128 "sid" - fsn.hu unofficial i386 Binary-1' in > drive Please let us know the full URL including filename of the image you used for the installation. In general the problem you see occurs on network or floppy based installations and not CD based installations. For CDs the problem cannot really occur, unless maybe there are problems reading it. Can you see anything in the logs to indicate this (switch to VT2 and check the output of 'dmesg' and contents (using nano) of /var/log/syslog)? Thanks. Frans Pop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
Package: linux-2.6
Version: 2.6.14-4
Severity: serious
The following error happens on Debian Installer boot in vmware (386 kernel).
This problem was not present in -3.
The system does come up after the error, but it looks so basic (memory
management AFAICT) that I've set RC severity anyway.
Feel free to adjust if you disagree.
Cheers,
FJP
ACPI: Processor [CPU0] (supports 8 throttling states)
kmem_cache_create: duplicate cache UNIX
[ cut here ]
kernel BUG at mm/slab.c:1807!
invalid operand: [#1]
Modules linked in: unix thermal processor fan pcnet32 mii uhci_hcd usbcore
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.14-2-386)
EIP is at kmem_cache_create+0x4ea/0x64c
eax: 002b ebx: c9c26b4c ecx: c02f8080 edx: 206b
esi: c0303829 edi: ca86fde9 ebp: c9c26980 esp: c988ff38
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 1605, threadinfo=c988e000 task=c98c8a70)
Stack: c02ba8f8 ca86fde4 000a c9a957a0 c9c2699c ff80 0080 c000
0080 ca870080 ca86fd60 0804e154 ca86fde4 c02410d2 ca86fde4 015c
2000 ca804000 ca870080 0804e190 0804e154
Call Trace:
[] proto_register+0x56/0x1b4
[] af_unix_init+0x0/0x5f [unix]
[] af_unix_init+0xd/0x5f [unix]
[] sys_init_module+0x99/0x16c
[] syscall_call+0x7/0xb
Code: c9 fc ff ff 55 e8 0f 0e 00 00 59 e9 a9 fd ff ff 90 ff 74 24 30 68 f8 a8
2b c0 e8 6e b3
fd ff ff 05 4c 16 39 c0 0f 8e cb 15 00 00 <0f> 0b 0f 07 0d a0 2b c0 58 5a e9
d7 fd ff ff b8
00 e0 ff ff 21
<6>usbcore: registered new driver usbkbd
drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
pgpWM4oRz0j8X.pgp
Description: PGP signature
Bug#339711: Severely broken on sparc
found 339711 2.0pl5-19.3 thanks Sam, thanks for working on this. I'm afraid the NMU has not fixed the problem on sparc though. [EMAIL PROTECTED]:~$ dpkg -l dhcp-client Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii dhcp-client 2.0pl5-19.3 DHCP Client $ sudo dhclient Internet Software Consortium DHCP Client 2.0pl5 Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved. Please contribute if you find this software useful. For info, please visit http://www.isc.org/dhcp-contrib.html sit0: unknown hardware address type 776 sit0: unknown hardware address type 776 Listening on LPF/sit0/ Sending on LPF/sit0/ Listening on LPF/lo/ Sending on LPF/lo/ Listening on LPF/eth0/08:00:20:9c:14:f5 Sending on LPF/eth0/08:00:20:9c:14:f5 Sending on Socket/fallback/fallback-net DHCPDISCOVER on sit0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 receive_packet failed on eth0: Network is down Bus error This while working in an ssh session from another system, so the network obviously is anything but down :-) pgpscOHkxXvMu.pgp Description: PGP signature
Bug#339711: Severely broken on sparc
On Saturday 03 December 2005 15:49, Frans Pop wrote: > Sam, thanks for working on this. > > I'm afraid the NMU has not fixed the problem on sparc though. I've found the cause. One patch had an extention ".diff" instead of ".patch" and because of that was not applied. I've uploaded (NMU) a new version fixing that. Cheers, FJP pgp3bulOOhwQP.pgp Description: PGP signature
Bug#341878: segfault on alpha, sparc
close 341878 1.22 thanks Bug arrived after fix had already been uploaded, therefore closing this way. On Saturday 03 December 2005 21:03, Joey Hess wrote: > Daily build install is failing like this on alpha, and I think on sparc > as well: No, it does not affect Sparc. Problem was that in some cases default keyboard arch was still being set to "none" even though that template had been removed and replaced by "skip-config" and "no-keyboard". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342028: gtk+2.0-directfb: FTBFS on mips and mipsel
Package: gtk+2.0-directfb Version: 2.0.9.2-12 Severity: serious Justification: FTBFS The package fails to build on these two architectures with the same error: gdkpango.c: In function 'gdk_draw_layout_line_with_colors': gdkpango.c:307: warning: enumeration value 'PANGO_UNDERLINE_ERROR' not handled in switch gdkpango.c:350: internal compiler error: Floating point exception This build failure is also blocking cdebconf from building on these architectures. pgpizU4WTNy36.pgp Description: PGP signature
Bug#342030: parted: FTBFS on mips and mipsel
Package: parted Version: 1.6.25.1-1 Severity: serious Justification: FTBFS The package fails to build on these two architectures with the same error: ../../../libparted/fs_hfs/advfs.c: In function 'hfs_read_bad_blocks': ../../../libparted/fs_hfs/advfs.c:241: internal compiler error: Floating point exception pgpAK1EpNXRYr.pgp Description: PGP signature
Bug#342030: parted: FTBFS on mips and mipsel
Thiemo Seufer replied to #342028 (similar error for gtk+2.0-directfb): "From the symptom I expect this to be fixed in gcc-4.0 4.0.2-4." Possibly this is valid for parted too. I understand that rebuilds are already being scheduled. [23:12:11] ths: So, just ask buildd admins to schedule a rebuild? [23:12:39] fjp: Neuro has btw. the list of all such failures and plans to use them as testcase for the redundancy buildds. pgpa1sgUTaaSX.pgp Description: PGP signature
Bug#341392: kernel BUG at mm/slab.c:1807!
On Tuesday 06 December 2005 05:23, Jurij Smakov wrote:
> It's not kernel's fault. I have just booted the 2.6.14 off today's
> sid_d-i daily netinst, and it has the bug. The bug appears because the
> af_unix_init function is invoked twice, and it normally should not
> happen. This function is the init function for the unix domain socket
> driver, which we have recently started compiling into the kernel, so
> that the corresponding module (unix.ko) is no longer shipped in kernel
> packages. It is not present in linux-image-2.6.14-2-{386,686} packages
> (version 2.6.14-4) as you can easily check. However, somehow this
> unix.ko module ends up in the installer initrd anyway, as
>
> /lib/modules/2.6.14-2-386/kernel/net/unix/unix.ko
Good catch Jurij.
This looks to be a serious bug in kernel-wedge as it seems a module from a
previous kernel version is included when that module is not present for
the kernel version for which udebs are being built.
pgp5YkqzIV2eb.pgp
Description: PGP signature
Bug#341392: RM: socket-modules-2.6.14-2-386-di - obsolete and causing problems
reassign 341392 ftp.debian.org retitle 341392 Please remove obsoleted socket-modules-2.6.14-2-386-di thanks On Tuesday 06 December 2005 06:55, Frans Pop wrote: > This looks to be a serious bug in kernel-wedge as it seems a module > from a previous kernel version is included when that module is not > present for the kernel version for which udebs are being built. Well, it isn't kernel-wedge. It's just that the udeb needs to be removed from the archive. I've pinged jvw on #d-release for that. We'll have to watch out for this for other arches too (notably AMD64). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342706: D-I - Minor buildd problems
Package: libgtk+2.0-directfb0 Version: 2.0.9.2-12 Severity: serious This from a thread on d-release. Alastair, could you please look into this? As it is keeping cdebconf from building on 2 arches, it's pretty important. On Friday 09 December 2005 17:03, Steve Langasek wrote: > On Fri, Dec 09, 2005 at 01:17:42PM +0100, Frans Pop wrote: > > There are several packages relevant for the installer that have what > > looks like minor problems keeping them from being built on some > > arches. > > - cdebconf (0.91) > > Failed on alpha and ia64 with strange build dep error; a simple > > retry may fix this. > > No, this is someone trying to be clever and hard-coding a dependency on > libc6 into libgtk+2.0-directfb0. The correct dependency on alpha and > ia64 is libc6.1. (I have no idea what the alternative on "| libc" is > supposed to do; *nothing* provides "libc" on alpha, and even if it did, > it'd be bloody worthless as a dependency. We have sonames in our lib > package names for a reason!) pgpQZECYSGx71.pgp Description: PGP signature
Bug#342906: klibc: FTBFS on Sparc64 (local build)
Package: klibc Version: 1.1.1-4 Severity: serious Justification: Fails to build from source I was trying to recover from yaird failing to create an initrd for the new kernel and, to install initramfs-tools, had to try to build klibc locally as it's not available from the mirrors for Sparc. This resulted in the following build failure: [...] strip gzip -o gzip.stripped make[2]: Leaving directory `/home/projects/klibc/klibc-1.1.1/gzip' make[1]: Leaving directory `/home/projects/klibc/klibc-1.1.1' touch debian/stamp-makefile-build if [ -e ash/sh.shared ]; then mv -f ash/sh.shared ash/sh; fi make: *** No rule to make target `configure', needed by `build/libklibc-dev'. Stop. Builddeps: ii bison2.1-0.2 A parser generator that is compatible with YACC ii cdbs 0.4.32common build system for Debian packages ii debhelper5.0.10helper programs for debian/rules ii flex 2.5.31-36 A fast lexical analyzer generator. ii gcc-3.3 3.3.6-10 The GNU C compiler ii linux-headers-2.6-12 2.6.12-10 Common architecture-specific header files for Linu pgpV3OjGpRYvO.pgp Description: PGP signature
Bug#342906: klibc: FTBFS on Sparc64 (local build))
The bug seems to be caused by the new make (3.80+3.81.b3-1). The README.Debian lists several backwards incompatibility warnings for this version. Possibly the build failure is caused by one of those. The build succeeded after downgrading to make 3.80-12. I'm not sure where this problem needs to be fixed: klibc, cdbs or make. I'll leave it up to you to reassign. Cheers, FJP pgpLtijdpDEq6.pgp Description: PGP signature
Bug#343902: debconf: "Can't call method 'description'" during tasksel
Package: debconf Version: 1.4.62 Severity: serious Justification: Breaks new installations When installing a new system (unstable), tasksel, while showing a progress bar, fails at the end of downloading packages with the following error: Can't call method 'description' on an undefined value. Attached are two screenshots showing a log of the error using "DEBCONF_DEBUG=.". I am reliably informed that this is almost certainly a debconf-apt-progress bug. apt-progress1.png Description: PNG image apt-progress2.png Description: PNG image pgpOcehrW4qjy.pgp Description: PGP signature
Bug#358532: installation-reports: sparc ultra 1 reboot fails
severity 358532 important reassign 358532 hw-detect thanks On Thursday 23 March 2006 03:35, Blars Blarson wrote: > Severity: grave > Justification: renders package unusable Please don't inflate severity: a reboot failure on one specific type of system does not make the whole installer unusable. > esp does not support sysfs, this check for it needs to be disabled. Why does this need to be disabled? Would that result in a good boot? AFAICT the problem is that the esp module is not included in and loaded by the initrd, thus resulting in your root device not being available. This actually is expected, as before the Beta 2 release we only had time to implement sbus support in d-i itself (which seems to have worked) and not the code needed to make sure detected devices are also included in the initrd. See the changelog for hw-detect 1.33. If you're willing to test the needed modifications, it should not be hard to implement this. Cheers, FJP pgpPbjCnX5q5E.pgp Description: PGP signature
Bug#358510: linux-image: SCSI/SATA boot problem
severity 358510 important thanks On Thursday 23 March 2006 00:57, Glenn English wrote: > When it comes time, during the boot process, to mount the root > partition, sda has become a SATA drive. The boot kernel says sda3 > doesn't exist, and drops to a shell (or when the SCSI has only one > partition, the boot kernel panics). Looks like you've been hit by the first erratum mentioned on [1]. This is something we're aware of and that we hope to solve for the next release of d-i and at least before Etch is released. > [rant] > If you want to discuss such fundamental kernel design issues, please do it with the upstream kernel developers, not here. For what it's worth, you're wrong in that there's some kind of structural conflict. There is not, just a timing issue that could happen just as easily if you had two different scsi controllers or two different sata controlers in the same box. [1] http://www.debian.org/devel/debian-installer/errata pgpOrHAQa1bCW.pgp Description: PGP signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
Package: cdebconf Version: 0.97 Severity: serious When debconf-copydb is run from pkgsel's postinst script, it deletes the existing /var/cache/debconf/templates.dat in /target; after it has run only copied templates are present. This results in the problem that has been reported that tasksel is not translated. Commenting out the debconf-copydb statement solves this problem. Verified with Etch Beta 2. pgpbKLKcAvkeW.pgp Description: PGP signature
Bug#361024: note on "2.4 is deprecated"
On Thursday 13 April 2006 22:59, Steve Langasek wrote: > I think etch should support 2.4 in the sense of "upgrade support only"; > i.e., it should support 2.4 because we need to be able to install etch > on systems running sarge 2.4 kernels, not because we'll provide support > for 2.4 in etch. What about (sub)arches that currently do not yet support installing 2.6? If 2.4 is really going to be dropped for Etch except for upgrade purposes, I'd very much like to see a formal (release) policy statement saying so. If 2.4 kernels are really abandoned, it will mean that we (d-i) could (should even) start cleaning out 2.4 related code and prod lagging architectures into more speed where it comes to switching to 2.6. Delaying a formal decision much longer will probably mean we'll be stuck with 2.4 whether we like it or not. pgp6RZnnCAGiT.pgp Description: PGP signature
Bug#362800: debian-installer: cd-rom installer requires online repository
severity 362800 important thanks On Saturday 15 April 2006 19:22, Nizamov Shawkat wrote: > Today I downloaded the fresh Etch iso image (CD-1, ~650Mb). > When I tried to install, installer correctly recognized media as Etch > 'testing' medium Then installer required to define the online > repository to install from and subsequently, at step of base system > install , refused to install saying something like "dont now how to > install - no cd found and mirror is not reachable" ( This PC has NIC > but no network ) > So I rendered this bug as critical as it does not allow to correctly > install from appropriate medium The fact that it tries to use a network mirror and a workaround for that is now documented in the errata for the Beta2 release [1]. Your problem is not that an online repository is required but that it fails somehow to read your CD. We've had several reports of this, but no one has yet taken the trouble to help us find out where the real problem is. Can you please do the following. - do a new install - proceed to partitioning - while you are there: - switch to VT2 (using alt-F2) - use nano to edit the file /var/lib/dpkg/info/base-installer.postinst and add a line 'set -x' below the first line - switch back to VT2 (using alt-F1) - continue the installation until the error happens - send us the /var/log/syslog file (gzipped!) You can probably use the "Save debug logs" option from the main menu to save the syslog file. Cheers, FJP [1] http://www.us.debian.org/devel/debian-installer/errata -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363079: x11-common postinst fails about broken test
severity 363079 normal merge 363079 362846 thanks On Monday 17 April 2006 15:28, Harald Dunkel wrote: > -if [ ! -L -e -d "/usr/X11R6/bin" ]; then > +if ! [ -L "/usr/X11R6/bin" ] && [ -d "/usr/X11R6/bin" ]; then This bug was already filed as #362846 and was already fixed, though the fixed version has possibly not yet been uploaded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352753: udev: ide-generic no longer loaded on boot
Package: udev Version: 0.084-4 Severity: serious After upgrade of udev from 0.084-3 to 0.084-4 and regenerating initramfs-tools initrd, ide-generic is no longer loaded on boot. I get dropped into a shell. Doing: # modprobe ide-generic # exit is enough to continue and complete the boot. After downgrading udev and regenerating the initrd the system boots normally again. Setting RC severity as this is a regression from earlier udev version (ignoring the error messages during boot). Kernel and initramfs-tools are current unstable. My laptop uses the piix driver. :00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) :00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) :00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) pgpWXjH3aBFOw.pgp Description: PGP signature
Bug#352753: udev: ide-generic no longer loaded on boot
tags + patch thanks Hi Marco, We've done a debugging session today involving Otavio Salvadore (who also saw the issue), maks and myself. There are two possible solutions, both involving modifications in /usr/share/initramfs-tools/hooks/udev. 1) revert inclusion of *_id scripts Commenting out the three lines at the end of the current file lets the system boot again. 2) add 'copy_exec /lib/udev/ide.agent /lib/udev' at the end of the file Apparently some _id script calls ide.agent and this makes sure ide-generic is loaded at the correct time. An lsmod after both boots shows ide-generic loaded after the piix driver, AFAIK this is correct. The second solution has our preference. Basically ide.agent does the same as what's currently in /usr/share/initramfs-tools/scripts/init-premount/ide (which could probably be cleaned now). The comment at the top of the ide.agent seems to imply that this whole ide-generic issue will be fixed in 2.6.16 kernels, which would be great. With my d-i release manager hat on, I would suggest uploading -5 with this fix at MEDIUM urgency. I would be very unhappy with -4 in testing in the middle of preparing for D-I Beta2. I will make sure that udev gets into testing before the final build for Beta2. One other thing. With the patch applied, most errors that are shown with -3 are gone (there were screens full of them!), but I still get 2 times the following error on the console during a boot: (...) exec of program /etc/initd.d/hdparm failed IMO it would be good to suppress such messages as, in my experience, they will only lead to unnecessary installation and bug reports. maks suggested to re-add the "silence_exec_error" patch for Beta2 and maybe come back to this issue after that? Thanks, Frans Pop pgpqq2QrT7EjA.pgp Description: PGP signature
Bug#352753: udev: ide-generic no longer loaded on boot
On Wednesday 15 February 2006 12:50, Marco d'Itri wrote: > Sorry, the right command was "udevtest /block/hda". $ sudo udevtest /block/hda main: looking at device '/block/hda' from subsystem 'block' run_program: 'ata_id --export /dev/.tmp-3-0' run_program: '/lib/udev/ata_id' (stdout) 'ID_TYPE=disk' run_program: '/lib/udev/ata_id' (stdout) 'ID_MODEL=IC25N060ATMR04-0' run_program: '/lib/udev/ata_id' (stdout) 'ID_SERIAL=MRG357K3JG1N2H' run_program: '/lib/udev/ata_id' (stdout) 'ID_REVISION=MO3OAD4A' run_program: '/lib/udev/ata_id' (stdout) 'ID_BUS=ata' run_program: '/lib/udev/ata_id' returned with status 0 run_program: 'edd_id --export /dev/.tmp-3-0' run_program: '/lib/udev/edd_id' (stderr) 'no kernel EDD support' run_program: '/lib/udev/edd_id' returned with status 2 run_program: 'path_id /block/hda' run_program: '/lib/udev/path_id' (stdout) 'ID_PATH=pci-:00:1f.1-ide-0:0' run_program: '/lib/udev/path_id' returned with status 0 udev_rules_get_name: add symlink 'disk/by-id/ata-IC25N060ATMR04-0_MRG357K3JG1N2H' udev_rules_get_name: add symlink 'disk/by-path/pci-:00:1f.1-ide-0:0' run_program: 'vol_id --export /dev/.tmp-3-0' run_program: '/lib/udev/vol_id' returned with status 4 udev_rules_get_name: no node name set, will use kernel name 'hda' main: run: 'socket:/org/kernel/udev/monitor' main: run: '/etc/init.d/hdparm hotplug' main: run: 'udev_run_hotplugd block' main: run: 'udev_run_devd block' pgp899AQB7TAr.pgp Description: PGP signature
Bug#352753: udev: ide-generic no longer loaded on boot
Marco,
Attached is the info you requested, at least I hope it is.
You asked for 'udevtest -a -p /sys/block/hdetc', but udevtest only gave me
systax errors or 'could not open file' errors. udevinfo did give a result
with those parameters, so I decided you probably mistyped.
If you actually want udevtest, what would be the correct command?
On Wednesday 15 February 2006 01:52, Marco d'Itri wrote:
> BTW, I would really really like to see the content of an uevent which
> causes ide-generic to be loaded.
I'm happy to help research the why of ide-generic further and Sven Luther
also suggested we do so on d-kernel list. I'd also be very happy if we
could agree to delay this until after D-I Beta2.
The plain fact is that a number of ide drivers seem to need ide-generic
loaded after the "real" driver is loaded. Loading it early blocks the use
of DMA for some drivers. There have been several threads about this on
d-kernel and both initramfs-tools and yaird have added workarounds for
it.
> When is the deadline for entering testing for Beta2?
udev would have to migrate to testing around February 20...
> Maybe, but I'd rather to fix this once for good instead of hiding all
> errors again.
Ack.
Cheers,
Frans
udevinfo starts with the device the node belongs to and then walks up the
device chain, to print for every device found, all possibly useful attributes
in the udev key format.
Only attributes within one device section may be used together in one rule,
to match the device for which the node will be created.
looking at device '/block/hda':
KERNEL=="hda"
SUBSYSTEM=="block"
SYSFS{stat}=="2217 18184810336529 656 1590
179684519202248981721"
SYSFS{size}=="117210240"
SYSFS{removable}=="0"
SYSFS{range}=="64"
SYSFS{dev}=="3:0"
looking at device '/devices/pci:00/:00:1f.1/ide0/0.0':
ID=="0.0"
BUS=="ide"
DRIVER=="ide-disk"
looking at device '/devices/pci:00/:00:1f.1/ide0':
ID=="ide0"
BUS==""
DRIVER==""
looking at device '/devices/pci:00/:00:1f.1':
ID==":00:1f.1"
BUS=="pci"
DRIVER=="PIIX_IDE"
SYSFS{modalias}=="pci:v8086d24CAsv1179sd0001bc01sc01i8a"
SYSFS{local_cpus}=="1"
SYSFS{irq}=="169"
SYSFS{class}=="0x01018a"
SYSFS{subsystem_device}=="0x0001"
SYSFS{subsystem_vendor}=="0x1179"
SYSFS{device}=="0x24ca"
SYSFS{vendor}=="0x8086"
looking at device '/devices/pci:00':
ID=="pci:00"
BUS==""
DRIVER==""
pgpSDjRQwJV40.pgp
Description: PGP signature
Bug#353065: linux-image-2.6.15-1-k7: update of 2.6.15-1-k7 results in unstartable system
On Wednesday 15 February 2006 23:48, Chris Searle wrote: > I have no idea how to go about debugging this and of course - since it > can't find the disks - no logs to look in :( Please try the following at the shell prompt: # modprobe ide-generic # echo /dev/hda* Are your partitions listed now? If so: # exit And your system should continue to boot normally. If this works, this is a known issue that has already been fixed in a new version of udev. Could you please tell us which driver your hard disk controller needs? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354339: Always tries to retrieve a preseed file even for not preseeded installs
tags 354339 + unreproducible thanks On Saturday 25 February 2006 14:14, Christian Perrier wrote: > It seems that preseed always tries to retrieve a preseed file...even > for not preseeded installs. > > I found this while running a standard install with the sid_d-i netinst > of 20060224. I cannot reproduce this with either sid_d-i 20060224 or 20060225, so there must be something in your local situation that causes this. Please run the installation at medium priority and tell at which menu step the preseeding happens. When you've done that, try to find the script that is run and add a 'set -x' to get a log of what it actually does. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354339: Always tries to retrieve a preseed file even for not preseeded installs
tags 354339 - patch
tags 354339 - pending
thanks
I have looked at the coding and I'm not happy with it for the release.
Although I agree that the patch by Geert will solve the problem seen by
Christian, I think it only helps to hide some more basic problems with
the whole implementation of dhcp preseeding.
For one thing, my dhcp server setup [1] already uses 'filename' for PXE
netbooting. So it seems that the chosen solution is incompatible with
netbooting which I doubt was the intention. Maybe it would be better to
use something like 'preseed-url' instead [2].
Having the dual use of 'filename' also makes the isinstallable check less
than ideal as it will currently also make network-preseed installable for
my PXE netboot setup while I have not set that up for dhcp preseeding.
I think the current test
if [ -n "$FN" -a -z "${FN##*://*}" ]; then
is intended to check that $FN actually contains an URL.
However, this is not very obvious from the code. It is probably better to
replace this test with something like
if echo "$FN" | grep -q "\(http\|ftp\)://" ; then
IMO all this needs some thought and changes in the implementation. I have
therefore uploaded a version of preseed without support for dhcp pre-
seeding but with the fixes needed for existing preseeding functionality.
[1]
My dhcp server setup contains:
group {
filename "/i386/pxelinux.0";
next-server 10.19.66.2;
host {
hardware ethernet ;
fixed-address ;
option host-name "";
}
}
This results in a lease file which contains (even if I do not actually PXE
boot):
lease {
interface "eth0";
fixed-address ;
filename "/i386/pxelinux.0";
option [...]
[...]
}
[2] Note that this would also need to be changed in the manual.
pgpdMnfdBG2OL.pgp
Description: PGP signature
Bug#354339: Always tries to retrieve a preseed file even for not preseeded installs
On Wednesday 01 March 2006 07:33, Joey Hess wrote: > Frans Pop wrote: > > For one thing, my dhcp server setup [1] already uses 'filename' for > > PXE netbooting. So it seems that the chosen solution is incompatible > > with netbooting which I doubt was the intention. > > No, see the documentation (in the installation manual). It's possible > to conditionalise the filename to send the url only to the d-i dhcp > client while sending a regular file for the pxe boot stage. Right, I missed that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355098: debian-installer - FTBFS: Tries to use apt with key checks
or security checks. +# - debian-archive-keyring +# To provide the archive key for security checks. # - dpkg (>= 1.13.9) # We tweak dpkg logging options only understood by this # version. Index: debian/changelog === --- debian/changelog (revision 35185) +++ debian/changelog (working copy) @@ -1,3 +1,10 @@ +debian-installer (20060303) unstable; urgency=low + + * Add build dependency on debian-archive-keyring and make sure that is used +for downloading udebs. Closes: #355098. + + -- Frans Pop <[EMAIL PROTECTED]> Fri, 3 Mar 2006 19:51:22 +0100 + debian-installer (20060302) unstable; urgency=low * Remove floppy-modules udeb again from powerpc root floppy as it seems this pgppMHT09yRy3.pgp Description: PGP signature
Bug#355098: debian-installer - FTBFS: Tries to use apt with key checks
On Friday 03 March 2006 20:31, Frans Pop wrote: > I think the attached patch may allow the buildd to perform the key > check, but I'm not completely sure. Actually, it looks like the change in get-packages may not be needed and we can suffice with an extra build-dep on debian-archive-keys. This package will run apt-key update in its postinst and thus update /etc/apt/trusted.gpg. As Joey mentioned on IRC, hard linking to the keyring in /usr/ would mean that locally added keys in the default keyring will no longer be used. pgpqzYCXLog73.pgp Description: PGP signature
Bug#353111: linux-image-2.6.15-1-sparc64-smp: 2.6.15 kernel can't find root disk /dev/sda1, won't boot
On Wednesday 08 March 2006 06:42, Blars Blarson wrote: > Since the system isn't bootable it's hard to check the contents of > that file. You could try the rescue mode of the installer to get a chroot into your root directory to generate a new initrd. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Monday 19 June 2006 20:57, Steinar H. Gunderson wrote: > After some discussion on IRC, here's the updated patch. Joey applied this patch yesterday and today I've built cdebconf for the new version and after that a mini.iso including that. When pkgsel is run, the debconf database is still being trashed... /me is confused pgp3ex3idptPJ.pgp Description: PGP signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
(Keeping Steinar in To: in the hope he'll want to try this one as well ;-) On Tuesday 20 June 2006 16:40, you wrote: > One change is needed yet; the current code in debconf-copydb simply > turns off i18n support (since the old code couldn't handle that > properly, it seems, or perhaps it's even older). Just nuke the setenv() > line from debconf-copydb.c and we should be okay. Works much better with that removed. You were right though that the database is completely reorganized... After some sed and sort magic, I could verify the contents. The only remaining issue is that after the debconf-copydb all "Owners:" fields from the original templates.dat in target are lost. Only three templates were added: Name: debian-installer/country Name: debian-installer/keymap Name: debian-installer/language The config.dat looks good too, with the three templates added and a value for passwd/username merged. pgp3N7SUj6zaI.pgp Description: PGP signature
Bug#374705: adduser: creates incorrect mail spool files during new installation
Package: adduser Version: 3.87 Severity: serious Tags: d-i After a new installation using Debian Installer, there are wrong mail files for several (system) users that are created during the installation: # cd /target/var/spool/mail # ls -l -- 1 root mail 0 2006-06-20 13:41 Debian-exim -- 1 root mail 0 2006-06-20 13:55 fjp -- 1 root mail 0 2006-06-20 13:41 identd -- 1 root mail 0 2006-06-20 13:41 statd (fjp is the normal user created during this install) Note that both the permissions and the ownership are broken. This breaks mail delivery for the installed system. AFAIK there is actually no need to create mail spool files for new users? I was able to create a similar file from the d-i debug shell: # chroot /target adduser xxx [...] # ls -l xxx -- 1 root mail 0 2006-06-20 14:15 xxx pgprZBBRocr7g.pgp Description: PGP signature
Bug#374705: #374705: adduser: creates incorrect mail spool files during new installation
Confirmed that the bug was introduced with passwd 4.0.15-10. After downgrading to 4.0.15-9 there is no longer a mail spool file created for a new user. pgpO0EixybjeR.pgp Description: PGP signature
Bug#374705: [Pkg-shadow-devel] Bug#374705: tentative patch
On Wednesday 21 June 2006 22:26, you wrote: > However, I think the issue is not present in the 4.0.16 versions > (according to my tests and according to the code). > > Can somebody else confirm? Confirmed. If I do a new install of unstable, the mail spool dir is clean. pgp3pZbjlwzC1.pgp Description: PGP signature
Bug#375927: RAID: groot is always set to (hd0,0)
reassign 375927 installation-reports severity 375927 normal thanks On Thursday 29 June 2006 01:53, Michael Biebl wrote: > md0 (sda1,sdb1) => swap > md1 (sda2,sdb2) => / > grub is installed correctly, but groot in /boot/grub/menu.lst is set to > (hd0,0), so update-grub generates a /boot/grub/menu.lst, where root is > not correctly set leading to an unbootable system. groot is not the same as root. (hd0,0) seems perfectly OK to me for groot. Please show us the lines as generated by the installer in grub's menu.lst for the default entry for the installed system and the lines as you think they should be (or better: with which the system does boot). > (this is the reason, why I set the severity to grave). This is a fairly unusual setup and the error should be easy to correct, especially given that grub menu lines can be corrected during the boot. Therefore a RC severity is not correct. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376260: glib2.0: FTBFS on IA64
Package: glib2.0 Version: 2.10.3-2 Severity: serious Last upload of glib2.0 has failed to build on IA64. This was already discussed on IRC, but I've decided to file a BR anyway as this will block the release of the Beta3 release of Debian Installer. < fjp> Np237: Any ideas about the glib2.0 build failure on IA64? < Np237> fjp, none, sorry < Np237> looks like references to ia64 specific assembly code < vorlon> Np237: from time to time, there have been arch-specific, glibc-provided symbols that can't be made local in a version script without breaking the linkage. This looks like an instance of that. < vorlon> hmm, s/glibc-provided/compiler-provided/ < Np237> vorlon, so this is a problem with glib's version script? < vorlon> looks like it to me < Np237> and this one is autogenerated with libtool... < vorlon> yuck. pgpRhZj07tbdG.pgp Description: PGP signature
Bug#376771: kernel-image-2.4-sparc32 in unstable is not installable
On Tuesday 04 July 2006 23:20, Joey Hess wrote: > An updated kernel-image-2.4-sparc32 was uploaded to stable and reached > unstable since that version was newer than anyhing in unstable. The new > version was for the -3 abi version of the kernel, which for sparc32, > has for some reason not reached unstable/testing even though it is > available in proposed-updates. As I understand it this is an FTP master problem: since the implementation of NEW handling for p-u (around the time of the Sarge r2 release) there have been no syncs of any security updates from p-u to unstable/testing for any package. > Either the version in proposed-updates should be added to unstable too, > or a new version uploaded. Until this happens, sparc32 installs will > not be possible (unless we finally get a 2.6 kernel that can support > sparc32). There is a 2.6 kernel that supports sparc32 (2.6.16) and e.g. daily 2.6 netboot images are already available for sparc32. There are also d-i images for CDs based on 2.6, but these are not yet supported in debian-cd as adding them would break weekly CD builds. pgpuvFd4LMdPI.pgp Description: PGP signature
Bug#376260: Bug:#376260: glib2.0: FTBFS on IA64
Hi, After pinging Lamont on IRC, I decided to try the fix myself... glib2.0 with debian/patches/999_ia64_atomic_ops_broken.patch removed built fine on merulo (sid chroot). ii gcc 4.1.1-3 The GNU C compiler Is this a case of "if it builds it's OK"? If you like, I could take care of the NMU. Cheers, FJP pgpPYLVQ3IXN9.pgp Description: PGP signature
Bug#377853: CONFIG_USB_STORAGE_DEBUG enabled => linux-image-2.6.16-2-nslu2 is unusable
On Thursday 13 July 2006 00:34, Martin Michlmayr wrote: > Yeah, I just noticed that myself. :/ It does suck but I'm not sure > this is a RC bug. The kernel does work, sort of, after all... we're > trying to get beta3 out and I think the -boot team will kill me if > there has to be another kernel rebuild so I suggest we leave it as it > is for now (I've disabled it in SVN already for future releases). Also, nslu2 is not really a mainstream arch that justifies delaying everything. This seems like a too small issue to have to rebuild for all arches to me. > Ccing -boot to get comments. Would there be time for another kernel > upload? If not, I'll downgrade this bug. An upload would just be possible, especially if it includes no other changes affecting other arches (so we can skip rebuilding the udebs). The main delay would be the build for arm which takes over a day... I'll leave the final decision to the kernel team, but if you upload please do so ASAP. Isn't there a way to work around this at run time (i.e. setting a value to 0 in /proc somewhere that disables the debugging)? Cheers, FJP pgpbNsk1gWptu.pgp Description: PGP signature
Bug#372734: (kein Betreff)
On Sunday 16 July 2006 20:59, Florian Effenberger wrote: > Could anybody please move that to the repository? Bug still is there... It will be part of the next point release for stable. Fixed package is currently available from proposed-updates. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378521: installation-report: installed system is not working
severity 378521 normal thanks On Monday 17 July 2006 06:39, Manfred Richter wrote: > Comments/Problems: > During installation a driver for the ethernet, called sky2, is used. > After installation this driver is not longer present. Davide Viti has already given you the reason for this issue. It should be resolved sometime this week as we expect the 2.6.16 kernels to finally migrate to testing. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372734: (kein Betreff)
On Monday 17 July 2006 10:53, you wrote: > > It will be part of the next point release for stable. Fixed package > > is currently available from proposed-updates. > > It isn't. Having > > deb ftp://ftp.de.debian.org/debian sarge main contrib non-free > deb http://ftp.de.debian.org/debian sarge-proposed-updates main contrib > non-free > deb http://security.debian.org sarge/updates main contrib non-free > > in my sources.list, I still get the error after apt-get update && > apt-get upgrade What version do you have installed or is it trying to install? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373567: finish-install fails also with busybox v. 1.1.3-2
On Wednesday 19 July 2006 22:22, Patrick Winnertz wrote: > I installed an cdd (debian-edu) and the installer failed in the > finish-install.postinst - script. > Errormessage as above (shortly: unsupported option -k) > The Busybox Version shipped with the cd is Busybox 1.1.3-2 and I seriously doubt you are using the busybox-udeb with that version when building the installer's initrd. Check your /var/lib/dpkg/status file. The -k option _is_ supported in busybox-udeb 1.1.3-2. pgp7d1Y6hT8kt.pgp Description: PGP signature
Bug#335950: install cannot figure out how to install no cdrom found
severity 335950 normal reassign 335950 installation-reports thanks On Thursday 27 October 2005 00:32, Kenneth Gessner wrote: > Severity: critical > Justification: breaks the whole system Again the severity is inflated. How can it break the system if there is no system installed? > "cannot install base system. > the installer cannot figure out how to install the base system. no > installable cdrom was found and no valid mirror was configured." As this works fine for most users, it is more likely a kernel problem related to your hardware. You seem to have SATA. There are known driver conflicts for some controllers between the CD driver and the SATA driver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337248: libgtk+2.0-directfb-dev: Missing dependency on pkg-config
Package: libgtk+2.0-directfb-dev Version: 2.0.9.2-10 Followup-For: Bug #337248 As this package supplies .pc files, it should depend on pkg-config (libgtk2.0-dev does the same). No real hurry to add this as this is currently taken care of for cdebconf-gtk by its dependency on libgtk2.0-dev. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-16.0508-2 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libgtk+2.0-directfb-dev depends on: ii libdirectfb-dev 0.9.22-8 frame buffer graphics library, dev ii libgtk+2.0-directfb0 2.0.9.2-10 gtk+2.0 implementation for the fra libgtk+2.0-directfb-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337382: installation-guide: FTBFS: sed: unknown option to 's'
tag 337382 pending thanks On Friday 04 November 2005 09:48, Daniel Schepler wrote: > Tracing this by adding a set -x to the command line, it appears this > is being caused by s390 expanding to an ARCH_FULL of "S/390". Correct. This is already fixed in the rules file by changing the separators for sed from "/" to ":". I would not have expected anybody to try and build the manual themselves though :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337382: installation-guide: FTBFS: sed: unknown option to 's'
severity 337382 important thanks Downgrading this issue. As the installation-guide is arch all, it does not need to be build on the buildd's and is therefore less critical. It should at least not block the current version from moving to testing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339711: dhcp-client: Severely broken on sparc
I'm seeing the same problem on my Sparc Ultra10. Switching to dhcp3-client solved the issue. Removal of the package might not be such a good idea as Debian-Installer uses the dhcp-client-udeb. I've not yet checked if the udeb has the same problems on sparc. pgpj9M3nFzGdl.pgp Description: PGP signature
Bug#339711: dhcp-client: Severely broken on sparc
On Saturday 19 November 2005 05:05, Steve Langasek wrote: > What's holding up the switch to dhcp3-client-udeb? Andrew Pollock did > a lot of work earlier this year to get it ready for d-i use. Is there > still something missing, or is it just a question of trying it out? The only issue AFAIK is size. For i386 Package Installed dhcp-client-udeb 40132 dhcp3-client-udeb145396 For sparc Package Installed dhcp-client-udeb 43176 dhcp3-client-udeb150608 For ia64 Package Installed dhcp-client-udeb 70352 dhcp3-client-udeb268 1356 As you can see a factor 3-4 larger. This is especially bad for floppy based installation. pgpP9Be2caC11.pgp Description: PGP signature
Bug#333835: ctrlproxy: Eats up memory making the system unusable
On Saturday 19 November 2005 10:41, Steve Langasek wrote: > Do we actually have reason to believe that this is a memory leak, i.e., > leaving the daemon running will continue to eat more memory? If the > program simply needs 70-some MB to run, that's unfortunate, but not RC; > if, OTOH, its memory usage continues to grow beyond the point shown in > the bug report, I agree that sounds release-critical. Yes, it slowly continues to eat more and more memory over time. The situation shown in the bug report came to be after running for several months. It runs fine using less memory when restarted. pgpdx3q2RZNgv.pgp Description: PGP signature
Bug#339711: dhcp-client: Severely broken on sparc
On Saturday 19 November 2005 15:15, Steve Langasek wrote: > Granted, though it seems that at least two of the architectures you > quoted don't support floppy installs in etch? :) Sparc does but they are not part of official release as building them requires root. pgpRx89JdeMb9.pgp Description: PGP signature
Bug#342925: missing ide-generic
On Friday 23 December 2005 14:34, maximilian attems wrote: > please try the attached patch, > should load ide-generic even if udev didn't yet bring it up: Although my initial report was for Sparc (which I will test tomorrow, I've also tested it on my laptop. ide-generic is loaded, but ide-disk is not, so not quite there yet for me. The laptop (Toshiba Satellite A40) needs piix (which is loaded): :00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 03) Cheers, FJP pgpmQMc5vM18X.pgp Description: PGP signature
Bug#342925: missing ide-generic
On Saturday 24 December 2005 04:32, Frans Pop wrote: > On Friday 23 December 2005 14:34, maximilian attems wrote: > > please try the attached patch, > > should load ide-generic even if udev didn't yet bring it up: > > Although my initial report was for Sparc (which I will test tomorrow) The patch does not solve anything for the Sparc: ide-disk still does not get loaded. pgpEh12Fjdlw5.pgp Description: PGP signature
Bug#342925: fails to load ide-disk, doesn't find hdd
On Thursday 29 December 2005 02:48, maximilian attems wrote: > could you try the attached hook file, > please place it under > /usr/share/initramfs-tools/scripts/init-premount/ The ide hook file in #344754 works for me on both my Sparc and laptop. Cheers, FJP pgpuUo1BmT4gV.pgp Description: PGP signature
Bug#322723: 'ip route' kernel problem w/ gcc-4.0
I've reassigned this bug from the kernel to gcc-4.0 as we feel that the solution chosen in the kernel packaging is not really a fix, but a workaround. As tests have shown that the problem does not exist when the same kernel is compiled with gcc-3.3, the real bug is likely in gcc-4.0. I've "found" the bug for 4.0.1-3 after looking at the dates for relevant uploads, but as uploads were quite frequent, I could be off by a version either way. Please see the bug history for details. Cheers, FJP pgpIerUbQ3XM7.pgp Description: PGP signature
Bug#322723: 'ip route' kernel problem w/ gcc-4.0
On Wednesday 07 September 2005 23:21, you wrote: > It would be extremely helpful if you could find a way to reproduce > this that does not require root... any ideas? Well, I think the problem can also be reproduced outside a debian-installer environment (getting linux-image-2.6.12-1-386 (2.6.12-2) out of the archives and running 'ip route add' should reproduce it), but I've seen no other commands than 'ip route add' fail and that does require root... Unfortunately I have hardly any C background and feel I've already passed the limits of what I can do (a lot of the info was gathered with help of joeyh and waldi). Maybe the best thing would be to work together with the kernel team on this issue. Hmm. waldi just pointed me at #325670 on IRC. Looks like it may be related. pgpnaGUPOMDrY.pgp Description: PGP signature
Bug#328992: partconf: [s/390] No longer recognizes dasd partitions
Package: partconf Version: 1.10 Severity: grave Tags: d-i During installation for s/390, partconf no longer recognizes partitions on a dasd. This is probably due to recompilation against libparted 1.6.24. pgpmSfYq3oxbn.pgp Description: PGP signature
Bug#329994: base-installer: lilo-installer fails because vmlinuz symlink is not in /
Package: base-installer Version: 1.24 Severity: serious In commit r29833 the value of link_in_boot was changed from false to true for i386 and amd64. This change make lilo-installer fail as lilo.conf is configured to expect symlinks for the kernel and initrd in / (if boot is not a separate partition). The changelog entry for this change (release 1.24) is: * Turn link_in_boot on for both i386 and amd64. They should be the same, and Kamion points out turning it off for amd64 is a regression. pgpEN5cdOh6ci.pgp Description: PGP signature
Bug#329994: base-installer: lilo-installer fails because vmlinuz symlink is not in /
On Sunday 25 September 2005 09:40, Petter Reinholdtsen wrote: > Why the serious severity? lilo is not the default boot loader, so > this only affect expert installs. Because LILO is the default installer in some cases (/ on XFS IIRC) and is also ofter prefered by users for RAID installs. Also, it is a clear regression from Sarge. > > In commit r29833 the value of link_in_boot was changed from false to > > true for i386 and amd64. This change make lilo-installer fail as > > lilo.conf is configured to expect symlinks for the kernel and initrd > > in / (if boot is not a separate partition). > > I suggest reassigning this to the lilo package, asking it to generate > a lilo.conf file pointing into /boot/ instead of expecting symlinks in > /. That should be lilo-installer, not lilo, as it is lilo-installer that creates the lilo.conf. However, I would first like to hear what the problem was for AMD64 that prompted the change in the first place and make sure that RAID and LVM installs will not be broken by changing things that way. pgpWWv5uObsWw.pgp Description: PGP signature
Bug#329994: base-installer: lilo-installer fails because vmlinuz symlink is not in /
On Monday 26 September 2005 17:11, Lennart Sorensen wrote: > My raid install of sarge used grub. Why ever would you want it to use > lilo? No idea. Just noticed in installation reports that quite a few users prefer lilo over grub. > Or does grub behave that differently on amd64 that it can't support md > raid1 like it does on i386? Would not expect that to be the case. pgp8V04HBMzrR.pgp Description: PGP signature
Bug#319148: discover1: ftbfs [sparc] invalid application of 'sizeof' to incomplete type 'struct sbus_info'
Hi Jurij, Could you take a look at this bug (as you submitted the original patch and this could be kernel headers related...). Cheers, FJP On Wednesday 20 July 2005 09:26, Blars Blarson wrote: > discover1 failed to build on a sparc buildd, duplicated on my sparc > pbuilder: [11:30:24] any sparc users around? Please have a look on #319148, ftbfs for discover1. [11:30:24] pere: where is "struct sbus_info" defined? [11:30:24] don't say it is somewhere in the kernel headers [11:30:24] waldi: I have no idea. the sbus support was provided as a patch in bts, from some sparc user. [12:45:18] pere: I assume you refer to #299074. That is not 'some sparc user', but trave11er who is on the kernel team and can often be found on this channel. [12:49:17] pere: The funny thing is that the change was introduced in 1.7.9 and that did build correctly on sparc. I wonder if this could be a change in the kernel headers? [12:54:14] entirely possible; l-k-h has had several recent uploads. [12:55:20] doesn't mean it's not a discover bug, though. pgpN2GqbfIm0M.pgp Description: PGP signature
Bug#319148: Blocking a major ISP in Netherlands
Hi Blars, I've had trouble mailing you in the past, but this time it prevents me from sending you your GPG key with my signature. Because I'm not sure how else to contact you, I'm abusing the BTS. I got the mail returned with: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mailer after MAIL FROM:<[EMAIL PROTECTED]>: host blars.org [64.81.35.59]: 553 5.3.0 mail from spamming sites refused, see http://www.blars.org/errors/block.html The mail was sent through smtp.tiscali.nl (195.241.79.132), although from the headers it appears as if it was handled by smtp-out1.tiscali.nl (195.241.79.176). Tiscali is one of the major ISPs in the Netherlands, so currently you are blocking on an extremely course basis. Cheers, Frans Pop Here are the headers for the original message: Return-path: <[EMAIL PROTECTED]> Received: from [195.240.184.66] (helo=localhost) by smtp-out1.tiscali.nl with esmtp (Tiscali http://www.tiscali.nl) id 1Dua9c-0002lD-DD for <[EMAIL PROTECTED]>; Mon, 18 Jul 2005 20:15:48 +0200 Received: from fjp by localhost with local (Exim 4.50) id 1Dua9d-0004TR-6t for [EMAIL PROTECTED]; Mon, 18 Jul 2005 20:15:49 +0200 MIME-Version: 1.0 Subject: Your signed PGP key 0x8351C3C268AC5746 User-Agent: caff 0.0.0.58 - (c) 2004, 2005 Peter Palfrader X-Mailer: MIME-tools 5.417 (Entity 5.417) Sender: "Frans Pop,,," <[EMAIL PROTECTED]> Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="--=_1121710549-17145-1" To: [EMAIL PROTECTED] Content-Transfer-Encoding: binary From: "Frans Pop" <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> Date: Mon, 18 Jul 2005 20:15:49 +0200 X-SA-Do-Not-Run: Yes pgpzhu78m6skJ.pgp Description: PGP signature
Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time
On Tuesday 26 July 2005 19:27, Stefan Esterer wrote: > After i choose the Sarge install in grub the kernel stops after some > time with : > modprobe: FATAL: Error inserting pciehp > (/lib/modules/2.6.8-2-686/kernel/drivers/pci/hotplug/shpchp.ko): > Operation not permitted > shpchp: can't be loaded > [...] > hw_random: can't be loaded > [...] Everything up to here is "normal". These modules are not supported by your hardware but do no harm. Just blacklist them for both discover and hotplug and you will be fine. > Unable to handle kernel NULL pointer dereference at virtual adress > 0024 > [...] > i810_audio: can't be loaded > [...] This one looks very much like a problem I've seen in several installation reports. [1] gives the best summary and status of the problem and has a workaround. Could you check that's the same issue? Basic problem: we really need someone who has the hardware and is willing to test solutions. Could you do that? The first step would be: check if the problem still occur with the 2.6.12 kernel. The second step would be: get in touch with the ALSA people and try to get the problem solved (maybe testing with latest drivers from CVS first). [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298623 Cheers, FJP (P.S. Please give a little bit more of the console output next time; it was just chance that I recognized the issue from the two relevant lines.) pgpVvzvo96BIS.pgp Description: PGP signature
Bug#320784: installation-reports: missing script & packages from CD
severity 320784 normal thanks Daily images can be broken sometimes (like the images dated 31-07-2005)... On Monday 01 August 2005 14:29, Torok Edwin wrote: > Debian-installer-version: > http://cdimage.debian.org/pub/cdimage-testing/etch_d-i/i386/20050709/de >bian-testing-i386-netinst.iso uname -a:Linux lightspeed.dnsalias.net Hmm. Juli 9, that is quite old... > I. The network couldn't be configured because I use PPPoE, i managed to > configure it after the reboot (this is a known issue, I've read on the > webpage). Well, there is a module that should work. Only problem is that no one has really tested it for PPPoE so far and given us useful feedback. If you're interested, try installing with 'install debconf/priority=medium' and select the ppp-modules component after the installation CD is mounted. Note: this does not really make sense with a netinst as you don't need the network before reboot (unless you want to use the bugreporter component). You could try the business card image or netbooting instead... > II. The base system didn't install, because: > 1. Deboostrap error: no such script /usr/lib/debootstrap/scripts/etch > solution: I copied the /usr/lib/debootstrap/scripts/sid to etch Should be fixed now. > 2. Couldn't download: > at, exim4, ipchains, mailx, exim4-config, exim4-base, > exim4-daemon-light note: the packages aren't on the netinst CD! > solution: I removed the packages from the install script Hmm. That's weird. Does the current netinst still have the same problem for you? > 3. Couldn't meet dependencies of initrd-tools: > cramfsprogs, dash missing from the install script > solution: I added those packages to the install script > 4. Couldn't meet dependencies of whiptail and other packages that > depend on libslang2 > solution: I added libslang2 to the install script Should all be solved in current images. > III. Apt-setup should ask if I want to add more sources when adding an > http source, but instead it just went to the next step (choosing > packages to install) > solution: I added the local mirrors, and cdroms first,(in this case > apt-setup asked me if I want more sources added) and then the > http source That is a design choice in order to limit the number of questions asked (based on number of packages available). Thanks for submitting the report. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322723: dhcp-client-udeb: 'id route add' fails w/ "Network is unreachable"
Package: dhcp-client-udeb Version: 2.0pl5-19.1 Severity: serious Tags: d-i Installations for 1386 using current daily builds (using 2.6.12) are failing with a screen saying "no default route could be set". The cause for this is that in /etc/dhclient the 'ip route add' command is failing. It returns "ip: RTNETLINK answers: Network is unreachable". This problem has been seen both on real hardware (like my laptop) and both qemu and vmware. I'm able to reproduce it consistently. I've never seen the problem during installations using images based on 2.6.8 or 2.6.11. It happens both when using DHCP and for static net configuration. I've been trying to trace the problem using several different daily netinst images (using 2.6.12) and the official Sarge netinst (using 2.6.8) for comparison and using different network devices/modules. The error happens both when dhclient is run from netcfg and when it's run from VT2 in busybox. A log with set -x in /etc/dhclient-script is attached. I've also run an strace on the 'ip route add' command. Attached are an strace for the failed command and one for a successful command from a 2.6.8 install. Currently I'm unsure whether this is a kernel problem, a d-i problem, a busybox problem and/or related to other changes in unstable (like gcc transition). I've reached the end of my skills, somebody else needs to take over from here. I'm submitting this bug against dhcp-client-udeb because that's where it manifests itself, but feel free to add info and reassign. Internet Software Consortium DHCP Client 2.0pl5 Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved. Please contribute if you find this software useful. For info, please visit http://www.isc.org/dhcp-contrib.html + set -e + [ -n ] + [ -n ] + [ -n ] + [ -n ] + ip link set lo up + sleep 1 + exit 0 + set -e + [ -n ] + [ -n ] + [ -n ] + [ -n ] + ip link set eth0 up + sleep 1 + exit 0 Listening on LPF/lo/ Sending on LPF/lo/ Listening on LPF/eth0/00:0c:29:cb:57:af Sending on LPF/eth0/00:0c:29:cb:57:af Sending on Socket/fallback/fallback-net DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 6 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPACK from 172.16.249.254 + set -e + [ -n 255.255.255.0 ] + ptom 255.255.255.0 + new_mask=/24 + [ -n ] + [ -n 172.16.249.255 ] + new_broadcast_arg=broadcast 172.16.249.255 + [ -n ] + set_hostname + cat /proc/sys/kernel/hostname + local current_hostname= + [ -z ] + echo + [ -n ] + [ -n ] + [ -z ] + ip link set eth0 up + ip addr flush dev eth0 + ip addr add 172.16.249.130/24 broadcast 172.16.249.255 dev eth0 + ip route add default via 172.16.249.2 ip: RTNETLINK answers: Network is unreachable bound to 172.16.249.130 -- renewal in 900 seconds. dhclient_2.6.12.strace.gz Description: GNU Zip compressed data dhclient_2.6.8.strace.gz Description: GNU Zip compressed data pgpBSTUSZD8Nh.pgp Description: PGP signature
Bug#225693: #225693 boot-floppies should never go into sarge
reopen 225693 retitle boot-floppies should never migrate to testing thanks Oops. boot-floppies is the source package and that still _is_ in unstable. There is also a bug in the BTS website which led me astray here... pgp38HKiKvP0O.pgp Description: PGP signature
Bug#333217: discover1: ftbfs [sparc] error: too few arguments to function 'init_lst'
On Tuesday 11 October 2005 13:17, Gaudenz Steinlin wrote: > Please try the attached patch and see if the generated binary works. Compiles and runs fine on my Ultra 10. Output of old and new versions attached. Cheers, FJP Reading PCI hardware database... Reading PCI hardware database... Reading PCI hardware database... Reading USB hardware database... Reading USB hardware database... Reading USB hardware database... Reading PCMCIA hardware database... Reading PCMCIA hardware database... Reading PCMCIA hardware database... Reading SBUS hardware database... Reading SBUS hardware database... Reading SBUS hardware database... Reading PCI hardware database... Reading PCI hardware database... Reading PCI hardware database... Reading USB hardware database... Reading USB hardware database... Reading USB hardware database... Reading PCMCIA hardware database... Reading PCMCIA hardware database... Reading PCMCIA hardware database... Reading SBUS hardware database... Reading SBUS hardware database... Reading SBUS hardware database... Reading PCI hardware database... Reading PCI hardware database... Reading PCI hardware database... Reading USB hardware database... Reading USB hardware database... Reading USB hardware database... Reading PCMCIA hardware database... Reading PCMCIA hardware database... Reading PCMCIA hardware database... Reading SBUS hardware database... Reading SBUS hardware database... Reading SBUS hardware database... Probing PCI cards... Found Sun Microsystems Computer Corp. Ultra IIi (Unknown) Found Sun Microsystems Computer Corp. Simba Advanced PCI Bridge (bridge) Found Sun Microsystems Computer Corp. Simba Advanced PCI Bridge (bridge) Found Syba Tech Ltd Parallel Port Card 2xEPP (bridge) Found Sun Microsystems Computer Corp. EBUS (Unknown) Found Sun Microsystems Computer Corp. Happy Meal (ethernet) Found ATI Technologies, Inc. 3D Rage I/II 215GT [Mach64 GT] (video) Found CMD Technology Inc PCI0646 (Unknown) Probing USB devices... Probing SBUS devices... Probing parallel ports... Found [/dev/lp1] Found [/dev/lp2] Probing serial ports... Found [/dev/ttyS0] Found [/dev/ttyS1] discover.old Description: application/trash pgp2zzXkLdNCz.pgp Description: PGP signature
Bug#333835: ctrlproxy: Eats up memory making the system unusable
Package: ctrlproxy Version: 2.6.2-1 Severity: critical Justification: breaks unrelated software After running ctrlproxy for a fairly long time as daemon: Mem: 30180 29248932 0 1336 5596 -/+ buffers/cache: 22316 7864 Swap:60440 60440 0 After killing ctrlproxy and starting it again: total used free sharedbuffers cached Mem: 30180 17168 13012 0 1508 7412 -/+ buffers/cache: 8248 21932 Swap:60440 3576 56864 -- System Information: Debian Release: 3.1 Architecture: i386 (i586) Kernel: Linux 2.4.27-2-586tsc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages ctrlproxy depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libssl0.9.70.9.7e-3 SSL shared libraries ii libxml22.6.16-7 GNOME XML library ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information pgpHhHOjfJ9RT.pgp Description: PGP signature
Bug#334613: tetex-bin: fmtutil-sys fails during package package setup
Package: tetex-bin Version: 3.0-9 Followup-For: Bug #334613 I've seen the same problem, with the following extra note. Setting up tetex-bin was retried automatically, and that time succeeded. After that tetex-extra could be set up and it appears that the total installation was successful. Upgrade log (partial) attached. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-16.0508-2 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages tetex-bin depends on: ii debconf [debconf-2.0] 1.4.58 Debian configuration management sy ii debianutils 2.15 Miscellaneous utilities specific t ii dpkg 1.13.11.0.1package maintenance system for Deb ii ed0.2-20 The classic unix line editor ii libc6 2.3.5-7GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-2 GCC support library ii libice6 6.8.2.dfsg.1-9 Inter-Client Exchange library ii libkpathsea4 3.0-9 path search library for teTeX (run ii libpaper1 1.1.14-3 Library for handling paper charact ii libpng12-01.2.8rel-5 PNG library - runtime ii libsm66.8.2.dfsg.1-9 X Window System Session Management ii libstdc++64.0.2-2The GNU Standard C++ Library v3 ii libt1-5 5.1.0-2Type 1 font rasterizer library - r ii libx11-6 6.8.2.dfsg.1-9 X Window System protocol client li ii libxaw8 6.8.2.dfsg.1-9 X Athena widget set library ii libxext6 6.8.2.dfsg.1-9 X Window System miscellaneous exte ii libxmu6 6.8.2.dfsg.1-9 X Window System miscellaneous util ii libxp66.8.2.dfsg.1-9 X Window System printing extension ii libxpm4 6.8.2.dfsg.1-9 X pixmap library ii libxt66.8.2.dfsg.1-9 X Toolkit Intrinsics ii mime-support 3.35-1 MIME files 'mime.types' & 'mailcap ii perl 5.8.7-7Larry Wall's Practical Extraction ii sed 4.1.4-4The GNU sed stream editor ii tetex-base3.0-9 Basic library files of teTeX ii ucf 2.002 Update Configuration File: preserv ii xlibs 6.8.2.dfsg.1-9 X Window System client libraries m ii zlib1g1:1.2.3-6 compression library - runtime Versions of packages tetex-bin recommends: pn libxml-parser-perl (no description available) pn perl-tk(no description available) pn psutils(no description available) ii whiptail 0.51.6-31 Displays user-friendly dialog boxe -- debconf information: tetex-bin/updmap-failed: tetex-bin/hyphen: french[=patois], ngerman[=naustrian-neue_Rechtschreibung] tetex-bin/oldcfg: true tetex-bin/upd_map: true tetex-bin/cnf_name: tetex-bin/fmtutil: true tetex-bin/use_debconf: false tetex-bin/fmtutil-failed: Setting up tetex-base (3.0-9) ... Installing new version of config file /etc/texmf/latex/texsys.cfg ... Installing new version of config file /etc/texmf/latex/color.cfg ... Installing new version of config file /etc/texmf/latex/graphics.cfg ... Installing new version of config file /etc/texmf/context/texexec.ini ... Installing new version of config file /etc/texmf/context/cont-usr.tex ... Installing new version of config file /etc/texmf/modes.mf ... Installing new version of config file /etc/texmf/dvips/config.ps ... Installing new version of config file /etc/texmf/dvips/config.pdf ... Installing new version of config file /etc/texdoctk/texdoctk.dat ... Using obsolete pdftex.cfg to generate pdftexconfig.tex ... done. Removing obsolete, unchanged conffile /etc/texmf/latex/latex.ini Removing obsolete, unchanged conffile /etc/texmf/cyrplain/cyrtex.ini Removing obsolete, unchanged conffile /etc/texmf/cyrplain/cyrtxinf.ini Removing obsolete, unchanged conffile /etc/texmf/cyrplain/cyramstx.ini Removing obsolete, unchanged conffile /etc/texmf/etex/etex.ini Removing obsolete, unchanged conffile /etc/texmf/platex/platex.ini Removing obsolete, unchanged conffile /etc/texmf/context/cont-de.ini Removing obsolete, unchanged conffile /etc/texmf/context/cont-en.ini Removing obsolete, unchanged conffile /etc/texmf/context/cont-it.ini Removing obsolete, unchanged conffile /etc/texmf/context/cont-nl.ini Removing obsolete, unchanged conffile /etc/texmf/context/cont-ro.ini Removing obsolete, unchanged conffile /etc/texmf/context/cont-uk.ini Removing obsolete, unchanged conffile /etc/texmf/context/cont-cz.ini Replacing config file /etc/texmf/mktex.cnf with new version Replacing config file /et
Bug#333835: ctrlproxy: Eats up memory making the system unusable
On Monday 24 October 2005 17:46, Faidon Liambotis wrote: > Moreover, I highly doubt that memory leak bugs are justified as > severity "critical". For regular applications I would agree. For an application that runs as a daemon and is likely to run permanently on a server, I think an RC severity is waranted. pgptSA0wcZA2l.pgp Description: PGP signature
Bug#322723: Reassign #322723
reassign 322723 linux-2.6 retitle 322723 D-I: 'id route add' fails w/ "Network is unreachable" thanks We have just tested this issue using an installer with the busybox version from Sarge and the error shows up then as well. We feel this makes the kernel the most likely source of the problem. pgp6LBWnwM61M.pgp Description: PGP signature
Bug#322723: Bug#323143: ip neigh flush (iproute) hangs because CONFIG_ATM_CLIP=y
On Tuesday 16 August 2005 19:35, Andres Salomon wrote: > > Regarding this problem with iproute: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282492 > > > > Would it be possible to include a fix for this, or at least make > > CONFIG_ATM_CLIP a module instead of a yes in the stock kernel? > > I'm suffering it right now, and it is the only reason that forces > > me to compile my own kernels... > > Thanks, > > This should probably be the case anyways, as it appears to be marked > EXPERIMENTAL, and the config does support tristate. Not only that, but > it's configured differently across different archs; definitely a > candidate for a global config. Could this also be the cause of #322723 (d-i installs failing because of failing ip route command)? It seems somewhat similar. If so, please implement the change soonest. Cheers, FJP pgpnVr447rZAC.pgp Description: PGP signature
Bug#322723: #322723 D-I: 'id route add' fails w/ "Network is unreachable"
With help from waldi I have done some additional tests for this issue yesterday and today. Here are the main results: - the problem is still there if Sarge's 'ip' is used instead of the busybox version - the problem is still there if the new linux-image-2.6.12-1-386 (2.6.12-5) kernel is used in the installer - the problem is *gone* if the kernel is compiled with gcc-3.3 from linux-source-2.6.12 (2.6.12-5) - the problem is also gone if 'route add default gw ...' is used instead of 'ip route add default via ...'; this could be used as a workaround Cheers, FJP pgp3JZX5amkh0.pgp Description: PGP signature
Bug#322723: #322723 D-I: 'id route add' fails w/ "Network is unreachable"
On Friday 19 August 2005 21:01, Bastian Blank wrote: > - the problem is not there in the 686 image. On request from waldi, I've compiled a -386 kernel (using gcc-4.0) with one change in ./debian/arch/i386/config.386: - CONFIG_CC_OPTIMIZE_FOR_SIZE=y + # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set The problem was solved when installing from a mini.iso built using this kernel. pgpTYLWFNZchx.pgp Description: PGP signature
