Bug#281952: additional /proc/device-tree patch for this issue. ...
Hello, please find here attached two files :
1) pmu_fix.patch : a new version of the 08 patch, with the change attached,
take it with a grain of salt since i had hunk offset when applying 08 alone.
2) pmu_fix.diff : the diff between the old version and the new one.
As you see, the crux of this patch is to check for the existence of a via-pmu
device in the firmware provided device-tree. I believe that this way we will
catch all instances of machines which have a /dev/pmu (checked in the 2.6.8
kernel source tree, the sole of importance for this case and powerpc), over
the previous hacky powerbook detection scheme.
Hope this help and you will find time to fix this soon.
Friendly,
Sven Luther
diff -ur control-center-2.8.1/gnome-settings-daemon/actions/acme-fb-level.c
control-center-2.8.1-patched/gnome-settings-daemon/actions/acme-fb-level.c
--- control-center-2.8.1/gnome-settings-daemon/actions/acme-fb-level.c
2005-01-18 19:43:23.60320 +0100
+++ control-center-2.8.1-patched/gnome-settings-daemon/actions/acme-fb-level.c
2005-01-18 19:44:48.055828096 +0100
@@ -143,7 +143,7 @@
AcmeFblevel *self;
int fd, foo;
- if (acme_fblevel_is_powerbook () == FALSE) {
+ if (g_file_test ("/proc/device-tree/aliases/via-pmu",
G_FILE_TEST_EXISTS) == FALSE) {
return NULL;
}
@@ -177,24 +177,3 @@
self->_priv->pmu_fd = fd;
return self;
}
-
-gboolean
-acme_fblevel_is_powerbook (void)
-{
- FILE *fd;
- char str[2048];
- gboolean found = FALSE;
-
- fd = fopen ("/proc/cpuinfo", "r");
- while (!feof (fd) && found == FALSE)
- {
- fread (str, 1, 2048, fd);
- if (strstr (str, "NewWorld") != NULL)
- found = TRUE;
- }
-
- fclose (fd);
-
- return found;
-}
-
diff -ur
control-center-2.8.1-orig/gnome-settings-daemon/actions/acme-fb-level.c
control-center-2.8.1-patched/gnome-settings-daemon/actions/acme-fb-level.c
--- control-center-2.8.1-orig/gnome-settings-daemon/actions/acme-fb-level.c
2004-09-10 04:34:57.0 +0200
+++ control-center-2.8.1-patched/gnome-settings-daemon/actions/acme-fb-level.c
2005-01-18 19:44:48.055828096 +0100
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#ifndef FBIOBLANK
#define FBIOBLANK 0x4611 /* 0 or vesa-level+1 */
@@ -84,6 +85,17 @@
return;
}
+GQuark
+acme_fblevel_error_quark (void)
+{
+ static GQuark quark = 0;
+
+ if (quark == 0)
+ quark = g_quark_from_string ("acme-fblevel-quark");
+
+ return quark;
+}
+
int
acme_fblevel_get_level (AcmeFblevel *self)
{
@@ -126,16 +138,23 @@
}
AcmeFblevel *
-acme_fblevel_new (void)
+acme_fblevel_new (GError **error)
{
AcmeFblevel *self;
int fd, foo;
- if (g_file_test ("/dev/pmu", G_FILE_TEST_EXISTS) == FALSE)
+ if (g_file_test ("/proc/device-tree/aliases/via-pmu",
G_FILE_TEST_EXISTS) == FALSE) {
return NULL;
+ }
+
- if (acme_fblevel_is_powerbook () == FALSE)
+ if (g_file_test ("/dev/pmu", G_FILE_TEST_EXISTS) == FALSE) {
+ *error = g_error_new_literal (ACME_FBLEVEL_ERROR,
+ ACME_FBLEVEL_ERROR_NO_PMU_DEVICE,
+ _("No '/dev/pmu' device found"));
return NULL;
+ }
+
self = ACME_FBLEVEL (g_object_new (ACME_TYPE_FBLEVEL, NULL));
/* This function switches the kernel backlight control off.
@@ -147,31 +166,14 @@
* Notice nicked from pbbuttons*/
fd = open ("/dev/pmu", O_RDWR);
/* We can't emit the signal yet, the signal isn't connected! */
- if (fd < 0)
+ if (fd < 0) {
+ *error = g_error_new_literal (ACME_FBLEVEL_ERROR,
+ ACME_FBLEVEL_ERROR_WRONG_PERMS,
+ _("No permission to open
'/dev/pmu' device"));
return NULL;
+ }
foo = ioctl(fd, PMU_IOC_GRAB_BACKLIGHT, 0);
self->_priv->pmu_fd = fd;
return self;
}
-
-gboolean
-acme_fblevel_is_powerbook (void)
-{
- FILE *fd;
- char str[2048];
- gboolean found = FALSE;
-
- fd = fopen ("/proc/cpuinfo", "r");
- while (!feof (fd) && found == FALSE)
- {
- fread (str, 1, 2048, fd);
- if (strstr (str, "PowerBook") != NULL)
- found = TRUE;
- }
-
- fclose (fd);
-
- return found;
-}
-
Seulement dans control-center-2.8.1-patched/gnome-settings-daemon/actions:
acme-fb-level.c.orig
diff -ur
control-center-2.8.1-orig/gnome-settings-daemon/actions/acme-fb-level.h
control-center-2.8.1
Bug#274677: wontfix ?
On Tue, Jan 18, 2005 at 05:41:44PM +, Scott James Remnant wrote: > On Tue, 2005-01-18 at 18:02 +0100, Sven Luther wrote: > > > I am just wondering if you would care to give any particular reason to your > > "wontfix" tag ? That conclusion to that bug report is maybe a bit terse, > > don't > > you think ? Not at all what an unsuspecting reader of our BTS is in his > > right > > to expect. > > > Certainly, my dear Sven. > > We're all volunteers and we give our time to this project because we > love to do so. I personally put effort into maintaining dpkg because I > enjoy the unique challenge the code represents, and get a great deal of > satisfaction from it. > > > However, not just as volunteers, but as human beings, we deserve the > right to be able to give our time without fear or intimidation from > others. > > The language Marc used in his reply was both rude and aggressive. This > intimidated me into treating his bug differently from the other 400-odd > equal-status bugs currently filed against dpkg. > > > I have a right to work without that intimidation, therefore I declined > to fix the bug or enter any further discourse about it. > > Fortunately Santiago is an excellent moderator, and provided Marc > listens to him, I'm willing to ignore his behaviour and go back to > considering this just any bug. Well, a bug without any reply for over 3 month is some cause for someone maybe loosing his calm, he is clearly a volunteer like you, and a fellow contributor to debian. All the remarks that apply to you which you justly gave above, also apply to him, and leaving a bug report about something that clearly affects the progress of his work on debian/hurd, is also somewhat rude don't you think ? Also, think of the other inocent bystanders. I personally believe, as maintainer, that it is my duty to provide at least an acknowledgement in a relative quick time after each bug report against my packages, but then i understand not everyone seems to think this is so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#274677: wontfix ?
On Tue, Jan 18, 2005 at 07:17:41PM +, Scott James Remnant wrote: > On Tue, 2005-01-18 at 20:02 +0100, Sven Luther wrote: > > > Well, a bug without any reply for over 3 month is some cause for someone > > maybe > > loosing his calm, he is clearly a volunteer like you, and a fellow > > contributor > > to debian. All the remarks that apply to you which you justly gave above, > > also > > apply to him, and leaving a bug report about something that clearly affects > > the progress of his work on debian/hurd, is also somewhat rude don't you > > think ? > > > There are 400 bugs, even if I process them out of order, this one is a > *long* way down the list. But you didn't get all those bug reports the same day, don't you ? There is a patch included, the initial report was done in good form, and altough hurd is not released, it is an important component of debian, so the bug report is clearly above average and warranted at least a response. A quick line that it is part of base and thus frozen or therelike would have been enough, a full silence is in my opinion worse than any shouting that could happen. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291234: parted: No Implementation: This ext2 filesystem has a rather strange layout! Parted No Implementation: This ext2 filesystem has a rather strange layout!
tags 291234 + upstream help thanks On Wed, Jan 19, 2005 at 03:47:11PM +0100, Joel Soete wrote: > Package: parted > Version: 1.6.11-9 > Severity: normal > > Hello all, > > I am running a debian unstable' (today updated) with a developement kernel > 2.6.11-rc1-pa3 on hppa box (b2000). > This system own 2 Disk: one boot disk of 9gb and a 'data' disk of 36Gb. > > the boot disk sda has the following slicing schema (cfdisk): > Disk /dev/sda: 9100 MB, 9100044288 bytes > 64 heads, 32 sectors/track, 8678 cylinders > Units = cylinders of 2048 * 512 = 1048576 bytes > >Device Boot Start End Blocks Id System > /dev/sda1 1 61 62448 f0 Linux/PA-RISC boot > /dev/sda2 62 306 250880 82 Linux swap / Solaris > /dev/sda3 307 367 62464 83 Linux > /dev/sda4 3688557 83865605 Extended > /dev/sda5 3681953 1624048 83 Linux > /dev/sda619542197 249840 83 Linux > /dev/sda721982319 124912 83 Linux > /dev/sda823202441 124912 83 Linux > /dev/sda924424394 1999856 83 Linux > /dev/sda10 43956347 1999856 83 Linux > /dev/sda11 63488300 1999856 83 Linux > /dev/sda12 83018557 263152 83 Linux > > And the second disk: > Disk /dev/sdb: 36.4 GB, 36420075520 bytes > 64 heads, 32 sectors/track, 34732 cylinders > Units = cylinders of 2048 * 512 = 1048576 bytes > >Device Boot Start End Blocks Id System > /dev/sdb1 1 3473235565552 83 Linux > > As I don't need any more to have the full disk for a data slice on this disk, > I would like to use parted to re-partition as: > /dev/sdb1 1 61 62448 f0 Linux/PA-RISC boot > /dev/sdb2 62 306 250880 82 Linux swap / Solaris > /dev/sdb3 307 367 62464 83 Linux > /dev/sdb4 3688557 83865605 Extended > /dev/sdb5 3681953 1624048 83 Linux > /dev/sdb619542197 249840 83 Linux > /dev/sdb721982319 124912 83 Linux > /dev/sdb823202441 124912 83 Linux > /dev/sdb924424394 1999856 83 Linux > /dev/sdb10 43956347 1999856 83 Linux > /dev/sdb11 63488300 1999856 83 Linux > /dev/sdb12 8301 3473235565552 83 Linux > > (for mirroring with raid1) > > (in summary: > parted > resize 1 0.016 26432.000 (i.e. 34732 - 8300) > move 1 0.016 8300.000 > > then create sdb[1..11] ) > > but when I asked 'parted' to check the disk slice 1: > # ./parted/parted /dev/sdb > [...] > Using /dev/sdb > (parted) p > > Disk geometry for /dev/sdb: 0.000-34732.890 megabytes > Disk label type: msdos > MinorStart End Type Filesystem Flags > 1 0.016 34732.000 primary ext3 > (parted) check 1 > > No Implementation: This ext2 filesystem has a rather strange layout! Parted > can't resize this (yet). Parted cannot handle newer ext2/3 filesystems, and this results in the message you see. upstream knows about this, but i didn't see any clear intentions to solve this, so i don't think there will be a quick fix for this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291234: [Parted-maintainers] Bug#291234: parted: No Implementation: This ext2 filesystem has a rather strange layout! Parted No Implementation: This ext2 filesystem has a rather strange layout!
On Thu, Jan 20, 2005 at 11:30:42AM +, paddy wrote: > What you can do as a workaround is use the relevant tool to remove > the ext3 features that parted doesn't like, resize, and then add them > back in. Bah, this is hacky, i would just use resize2fs directly in this case, and anyway, i think this problem also applies to newer ext2 partitions. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291234: [Parted-maintainers] Bug#291234: parted: No Implementation: This ext2 filesystem has a rather strange layout! Parted No Implementation: This ext2 filesystem has a rather strange layout!
On Thu, Jan 20, 2005 at 04:48:36PM +0100, Joel Soete wrote: > > > > On Thu, Jan 20, 2005 at 11:30:42AM +, paddy wrote: > > > What you can do as a workaround is use the relevant tool to remove > > > the ext3 features that parted doesn't like, resize, and then add them > > > back in. > > > > Bah, this is hacky, i would just use resize2fs directly in this case, and > > anyway, i think this problem also applies to newer ext2 partitions. > > > mmm > > I tried also but far from being an expert of fdisk at one moment I made enough > mistake to reach to broken my fs :-( > (... :-) I had a fresh backup so don't have any pb to recover data) For ext2/3, resize2fs works fine. i used it extensively to install all those 300 pegasos machines we sent out. > I had an additional remark: > to use this disk as a new boot disk (a mirror) for my hppa box I need at > least > a (small) /boot fs standing in the first 2Gb of the disk > I have so to move my original data slice. Unfortunately, the best I can do > is to reduce the size of my fs to 20Gb (on a disk of 36Gb). So I will never > have any opportunity to copy it at another place on the same disk (the only > other available disk being of only 9Gb) to mimic the move. apt-get install partimage and partimage-server. partimage can be used to backup (and compress) a existing disk image to either a local disk or a networked partimage server. Works both way. I would create a boot initrd including it, and then boot into the initrd, mount your backup partition, (in the last 16GB), partimage the first partition to it, delete the partition, recreate the partition and /boot, partimage it back, reboot. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281952: additional /proc/device-tree patch for this issue. ...
On Sat, Jan 22, 2005 at 08:37:59PM +0100, Juergen Kreileder wrote: > > > As you see, the crux of this patch is to check for the existence of > > a via-pmu device in the firmware provided device-tree. > > This isn't really good enough. My machine (G5) has a PMU, it's in the Ah, yes. Is it a via-pmu ? I don't think so, and so accordying to current kernel sources, there is no /dev/pmu created, which is the exclusive domain of via-pmu.c. Can you provide me with your /proc/device-tree/aliases content please ? > device-tree and /proc/pmu exists too. But it does not have > /dev/pmu[1]. You only get /dev/pmu the kernel was built with > CONFIG_PMAC_PBOOK (last time I checked ppc64 didn't compile with that > option). Exactly. > Even if you patch the kernel to get /dev/pmu on all machines with a > via-pmu (I've written a patch for this some time ago), it wouldn't > help because not all machines have an fblevel control. So, at least we weed out all machines which have no chance of having a /dev/pmu. Do you know how we can check for machines which have a fblevel control ? > Anyhow, I won't complain as long as errors are just logged to > .xsession-errors instead of being reported via annoying dialogs. Hehe. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281952: additional /proc/device-tree patch for this issue. ...
On Sun, Jan 23, 2005 at 12:37:50PM +0100, Juergen Kreileder wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> > On Sat, Jan 22, 2005 at 08:37:59PM +0100, Juergen Kreileder wrote:
> >>
> >>> As you see, the crux of this patch is to check for the existence
> >>> of a via-pmu device in the firmware provided device-tree.
> >>
> >> This isn't really good enough. My machine (G5) has a PMU, it's in
> >> the
> >
> > Ah, yes. Is it a via-pmu ? I don't think so,
>
> It's a via-pmu:
Ok, so where is the problem ? The /dev/pmu stuff would be accessible in
acme/control-center/whatever-it-is, nd everyone will be happy ? Unless you are
telling me that you don't have blacklight control for this one ?
> That means device 10:154 doesn't get registered unless CONFIG_PMAC_PBOOK
> is set
Well, CONFIG_PMAC_PBOOK is enabled in the debian kernels, as should be.
> => I don't get /dev/pmu at all with udev. (Without udev accessing the
> 10:154 /dev/pmu will just give ENODEV.)
Ah. So, you are not using a debian kernel, and there is no reason to support
you at all :)
> > Can you provide me with your /proc/device-tree/aliases content please ?
>
> ,[ ls /proc/device-tree/aliases ]
> | cd k2-cd mac-io pci4sd1 uni-n veo0
> | cd1 k2-enetmacio-mpic pci5sd2 usb0veo1
> | cpu0k2-fw mouse pci6sd3 usb1veo2
> | cpu1k2-mac-io namepci7second-boot usb-1a veo3
> | dartk2-satanvram rtc u3 usb-1b via-pmu
> | eject-key k2-uatapci satauata usb2vsp
> | enetkeyboard pci0sccaui2c usb-2a wireless
> | first-boot ki2c pci1sccbultra0 usb-2b
> | fw last-boot pci2screen ultra1 usb-2c
> | hd linux,phandle pci3sd0 uni-mpic usb3
> `
>
> ,[ cat /proc/device-tree/aliases/via-pmu ]
> | /ht/[EMAIL PROTECTED]/mac-io/via-pmu
> `
Ok.
> > Do you know how we can check for machines which have a fblevel
> > control ?
>
> Maybe the tests in
> linux/arch/ppc/platforms/pmac_backlight.c::register_backlight_controller
> are what this code should use, ie. look for a backlight device:
Well, we need to test this from userland, not kernelland.
> ,
> | bk_node = find_devices("backlight");
Ok, so there is maybe a blacklight device somewhere in /proc/devices ?
> | #ifdef CONFIG_ADB_PMU
> | /* Special case for the old PowerBook since I can't test on it */
> | backlight_autosave = machine_is_compatible("AAPL,3400/2400")
> | || machine_is_compatible("AAPL,3500");
> | if ((backlight_autosave
> | || machine_is_compatible("AAPL,PowerBook1998")
> | || machine_is_compatible("PowerBook1,1"))
> | && !strcmp(type, "pmu"))
> | valid = 1;
> | #endif
But these don't have a /dev/pmu ? Or do they have it ?
> | if (bk_node) {
> | prop = get_property(bk_node, "backlight-control", NULL);
> | if (prop && !strncmp(prop, type, strlen(type)))
> | valid = 1;
> | }
> `
>
> linux/arch/ppc64 doesn't have any backlight support so far.
So ...
> The only thing that worked on my PowerMac G5 with a ppc64 kernel, when
> I patched it to enable /dev/pmu without CONFIG_PMAC_PBOOK, was getting
> events from the power button.
Ok
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281952: additional /proc/device-tree patch for this issue. ...
On Sun, Jan 23, 2005 at 01:13:01PM +0100, Juergen Kreileder wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> > On Sun, Jan 23, 2005 at 12:37:50PM +0100, Juergen Kreileder wrote:
> >> It's a via-pmu:
> >
> > Ok, so where is the problem ? The /dev/pmu stuff would be accessible
> > in acme/control-center/whatever-it-is, nd everyone will be happy ?
> > Unless you are telling me that you don't have blacklight control for
> > this one ?
>
> It doesn't have a backlight control.
Ok.
> > Ah. So, you are not using a debian kernel, and there is no reason to
> > support you at all :)
>
> Hehe :-)
> (Using the kernel provided by Debian would mean wasting 2GB of memory
> on my machine.)
So you are using a 64bit kernel, or is there anything else in particular you
have a problem with ?
> > Well, we need to test this from userland, not kernelland.
>
> It shouldn't be too hard to find "backlight" in device-tree.
Indeed.
/me boots my ibook to check ...
Mmm, indeed. The following alogirthm is a rafinement of the current setup in
CVS :
1) if there is no /proc/device-tree/aliases/via-pmu, we quit.
2) if there is no /proc/device-tree/aliases/mac-io (should never be the case
if there is a via-pmu i think), we quit too.
3) if there is no /proc/device-tree/`cat
/proc/device-tree/aliases/mac-io`/backlight
we quit too, since there is no fblevel stuff available in /dev/pmu.
=> obvious problem is if there is a backlight without via-pmu, or if the
backlight is not on node mac-io. I doubt this happens for now, and we
can fix those cases later if they show up.
And then, we continue with the normal stuff :
4) if there is no /dev/pmu, we warn the user silently and quit.
5) if /dev/pmu is not writable, we warn the user silently, and quit.
6) if it passes upto here, we do the fblevel stuff.
7) we add a mention to the above in README.Debian, including an example on
how to make /dev/pmu usable with and without udev. Also a warning on the
security risks involved.
Does this sound acceptable ?
> >> ,
> >> | bk_node = find_devices("backlight");
> >
> > Ok, so there is maybe a blacklight device somewhere in /proc/devices
> > ?
>
> Yes. (At least I think so, I only have one machine and that doesn't
> have any backlight control.)
Ok.
> > But these don't have a /dev/pmu ? Or do they have it ?
>
> via-pmu.c uses register_backlight_controller from pmac_backlight.c, so
> this should cover machines with via-pmu.
Indeed.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#206038: nautilus: Same thing happens when playing with dual-screen layout.
Package: nautilus Version: 2.8.2-2 Followup-For: Bug #206038 Hello, I played with my dual screen setup, and stacked the screens vertically to try to workaround the radeon mergedfb 2048 resolution limit (2x1280x1024). I reverted this as it didn't work. Saddly, the icons ended up being in the bottom screen of the vertical layout, and thus when reverting to horizontal dual-screen, they simply dissapeared, probably being drawn at screen coordinates below the showed screen. There seem to be no way to get these back in place at all, so i think this issue may be not minor but probably normal at least. It is similar to a gnome-panel issue in bug : #289114 and #289117, maybe duplicated in corresponding gnome-panel bugs. A quick fix here would be to have code that checks when displaying icons if they are out of the visible area, and then redisplay them in their default position. I am not sure if something more subtle can be done or not. Friendly, Sven Luther -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.8-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages nautilus depends on: ii capplets 1:2.8.1-3 configuration applets for GNOME 2 ii desktop-file-utils 0.9-1 Utilities for .desktop files ii libart-2.0-2 2.3.16-6Library of functions for 2D graphi ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libaudiofile00.2.6-5 Open-source version of SGI's audio ii libbonobo2-0 2.8.0-4 Bonobo CORBA interfaces library ii libbonoboui2-0 2.8.0-2 The Bonobo UI library ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libeel2-22.8.2-1 Eazel Extensions Library (for GNOM ii libesd0 0.2.35-2Enlightened Sound Daemon - Shared ii libexif100.6.9-4 The EXIF library allows you to par ii libgail-common 1.8.2-1 GNOME Accessibility Implementation ii libgail171.8.2-1 GNOME Accessibility Implementation ii libgconf2-4 2.8.1-4 GNOME configuration database syste ii libglade2-0 1:2.4.1-1 Library to load .glade files at ru ii libglib2.0-0 2.6.1-2 The GLib library of C routines ii libgnome-desktop-2 2.8.1-2 Utility library for loading .deskt ii libgnome2-0 2.8.0-6 The GNOME 2 library - runtime file ii libgnomecanvas2-02.8.0-1 A powerful object-oriented display ii libgnomeui-0 2.8.0-3 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.8.3-9 The GNOME virtual file-system libr ii libgtk2.0-0 2.4.14-2The GTK+ graphical user interface ii libice6 4.3.0.dfsg.1-10 Inter-Client Exchange library ii libnautilus2-2 2.8.2-2 libraries for nautilus components ii liborbit21:2.10.2-1.1libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.6.0-3 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii librsvg2-2 2.8.1-2 SAX-based renderer library for SVG ii libsm6 4.3.0.dfsg.1-10 X Window System Session Management ii libstartup-notification0 0.7-1 library for program launch feedbac ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxml2 2.6.11-5GNOME XML library ii nautilus-data2.8.2-2 data files for nautilus ii shared-mime-info 0.15-1 FreeDesktop.org shared MIME databa ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341104: linux-patch-debian-2.6.14: dropping EXTRAVERSION from official kernel patches
On Mon, Nov 28, 2005 at 02:04:12PM +0100, Pascal A. Dupuis wrote: > Package: linux-patch-debian-2.6.14 > Version: 2.6.14-4 > Severity: minor > > Hello, > > I've just compiled a new kernel from > linux-patch-debian-2.6.14_2.6.14-4_all.deb, > and I noticed this includes the official patches 2.6.14.1 up to > 2.6.14.3, except from the extraversion. So, by default the new kernel > will be called vmlinuz-2.6.14, possibly overriding a previous > 2.6.14. Furthermore, it is difficult to tell which version you > run exactly. The fix is to run make-kpkg as: > make-kpkg --added-patches debian --append-to-version ".3" kernel-image > modules-image > > Is there some good reason to drop the EXTRAVERSION from official > patches ? Why not keep it, or even modify it as something like > ".3-debian" so that a 'uname -a' will make clear that the actual > kernel is a 2.6.14, patched up to interim revision .3, and with > specific debian patches ? Please have a look at /proc/version, which should have all the info you need : Linux version 2.6.14-2-powerpc (Debian 2.6.14-3) ([EMAIL PROTECTED]) (gcc version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3.sven.1)) #2 Thu Nov 10 11:55:12 UTC 2005 This is mine, for example, and you see that it is 2.6.14-2-powerpc official kernel built from debian source 2.6.14-3. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341104: linux-patch-debian-2.6.14: dropping EXTRAVERSION from official kernel patches
On Mon, Nov 28, 2005 at 04:49:10PM +0100, Pascal A. Dupuis wrote: > On Mon, Nov 28, 2005 at 02:55:13PM +0100, Sven Luther wrote: > > Linux version 2.6.14-2-powerpc (Debian 2.6.14-3) ([EMAIL PROTECTED]) (gcc > > version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3.sven.1)) #2 Thu Nov 10 > > 11:55:12 UTC 2005 > > > > This is mine, for example, and you see that it is 2.6.14-2-powerpc official > > kernel built from debian source 2.6.14-3. > > > Sven, > > thank you for your reply. Mine reads: > Linux version 2.6.14.3 () ([EMAIL PROTECTED]) (gcc version 4.0.2 (Debian > 4.0.2-2)) #1 Mon Nov 28 12:39:26 CET 2005 > > So ... > 1) the 2.6.14.3 is VERSION + the EXTRAVERSION I forced with make-kpkg > 2) the debian source is empty > > The suggestion was also to avoid name clashes, i.e. > linux-patch-debian-2.6.14_2.6.14-2_all.deb -> applied on 2.6.14 > linux-patch-debian-2.6.14_2.6.14-3_all.deb -> applied on 2.6.14.2 > linux-patch-debian-2.6.14_2.6.14-4_all.deb -> applied on 2.6.14.3 > > thus, compiling with one of the three versions should not result each > time in vmlinuz-2.6.14 but vmlinuz-2.6.14[.extraversion] This is some magic Bastian Blank played with, Bastian, could you comment on this ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341104: linux-patch-debian-2.6.14: dropping EXTRAVERSION from official kernel patches
On Tue, Nov 29, 2005 at 05:00:24PM +0100, Pascal A. Dupuis wrote:
> On Mon, Nov 28, 2005 at 05:09:41PM +0100, Sven Luther wrote:
> > > The suggestion was also to avoid name clashes, i.e.
> > > linux-patch-debian-2.6.14_2.6.14-2_all.deb -> applied on 2.6.14
> > > linux-patch-debian-2.6.14_2.6.14-3_all.deb -> applied on 2.6.14.2
> > > linux-patch-debian-2.6.14_2.6.14-4_all.deb -> applied on 2.6.14.3
> > >
> > > thus, compiling with one of the three versions should not result each
> > > time in vmlinuz-2.6.14 but vmlinuz-2.6.14[.extraversion]
> >
> > This is some magic Bastian Blank played with, Bastian, could you comment on
> > this ?
> >
>
> Some more news:
>
> 1) kernels compiled from pristine source + applied debian patches of
> debian source resulted in the same name for the kernel image
>
> 2) I got a number of crashes (total freeze) with such kernel. The
>personnal best is less than 5 minutes :-{. A 2.6.14.3 pristine
>(linux patches - no debian patches) does not exhibit this
>behaviour, AFAIK (currently stress testing it - no problems)
Could you please try the debian 2.6.14-4 linux-image kernels please ?
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341279: Missing bttv.h
On Tue, Nov 29, 2005 at 09:06:05PM +0100, Amaya Rodrigo Sastre wrote: > Package: linux-headers-2.6.14 > Severity: normal > > Hi there, > > In order to build lirc-modules-source I used to depend on linux-headers. > Right now linux-headers do not include bttv.h, which I need in order to > build certain lirc modules. You need to : 1) build-depend on linux-headers-2.6.14-2-all 2) look at the list of flavours in /usr/src/linux-headers-2.6.14/flavours 3) for each flavour, do a build of the modules with KSRC=/lib/modules/2.6.14-2- > I wonder if this file could be included there, as depending on the whole > linux-source seems a bit too much for just that file. > > Thanks for your time. Any suggestions greatly welcome. Is it also missing in the per-flavour packages ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333684: gparted does it right
On Tue, Nov 29, 2005 at 04:43:36PM +0100, Jerome Warnier wrote: > Package: parted > Version: 1.6.25.1-1 > Followup-For: Bug #333684 > > Something even more weird: gparted is doing the same thing without any > problem. > And it is also using the same libparted1.6-13 (1.6.25.1-1)... gparted uses some external tools for some stuff, so maybe also for this (not sure wat this is though, please provide at least a hint of context for those followup mails :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341378: kernel 2.6.12 and 2.6.14 crash on boot loading usb drivers on a sis chipset
severity 341378 important thanks On Wed, Nov 30, 2005 at 11:39:41AM +0100, Maximilian Attems wrote: > On Wed, Nov 30, 2005 at 11:05:26AM +0100, giorgiove wrote: > > Package: kernel > > Severity: critical > > Justification: breaks the whole system > > > > hmm as it works for others that severity seems midly exagerated, > leave it to other d-kernel maintainer. Indeed, lowering it. > > -- System Information: > > Debian Release: testing/unstable > > APT prefers unstable > > APT policy: (500, 'unstable'), (500, 'testing') > > Architecture: i386 (i686) > > Shell: /bin/sh linked to /bin/bash > > Kernel: Linux 2.6.14-2-686 > > Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) > > With new udev (I reported to udev maintainer but it says it's a > > kernel problem) the kernel doesn't' boot anymore making a mess of usb > > tree as described in the log file I attached below. the only way is > > to deinnstall udev and use old hotplug > > please send in: > working dmesg after boot, lspci output. Oh, this is udev breakage, clearly not critical then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341524: yaird: fails to upgrade from linux-2.4 to 2.6
On Thu, Dec 01, 2005 at 01:29:08AM -0500, The Anarcat wrote: > Package: yaird > Version: 0.0.11-12 > Severity: important > > > Hello, > > I just upgraded to sid from sarge, and I'm having problems moving to the > kernel 2.6. First off, let me mention that the upgrade didn't go as > smoothly as planned, which was to be expected nowadays... My packages > for kernel-image-2.6 were removed somehow, probably due to the new > linux-image kernels. Anyways... > > Now that I actually try to switch to 2.6, some weird problem doesn't > want to let me. I tried this: Well, yaird cannot install from a 2.4 kernel, which is why you see this failure. The correct upgrade way using yaird is to first upgrade to the sarge (2.6.8) or etch (2.6.12) 2.6 kernel, and then upgrade to 2.6.14 after a reboot, using yaird, or boot the current 2.6.14 based sid-d-i netinst, once you are at the partitioning step, go to console 2, mount your root partition, chroot into it, mount /proc and /sys, and dpkg-reconfigure linux-image-2.6.14-2-k7. The other alternative is to install initramfs-tools, which knows how to install from a 2.4 kernel. I prefer using yaird myself though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341524: yaird: fails to upgrade from linux-2.4 to 2.6
On Thu, Dec 01, 2005 at 02:12:20AM -0500, The Anarcat wrote: > On Thu Dec 01, 2005 at 07:58:32AM +0100, Sven Luther wrote: > > > > Well, yaird cannot install from a 2.4 kernel, which is why you see this > > failure. The correct upgrade way using yaird is to first upgrade to the > > sarge > > (2.6.8) or etch (2.6.12) 2.6 kernel, and then upgrade to 2.6.14 after a > > reboot, using yaird, or boot the current 2.6.14 based sid-d-i netinst, once > > you are at the partitioning step, go to console 2, mount your root > > partition, > > chroot into it, mount /proc and /sys, and dpkg-reconfigure > > linux-image-2.6.14-2-k7. The other alternative is to install > > initramfs-tools, > > which knows how to install from a 2.4 kernel. I prefer using yaird myself > > though. > > Is this what the upgrade path from sarge will look like for etch > (assuming here that etch will go up to 2.6.14, or will that not happen > at all?). No, but we are still far from the sarge release (which is scheduled for december 2006, with freeze in july or so), and we probably will have to move to having initramfs-tools the first default for it. Maybe the best idea would be to have yaird as first default as now, but have the dependencies install both, which would guarantee it always works. > In general, why not simply change the depends to have the whole thing > Just Work in the general case? Well, at 2.6.14 release time, initramfs-tools, and his klibc dependency, had some maturation problems, and is also regularly broken by udev, so for now, yaird, provided it works, is still the more solid solution, and at least it will fail cleanly, and give you an error message or such, while initramfs-tools may or not fail during boot time. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341524: yaird: fails to upgrade from linux-2.4 to 2.6
On Thu, Dec 01, 2005 at 08:25:13AM +0100, Sven Luther wrote: > Well, at 2.6.14 release time, initramfs-tools, and his klibc dependency, had > some maturation problems, and is also regularly broken by udev, so for now, > yaird, provided it works, is still the more solid solution, and at least it > will fail cleanly, and give you an error message or such, while > initramfs-tools may or not fail during boot time. In case this was not clear, this applied to the time 2.6.14 was released. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341524: yaird: fails to upgrade from linux-2.4 to 2.6
On Thu, Dec 01, 2005 at 12:17:25PM +0100, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 1 Dec 2005 08:25:13 +0100 > Sven Luther <[EMAIL PROTECTED]> wrote: > > > Maybe the best idea would be to have yaird as first default as now, > > but have the dependencies install both, which would guarantee it > > always works. > > A better approach IMHO is to recommend (not depend on) alternative > ramdisk tool than the one picked as default. Well, with tools like aptitude, there is not much of a difference. > initramfs-tools will pull in udev which is unwanted for some, and yaird > will similarly pull in perl dependencies that is unwanted for some. perl dependencies are hardly problematic, especially since we have perl-base, altough it would be good to make yaird depend on perl-base only, but we discussed this already. Udev might be more legitimate to not want though. > Sure, both can be seen as weird complaints (I have had my fights with > convincing the php4 maintainer to not depend on X11 by default when This is also a sane complaint, we divided ocaml packages between the x version and the nox stuff too. > sanely avoidable), but I don't think disliking udev should force one to > either recompile kernels or use equivs. Yep, that makes sense. Too bad dependencies don't allow us to do something more advanced. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341559: yaird: fails to create initrd
On Thu, Dec 01, 2005 at 12:37:23PM +0100, Hans Ekbrand wrote: > Package: yaird > Version: 0.0.11-12 > Severity: important > > This is a Old-world IDE-based Macintosh Performa 5400, running unstable on a > 2.6.8-12 kernel. Hi Hans, ... Do you happen to know exactly which driver is needed for this device ? > Unpacking linux-image-2.6-powerpc (from > .../linux-image-2.6-powerpc_2.6.14-4_powerpc.deb) ... > Setting up linux-image-2.6.14-2-powerpc (2.6.14-4) ... > Using /usr/sbin/mkinitrd.yaird to build the ramdisk. > Full list of probed ramdisk generating tools : /usr/sbin/mkinitrd > /usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs. > yaird error: unrecognised device: > /sys/devices/pci:00/:00:10.0/0.f300:ohare > yaird error: unrecognised device: > /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA Could you send us a : find /sys/devices/pci:00/:00:10.0/0.f300:ohare output, so we know this ? I suppose this is just that yaird doesn't know about the intermediary nodes between the actual block driver and the hardware it knows of, so will be rather easy to fix. Erik, Jonas, what about a "i know what i do" option, which would allow to ignore this kind of in-between nodes, provided that the final block driver is known ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341559: yaird: fails to create initrd
On Thu, Dec 01, 2005 at 01:10:39PM +0100, Hans Ekbrand wrote:
> On Thu, Dec 01, 2005 at 12:54:34PM +0100, Sven Luther wrote:
> > On Thu, Dec 01, 2005 at 12:37:23PM +0100, Hans Ekbrand wrote:
> > > Package: yaird
> > > Version: 0.0.11-12
> > > Severity: important
> > >
> > > This is a Old-world IDE-based Macintosh Performa 5400, running unstable
> > > on a 2.6.8-12 kernel.
> >
> > Hi Hans, ...
> >
> > Do you happen to know exactly which driver is needed for this device ?
>
> Do you mean which module to drive this IDE harddisk?
>
> > > Unpacking linux-image-2.6-powerpc (from
> > > .../linux-image-2.6-powerpc_2.6.14-4_powerpc.deb) ...
> > > Setting up linux-image-2.6.14-2-powerpc (2.6.14-4) ...
> > > Using /usr/sbin/mkinitrd.yaird to build the ramdisk.
> > > Full list of probed ramdisk generating tools : /usr/sbin/mkinitrd
> > > /usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs.
> > > yaird error: unrecognised device:
> > > /sys/devices/pci:00/:00:10.0/0.f300:ohare
> > > yaird error: unrecognised device:
> > > /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA
> >
> > Could you send us a :
> >
> > find /sys/devices/pci:00/:00:10.0/0.f300:ohare
>
> /sys/devices/pci:00/:00:10.0/0.f300:ohare
> /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA
> /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA/ide0
> /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA/ide0/0.0
> /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA/ide0/0.0/block
This is probably similar to the problem we had :
/sys/devices/pci0001:10/0001:10:17.0/0.8000:mac-io/0.0002:ata-3/ide1
so instead of ignoring 0.8000:mac-io and 0.0002:ata-3, you need to
ignore 0.f300:ohare and 0.0002:ATA.
So, in /usr/lib/yaird/perl/Hardware.pm, at line 81, you need to copy one of the
two
above lines :
if ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:mac-io$!) {
# Apple bus; harmless
}
elsif ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:ata-\d+$!) {
# Apple IDE bus; harmless
}
for your case, maybe something like :
if ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:ohare$!) {
# Apple bus; harmless
}
elsif ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:ATA\d+$!) {
# Apple IDE bus; harmless
}
but i am no perl expert, and may have gotten the exact magic wrong.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341559: yaird: fails to create initrd
On Thu, Dec 01, 2005 at 02:08:14PM +0100, Hans Ekbrand wrote: > On Thu, Dec 01, 2005 at 01:41:01PM +0100, Maximilian Attems wrote: > > clone 341559 -1 > > reassign -1 initramfs-tools > > stop > > > > On Thu, Dec 01, 2005 at 01:33:10PM +0100, Hans Ekbrand wrote: > > > On Thu, Dec 01, 2005 at 12:51:48PM +0100, maximilian attems wrote: > > > > just saw your bugreport could you try latest initramfs-tools > > > > from unstable too? would be cool to get it tested, > > > > and report probable boot error (or success)? > > > > > > Exactly the same error: > > > > > > # dpkg --configure -a > > > Setting up linux-image-2.6.14-2-powerpc (2.6.14-4) ... > > > Using /usr/sbin/mkinitrd.yaird to build the ramdisk. > > > > well you are still using yaird. > > OK. I thought installing initramfs-tools would suffice, I didn't know > that it was an alternativ to yaird, nor that it would not be used by > default. > > > please try temporarly adding to /etc/kernel-img.conf > > ramdisk = /usr/sbin/mkinitramfs /usr/sbin/mkinitrd > > OK. > > Now it worked! the initrd was created and the boot successful. Can you try the same thing also using MODULES=dep (or whatever that option is called) in /etc/mkinitramfs/mkinitramfs.conf please ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341559: yaird: fails to create initrd
On Thu, Dec 01, 2005 at 03:27:35PM +0100, Maximilian Attems wrote: > On Thu, Dec 01, 2005 at 03:16:04PM +0100, Sven Luther wrote: > > On Thu, Dec 01, 2005 at 02:08:14PM +0100, Hans Ekbrand wrote: > > > On Thu, Dec 01, 2005 at 01:41:01PM +0100, Maximilian Attems wrote: > > > > clone 341559 -1 > > > > reassign -1 initramfs-tools > > > > stop > > > > > > > > On Thu, Dec 01, 2005 at 01:33:10PM +0100, Hans Ekbrand wrote: > > > > > On Thu, Dec 01, 2005 at 12:51:48PM +0100, maximilian attems wrote: > > > > > > just saw your bugreport could you try latest initramfs-tools > > > > > > from unstable too? would be cool to get it tested, > > > > > > and report probable boot error (or success)? > > > > > > > > > > Exactly the same error: > > > > > > > > > > # dpkg --configure -a > > > > > Setting up linux-image-2.6.14-2-powerpc (2.6.14-4) ... > > > > > Using /usr/sbin/mkinitrd.yaird to build the ramdisk. > > > > > > > > well you are still using yaird. > > > > > > OK. I thought installing initramfs-tools would suffice, I didn't know > > > that it was an alternativ to yaird, nor that it would not be used by > > > default. > > > > > > > please try temporarly adding to /etc/kernel-img.conf > > > > ramdisk = /usr/sbin/mkinitramfs /usr/sbin/mkinitrd > > > > > > OK. > > > > > > Now it worked! the initrd was created and the boot successful. > > > > Can you try the same thing also using MODULES=dep (or whatever that option > > is > > called) in /etc/mkinitramfs/mkinitramfs.conf please ? > > no please dont!! Huh ? You don't want people to test initramfs-tools in MODULES=dep mode ? > svenl stop givine bad advices to users. Huh again ? > #341559 is an yaird bug, > the initramfs one was cloned as #341567 and is fixede. Who cares, his stuff worked in initramfs-tools with MODULES=most, but was it tested in MODULES=dep ? Friendly, Sven Luther > > -- > maks > > ps one last time cc 341559, sorry for the noise jonas. > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > --- > Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341559: yaird: fails to create initrd
On Thu, Dec 01, 2005 at 04:37:30PM +0100, Maximilian Attems wrote: > On Thu, Dec 01, 2005 at 03:50:46PM +0100, Jonas Smedegaard wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Thu, 1 Dec 2005 15:27:35 +0100 > > Maximilian Attems <[EMAIL PROTECTED]> wrote: > > > > > > > Now it worked! the initrd was created and the boot successful. > > > > > > > > Can you try the same thing also using MODULES=dep (or whatever that > > > > option is called) in /etc/mkinitramfs/mkinitramfs.conf please ? > > > > > > no please dont!! > > > > > > svenl stop givine bad advices to users. > > > #341559 is an yaird bug, > > > the initramfs one was cloned as #341567 and is fixede. > > > > Why not? Is that option somehow unsupported? > > > > We have here a chance to test initramfs-tools on a tricky machine - and > > Sven suggests to then extend the test to not only the default setting > > but also the more compact one. > > > > It is no secret that Sven and I is fond of yaird, but this is no > > competition: Do you prefer discovering possible bugs closer to release? > > > defaults are set out of *dam-good-reasons*. :) > if you wana play around with them do it on your dev machine. > if svenl is serious about his little pet option than he would have > followed up to his bug report long since 5th november. > it's none of the business of this bug reporter. Ok, since we go this way, i notice that you didn't even bother to post a single post to said bug report, and that when i used my time to test initramfs-tools on the pegasos, you ended up being uncivile to me (again) on irc, so really, i am a bit sick of your behavior. > it seems like that very nice old world mac had np booting an full > featured initramfs and reporter wanted to get his machine up quickly. So, what does it cost asking that he goes the full way and tries out MODULES=dep, or are you afraid it will be broken, and will need to coerce someone else to fix the bug for you ? Like you not even bothering to look at how to build klibc with l-k-h as it should, and me having to do it for you ? Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341597: [ppc,d-i-gtk] installation report on b&w G3
On Thu, Dec 01, 2005 at 04:59:59PM +0100, Wolfram Quester wrote: > Package: installation-reports > > Boot method: miniiso with graphical installer daily build from Sven Luther > Image version: > http://people.debian.org/~luther/d-i/gtkdi/images/2005-12-01/powerpc/gtk-miniiso/mini.iso > Date: 2005-12-01 > > Machine: Apple PowerMac G3 (Blue&White) > Processor: G3, 400 MHz > Memory: 192 MB > Partitions: > > > Output of cat /proc/cpuinfo: > processor : 0 > cpu : 740/750 > temperature : 32-37 C (uncalibrated) > clock : 400MHz > revision : 2.2 (pvr 0008 0202) > bogomips : 794.62 > machine : PowerMac1,1 > motherboard : PowerMac1,1 MacRISC Power Macintosh > detected as : 66 (Blue&White G3) > pmac flags: > L2 cache : 1024K unified > memory: 192MB > pmac-generation : NewWorld > > Output of lspci > :00:00.0 Host bridge: Motorola MPC106 [Grackle] (rev 40) > :00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 02) > :00:10.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE/SG Mmm, this is a rage 128, not sure if it will have enough memory, or if the corresponding fbdev is broken or something. Attilio, do you perhaps have some program linked with the .deb libraries, that the user could run to test under normal circunstances ? This would make debugging somewhat easier maybe. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341597: [ppc,d-i-gtk] installation report on b&w G3
On Thu, Dec 01, 2005 at 09:46:50PM +0100, Attilio Fiandrotti wrote: > >Mmm, this is a rage 128, not sure if it will have enough memory, or if the > >corresponding fbdev is broken or something. > > > >Attilio, do you perhaps have some program linked with the .deb libraries, > >that > >the user could run to test under normal circunstances ? This would make > >debugging somewhat easier maybe. > > > > this is what i got on directfb-dev from [EMAIL PROTECTED] (thanks!) > after forwarding wolfram's post > > - > I recommend to disable hw acceleration on ppc systems. At least for now. Oh well, we should fix it instead, whatever it is :) > It is best to pass > > --with-gfxdrivers=none > > to configure on ppc. > > Judging from your cursor you are experiencing the "bi-endian system" > problem. (ram: big-endian, vram: little-endian). This should not result I have some problem understanding this, back in the days when i used to write X graphic drivers (for 3dlabs permedia3 and later wildcat vp), i remember perfectly the graphic card being able to be programmed in auto endian switching when accessing the video ram, and i suppose that is what X does. I think there is no reason this should not happen here, and i even believe this is the way the fbdev drivers program it, since it usually is part of the low-level programmation of the video ram aperture, not something which would need to be done in the directfb accel driver. > in a crash, but shows me that you are using a gfxdriver, which in > addidion may cause your segfault. > - > > i know HW acceleration can disabled at runtime bi adding "no-hardware" > option to /etc/directfb (see > http://www.directfb.org/docs/directfbrc.5.html). > Since this seems to be a DFB upstream bug, shouldn't better the > discussion take place at [EMAIL PROTECTED] here we could get > more specialistic help. > To make simple tests you could compile and run the "simple" app from > http://www.directfb.org/downloads/Extras/DFBTutorials-0.5.0.tar.gz Well, if we can disable it at runtime, the best is to have a d-i kernel command line option to disable it or something, no ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341559: yaird: fails to create initrd
tags 341559 + patch
thanks
On Thu, Dec 01, 2005 at 11:25:34PM +0100, Hans Ekbrand wrote:
> On Thu, Dec 01, 2005 at 01:52:34PM +0100, Sven Luther wrote:
> > On Thu, Dec 01, 2005 at 01:10:39PM +0100, Hans Ekbrand wrote:
> > > On Thu, Dec 01, 2005 at 12:54:34PM +0100, Sven Luther wrote:
>
> [...]
>
> > > > find /sys/devices/pci:00/:00:10.0/0.f300:ohare
> > >
> > > /sys/devices/pci:00/:00:10.0/0.f300:ohare
> > > /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA
> > > /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA/ide0
> > > /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA/ide0/0.0
> > > /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA/ide0/0.0/block
> >
> > This is probably similar to the problem we had :
> >
> > /sys/devices/pci0001:10/0001:10:17.0/0.8000:mac-io/0.0002:ata-3/ide1
> >
> > so instead of ignoring 0.8000:mac-io and 0.0002:ata-3, you need to
> > ignore 0.f300:ohare and 0.0002:ATA.
> >
> > So, in /usr/lib/yaird/perl/Hardware.pm, at line 81, you need to copy one of
> > the two
> > above lines :
> >
> > if ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:mac-io$!) {
> > # Apple bus; harmless
> > }
> > elsif ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:ata-\d+$!) {
> > # Apple IDE bus; harmless
> > }
> >
> > for your case, maybe something like :
> >
> > if ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:ohare$!) {
> > # Apple bus; harmless
> > }
> > elsif ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:ATA\d+$!) {
> > # Apple IDE bus; harmless
> > }
> >
> > but i am no perl expert, and may have gotten the exact magic wrong.
>
> Attached is a patch that made it match the two problematic lines:
>
> > > /sys/devices/pci:00/:00:10.0/0.f300:ohare
> > > /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA
>
> With the patch applied, the initrd was successfully created, and the
> kernel booted without any problems.
Hehe, thanks, i guess a diff -u is prefered, but i am sure Erik and Jonas will
be able to adapt.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341686: xterm cannot be started in utf-8 mode by default
On Fri, Dec 02, 2005 at 01:51:00PM +0100, David MartÃnez Moreno wrote: > El viernes, 2 de diciembre de 2005 09:56, Jan Willem Stumpel escribió: > > Package: xterm > > Version: 6.8.2.dfsg.1-11 > > Severity: normal > > Tags: l10n > > > > > > xterm -u8 does not start xterm in UTF-8 mode, nor does specifying > > xterm*VT100*utf8: in ~/.Xresources make xterm start in UTF-8 mode by > > default. > > > > Xterm can be switched to UTF-8 manually (control-rightclick) in both cases, > > but I'd like it to be in UTF-8 mode by default. This is possible with xterm > > version 200, but not with the current Sid version (202). > > Could you please test latest version (204-0pre1) from experimental and > see if > it works? It works for me (I use ISO8859-15): Notice that some locales have shifted to UTF-8 by default for etch (like french, but i think a couple other european languages too, i saw it in german too i think). Will xterm default to the right thing in this case ? Friendly, Sven Luther
Bug#341738: linux-image-2.6.14-2-686: Could not read output for /sbin/modprobe -v -n --show-depends --set-version 2.6.14-2-686 auto (fatal)
reassign 341738 yaird thanks On Fri, Dec 02, 2005 at 06:36:41PM +0200, Jari Aalto wrote: > Package: linux-image-2.6.14-2-686 > Version: 2.6.14-4 > Severity: important > > Kernel cannot be installed. See below. This is a yaird bug, reassigning. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298020: [Parted-maintainers] Bug#298020: Suggested reopen: "298020: parted: hfs(+) support is still poorly documented"
On Fri, Dec 02, 2005 at 04:49:15PM -0500, A. Costa wrote: > Note: for some reason most of the following lay neglected in my > Draft folder for a few months. > > On Fri, 9 Sep 2005 08:10:42 +0200 > Sven Luther <[EMAIL PROTECTED]> wrote: > > > Well, reiserfs is a nice FS to have around when you want some data to > > disappear without a trace :) > > Eek, hope you're not speaking from experience. Still, I admire the > thought behind Reiser4, it has some interesting ideas. Nope, worse, from doing user support to some guys it happened too :) > > The problem is that libparted use the non-official libreiser thingy, and > > need > > to be switched to the official one, nobody volunteered to do the work > > though, > > maybe you do ? > > It'd be difficult, sorry -- I'm not a maintainer, and don't know > enough yet about the unofficial libreiser package to know what needs > doing. I guess most people are in the same case, a bit lost about this whole reiser mess. A read of the parted mailing list archive (we do have an archive, right ?) > > Well, apart from the above, libreiserfs has been orphaned since ages. > Obviously no maintainer wants to support an utterly dead thing, but > it's unclear that the reiserfs family of stuff is no more. For example: > > % zcat /usr/share/doc/reiser4progs/changelog.Debian.gz | head -n 5 > reiser4progs (1.0.5-1) unstable; urgency=low > > * New upstream release. > >-- Domenico Andreoli <[EMAIL PROTECTED]> Thu, 18 Aug 2005 13:00:20 > +0200 Ah, nice, my knowledge may be obsolet then. > > > ...and the info page mentions 'reiserfs' dozens of times. And a lot of > > > Debian users, (and Debian variants or offshoots), use reiser, -- for > > > example 'reiserfs' is one of the default file systems on this 'Mepis' > > > LiveCD** I have, etc. etc. > > > > Sure, they store everything on the liveCD; and nothing vital on the > > filesystem > > :) Reiserfs used to be popular back then, when there where scarce > > alternatives, but i doubt there is a single distro making it default now > > that > > we have ext3. > > An inductive and therefore not so reliable argument about > reliability: 'Mepis' is a popular liveCD, so its busy user forums > should have several horror stories about reiserfs, if that Well, as said, my main experience is on powerpc, and mirrored by many of the important powerpc porters, and i don't think Mepis is ported to powerpc, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298020: [Parted-maintainers] Bug#298020: Suggested reopen: "298020: parted: hfs(+) support is still poorly documented"
On Fri, Dec 02, 2005 at 04:50:01PM -0500, A. Costa wrote: > Note: I'm 3 months late! > > On Fri, 9 Sep 2005 08:11:47 +0200 > Sven Luther <[EMAIL PROTECTED]> wrote: > > > BTW, do you have SVN access to the repo, and want help comaintaining > > it, at least for such stuff ? > > If you were addressing me (Costa) and not K. Guillaume, then no, I Yes, i know K.G. has access. > haven't any SVN access -- also I'm new to 'subversion'. But If you know CVSm subversion is trivial, even if you don't know CVS :) > if offering such access would make maintaining stuff easier for you, > I'm certainly willing to give it a try. You need to create an alioth account (alioth.debian.org), and tell us about it, and we will add you. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Mon, Dec 05, 2005 at 12:20:36AM +0100, Attilio Fiandrotti wrote: > Package: cdebconf-gtk-udeb > Severity: normal > > DirectFrameBuffer by default enables hardware acceleration whenever > possible, this resulted in a DFB crash on many PPC systems [1] . > DFB's HW acceleration should be disabled at runtime for those fb drivers > that are known to be actually broken. Right now we have the following cases tested : Known good : radeonfb, vesafb (or whatever x86 uses). Known bad : atyfb, nvidiafb And furthermore, the cursor bug is due to an endianess error in the directfb accel code. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342086: linux-image-2.6.14-2-powerpc: postinst asks to set up booting with NoLOADER
On Mon, Dec 05, 2005 at 09:59:27AM +0100, Matijs van Zuijlen wrote: > Package: linux-image-2.6.14-2-powerpc > Version: 2.6.14-4 > Severity: normal > > After installing this image, I'm told: > > NoLOADER sets up your system to boot Linux directly from your hard disk, > without the need for booting from a boot floppy. > > ... and I'm asked wether I would like to have NoLOADER set up a boot block > or not. > > I'm quite sure I'm using yaboot. To my understanding, NoLOADER is a flag > for the case when no loader was found. This doesn't seem to work properly. This is a bug in kernel-package, which is hopefully fixed in kenrel-package 10.00x. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342372: missing dependency on debconf
On Wed, Dec 07, 2005 at 05:48:21PM +0200, Eero Häkkinen wrote: > Package: mkvmlinuz > Version: 17 > Severity: serious > > mkvmlinuz requires debconf but does not has a corresponding dependency field > (and debconf is not Essential). Oh well, will need to upload a fixed version on friday. That said, now that the kernel images will use debconf in their postinsts, it would not really cause a problem, but nice to fix still. Friendly, Sven Luther
Bug#342704: ocaml: FTBFS on hppa: "Error: Field out of range [-262144..262143] (-267528)."
On Fri, Dec 09, 2005 at 05:27:46PM +0100, Julien Cristau wrote: > Package: ocaml > Version: 3.09.0-3 > Severity: serious > Justification: no longer builds from source > > ocaml FTBFS on hppa with the following error (from the build log): > ../../ocamlcompopt.sh -warn-error Ay -I ../camlp4 -I ../boot -c -impl > pa_o_fast.ppo > [...] > /tmp/camlasm6f9a2e.s: Assembler messages: > /tmp/camlasm6f9a2e.s:97621: Error: Field out of range [-262144..262143] > (-267528). > Assembler error, input left in file /tmp/camlasm6f9a2e.s > make[3]: *** [pa_o_fast.cmx] Error 2 > > Full build log at > http://buildd.debian.org/fetch.php?&pkg=ocaml&ver=3.09.0-3&arch=hppa&stamp=1134140171&file=log&as=raw > > 3.09.0-1 built fine, so this might be yet another toolchain problem :( Could this be related to the problem some package had with regard to hppa ? I don't remember the package out of hand now, but a fixed upload was done a few days ago. Not sure if it was a workaround or just a quick hack though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329319: [Yaird-devel] Bug#329319: yaird: swsusp not all that hard
On Mon, Dec 12, 2005 at 11:59:05PM +0100, Erik van Konijnenburg wrote: > The issue of where to resume from is indeed the most important for end-users; > your idea of using a 'resume' option is interesting, but I'm not yet sure it's > what we want. > > Two points to consider: > * what do other tools do? We would not want people that convert to or from > initrd-tools or mkinitramfs to have to change their grub of fstab > configuration > to keep their swsusp working. Only be incompatible if it can't be avoided. > Ideally, avoid incompatibility even among distros. My impression is that they use the resume= option on the kernel command line, which is then parsed by initrd-tools or whatever. I feel the sane thing to do is to support all three possible ways : 1) have the resume= kernel command line option provided by the user / grub/lilo/yaboot/etc override the detected partition. This is always a good idea, as we showed with the root= kernel command line option, and will allow the user to recover more easily from mistakes and such. 2) have yaird look at the resume option in /etc/fstab as suggested here. Not sure if this is the best thing to do though. 3) have it specified/specifiable in /etc/yaird.conf. The real question being what other tools who do the suspend step usually use for configuration, the resume step is rather easy once we know that. > * Could we avoid configuration altogether? We could simply always do the > resume > code for all swap devices, if swsusp or swsusp2 is enabled in the kernel > config. > If the distro has swsusp in the kernel, this would mean users could start > using swsusp without having to regenerate the initramfs; downside is they > would > have to edit the grub/lilo menu. Notice that one thought i had about swsusp is to have multiple swap partitions associated with multiple non-overlapping partition sets and be able to resume in the one or the other, so i believe your idea will kill this kind of setup. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342053: Boot-time script to disable DFB's HW acceleration
On Tue, Dec 13, 2005 at 10:38:10AM +0100, Attilio Fiandrotti wrote: > This script should disable DFB's harware acceleration for those vesa Those are no vesa drivers, but fbdev drivers :) Vesa is only vesafb, the others are the real thing :) > drivers whose accelerated modes are known to be broken. > I think this script should be named something like "Sxxdisable_dfbhw.sh" > and should be installed into /lib/debian-installer.d and provided by > rootskel-gtk package. > Since this is meant mainly for PPC systems, Sven could you please have a > look at it? > A more appropriate name for "DISABLE_FB_ACCELERATION" boot option i've > added may be needed too. > > thanks > > Attilio > > > #List of vesa drivers that require DFB's HW acceleration to be disabled > BAD_LIST="atyfb nvidiafb" > > if [ -z "DISABLE_FB_ACCELERATION" ]; then where is this one taken from ? Maybe a better name would be dfb/hwaccel_disable or something such, i thought the all-cap names had been dropped, but i could be wrong. > echo "no-hardware" >>/etc/directfbrc > else > for driver in $BAD_LIST; do > if [ $(dmesg|grep $driver |wc -w) -gt 0 ];then I am not sure if dmesg + grep + wc is the best way to do this, but i also don't know how to best map the /proc/fb entries to module names, but we have this one, as well as : /sys/bus/pci/drivers/radeonfb/0000\:00\:10.0/graphics\:fb0 Which needs a 2.6 kernel though, but i don't think we are building 2.4 graphical d-i anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343048: linux-image-2.6.14-2-686: no need to install initramfs-tools (but piix not loaded)
On Tue, Dec 13, 2005 at 12:27:09PM +0100, Thomas Maier wrote: > Am Dienstag, den 13.12.2005, 11:52 +0100 schrieb Jonas Smedegaard: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Tue, 13 Dec 2005 09:44:22 +0100 > > Thomas Maier <[EMAIL PROTECTED]> wrote: > > > > > It seems piix was the critical one. > > > > Yes - that's why piix is mentioned in the title of this thread... > > Yes, I added it to the title after finding out :). Michael Setzer > wrote, that adding > MODULE ide-generic > MODULE ide-disk > to /etc/yaird/Default.cfg makes it work. I could boot with that, but > DMA was disabled. I found out that manually adding piix reenables DMA > for me, so I meant "yes it works, no need to install initramfs-tools, > but piix is not loaded and that disables my DMA". What about addign only piix, and not the others ? Will this work ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342053: Boot-time script to disable DFB's HW acceleration
On Tue, Dec 13, 2005 at 01:02:04PM +0100, Attilio Fiandrotti wrote: > Sven Luther wrote: > >>echo "no-hardware" >>/etc/directfbrc > >>else > >>for driver in $BAD_LIST; do > >>if [ $(dmesg|grep $driver |wc -w) -gt 0 ];then > > > > > >I am not sure if dmesg + grep + wc is the best way to do this, but i also > >don't know how to best map the /proc/fb entries to module names, but we > >have > >this one, as well as : > > > > /sys/bus/pci/drivers/adeonfb/\:00\:10.0/graphics\:fb0 > > > >Which needs a 2.6 kernel though, but i don't think we are building 2.4 > >graphical d-i anyway. > > ok, so i suppose checking if /sys/bus/pci/drivers/ Yep, in the general case, it should be possible to have multiple graphic cards, and the broken one not being the one used for booting d-i. Also, of interest is : /sys/class/graphics/fb0, which has a device/driver symlink to the above path you suggest, but i don't know how to find the radeonfb driver name information from this one, which sucks. > exist is enough to tell if HW acceleration has to be disabled. > Below is the same script reworked after your and Geert Stappers's > corrections. > The user, to manually disable DFB HW acceleration, should boot with > something like "install NO_DFB_ACCELERATION=TRUE" and this should be > documented in the d-i manual and/or in the help screen that you see when > you press F2 at boot time. Yeah, altough i prefer the lower-case new option format thingy, but maybe they are reserved for debconf variables ? dfb/no_accel=true ? Do we have access to debconf already at this early stage ? > Where this piece of code should be collocated? inside a new "Sxx.sh" > script or should be better appended to > /lib/debian-installer.d/S35framebuffer-linux or some other already > existing script? Not sure, it has to run early enough (before gtkdi is launched) and late enough (after the framebuffer drivers have been loaded. Maybe adding ti to S35framebuffer-linux is a good thing. > Note that the list of bad fbdev deviced is hardcoded inside this script: > is this a good idea? but i have no idea of where else those could be > listed.. It should be a preseedable debconf value maybe, not sure, see my above comment, dfb/bad_fbdevs="nvidiafb atyfb" would be a good idea. Maybe we could reverse the script and whitelist the known good graphic cards though, with : dfb/good_fbdevs="radeonfb vesafb" ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343194: ...
Hi, ... I also believe the creation of this list is a good idea, and support it, altough i guess the previous supporters and their involvement with debian in france and in general should be more than enough to confer enough weight to this request. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342704: Disable HPPA native code compiler
On Thu, Dec 15, 2005 at 01:47:36PM +0100, Florian Weimer wrote: > Upstream has responded; they won't fix this, and they no longer > maintain the native code compiler on HPPA. I susgest to disable it in > the Debian package. Seems reasonable indeed. Unless someone shows up and want to fix it. I don't think we lose much, as hppa is definitively not the plateform of choice for having compute-intensive ocaml apps running. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342248: [m68k headers] binaries are i386 - cannot execute binary file
On Thu, Dec 15, 2005 at 02:09:47PM +0100, Max Vozeler wrote: > Hi Christian, > > On Thu, Dec 15, 2005 at 08:12:05AM +0100, Christian T. Steigies wrote: > > On Tue, Dec 06, 2005 at 03:48:40PM +0100, Max Vozeler wrote: > > > Apparently the binaries in m68k -headers were built for i386. > > > > Yes, this may very well be possible, since the m68k linux-* packages > > were cross-compiled on i386. Since the linux-image-* packages are > > built in the same run, and they are properly cross-compiled for m68k > > and actually work (at least) on (my) m68k boxes, this must be a bug in > > the linux-headers build rules, they should be cross-compiled, too. > > Thanks for looking into this. > > > > This breaks builds of external modules as they try to execute eg. > > > scripts/basic/fixdep on m68k. > > > > Do you have any external modules for m68k that are not part of the kernel? > > Who is supplying those? > > It's not specific to m68k actually. The module in question is the > loop-AES extended loopback encryption module maintained by Jari Ruusu > <[EMAIL PROTECTED]>. I'm trying to build it for all > archs that have 2.6 -di kernels in the archive. Are you sure you are using the per-flavour header packages (linux-headers-2.6.14-2- ? Also, do you know about the external build module plan ? It is as follows : 1) build-depend on linux-headers-2.6.14 or linux-headers-2.6.14-2-all. 2) look at /usr/src/linux-headers-2.6.14-2/flavours for a list of supported flavours. 3) for f in `cat /usr/src/linux-headers-2.6.14-2/flavours`; do ... make ... KSRC=/lib/modules/2.6.14-2-$f ... done Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329057: gnome-randr-applet: "Inverted" rotation selected automatically (and wrongfully)
On Fri, Dec 16, 2005 at 09:40:48PM +0100, René Højbjerg Larsen wrote: > Hi, > > The attached patch fixes the problem (due to bad logic in the rotation > detection code). > > It also reverses the order of the menu entries, making "Normal" the > first entry, followed by "Left", which makes a lot more sense than the > default behavior, IMHO. If you don't want to make this change then don't > apply the second chunk of the patch. Ok, thanks. > This should probably be sent upstream. Yeah, not sure if upstream is active still though. Friendly, Sven Luther
Bug#343443: linux-image-2.6.14-2-k7: initrd(yaird) doesn't contain HD modules
On Fri, Dec 16, 2005 at 01:14:32PM +0100, Pau Capdevila wrote: > Package: linux-image-2.6.14-2-k7 > Version: 2.6.14-5 > Followup-For: Bug #343443 > > > The default installation did not boot failing to found hard disk devices. So, what kind of disk do you have, and what controller does it sit own (well, what chipset you have on your motherboard probably). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343443: linux-image-2.6.14-2-k7: initrd(yaird) doesn't contain HD modules
On Sat, Dec 17, 2005 at 07:08:35PM +0100, Pau Capdevila wrote: > Hi, > > Sorry for not giving all this info from the beggining. > > The filesystem is ReiserFS. /me hopes you don't have any important data on that disk :) > The output of lspci is: > > Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1) > RAM memory: nVidia Corporation nForce2 Memory Controller 0 (rev c1) > RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1) > RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1) > RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1) > RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1) > ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4) > SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2) > USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) > USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) > USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) > Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1) > Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio Controler > (MCP) (rev > PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3) > IDE interface: nVidia Corporation nForce2 IDE (rev a2) > PCI bridge: nVidia Corporation nForce2 AGP (rev c1) > Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ > (rev 10) > VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) > > Please tell me how to obtain the installation log you mentioned earlier. not sure, Jonas will probably give you the exact command to test this, but you could do : dpkg-reconfigure linux-image-2.6.14-2- and paste the whole output to this bug report. Also, if you could put your /boot/initrd.img-2.6.14-2- online somewhere that would be helpfull, or list its content, not sure how exactly, but it involves gzip and cpio. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343443: linux-image-2.6.14-2-k7: initrd(yaird) doesn't contain HD modules
On Sat, Dec 17, 2005 at 08:25:21PM +0100, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sat, 17 Dec 2005 19:48:49 +0100 > Sven Luther <[EMAIL PROTECTED]> wrote: > > > > Please tell me how to obtain the installation log you mentioned > > > earlier. > > > > not sure, Jonas will probably give you the exact command to test > > this, but you could do : > > > > dpkg-reconfigure linux-image-2.6.14-2- > > Sounds right. > > > > and paste the whole output to this bug report. Also, if you could put > > your /boot/initrd.img-2.6.14-2- online somewhere that > > would be helpfull, or list its content, not sure how exactly, but it > > involves gzip and cpio. > > Well, I use mc: > > 1) Place the marker on top of your initrd below /boot > > 2) ALT+o to get same dir in opposite pane > > 3) CTRL+x s to create symlink of the initrd file: > > a) Edit symlink name: TAB, END, add ".cpio", ENTER > > 4) Move to the cpio-named symlink and press ENTER to browse in it... Yeah, but i think a command which can have the output redirected to a file he can post to the bug report would be more helpfull here: Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343980: [powerpc] g5 thermal overtemp bug
Package: linux-2.6
severity: important
version: 2.6.14-4
tags: patch
- Forwarded message from Benjamin Herrenschmidt <[EMAIL PROTECTED]> -
Subject: [Fwd: [PATCH] powerpc: g5 thermal overtemp bug]
Figure that might interest distros ...
Forwarded Message
Subject: [PATCH] powerpc: g5 thermal overtemp bug
The g5 thermal control for liquid cooled machines has a small bug, when
the temperatures gets too high, it boosts all fans to the max, but
incorrectly sets the liquids pump to the min instead of the max speed,
thus causing the overtemp condition not to clear and the machine to shut
down after a while. This fixes it to set the pumps to max speed instead.
This problem might explain some of the reports of random shutdowns that
some g5 users have been reporting in the past.
Many thanks to Marcus Rothe for spending a lot of time trying various
patches & sending log logs before I found out that typo. Note that
overtemp handling is still not perfect and the machine might still
shutdown, that patch should reduce if not eliminate such occcurences in
"normal" conditions with high load. I'll implement a better handling
with proper slowing down of the CPUs later.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/drivers/macintosh/therm_pm72.c
===
--- linux-work.orig/drivers/macintosh/therm_pm72.c 2005-11-10
08:20:14.0 +1100
+++ linux-work/drivers/macintosh/therm_pm72.c 2005-12-19 11:20:39.0
+1100
@@ -933,7 +933,7 @@
if (state0->overtemp > 0) {
state0->rpm = state0->mpu.rmaxn_exhaust_fan;
state0->intake_rpm = intake = state0->mpu.rmaxn_intake_fan;
- pump = state0->pump_min;
+ pump = state0->pump_max;
goto do_set_fans;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338435: status of the ocaml 3.09.0 migration ...
On Mon, Dec 19, 2005 at 03:32:40AM -0800, Steve Langasek wrote: > On Mon, Dec 19, 2005 at 08:46:14AM +0100, Sven Luther wrote: > > > 04:24 < vorlon> hey all. Where are we on being able to close bug #338435? > > 04:25 < vorlon> it turns out KDE needs ocaml to be pushed first, because > > abiword-plugins uses gtkmathview and abiword and koffice both depend on > > libwpd. > > 04:26 < vorlon> (so, in fact, they need to be pushed in at the same time, > > hurrah.) > > > Well, i guess this is good, as it seems ocaml is being used in more outside > > projects, there is also the other package of Jeffries which is linked to > > KDE. > > For info, 338435 is the blocker bug i put to avoid ocaml 3.09.0 entering > > testing without us noticing. > > From discussions on IRC, there are three outstanding issues for ocaml: > > - FTBFS on hppa. This is already a separate RC bug against ocaml (342704). > - the ABI-breaking fix for cduce; it's my understanding that this patch has > not yet been included in the ocaml package in unstable, and including it > would require rebuilding all of the ocaml packages, but that this doesn't > necessarily have to wait for ocaml 3.09.1. > - a handful of packages that still build-depend on ocaml-3.08.3 or similar, > and require sourceful uploads for the ocaml transition. These packages > are advi, approx, camlrpc, cduce, cryptokit, lablgtk, missinglib, mlgtk, Fixed approx has been uploaded, mlgtk and lablgtk should go. For the rest, i would just quick them out of testing right now and be done with it, they can reenter when they are ready. > ocamldsort, pycaml, spamoracle, syslog-ocaml. Each of these packages > should have a separate RC bug filed against it if there are no immediate > plans to upload them. Of these packages, only ocamldsort has significant > reverse-dependencies; so if the maintainers are not reactive, the other > packages ought to be removed from testing to allow this transition to > complete, and catch up again on their own time. Indeed. > None of the above issues should be particularly difficult to resolve, and > none warrant keeping a dummy bug open against ocaml (except that the bugs > from point 3 should probably be filed before closing this, I guess). Also, > if cduce is the only package broken by issue #2, I'm not sure we should hold > up the transition for it either at this point. The dummy bug is there also for documentation purpose to lessen the guys filling bugs because of the transition. > What is needed to get an ocaml upload to fix #1, and possibly #2 as well? #1 will be solved by dropping native support for hppa, #2, i guess we kick cduce out of testing and wait for ocaml 3.09.1, easiest that way. Both can happen fairly quickly. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340629: [powerpc] possible fix for ARCH=powerpc ...
tags 340629 + patch
thanks
hi Manoj, ...
I wrote this fully untested powerpc.mk file, which i believe should replace
the ppc.mk and ppc64.mk for kernel versions >=2.6.15, not sure how to best do
this, but it is a need-fix for the 2.6.15 kernel release.
I believe it will not work as is out of the box, as these box will still
advertize as ppc and ppc64 system, not as powerpc ones, even if we now use
ARCH=powerpc.
Friendly,
Sven Luther
# -*- Mode: Makefile-Gmake -*-
## ppc.mk ---
## Author : Manoj Srivastava ( [EMAIL PROTECTED] )
## Created On : Mon Oct 31 18:31:06 2005
## Created On Node : glaurung.internal.golden-gryphon.com
## Last Modified By : Manoj Srivastava
## Last Modified On : Mon Oct 31 18:31:06 2005
## Last Machine Used: glaurung.internal.golden-gryphon.com
## Update Count : 0
## Status : Unknown, Use with caution!
## HISTORY :
## Description : handle the architecture specific variables.
##
## arch-tag: 5f56e1be-14d8-4843-bf39-423460c2ab1a
##
##
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 2 of the License, or
## (at your option) any later version.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program; if not, write to the Free Software
## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
##
###
# prpmc and mbx are not guessed automatically yet.
ifeq ($(DEB_BUILD_ARCH),powerpc)
# This is only meaningful when building on a PowerPC
ifeq ($(GUESS_SUBARCH),)
GUESS_MACHINE:=$(shell awk '/machine/ { print $$3}' /proc/cpuinfo)
GUESS_CPU:=$(shell awk '/cpu/ { print $$3}' /proc/cpuinfo)
GUESS_GENERATION:=$(shell awk '/generation/ { print $$3}' /proc/cpuinfo)
ifneq (,$(findstring POWER,$(GUESS_CPU)))
GUESS_SUBARCH:=powerpc64
else
ifneq (,$(findstring PPC970,$(GUESS_CPU)))
GUESS_SUBARCH:=powerpc64
else
ifneq (,$(findstring NuBus,$(GUESS_GENERATION)))
GUESS_SUBARCH:=nubus
else
ifneq (,$(findstring Amiga,$(GUESS_MACHINE)))
GUESS_SUBARCH:=apus
endif
endif
endif
endif
ifeq ($(GUESS_SUBARCH),)
GUESS_SUBARCH:=powerpc
endif
else
GUESS_SUBARCH:=powerpc
endif
endif
ifeq (,$(findstring $(KPKG_SUBARCH),apus Amiga APUs nubus powerpc powerpc32
powerpc64 prpmc mbx MBX))
KPKG_SUBARCH:=$(GUESS_SUBARCH)
endif
KERNEL_ARCH:=powerpc
ifneq (,$(findstring $(KPKG_SUBARCH), powerpc powerpc32 powerpc64))
ifneq (,$(findstring $(KPKG_SUBARCH), powerpc64))
target := vmlinux
endif
ifneq (,$(findstring $(KPKG_SUBARCH), powerpc powerpc32))
NEED_IMAGE_POST_PROCESSING = YES
IMAGE_POST_PROCESS_TARGET := mkvmlinuz_support_install
IMAGE_POST_PROCESS_DIR:= arch/ppc/boot
INSTALL_MKVMLINUZ_PATH =
$(SRCTOP)/$(IMAGE_TOP)/usr/lib/kernel-image-${version}
target := zImage
loaderdep=mkvmlinuz
endif
kimagesrc = vmlinux
kimage := vmlinux
kimagedest = $(INT_IMAGE_DESTDIR)/vmlinux-$(version)
DEBCONFIG= $(CONFDIR)/config.$(KPKG_SUBARCH)
endif
ifneq (,$(findstring $(KPKG_SUBARCH),APUs apus Amiga))
KPKG_SUBARCH:=apus
KERNEL_ARCH:=ppc
loader := NoLoader
kimage := vmapus.gz
target = zImage
kimagesrc = $(shell if [ -d arch/$(KERNEL_ARCH)/boot/images ]; then \
echo arch/$(KERNEL_ARCH)/boot/images/vmapus.gz ; else \
echo arch/$(KERNEL_ARCH)/boot/$(kimage) ; fi)
kimagedest = $(INT_IMAGE_DESTDIR)/vmlinuz-$(version)
kelfimagesrc = vmlinux
kelfimagedest = $(INT_IMAGE_DESTDIR)/vmlinux-$(version)
DEBCONFIG = $(CONFDIR)/config.apus
endif
ifneq (,$(findstring $(KPKG_SUBARCH), NuBuS nubus))
KPKG_SUBARCH := nubus
KERNEL_ARCH:=ppc
target := zImage
loader= NoLoader
kimagesrc = arch/$(KERNEL_ARCH)/appleboot/Mach\ Kernel
kimage := vmlinux
kimagedest = $(INT_IMAGE_DESTDIR)/vmlinuz-$(version)
endif
ifneq (,$(findstring $(KPKG_SUBARCH),PRPMC prpmc))
KPKG_SUBARCH:=prpmc
KERNEL_ARCH:=ppc
loader := NoLoader
kimage := zImage
target = $(kimage)
kimagesrc = arch/$(KERNEL_ARCH)/boot/images/zImage.pplus
kimagedest = $(INT_IMAGE_DESTDIR)/vmlinuz-$(version)
kelfimagesrc = vmlinux
kelfimagedest = $(INT_IMAGE_DESTDIR)/vmlinux-$(version)
endif
ifneq (,$(findstring $(KPKG_SUBARCH),MBX mbx))
KPKG_SUBARCH:=mbx
KERNEL_ARCH:=ppc
loader := NoLoader
kimage := zImage
target = $(kimage)
kimagesrc = $(shell if [ -d arch/$(KERNEL_ARCH)/mbxboot ]; then
Bug#340629: ppc64 missing from upstream 2.6.15-rc6?
On Tue, Dec 20, 2005 at 09:46:08AM +0200, Eduardo Trápani wrote: > >You need to do : > > > > make-kpkg --config oldconfig --arch powerpc ... > > I tried, the error is below. What is the alternative way to build the > kernel? In i386 I used to make zImage and then copy the files from > arch/boot or something like that. Is there documentation on how to do it > for these kernels? > > Thanks, Eduardo. > > # make-kpkg --arch powerpc --initrd kernel-image > > == making target debian/stamp-build-kernel [new prereqs: sanity_check > stamp-kernel-conf]== > /usr/bin/makeARCH=ppc \ This is the culprit, you can go into /usr/share/kernel-package/kernel/arch/ppc.mk or ppc64.mk and edit it so it says ARCH=powerpc. I have submitted a patch to #340629, but it is tentative and untested, would be nice if you could help out iron it out, CCing the bug report. Manoj, i would like to know how the .mk snipplets are chosen, i think the best solution for this would be to have make-kpkg check the version being built, and for <2.6.15, chose ppc.mk or ppc64.mk depending on if the arch exported by the kernel is ppc or ppc64, and for kernels bigger than 2.6.15 (or rc versions) chose the powerpc.mk snipplet instead, and then normally the patch i provide should be ok. Not sure, you are the master of this, and i failed to understand how the snipplet are chosen, but then i didn't look long. Friendly, Sven Luther > zImage > make[1]: Entering directory `/usr/src/linux-2.6.15-rc6' > CHK include/linux/version.h > CHK include/linux/compile.h > CHK usr/initramfs_list > GEN .version > CHK include/linux/compile.h > UPD include/linux/compile.h > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > arch/powerpc/kernel/built-in.o: In function `power4_idle': multiple > definition of `power4_idle' > arch/ppc/kernel/idle_power4.o:arch/ppc/kernel/idle_power4.S:(.text+0x4): > first defined here > make[1]: *** [.tmp_vmlinux1] Error 1 > make[1]: Leaving directory `/usr/src/linux-2.6.15-rc6' > make: *** [debian/stamp-build-kernel] Error 2 > > # > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > --- > Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > >
Bug#344413: [powerpc] k-p 10.00x breaks debconf based /etc/kernel/*.d scripts like mkvmlinuz
Package: kernel-package Version: 10.019 Severity: grave kernel-package 10.0xx does a db_stop before calling the /etc/kernel/*.d snipplets, which breaks packages providing debconf using snipplets like mkvmlinuz. Since mkvmlinuz is depended upon by the powerpc kernel, and this means not only new kernels will be uninstallable on powerpc, but the package will be left in a dire state at upgrade time. Furthermore, kernel-package calling db_stop before running the snipplets is done in order for make allowance for /etc/kernel/*.d scripts doing non-debconf friendly interaction (writing to stdout directly and such), which breaks the spirit of the policy, which say that all interaction during a kernel installation has to be done through debconf, and thus making allowance for postinst hooks doing non-debconf interaction while breaking debconf using scripts is a violation of the spirit of the policy. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344416: [powerpc] kernel-package breaks mkvmlinuz, rendering 2.6.14-6 kernels uninstallable on powerpc
Package: linux-2.6 Version: 2.6.14-6 Severity: grave kernel-package 10.0xx does call db_stop before calling the /etc/kernel/*.d snipplets, which means all debconf using snipplets will be broken, and hang forever for a response from debconf which will never come. mkvmlinuz is among those using debconf in a /etc/kernel/*.d snipplet, and as the powerpc kernel depends on it, the result is that the powerpc kernel will not only be uninstallable, leave the dpkg-database in a unclean state, and wait-forever during installation thus playing hell with automated upgrades or whatever. I guess this means a new 2.6.14-7 upload quickly as soon as k-p gets fixed, but it would be nice if new k-p upgrades where tested more thoroughly before being inflicted unto the unsuspecting masses. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337509: marked as done (linux-headers-2.6.14: flavours file missing)
On Fri, Nov 04, 2005 at 11:19:58PM +0100, Bastian Blank wrote: > On Fri, Nov 04, 2005 at 10:58:29PM +0100, Sven Luther wrote: > > Bastian, please give a bit more info about this, and why should we not keep > > the flavours file, it was there for a reason, and it is much more user > > friendly to have it in a file, instead of having to do some strange search > > for > > config files like you suggest here, which may clash in case of user built > > packages being around. > > The flavours file does not provide the neccesary informations to build > anything against it. No information about the kernel arch, nor about the > compiler. Huh ? It contain the list of the names of the flavours for a given arch. In this sense it is exactly the info provided in the arch//defines file, and once you have that, you prefix it to the version-abi, and you know which kernels you then need to build for. This file is naturally per arch, and the arch you are building for is the arch you need. As for the compiler, well, it will be the one currently in sid/etch or whatever. The aim is to have each external module packages be able to build binary module packages for the official kernel flavours, and to generate the control file of those packages and such stuff. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels
On Sat, Nov 05, 2005 at 11:33:53AM +0100, Eduard Bloch wrote: > Package: linux-image-2.6.14-1-686 > Version: 2.6.14-2 > Severity: normal > > Hello, > > please consider not using CONFIG_MODVERSIONS in future. Reason: it makes > installation of alternative modules with the same names hard till > unpossible. Current example: ipw2200, which is contained in 2.6.14 in a > very old version. I cannot load the new version because lots of errors > about conflicting versions are detected (in dependent ieee82... modules > which I have built as well). Well, you could just subtly modifythe name or something, and do a diversion, not sure. The pwc module maintainer does exactly that, and has no such problem. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337497: initramfs-tools: [powerpc] doesn't work on pegasos - ALERT! /dev/hda1 does
On Sat, Nov 05, 2005 at 10:43:56AM +0100, Norbert Tretkowski wrote: > * Sven Luther wrote: > > ALERT!: /dev/hda1 does not exist, Dropping to a shell! > > I saw the same on my notebook (i386) when using MODULES=dep in > initramfs.conf. the above was with MODULES=most though. Well, whatever wasdefault, and since it had loads of cruft ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337497: moreinfo concerning the missing partitions ...
Hello, Well, i just spoke a bit with jbailey and investigated some, and founf the reason why the partitions where missing. It seems the ide_disk module is not loaded, which given that my disk is an ide one is pretty broken, i wonder if it could work on powermac or something. Also, there is no lsmod command which had me a bit baffled, and jbailey suggested creating an alias to /proc/modules, which allowed me to investigate this, would be cool to make it the default with : alias lsmod="more /proc/modules" Ok, will add ide_disk to /etc/mkinitramfs/modules, and we will see what happens. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd
On Sat, Nov 05, 2005 at 01:30:41PM +0100, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > reassign 337625 initramfs-tools > thanks > > On Sat, 05 Nov 2005 13:06:58 +0100 > Pau Capdevila <[EMAIL PROTECTED]> wrote: > > > Booting with original initrd gives black screen. > > Sounds like you had initramfs-tools and not yaird installed at the time > of initially installing the kernel. > > Reassigning to initramfs-tools. Jonas, i believe he had an older version of yaird without the fbcon fix, and rebuilt with yaird or something, not sure. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337663: initramfs-tools: droping in rescue shell has no loadkeys and do not default to right keymap.
Package: initramfs-tools Severity: normal Well, as said, it is rather painful when one is dropped in the rescue shell, to have it default to us keymap, even though you have another kind of keyboard layout (azerty for me). At least it should include the loadkeys binary as well as the keymaps if it fails to autodetect the right thing. Friendly, Sven Luther -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337663: initramfs-tools: droping in rescue shell has no loadkeys and do not default to right keymap.
On Sat, Nov 05, 2005 at 06:03:39PM +, Alastair McKinstry wrote: > Sven Luther wrote: > > >Package: initramfs-tools > >Severity: normal > > > > > >Well, as said, it is rather painful when one is dropped in the rescue > >shell, > >to have it default to us keymap, even though you have another kind of > >keyboard > >layout (azerty for me). At least it should include the loadkeys binary as > >well > >as the keymaps if it fails to autodetect the right thing. > > > >Friendly, > > > >Sven Luther > > > > > > > Little-known fact: the 'kbd-chooser' binary acts as loadkeys within d-i. > So we should make sure its loaded > and there is a symlink to it from /bin/loadkeys. Huh, this is not d-i, but initramfs-tools failback shell. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337682: initramfs-tools: ROOT=probe not implemented.
Package: initramfs-tools Severity: wishlist initramfs-tools generated ramdisk don't allow not passing the root filesystem in the command line, which would be probed at ramdisk boot time. This is a regression from initrd-tools which supported this feature. The way it works is to have the ramdisk generation detect the root partition, and use it as default if not overriden by the kernel command line. Friendly, Sven Luther -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, Nov 06, 2005 at 12:39:52PM +, Martin Michlmayr wrote: > * Manoj Srivastava <[EMAIL PROTECTED]> [2005-11-05 23:51]: > > Why should a symlink be ignored? What other stuff would people > > want to have ignored if we start on a slippery slope like this? > > nividia-source, vmware, and scads of others would like to dump stuff > > in /lib/modules, and the book keeping involved in keeping track of > > stuff in the /lib/modules/ which is OK to ignore would be > > massive. > > > The presence of that link is a bug, and should be fixed. Huh ? What is going on here, the /lib/modules//build/ link is *NOT* a bug, and is part of the plan to build external modules, and thus needed and advertized so. Please *DON'T* even think about removing it. > Can you explain why it is a bug? I think upstream puts header files > in /lib/modules//build/ too, so it's not as if this is a Debian > specific thing. (Correct me if I'm wrong; also CCing -kernel). Indeed, and most third party modules build out of the box checking for it and doing KSRC=/lib/modules//build/. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, Nov 06, 2005 at 09:13:35AM -0600, Manoj Srivastava wrote: > On Sun, 6 Nov 2005 12:39:52 +, Martin Michlmayr <[EMAIL PROTECTED]> said: > > > * Manoj Srivastava <[EMAIL PROTECTED]> [2005-11-05 23:51]: > >> Why should a symlink be ignored? What other stuff would people want > >> to have ignored if we start on a slippery slope like this? > >> nividia-source, vmware, and scads of others would like to dump > >> stuff in /lib/modules, and the book keeping involved in keeping > >> track of stuff in the /lib/modules/ which is OK to ignore would be > >> massive. > > >> The presence of that link is a bug, and should be fixed. > > > Can you explain why it is a bug? I think upstream puts header files > > in /lib/modules//build/ too, so it's not as if this is a Debian > > specific thing. (Correct me if I'm wrong; also CCing -kernel). > > No, upstream does not put headers in that location, but a > symbolic link. And the kernel-package does handle th build and source > links in kernel-package itself. The build symlink is the ownership of the linux-headers package that contains the pointed to headers, and it should stay so. We had too much trouble with dangling symlinks in the past (probably broken in sarge even), and it is now properly fixed, and should stay fixed, please don't break this now. > > Given that the warning by kernel-package talks about modules, why > > don't you do a 'find' and look for .o and .ko files? > > Err, no. /lib/modules/$version belongs to the image package; > and third parties are not supposed to be putting things in there. Yeah, you know that you are inconsistent here, you mention the vmware and nvidia packages, whose modules you want to catch, but then you claim no package outside of kernel-image is owning that dir. > >> kernel-package itself does not create that link, and the entity > >> responsible for that link should know better. > > > AFAIK many external build process (for kernel modules) except > > /lib/modules//build, so it's hardly a matter about "knowing > > better" on the side of the kernel-headers package. > > This is not quite correct. Every other third party modules > that looks for that link looks for /lib/modules/$(uname -r)/build -- > in other words, the build link for the cirrent kernel, not some > kernel that is not yet on the machine. Any official kernel package whose abi name doesn't change guarantees that the same /lib/modules/$(uname -r) modules will work for any kernel of that version, doing otherwise would be an RC bug, and has delayed even security fixes to be included in kernels in the past, particularly due to d-i. > > Unless you get upstream to change, it's quite likely that people > > will have a build symlink in their modules dir and the kernel-build > > message will therefore be useless and even misleading. > > kernel-headers is also different to your other examples > > (e.g. nividia-source) in that it doesn't put _modules_ there. So > > given that this is a well-known exception, I don't see why it would > > be so hard or troublesome to ignore /lib/modules//build when > > checking for modules dir. It's like one line of Perl code - and it > > will reduce one false positive. > > Can you explain to me why kernel-headers is not putting a > script in /etc/kernel/postinst.d and /etc/kernel/prerm.d to > optionally add and remove the build link? Because it is perfectly allowed to build out-of-tree modules without the kernel-image package being installed, it is even part of our upcoming module policy, the above proposal, altough nice, doesn't solve that, and even break it. Please, don't change that, this is not broken, so no reason for you to come and unilateraly break it. > >> There is a workaround for you, of course, until the bug is fixed in > >> the proper place: > > > I'm fairly sure the "proper place" is kernel-package and not > > kernel-headers, as outlined above. > > In which case, you have to convince me why the > /etc/kernel/postinst.d is not the right one. See above, but i guess this goes both ways, you have to convince us that the current method is broken, which you have not done, and the only claim i have seen (here and on irc) was that "/lib/modules/ should belong to kenrel-image", which you yourself contradict with the case of the nvidia or vmware modules. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, Nov 06, 2005 at 03:38:26PM +, Martin Michlmayr wrote: > * Manoj Srivastava <[EMAIL PROTECTED]> [2005-11-06 09:13]: > > > Can you explain why it is a bug? I think upstream puts header files > > > in /lib/modules//build/ too, so it's not as if this is a Debian > > > specific thing. > > > > No, upstream does not put headers in that location, but a > > symbolic link. > > The kernel-headers package only puts a symbolic link there, so this > point is moot. > > > Can you explain to me why kernel-headers is not putting a > > script in /etc/kernel/postinst.d and /etc/kernel/prerm.d to > > optionally add and remove the build link? > > Right, so what you're saying is that the headers package should create > the symlink in postinst and prerm rather than shipping it in the .deb > itself? > > I don't know anything about kernel packaging, but this sounds like a > good question and maybe someone from -kernel can take a look and think > about this. There is no reason that the linux-headers packages could not be used to build out-of-tree modules using the symlink, without having the linux-image installed, so this doesn't work, even though it looks like a seducing proposal. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, Nov 06, 2005 at 09:17:56AM -0600, Manoj Srivastava wrote:
> On Sun, 6 Nov 2005 14:00:13 +0100, Sven Luther <[EMAIL PROTECTED]> said:
>
> > On Sun, Nov 06, 2005 at 12:39:52PM +, Martin Michlmayr wrote:
> >> * Manoj Srivastava <[EMAIL PROTECTED]> [2005-11-05 23:51]:
> >> > Why should a symlink be ignored? What other stuff would
> >> > people
> >> > want to have ignored if we start on a slippery slope like this?
> >> > nividia-source, vmware, and scads of others would like to dump
> >> > stuff in /lib/modules, and the book keeping involved in keeping
> >> > track of stuff in the /lib/modules/ which is OK to ignore would
> >> > be massive.
> >>
> >> > The presence of that link is a bug, and should be fixed.
>
> > Huh ? What is going on here, the /lib/modules//build/ link is
> > *NOT* a bug, and is part of the plan to build external modules, and
> > thus needed and advertized so. Please *DON'T* even think about
> > removing it.
>
>
> Err, I never advertized any such thing. Can you explain to my
> why the solution of kernel-headers installing scripts in
> /etc/kernel/{postinst,prerm}.d would not work?
See my other mail.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, Nov 06, 2005 at 10:57:13AM -0600, Manoj Srivastava wrote: > > There is no reason that the linux-headers packages could not be used > > to build out-of-tree modules using the symlink, without having the > > linux-image installed, so this doesn't work, even though it looks > > like a seducing proposal. > > Third party modules which have been integrated into Debian can > still be built, without the linux-image installed, by > a) cd /usr/src/kernel-headers-foo, call make-kpkg > b) KSRC=/usr/src/kernel-headers-foo, call make-kpkg Yeah, hear yourself, because you don't feel like adding a simple exception to the check for build, or do a find -name \*.ko as Martin suggested, each and all the packaged modules need to be modified, as well as all third party module which are not packaged and depend on the build symlink working. > All the other third party modules I have seen look for > /lib/modules/$(uname -r)/build; which implies that the kernel image > is installed, since it is running, and thus the postint.d scripts > would already have been called. It does not. This is the right way to search for those modules, and it implies the kernel headers and remaininig infrastucture is there, *NOT* the kernel-image. > So, we are talking about modules that do not work with > kernel-package, which have not been integrated into debian, and yet > need to build against a version of the image package not installed. I > know of two such modules, nvidia, and vmware, and at least > vmware-config.pl asks where to find the headers, and people can > provide that. No, you have decided to close your eyes on the real problem and make things difficult to us just because of what you feel is right. Please don't. Also, see the thread on debian-project about asking vmware to start building modules for the official kernel images, your way of doing will make this more difficult, and for what gain ? That is the real question, what do you really intent by breaking the way the build symlink is now and should be working ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, Nov 06, 2005 at 11:06:27AM -0600, Manoj Srivastava wrote: > On Sun, 6 Nov 2005 16:59:36 +0100, Sven Luther <[EMAIL PROTECTED]> said: > > > On Sun, Nov 06, 2005 at 09:13:35AM -0600, Manoj Srivastava wrote: > >> On Sun, 6 Nov 2005 12:39:52 +, Martin Michlmayr > >> <[EMAIL PROTECTED]> said: > >> > >> > * Manoj Srivastava <[EMAIL PROTECTED]> [2005-11-05 23:51]: > >> >> Why should a symlink be ignored? What other stuff would people > >> >> want to have ignored if we start on a slippery slope like this? > >> >> nividia-source, vmware, and scads of others would like to dump > >> >> stuff in /lib/modules, and the book keeping involved in keeping > >> >> track of stuff in the /lib/modules/ which is OK to ignore would > >> >> be massive. > >> > >> >> The presence of that link is a bug, and should be fixed. > >> > >> > Can you explain why it is a bug? I think upstream puts header > >> > files in /lib/modules//build/ too, so it's not as if this is > >> > a Debian specific thing. (Correct me if I'm wrong; also CCing > >> > -kernel). > >> > >> No, upstream does not put headers in that location, but a symbolic > >> link. And the kernel-package does handle th build and source links > >> in kernel-package itself. > > > The build symlink is the ownership of the linux-headers package that > > contains the pointed to headers, and it should stay so. We had too > > much trouble with dangling symlinks in the past (probably broken in > > sarge even), and it is now properly fixed, and should stay fixed, > > please don't break this now. > > If you are using kernel-package for all related packages, this > is not broken, and it shall not break in the future. It is broken in sarge for something like 9/11th of the official arches, i believe. > >> > Given that the warning by kernel-package talks about modules, why > >> > don't you do a 'find' and look for .o and .ko files? > >> > >> Err, no. /lib/modules/$version belongs to the image package; and > >> third parties are not supposed to be putting things in there. > > > Yeah, you know that you are inconsistent here, you mention the > > vmware and nvidia packages, whose modules you want to catch, but > > then you claim no package outside of kernel-image is owning that > > dir. > > I can only catch these errors if kernel-package controls what > packages provide what stuff. If you use kernel-package, but move > things around under its nose, then heck, yes, stuff breaks. the build symlink belongs with the files it symlinks too. > >> >> kernel-package itself does not create that link, and the entity > >> >> responsible for that link should know better. > >> > >> > AFAIK many external build process (for kernel modules) except > >> > /lib/modules//build, so it's hardly a matter about "knowing > >> > better" on the side of the kernel-headers package. > >> > >> This is not quite correct. Every other third party modules that > >> looks for that link looks for /lib/modules/$(uname -r)/build -- in > >> other words, the build link for the cirrent kernel, not some kernel > >> that is not yet on the machine. > > > Any official kernel package whose abi name doesn't change guarantees > > that the same /lib/modules/$(uname -r) modules will work for any > > kernel of that version, doing otherwise would be an RC bug, and has > > delayed even security fixes to be included in kernels in the past, > > particularly due to d-i. > > How do you know? Any user can create a kernel-image with the Well, if the user breaks its stuff its his own fault, but i guess this can be solved by adding something to note those are official kernel packages or something. > kernel-package is trying to help out the end user here, even > if there is a turf war going on between "official" developers and > some end user. Nope, there is a turf war going on between you and official developers, that is different, our plans are wide ranging, and should include all the end-users needs, so contribute to them instead of resisting for petty little things like build symlink, and we will make the etch kernel and related packages something to be proud of, not the mess that debian kernels used to be upto now. > >> > Unless you get upstream to change, it's quite likely that people > >> > will have a build symlink in their
Bug#337902: Missing dependency on /usr/sbin/mkinitramfs
On Mon, Nov 07, 2005 at 07:48:07AM +0100, Magnus Ekdahl wrote: > Package: linux-image-2.6.14-1-k7 > Version: 2.6.14-2 > Severity: important > > When installing I get the following error (sorry for the swedish locale) > > running dpkg --pending --configure ... > Ställer in linux-image-2.6.14-1-k7 (2.6.14-2) ... > Failed to find suitable ramdisk generation tool for kernel version You should have either yaird or initramfs-tools installed, yaird has the benefit of not needing udev or hotplug. That said, there is a dependency on : yaird | initramfs-tools | linux-initramfs-tool Which should have pulled in yaird, but apparently hasn't, can you check why ? Maybe this is due to the preinst checking imposed by k-p ? Manoj, can you comment on this ? Friendly, Sven Luther
Bug#337902: Missing dependency on /usr/sbin/mkinitramfs
On Mon, Nov 07, 2005 at 10:52:34AM +0100, Magnus Ekdahl wrote: > Sven Luther wrote: > >On Mon, Nov 07, 2005 at 07:48:07AM +0100, Magnus Ekdahl wrote: > > > >>Package: linux-image-2.6.14-1-k7 > >>Version: 2.6.14-2 > >>Severity: important > >> > >>When installing I get the following error (sorry for the swedish locale) > >> > >>running dpkg --pending --configure ... > >>Ställer in linux-image-2.6.14-1-k7 (2.6.14-2) ... > >>Failed to find suitable ramdisk generation tool for kernel version > > > > > >You should have either yaird or initramfs-tools installed, yaird has the > >benefit of not needing udev or hotplug. > > > >That said, there is a dependency on : > > > > yaird | initramfs-tools | linux-initramfs-tool > > > >Which should have pulled in yaird, but apparently hasn't, can you check > >why ? > > I think that I have yaird installed. The output below is freely translated > from Swedish please run LANG=C when doing this kind of stuff. Not sure, this seems to be a kernel-package bug, need to look at it in the future. Friendly, Sven Luther
Bug#335578: ocamlopt.opt segfaults on Alpha
On Mon, Nov 07, 2005 at 05:16:53PM +0100, Julien Cristau wrote: > Hi, > > Starting from ocaml version 3.08.3-8, ocamlopt.opt doesn't work at all > on alpha. Since 3.08.3-7 built fine, I think this is a toolchain issue. > > 3.08.3-7 was built with gcc-4.0 4.0.1-4, binutils 2.16.1-2 and > libc6.1-dev 2.3.5-3, while 3.08.3-8 was built with gcc-4.0 4.0.1-6, > binutils 2.16.1cvs20050902-1 and libc6.1-dev 2.3.5-5. binutils is the likely culprit, i would say, especially given the way ocamlopt fails, and the fact that it was a cvs snapshot only augments that fear. Julien, could you maybe try downgrading to the older binutils version, and seeing what went wrong ? As said on irc, the likely solution here would be to disable the alpha native compilers until the solution is found. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336988: yaird: ignoring 'mesh' doesn't allow root device to be found
On Mon, Nov 07, 2005 at 07:48:32PM +0100, Erik van Konijnenburg wrote: > On Sat, Nov 05, 2005 at 03:30:26PM -0800, Beiad Dalton wrote: > > 'mesh' is the onboard oldworld SCSI host adapter; my installation > > happens to be on this, so when I boot 2.6.14-1-powerpc, I have no root > > filesystem. > > Could you post 'ls -lR /sys' to see what kind of input we have to > recognise this kind of host, > > and could you give a hint which modules you expect to be loaded > to get this device operational? at lest : /lib/modules/2.6.12-1-powerpc/kernel/drivers/scsi/mesh.ko I guess the usual scsi disk stuff too. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338045: [EMAIL PROTECTED]: [Debian-ppc64-devel] Package: installation-reports]
Package: installer - Forwarded message from Frank van Berkel <[EMAIL PROTECTED]> - From: Frank van Berkel <[EMAIL PROTECTED]> To: Sven Luther <[EMAIL PROTECTED]> Date: Mon, 7 Nov 2005 12:58:56 + Message-Id: <[EMAIL PROTECTED]> X-Mailer: Open WebMail 2.51 20050504 Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [Debian-ppc64-devel] Package: installation-reports Debian-installer-version: 20050311 http://cdimage.debian.org/pub/cdimage-testing/daily/powerpc/current/debian-testing-powerpc-netinst.iso uname -a: Date: 07-11-2005 10.30am Method: Netinst. iso Machine: i5 IBM,9406-520 Processor: iSeries Model 520 Memory: 2G Root Device: SCSI Root Size/partition table: Output of lspci and lspci -n: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[E] Reboot: [O] Comments/Problems: Yaboot wants to write the bootsection but I can't choose sda (where my debian lives) for writing! It seems like the bootflag option for the several hdisks is ignored. I'm able to set or unset the bootflag but the changes are not written to disk. ___ Debian-ppc64-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/debian-ppc64-devel --- Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335578: ocamlopt.opt segfaults on Alpha
On Tue, Nov 08, 2005 at 12:11:06AM +0100, Julien Cristau wrote: > On Mon, Nov 7, 2005 at 18:34:54 +0000, Sven Luther wrote: > > > binutils is the likely culprit, i would say, especially given the way > > ocamlopt > > fails, and the fact that it was a cvs snapshot only augments that fear. > > > > Julien, could you maybe try downgrading to the older binutils version, and > > seeing what went wrong ? > > > Indeed, rebuilding with binutils 2.16.1-2, gcc-4.0 4.0.1-6 and > libc6.1-dev 2.3.5-7, the build succeeded, and I got a working > ocamlopt.opt. > The problem seems to be between binutils 2.16.1-2 and > 2.16.1cvs20050902-1. Dropping debian-glibc and debian-gcc from the > Mail-Followup-To. I suppose this means you should clone the bugs and reassign a copy to binutils, maybe merge in first the previous bugs or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337935: Package: installation-reports
On Tue, Nov 08, 2005 at 12:47:17AM +0100, Benoit Chesneau wrote: > I can't post log sorry. anyway about version on kernel thi is the > just the message displayed by mkofboot. It require hfsutils. But I > can't installe it on chroot because apt says it's deprecated due to > version of kernel. Not really, can you tell us a bit more about the exact circunstances of this problem and the exact error messages ? hfsutils contains nothing that could displease apt : Depends: libc6 (>= 2.3.2.ds1-21) Suggests: hfsutils-tcltk and there are no postinst or whatever so i am really baffled by this report. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338105: linux-headers-2.6.14-rc4-powerpc: linux-headers does not include scripts/Kbuild.include
On Mon, Nov 07, 2005 at 11:20:25PM -0800, Troy Benjegerdes wrote: > Package: linux-headers-2.6.14-rc4-powerpc > Version: 2.6.13+2.6.14-rc4-0experimental.1 > Severity: important > Tags: experimental > Should be fixed in either 2.6.14-rc5 or 2.6.14 now in unstable, please confirm. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
On Tue, Nov 08, 2005 at 11:19:36AM +0100, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tue, 8 Nov 2005 11:31:10 +0900 > Horms <[EMAIL PROTECTED]> wrote: > > > Waldi, can you coment on how to add a recommends to > > images on a per-flavour basis? > > Isn't per-flavour control hints one of the new features of the > soon-to-be-in-sid kernel-package? > > If so, I suggest using that instead of bloating linux-2.6 packaging > unnecessarily. linux-2.6 packaging already has quite nice per-flavour dependency handling, thank you. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
On Tue, Nov 08, 2005 at 08:30:53PM +0900, Horms wrote: > On Tue, Nov 08, 2005 at 11:36:13AM +0100, Sven Luther wrote: > > On Tue, Nov 08, 2005 at 11:19:36AM +0100, Jonas Smedegaard wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On Tue, 8 Nov 2005 11:31:10 +0900 > > > Horms <[EMAIL PROTECTED]> wrote: > > > > > > > Waldi, can you coment on how to add a recommends to > > > > images on a per-flavour basis? > > > > > > Isn't per-flavour control hints one of the new features of the > > > soon-to-be-in-sid kernel-package? > > > > > > If so, I suggest using that instead of bloating linux-2.6 packaging > > > unnecessarily. > > > > linux-2.6 packaging already has quite nice per-flavour dependency handling, > > thank you. > > Either way, is it possible to add recommends on a per-flavour basis, > and if so, how? Not sure, i know we can add dependencies though, so the same mechanism can probably quite easily be used for recomends. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
On Tue, Nov 08, 2005 at 08:30:53PM +0900, Horms wrote:
> On Tue, Nov 08, 2005 at 11:36:13AM +0100, Sven Luther wrote:
> > On Tue, Nov 08, 2005 at 11:19:36AM +0100, Jonas Smedegaard wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > On Tue, 8 Nov 2005 11:31:10 +0900
> > > Horms <[EMAIL PROTECTED]> wrote:
> > >
> > > > Waldi, can you coment on how to add a recommends to
> > > > images on a per-flavour basis?
> > >
> > > Isn't per-flavour control hints one of the new features of the
> > > soon-to-be-in-sid kernel-package?
> > >
> > > If so, I suggest using that instead of bloating linux-2.6 packaging
> > > unnecessarily.
> >
> > linux-2.6 packaging already has quite nice per-flavour dependency handling,
> > thank you.
>
> Either way, is it possible to add recommends on a per-flavour basis,
> and if so, how?
I am not python familiar, but reading bin/gencontrol.py :
def process_depends(key, e, in_e, vars):
in_dep = in_e[key].split(',')
dep = []
for d in in_dep:
d = d.strip()
d = substitute(d, vars)
if d:
dep.append(d)
if dep:
t = ', '.join(dep)
e[key] = t
def process_package(in_entry, vars):
e = entry()
for i in in_entry.iterkeys():
if i in (('Depends', 'Provides', 'Suggests')):
process_depends(i, e, in_entry, vars)
elif i == 'Description':
process_description(e, in_entry, vars)
elif i[:2] == 'X-':
pass
else:
e[i] = substitute(in_entry[i], vars)
return e
I get the feeling that only Provides, Depends and suggests are supported.
Bastian, am i right in thinking that just adding Recomends to the above list
should do it ?
Simon, could you give it a try ?
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
On Tue, Nov 08, 2005 at 03:14:47PM +0100, Sven Luther wrote: > On Tue, Nov 08, 2005 at 08:30:53PM +0900, Horms wrote: > > On Tue, Nov 08, 2005 at 11:36:13AM +0100, Sven Luther wrote: > > > On Tue, Nov 08, 2005 at 11:19:36AM +0100, Jonas Smedegaard wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > On Tue, 8 Nov 2005 11:31:10 +0900 > > > > Horms <[EMAIL PROTECTED]> wrote: > > > > > > > > > Waldi, can you coment on how to add a recommends to > > > > > images on a per-flavour basis? You can now, just need to add recomends: to the arch//defines entry. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338045: [EMAIL PROTECTED]: Re: [Debian-ppc64-devel] Package: installation-reports]
- Forwarded message from Frank van Berkel <[EMAIL PROTECTED]> - From: Frank van Berkel <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Tue, 8 Nov 2005 20:50:39 +0100 Message-Id: <[EMAIL PROTECTED]> Subject: Re: [Debian-ppc64-devel] Package: installation-reports Cc: Sven Luther <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Hi Sven, On Tuesday 08 November 2005 19:17, Sven Luther wrote: > Ok, it seemt this is not a yaboot-installer issue, but that you didn't see > your disk/partition, and didn't proceed with yaboot-installer. > > We would like to know the content of your /proc/partitions, and if possible > can you do a 'parted -s /dev/discs/disc0 print' for all /dev/discs/* ? > > Also, during the partman partitioning step, did it create a prep partition, > with flags prep and boot ? What did you chose at this step ? Ahhh meaby I know what is wrong, but I can check it tomorrow. This is what I did, because I was in a hurry to check whether or not the iso would work I did at the partitioning choose for "Multi-user System". And at the console it was not very clear because no ansi console if there was a Prep partition. So meaby that is the problem. I also did try it with RedHat and there was no problem... But I will try it again tomorrow and let it know how it goes. Regards, Frank ___ Debian-ppc64-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/debian-ppc64-devel --- Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327746: This isn't tk8.4's fault
On Tue, Nov 08, 2005 at 08:50:26PM +0100, Wouter Verhelst wrote: > reassign 327746 tk8.4 > severity 327746 grave > reassign 327736 tk8.4 > severity 327736 grave > merge 327736 327746 > retitle 327736 tk8.4: needs to be rebuilt on m68k > tags 327736 + pending > thanks > > Hi, > > It appears tk8.4 was built with binutils 2.16.1cvs20050902, which is > utterly broken on m68k, in that it produces corrupt ELF binaries (see > #327780 for details). > > I've queued tk8.4 for a binNMU on m68k, and registered ocaml as > dep-waiting on a higher-than-current version of tk8.4. Feel free to > close this once a rebuilt version of tk8.4 has been uploaded. Thanks, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302031: status update
On Tue, Nov 08, 2005 at 02:16:55PM -0700, Troy Heber wrote: > Hello Sven, > > I just realized that Max and I both neglected to cc -submitter. We are Yeah, the bts sucks for not doing this by default. > unable to reproduce this issue. Can you still reproduce the problem on > a current version? When you have a minute can you take a quick look at > this bug and give us a update. Mmm, /me wishes people would give a small hint about the bug in such long-after recalls, looking at the bug report ... > Thanks for the assistance!! ... Oh well, it was not to me it happened in the first place, and i believe i have seen the same scenario refusing to upgrade recently, and not delete silently, so that i suspect this may be fixed. I don't particularly feel like reproducing this, and anyway have upgraded both client and server side multiple times since then. Let's close this and if it rehappens, i will repoen the bug, ok ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338185: stay on 2.6.12 for now
On Wed, Nov 09, 2005 at 01:51:53AM +0100, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > retitle 338185 ia64 has problems footprinting initramfs > thanks > > > ia64 users shouldn't upgrade to 2.6.14 yet - the ia64 kernel currently > > has problems footprinting initramfs, which means it can't work with > > either yaird or initramfs-tools. Monitor this bug for status info. > > Well, there's already one beneral make-sure-this-does-not-enter-sarge > bug opened a few days ago (by Sven, I believe), so better clarify > what's special about this one :-) Mine is about 2.6.14 not entering testing, but ok for sid, while this one is about ia64 guys not even installing it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338283: new kernel-package breaks official linux-2.6 kernel builds, should not propagate to testing.
Package: kernel-package Version: 10.008 Severity: grave As discussed on irc, the new 10.008 kernel-package was prematurely uploaded to unstable, and breaks linux-2.6 builds. The issues at hand are : 1. the missing config caues manuals not to build 2. the headers build binaries uneccessarily (but doesn't break build) 3. missing depends and recommends in the linux-image package. These are probably due to a k-p regression, which means that both the config for the arch-indep build and the control file provided by the linux-2.6 build infrastructure are not used for the final packages, for some yet mysterious reason. This is being worked on, and hopefully a fix will be out soon, but in the meantime, kernel-package 10.008 is useless for official linux-2.6 builds, and since it is in unstable, means we cannot upload anymore linux-2.6 packages until it is fixed, which makes this RC. Friendly, Sven Luther -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages kernel-package depends on: ii dpkg 1.10.28Package maintenance system for Deb ii dpkg-dev 1.10.28Package building tools for Debian ii gcc [c-compiler] 4:3.3.5-3 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.5-13 The GNU C compiler ii make 3.80-9 The GNU version of the "make" util ii perl 5.8.4-8Larry Wall's Practical Extraction -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338233: libnumerix-ocaml-dev: Missing libnumerix-ocaml
On Wed, Nov 09, 2005 at 12:44:15AM -0500, Mike Furr wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Chris Stork wrote: > > I had to install /usr/lib/ocaml/3.08.3/numerix/libnumerix-ocaml.a by > > hand from the source to make "ocamlc -custom ..." or "ocamlopt ..." > > work. > Ah I see. For some reason, I missed that the library changed names and > therefore it didn't get installed. Will be fixed in the next upload > (as soon as I figure out why this assembly code is all of sudden > segfaulting...) Because binutils is a broken mess taken from a random devel CVS snapshot ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338265: bibtex2html: broken dependencies forbid it from been installed in unstable
On Tue, Nov 08, 2005 at 10:41:19PM -0500, Yaroslav Halchenko wrote: > Package: bibtex2html > Severity: important > > I was upgrading my box and had to remove bibtex2html since > > bibtex2html depends on ocaml-base-nox-3.08.3 > ocaml-base-nox-3.08.3 does not appear to be available > > There is now > ii ocaml-base-nox 3.09.0-1 > which > Provides: ocaml-base-nox-3.09.0 > > Thank you in advance. Probably it is just up for a small fix in > dependencies ;-) We are currently in a big unstable dependency bump of ocaml 3.09.0, and this means a full rebuild of all ocaml packages. Unstable will be broken for a bit, please use the ocaml and bibtex2html of etch/testing in the meantime (or even sarge, since those are the sames). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338303: hevea: Uninstallable in sid
On Wed, Nov 09, 2005 at 11:19:58AM +0100, Rafael Laboissiere wrote: > Package: hevea > Version: 1.08-1 > Severity: important > > > $ apt-get install hevea > [...] > The following packages have unmet dependencies: > hevea: Depends: ocaml-base-nox-3.08.3 but it is not installable > E: Broken packages > > Changing the dependency from ocaml-base-nox-3.08.3 to > ocaml-base-nox-3.09.0 should fix the problem. No, a rebuild with ocaml 3.09.0 is needed, and should be available soon. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338431: linux-2.6: [infrastrucutre] gencontrol.py should know how to exclude stuff from deps, add INITRD_CMD setting.
Package: linux-2.6 Severity: normal Well, this is something that came up with the desire of not using the (currently broken) initramfs-tools on alpha. We need two implementations to fix this, or at least one of them but the other seems useful too. 1) gencontrol.py should know how to handle an 'excludes' field, which will be used to remove any reference to the entries in it when generating the depends and such fields, this would be used as : arch/alpha/defines: ... excludes: initramfs-tools and the line : Depends: yaird | initramfs-tools | linux-initramfs-tool, module-init-tools (>= 0.9.13) would be rewritten to : Depends: yaird | linux-initramfs-tool, module-init-tools (>= 0.9.13) 2) We need support for setting INITRD_CMD prior to the make-kpkg command which creates the postinst (i thinkg the kernel-image one not sure though). This would allow to do : arch/defines : ... ramdisks: mkinitrd.yaird mkinitramfs arch/alpha/defines : ... ramdisks: mkinitrd.yaird The first one would be nice to have, we currently keep the full depend and add a conflict on alpha, but i believe the second solution is better, altough it needs k-p 10.000x. The reason why the second fix is better, is that there is really no reason to stop alpha from installing initramfs-tools, just we have to make sure not to use it by default. Friendly, Sven Luther -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338435: ocaml 3.09.0 should not enter testing without our consent
Package: ocaml Severity: critical Justification: breaks unrelated software Well, this is just a safeguard to make sure that ocaml 3.09.0 will not enter testing without us knowing it should be ready for that. This will also block all dependent packages we are now rebuilding. Friendly, Sven Luther -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338148: ocaml was binNMUed with an older version of binutils, this is still an open issue though.
Hi, As discussed with the RMs, Steve Langasek did a binary NMU of ocaml with the older binutils, in order to allow us to build the rest of the ocaml dependent packages. This does not mean that this bug has been fixed in binutils, and this bug should not be closed because of that. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338437: [alpha] ocamlopt is broken due to broken binutils on alpha, fixed in binNMU, but should be rebuilt
Package: ocaml Severity: grave Justification: renders package unusable Well, as asked by the RMs, this bug is here to trackthe fact that binNMU with the older non-broken binutils was done, but needs to be fixed before ocaml gets into etch. Friendly, Sven Luther -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337321: kernel-package: Fails to build ppc64 2.6.14 kernel
On Thu, Nov 10, 2005 at 10:20:14AM +0100, Juergen Kreileder wrote: > Manoj Srivastava wrote: > >reassign 337321 mkvmlinuz > >thanks > >Hi, > > > >After talking to experts, I am told to convey this: > > a) You should be using --subarch powerpc64, which shall create vmlinux > > I should have mentioned that I've used that option. It tried to build > target zImage Please, tell us what kernel you are trying to build, and what is your .config. We are building powerpc64 images just fine, so this should not be your problem. > > b) You should use mkvmlinuz to create the zImage. > > Why? make-kpkg seems to be good enough, it just seems to use the wrong > target for G5 builds. The kernel package generated with > target=zImage.vmode works fine for me. Because we are separating the boot-wrapper thingy from the actual builds. The idea is to have make-kpkg build only the vmlinux file in all cases, and then have mkvmlinuz do the needed linking to produce your zImage.vmode or whatever. I will have a look at this over the WE, and we will see how it works out, but i need more info from you. What kernel version, and what config you use. BTW, why don't you use plain vmlinux with yaboot anyway ? > > c) Since mkvmlinuz does not yet support ppc64 yet, I am reassigning > >this bug there. After consideration, i am not 100% sure there is no problem in k-p after all, i will look at it this WE and reassign the bug to k-p if needed. > Juergen Kreileder, Blackdown Java-Linux Team > http://blog.blackdown.de/ Mmm, so when can we expect a newer powerpc blackdown java suite ? :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337321: kernel-package: Fails to build ppc64 2.6.14 kernel
clone 337321 -1
reassign -1 kernel-package
tags -1 + pacth
thanks
On Thu, Nov 10, 2005 at 11:21:15AM +0100, Juergen Kreileder wrote:
> Sven Luther wrote:
> >Please, tell us what kernel you are trying to build, and what is your
> >.config.
>
> I can't get to the machine right now but the problem probably is caused
> by the fact that my config only has PMAC relevant stuff, ie. I have
> CONFIG_PPC_PMAC but not CONFIG_PPC_PSERIES, CONFIG_PPC_MAPLE, ...
>
> That restricts boottargets-y to just zImage.vmode and zImage.initrd.vmode.
>
> Kernel is 2.6.14 vanilla.
This is indeed a k-p build
> >BTW, why don't you use plain vmlinux with yaboot anyway ?
>
> I've built ppc64 kernels with vmlinux manually up to now. I just
> came to zImage because make-kpkg tried to build one.
Ok.
Well, this will be fixed in the 10.00x packages, but in the meantime, you can
applyt the following patch, which modifies /usr/share/kernel-package/rules,
and should fix your problem.
Manoj, this patch is against 9.008.4 or older, i will provide you with a newer
one against 10.00x nextly.
> >Mmm, so when can we expect a newer powerpc blackdown java suite ?
> >
> >:)
>
> No date yet, my time for this port is a bit limited currently :-/
Too bad, thankfully the free javas are progressing, and there is the IBM jdk.
Friendly,
Sven Luther
--- /usr/share/kernel-package/rules.orig2005-11-10 10:30:40.0
+
+++ /usr/share/kernel-package/rules 2005-11-10 10:32:03.0 +
@@ -335,6 +335,7 @@
ifneq (,$(findstring $(KPKG_SUBARCH), powerpc powerpc64))
ifneq (,$(findstring $(KPKG_SUBARCH), powerpc64))
KERNEL_ARCH:=ppc64
+ target := vmlinux
endif
ifneq (,$(findstring $(KPKG_SUBARCH), powerpc))
KERNEL_ARCH:=ppc
@@ -342,9 +343,9 @@
IMAGE_POST_PROCESS_TARGET := mkvmlinuz_support_install
IMAGE_POST_PROCESS_DIR:= arch/ppc/boot
INSTALL_MKVMLINUZ_PATH =
$(SRCTOP)/$(IMAGE_TOP)/usr/lib/kernel-image-${version}
+ target := zImage
+ loaderdep=mkvmlinuz
endif
-target := zImage
-loaderdep=mkvmlinuz
else
KERNEL_ARCH=ppc64
target = $(kimage)
@@ -387,6 +388,7 @@
ifneq (,$(findstring $(KPKG_SUBARCH), powerpc powerpc64))
ifneq (,$(findstring $(KPKG_SUBARCH), powerpc64))
KERNEL_ARCH:=ppc64
+ target := vmlinux
endif
ifneq (,$(findstring $(KPKG_SUBARCH), powerpc))
KERNEL_ARCH:=ppc
@@ -394,9 +396,9 @@
IMAGE_POST_PROCESS_TARGET := mkvmlinuz_support_install
IMAGE_POST_PROCESS_DIR:= arch/ppc/boot
INSTALL_MKVMLINUZ_PATH =
$(SRCTOP)/$(IMAGE_TOP)/usr/lib/kernel-image-${version}
+ target := zImage
+ loaderdep=mkvmlinuz
endif
-target := zImage
-loaderdep=mkvmlinuz
kimagesrc = vmlinux
kimage := vmlinux
kimagedest = $(INT_IMAGE_DESTDIR)/vmlinux-$(version)
Bug#277835: 2.6.12 appears ok
On Thu, Nov 10, 2005 at 01:51:44PM +, Neil Pilgrim wrote: > Hi, > > I've finally had a chance to try the 2.6.12 kernel, via the > linux-image-2.6.12-1-686_2.6.12-10_i386.deb from testing, on this > otherwise sarge system. > > This works fine, at least with regard to mounting my usb stick. I will > test 2.6.12 further (I see it is actually based on 2.6.12.6), although > I'm wary of using a less-tested/more-recent version, even if it is off > the 'stable' branch of 2.6.12. > > With regard to obtaining an updated 2.6.8 version for sarge, I'm > certainly willing to test a slightly 'tweaked' version, but not really > able to set this up myself here. Of course, if 2.6.12 (or .14) is > actually considered 'safe', then I'd be inclined to just recommend that > instead, if people other than myself do have this problem - although > that's probably not really a line that debian could/should officially > take, I suspect :) Well, in most, if not all, aspects, the 2.6.12 and 2.6.14 kernels are better than the 2.6.8 ones, and at least the kernel team officially recomends using them, or the sarge backports we are or will be making available. Obviously, they can't be part of a sarge update with current policies, nor be a security upgrade. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338497: [wishlist] Please add 3w-xxxx to the initrd's /loadmodules
On Thu, Nov 10, 2005 at 06:11:42PM +0100, Christian Hammers wrote: > Package: kernel-image-2.6.8-2-686 > Version: 2.6.8-16 > Severity: wishlist > > Hello > > Please ad the 3w- which is the driver for the commonly used 3ware > (P)ATA RAID controller to the list of modules that get loaded automatically > because else it won't boot so well... Heu, what exactly are you trying to do here ? what is the list of modules to get loaded automatically, and will adding it to /etc/modules not solve your problem, whatever that problem is ? Debian booted without problem with my 3w-9xxx card in it, and worked just fine, btu that was an etch snapshot. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338497: [wishlist] Please add 3w-xxxx to the initrd's /loadmodules
On Thu, Nov 10, 2005 at 09:15:58PM +0100, Christian Hammers wrote: > Hello Sven > > On 2005-11-10 Sven Luther wrote: > > > Please ad the 3w- which is the driver for the commonly used 3ware > > > (P)ATA RAID controller to the list of modules that get loaded > > > automatically > > > because else it won't boot so well... > > > > Heu, what exactly are you trying to do here ? what is the list of modules to > > get loaded automatically, and will adding it to /etc/modules not solve your > > problem, whatever that problem is ? > > I need the 3w-.o SCSI RAID controller module to access the harddrive > where my root filesystem is on so using /etc/modules won't work. So, your real request is that initrd-tools is not including the module in your initrd. So, please add the module to /etc/mkinitrd/modules, and rebuild your initrd (with dpkg-reconfigure kernel-image-2.6.8-...). Alternatively, you can try installing one of the newer kernels from etch (2.6.12) or sid (2.6.14), with one of the new ramdisk generating tools (yaird or initramfs, i favour the first myself), since it is highly unlikely that initrd-tools will get significantly modified. > With "the list of modules that automatically get loaded" I meant the > /loadmodules (or so) file that I found inside the initrd image from the > official Debian kernel. The image contained a /lib/modules directory with > both 3w-9xxx.ko and 3w-.ko but in this file only the first was listed. Ok. > Or is there at least a kernel boot option which I could use to load this > module before "/" is tried to mount? The module exists in the initrd.img > nevertheless... (that would be enough for me as I remember that the > kernel was a Sarge one and so has very little chance to get updated) Nope, but i think the above should work. > > Debian booted without problem with my 3w-9xxx card in it, and worked just > > fine, btu that was an etch snapshot. > > The 9xxx cards are SATA RAID controller, they have a different module > (3w-9xxx.o). Ah, well, i thought it was a newer card, so if it worked the older should have worked too, but well, i was wrong. Hope the above helps. reading the manpage of mkinitrd should probably help you a lot understanding what is going on. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333831: Still present in 2.6.14 ?
Hi Simon, We would like to know if your bug (Hangs on boot loading ide-cd) is still present with the 2.6.14-2 packages currently in unstable ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338644: installation report
On Fri, Nov 11, 2005 at 06:50:47PM +, Ken Moffat wrote: > Package: installation-reports > > Debian-installer-version: 2005-11-11 powerpc64 gtk-miniiso64 from > people.debian.org/~luther/ > uname N/A > Date: 2005 11 11 > Method: > testing gtk mini iso (expecting failure anyway, because my network > card needs a 2.6.14 kernel) > > Machine: Powermac G5 > Processor: single 1.8 > Memory: 1.25GB > Root Device: sda6 > Root Size/partition table: N/A > > Output of lspci and lspci -n: > > lspci (from a gentoo install CD - of course, that can't install either) > > :f0:0b.0 Host bridge: Apple Computer Inc. U3L AGP Bridge > :f0:10.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX > 5200 Ultra] (rev a1) > 0001:00:01.0 PCI bridge: Apple Computer Inc. Shasta PCI Bridge > 0001:00:02.0 PCI bridge: Apple Computer Inc. Shasta PCI Bridge > 0001:00:03.0 PCI bridge: Apple Computer Inc. Shasta PCI Bridge > 0001:01:07.0 Class ff00: Apple Computer Inc. Shasta Mac I/O > 0001:01:0b.0 USB Controller: NEC Corporation USB (rev 43) > 0001:01:0b.1 USB Controller: NEC Corporation USB (rev 43) > 0001:01:0b.2 USB Controller: NEC Corporation USB (rev 43) > 0001:02:0c.0 IDE interface: Broadcom (formerly ServerWorks) K2 SATA > 0001:02:0d.0 Class ff00: Apple Computer Inc. Shasta IDE > 0001:02:0e.0 Firewire (IEEE 1394): Apple Computer Inc. Shasta Firewire > 0001:03:0f.0 Ethernet controller: Apple Computer Inc. Shasta (Sun GEM) > > lspci -n > > :f0:0b.0 Class 0600: 106b:0058 > :f0:10.0 Class 0300: 10de:0321 (rev a1) > 0001:00:01.0 Class 0604: 106b:0053 > 0001:00:02.0 Class 0604: 106b:0054 > 0001:00:03.0 Class 0604: 106b:0055 > 0001:01:07.0 Class ff00: 106b:004f > 0001:01:0b.0 Class 0c03: 1033:0035 (rev 43) > 0001:01:0b.1 Class 0c03: 1033:0035 (rev 43) > 0001:01:0b.2 Class 0c03: 1033:00e0 (rev 04) > 0001:02:0c.0 Class 0101: 1166:0240 > 0001:02:0d.0 Class ff00: 106b:0050 > 0001:02:0e.0 Class 0c00: 106b:0052 > 0001:03:0f.0 Class 0200: 106b:0051 > > Base System Installation Checklist: > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > > Initial boot worked:[E] > Configure network HW: [ ] > Config network: [ ] > Detect CD: [ ] > Load installer modules: [ ] > Detect hard drives: [ ] > Partition hard drives: [ ] > Create file systems:[ ] > Mount partitions: [ ] > Install base system:[ ] > Install boot loader:[ ] > Reboot: [ ] > > Comments/Problems: > > The boot is fine at first (in a framebuffer), but then it looks as if X > is being started - the screen flashes brightly (and jaggedly), then > immediately goes dark. This repeats every few seconds - it looks as if > there is some text (dark on light background, probably larger than the > framebuffer text), during the bright flashes, but these are not visible > for long enough to let me read any of it. At a guess, the text is the X > log, as if X is trying to find a resolution, failing, and immediately > restarting. > > As shown above, the agp is nVidia (sorry, but they mostly come through like > that now) and it is connected to a 14" LCD screen via a DVI-VGA adaptor and > KVM. Replace it by a radeon card :) Anyway, could you try video=ofonly while booting ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338045: Fixed in SVN, awaiting upload.
Hello, just a quick note about this bug report. The real problem was that the model was not listed in libdebian-installer/src/system/subarch-powerpc-linux.c, and thus partman-prep was not loaded for it, which means that the prep partition, and more importantly the debconf value for the boot partition was not set, and thus yaboot-installer failed to work as expected. libdebian-installer 0.36 will fix this issue. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338734: fstab doesn't mount NTFS partitions on Serial ATA drives.
On Sat, Nov 12, 2005 at 12:42:37PM +0100, Matteo Frare Barutti wrote: > Package: linux-2.6 > Version: all > Severity: normal > > Hi all, > > I found that Serial ATA drives with NTFS partitions present in /etc/fstab > doesn't get mounted in bootstrap. > drives are correctly detected; if you manually mount partitions via > terminal/console instead, they correctly get mounted; > > Example: > # /etc/fstab: static file system information. > # > # > proc/proc procdefaults0 0 > /dev/hda2 / ext3defaults,errors=remount-ro 0 1 > /dev/hda5 noneswapsw 0 0 > /dev/hdb/media/cdrom0 iso9660 ro,user,noauto 0 0 > /dev/sda1 /mnt/storagentfsumask=0222,ro 0 0 > > /dev/sda1 doesn't get mounted. > > then, if i write in a console: > mount /dev/sda1 /mnt/storage/ -t ntfs -r -o umask=0222 > everything is ok. > > Normal ATA drives with ntfs are correctly mounted on same system. > > Tried with all stable kernel, same problem. > Tried with another system, same problem. > > > see for reference: > http://lists.debian.org/debian-user/2005/09/msg01346.html; > http://lists.debian.org/debian-kernel/2005/01/msg00138.html; > > kernels >= 2.6 are affected with this issue, both stable and testing; Can you try adding ntfs to /etc/modules, and reboot and see if this still happens ? Anyway, i seriously doubt that this is a kernel bug, most probably either a mount bug or one in the boot scripts or whatever they are called, in charge of mounting the disks. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
