Hi,
Alessandro Amici writes:
> you have only a few seconds between the unpacking of scsi-modules
> udeb and the fatal modprobe.
If you run the installation in expert mode (by passing the parameter
DEBCONF_PRIORITY=low at the kernel command line) you should be able to
avoid this.
Regards, Jens.
reassign 279370 kernel-patch-powerpc-2.6.8
reassign 279491 kernel-patch-powerpc-2.6.8
thanks
Hi,
Alessandro Amici writes:
> - the SCSI driver (sym53c8xx)
Which chip exactly?
> [...] it looks like an irq problem, the fact that the d-i uses a
> 32bit kernel on a 64bit can well be to be the trigg
Hi,
Alessandro Amici writes:
> Severity: important
[...]
> nice black magic trick:
Well, I'm not sure if a bit of editing the kernel binary qualifies as
"major effect on the usability" or black magic, but anyway. As long
as you don't make it RC.
> - with an hexeditor look for the values '00 0c
tags 278957 +pending
thanks
Hi,
Frederik Schueler writes:
> I just uploaded the i386 kernel packages to
>
> http://users.idf.de/~fs/debian-kernel/i386/
I tried those, and my problem is indeed fixed. Thanks a bunch, please
consider uploading to unstable asap. I'm setting the appropriate tag
o
Hi,
> Sven Luther writes:
>
> > I think now that we have some spare place on the kernel, that it
> > would make sense to have at least the at kbd builtin (the usb one
> > pulls in too much stuff i think).
I can't believe I actually bothered to check this, but it turned out
that getting support f
Hi,
Sven Luther writes:
> I think now that we have some spare place on the kernel, that it
> would make sense to have at least the at kbd builtin (the usb one
> pulls in too much stuff i think).
The extra space is precious and there are more worthwhile drivers than
atkbd. More framebuffer drive
Hi,
Andrea Bedini writes:
> Package: kernel-image-2.6.7-powerpc
> Version: 2.6.7-5
> Severity: normal
>
> this is the oops. it happens at boot when hald starts.
Could you please do three things to provide more information:
1. Try the latest revision of kernel-image-2.6.8-powerpc and see
whe
Hi,
> How can this be suggested on an official packaged kernel?
Because the only alternative is to recompile.
> Asking an end user to binary-edit a kernel is mindless, from my point of view.
The most likely explanation for this point of view of yours is that
you don't really know what you're ta
tags 256818 -wontfix
tags 252818 +wontfix
close 256818
thanks
Hi,
I wrote:
> > I have found, thanks to Warren A. Layton (zeevon at debian dot
> > org) from the debian-powerpc list, the solution of the problem.
> > The kernel config parameter CONFIG_SERIAL_PMACZILOG has to be
> > deselected. It
tags 273673 +pending
thanks
Hi,
Maks Attems writes:
> ppc is build without CONFIG_SCSI_MULTI_LUN that makes a lot
> of card readers not available for ppc folks.
> it's enabled on i386, amd, ia64 and even alpha.
Thanks for pointing this out. Will go into the next upload.
> I think we even ag
Hi,
Joshua Kwan writes:
> I fear that using NEWS.Debian won't be obvious enough.
You may be right, given my experience with the NEWS.Debian file in the
PowerPC kernel-image packages. Then again, nobody knows how many
people read that file, paused to think, upgraded without major
problems and th
Hi,
Matthew Wilcox writes:
> Urm. I don't understand. You said that you encountered the problem
> in a Thinkpad 860, but bug 271852 refers to a powerpc-specific problem.
That's exactly what the Thinkpad 8xx series are - RS/6000 systems with
PowerPC 603e processors. See:
korgan:~# cat /proc/c
Hi,
Matthew Wilcox writes:
> > It outputs a "can't map PCI MMIO region" and does nothing at all.
> Interesting. This can only happen if ioremap() returns NULL.
Sorry. I got the message completely wrong. I really was:
| PCI: Enabling device :00:0c.0 ( -> 0003)
| sym.0.12.0: MMIO base
Hi,
Matthew Wilcox writes:
> As upstream maintainer, I'd like more information about it please ...
> - How does it "not work properly"? Does it hang on first access to
>the chip, or does it suffer data corruption?
It outputs a "can't map PCI MMIO region" and does nothing at all.
> - Are
Hi,
I recently encountered a machine (a Thinkpad 860) with a NCR 53C810
SCSI controller that would not work properly unless the config option
CONFIG_SCSI_SYM53C8XX_IOMAPPED was set. Under these circumstances,
installation was a royal pain in the ass, and therefore, I am inclined
to trade performa
Hi,
Frank Murphy writes:
> I imagine there aren't many ADB keyboards that have a Menu key. :)
It can be quite surprising to see the variety of ADB hardware out
there.
> I tried sending this upstream, but it seems there's a problem with
> the list.
Thanks for the patch. Did you try sending it
Hi,
Thanks for the patch. If nobody objects, I will check it into
kernel-source and enable the VGA console in kernel-patch-powerpc, so
the problem should be fixed in the next build.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Hi,
any further information on bugs 270321 and 270326? I installed two
PReP systems in the last few days, and put the root filesystem on
/dev/sda3. After that, both booting with root=/dev/sda3 and with no
root option at all worked. Therefore, I am inclined to change the
option from sda2 to sda3
Hi,
Peter Spuhler writes:
> Wondering if anyone besides myself has had their usb keyboard stop
> working or working very sluggishly after upgrading to 2.6.8-5
> powerpc-smp ? I can't figure out why this is happening, but it
> affects the console and X. USB trackball is working fine BTW. The
>
Hi,
Francis Reyes writes:
> Package: kernel-image-2.6.8-powerpc
> Version: 2.6.8-4
> Severity: normal
>
> I just installed kernel-image-2.6.8-powerpc as well as added the
> initrd.img to my yaboot, but upon booting no devices such as
> ethernet/usb are installed?
The drivers for those devices a
Hi,
Michel Dänzer writes:
> Does this really make the difference between fitting on a miBoot
> floppy or not?
The floppy I created yesterday has about 30k free. The compressed
config would take about 10k, i.e. a substantial amount of it.
> PS: Next time please make sure the submitter gets the
Hi,
Michel Dänzer writes:
> > How about /boot/config-2.6.7-powerpc?
>
> Doesn't help when the kernel has been upgraded since booted.
Leaving the kernel running for an extended period of time after an
upgrade is not recommended for a number of reasons, and in fact the
kernel-image postinst scrip
close 271088
thanks
Hi,
Sven Luther writes:
> Since the config is with the kernel in the package, there should be
> no doubt really.
> Also, as said, the aim was to fit the kernel on a miboot floppy, so
> any space gained is precious.
Precisely. I am backing out your change in svn again. Esp
close 256073
thanks
Hi,
Sven Luther writes:
> That said, i believe that nobody really looked into miboot since ages, so ...
In any case, I managed to build a working miBoot floppy from the
miBoot.img included with BootX_1.2.2.sit, and successfully started the
latest kernel vmlinux-2.6.8-powerpc
Hi,
Sven Luther writes:
> miboot [...] is not yet in debian, and needs OS 9 and some older
> codewarrior version,
How old?
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
reassign 256073 kernel-patch-powerpc-2.6.8
thanks
Hi,
Sven Luther writes:
> Jens, can you let this open
Sure. I thought this had been fixed for good.
> until we found out why miboot doesn't like objcopy -O binary, not
> using the miboot.image target ?
So this is really a mkvmlinuz bug? And,
reassign 256071 kernel-package
severity 256071 wishlist
thanks
Hi,
in a nutshell, the bug submitter wants something along the lines of
'apt-get install kernel-image-powerpc && reboot' to work on the CHRP
subarchitecture. Since this must be done in the postinst, and the
postinst should be the one
close 256073
thanks
Hi,
$ mkvmlinuz -a miboot -k boot/vmlinux-2.6.8-powerpc -d
usr/lib/kernel-image-2.6.8-powerpc -a miboot -o vmlinuz
$ ls -o vmlinuz
-rw-r--r-- 1 jens 1250126 Sep 10 10:52 vmlinuz
Nuff said.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz
Hi,
> I have found, thanks to Warren A. Layton (zeevon at debian dot org) from
> the debian-powerpc list, the solution of the problem. The kernel config
> parameter CONFIG_SERIAL_PMACZILOG has to be deselected. It seems it's a
> bug from the kernel which is not yet solved as of 2.6.7.
Can yo
Hi,
Nikolaus Schulz writes:
> I'm not sure if I understand you correctly: file a bug against
> the xserver because it requires the kernel's radeonfb?
Precisely. This is not supposed to happen (for instance, the nv
driver for nVidia cards works just fine regardless of the underlying
framebuffer)
tags 270743 +unreproducible
tags 270743 +patch
thanks
Hi,
Nikolaus Schulz writes:
> booting kernel 2.6.8 on my iBook 2.2 with a Radeon Mobility M7, the
> radeonfb driver fails to detect the display panel size, resulting in
> a blank screen.
This is very strange, since the Mobility M7 in the iBo
Hi,
Hollis Blanchard writes:
> pivot_root: No sKernel panic: Attempted to kill init!
> uch file or dire ctory
> /sbin/ini<0>Rebooting in 180 seconds..t: 426: cannot open dev/console:
> No such file
What kernel command line did you use? Try passing a root option
there, set to wherever you keep y
Hi,
Sven Luther writes:
> Yeah, i personally feel that the bootargs patch may not be the best
> solution though, and that
> a recompilation of the incriminated object file in mkvmlinuz,
I already told you this is not acceptable because it requires at least
a complete toolchain on every system,
Hi,
Sven Luther writes:
> Yeah, well, it may be needed in a self compiled kernel from the
> kernel-source-2.6.8, where the user like to set it, don't you think ?
In fact, I don't.
> So, you advocate shipping a broken command line support on chrp/pmac
> because you are too lazy or uninterested t
Hi,
Sven Luther writes:
> Well, no, why ? The patch is a correct fix, which makes the default
> command line work, do you seriously think it is better to have a
> broken default commandline on chrp/pmac,
I know for sure that the default command line is not needed for
PowerMacs, as one can use a
Hi,
Sven Luther writes:
> Can you check with giving the root device explicitly with : -r root when
> creating the initrd ?
Same thing. This is because the -r flag is only used for figuring out
the necessary modules.
> Also, if the same problems happens in d-i when you don't specifify
> root=/d
Hi,
Sven Luther writes:
> Can you provide a full serial log output ?
Sure. It's attached.
> Is the panic in question one happening because it doesn't find the
> initrd, or something else ?
It doesn't find the root filesystem if I omit the root option from the
kernel command line.
> How do yo
Hi,
Sven Luther writes:
> Jens, i would greatly appreciate if you could investigate a bit (and
> explain) what is going on on that box of yours,
What is going on is quite simple. If I omit the root option from the
kernel command line, the system panics. If I set the option correctly
(/dev/sda2
Hi,
Hollis Blanchard writes:
> Does this mean the ramdisk is bad?
Could well be. You can check its contents with 'fsck.cramfs -v /initrd.img'.
> Any way I can get some debug output from it?
On the serial console? Put console=ttyS0 last in the kernel command
line. Then /dev/console will poin
Hi,
Sven Luther writes:
> if the kernel is able to figure out the correct root device,
AFAICT, it isn't.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Hi,
Hollis Blanchard writes:
> > perl -pi -e s+/dev/sda2+/dev/foo7+ vmlinuz
> Sounds like that perl command being run by mkvmlinuz, supplying the
> current partition mounted on / . That shouldn't be too hard right?
As I said, it would be nicer to forward port the bootargs patch by
Leigh Brown.
Hi,
Hollis Blanchard writes:
> > Can you try a non-initrd kernel built from Debian sources?
> Kernel panic: VFS: Unable to mount root fs on unknown-block(3,3)
> <0>Rebooting in 180 seconds..
>
> It's missing some drivers that I assume would be present on the
> initrd...
This is bound to happ
Hi,
Hollis Blanchard writes:
> The default kernel commandline in the PReP kernel includes
> "root=/dev/sda2". Please remove this.
Well, this was selected because it is the default from
arch/ppc/Kconfig. While it is not the ideal solution, I think it
should stay enabled for the time being, beca
Hi,
Hollis Blanchard writes:
> Steps to reproduce:
> 1. install kernel-image-2.6.8-powerpc
> 2. run mkvmlinuz with "do_initrd = Yes" in kernel-img.cnf
> 3. boot the resulting vmlinuz-2.6.8-powerpc on PReP
[...]
> Setting PCI interrupts for a "IBM 7248, PowerSeries 830/850 (Carolina)"
[...]
> Ker
close 268392
thanks
Hi,
Toplitzer Helmut writes:
> Package: kernel-source-2.6.8
> Version: 2.6.8-3
> The new kernel breaks all CD bruning software in one or another way.
Upgrade to revision 2.6.8-4. It contains a fix backported from 2.6.9-rc1.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?b
Hi,
Siep Kroonenberg writes:
> This blinking LED for hd activity gets on my nerves, and is, at
> least for my hardware, unnecessary since hd activity is quite
> audible.
I feel the same about this. In fact, I wonder why it got enabled in
the first place.
> Alternatively, if there is an option
severity 268128 grave
thanks
Hi,
Bastian Kleineidam writes:
> Perhaps the new safe-for-copy scsi command patch is incomplete?
Yes. Apply the attached patch and see if the resulting kernel works;
I am not completely sure that the values are correct.
> PS: I left the severity normal for now sin
Hi,
Jens Schmalzing writes:
> It seems that the above-mentioned revision of kernel-source, which
> is currently in incoming, won't build at all (see below).
The attached patch seems to fix the issue; could someone have a look
at it, please?
Regards, Jens.
--- ./drivers/scsi/scsi_i
Hi,
It seems that the above-mentioned revision of kernel-source, which is
currently in incoming, won't build at all (see below). Unless I'm
completely mistaken, the missing values should be 0x8f for VERIFY_16
and 0x5d for GPCMD_SEND_CUE_SHEET, is it safe to just slam them into
include/scsi/scsi.h
Hi,
Sven Luther writes:
> BTW, I believe that the only reason this works for you is because you don't
> make uploads of older packages. The meta packages are right now provided by
> both 2.6.7-5 and 2.6.8-1, and the latest are being used because they where
> uploaded last. If you reuploaded a 2.6
Hi,
Horms writes:
> > > I would like to upload kernel-latest-2.4-i386 to d.o shortly.
> > > If there are any objections now would be a most excellent time
> > > to make them.
I still think the meta packages should be created by the current
source package, and sent a message with my main two poin
Hi,
Horms writes:
> > A separate source package raises synchronization issues. So those
> > meta packages should just be removed from older kernel-image source
> > packages.
>
> Could you elaborate on what synchronisation issues you forsee?
The two scenarios that spring to my mind immediately
Hi,
Sven Luther writes:
> The solution to this is to create a kernel-image-meta or whatever
> source package, which provides the kernel-image- and the
> kernel-image--2.[46] packages.
A separate source package raises synchronization issues. So those
meta packages should just be removed from old
Hi,
Manoj Srivastava writes:
> > To clarify the problem there are two source packages,
> > kernel-image-1-i386-2.4.26 and kernel-image-1-i386-2.4.27, each of
>
> These don't seem to be packages generated by kernel-package,
Of course not. Horms is talking about the *source* packages, which
are
Hi,
Christoph Hellwig writes:
> Talk to the firmware-removal zealots.
Talk to whoever went and just shuffled the tg3 related code in
prune-non-free around instead of activating it properly. Because just
like in 2.6.7, readd-tg3.dpatch is the only firmware related patch
that fails against vanill
Package: kernel-patch-powerpc-2.4.26
Version: 2.4.26-1
Severity: important
Hi,
subject says it all. More precisely:
$ < /usr/src/kernel-patches/powerpc/debian-powerpc.diff.gz gunzip | patch -p1
-f -s --dry-run
1 out of 2 hunks FAILED -- saving rejects to file
arch/ppc/platforms/Makefile.rej
Hi,
Shaul Karl writes:
> The description of kernel-patch-debian-2.6.8 claims that they should
> be applied to a pristine linux 2.6.8 kernel. Yet I get:
>
> No version.Debian file, assuming pristine Linux 2.6.8
> Reversed (or previously applied) patch detected! Assume -R? [n]
> Apply
tags 259354 +upstream
thanks
Hi,
Bernhard Reiter writes:
> However blacklisting does not seem to be the best solution
> as I need the USB ports.
Of course not. Removing the module should not be necessary at all, it
is just a kludge until the bug is properly fixed.
> This bug is not there wit
Hi,
Christian T. Steigies writes:
> So when I want to create an updated patch, I need a tree with the
> first patch applied, a tree with the second patch applied, plus an
> upstream tree and a linux-CVS tree where I get my m68k patches from,
> all unpacked?
This whole thread only deals with hand
Hi,
Sven Luther writes:
> So, i still don't understand what is broken.
Consider a patch that creates a single file containing a single line:
+foo
You publish this as the first revision, resulting in the patchset:
patch-1:
+foo
You realize you should have applied a different patch:
+bar
So
Hi,
Sven Luther writes:
> Still, the kernel-patch package should be able to make the upgrade,
> since it contains the patchset betweem the version of kernel-source
> the user has, and the last one.
That's exactly how it's done. More precisely, the apply script in
kernel-patch-debian does this w
Hi,
Sven Luther writes:
> i think it warrants an upload.
So do I. Stuff is here and here and here:
http://www.theorie.physik.uni-muenchen.de/~jens/kernel-source/
http://www.theorie.physik.uni-muenchen.de/~jens/kernel-patch-powerpc/
http://www.theorie.physik.uni-muenchen.de/~jens/mol-modules/
Hi,
Goswin von Brederlow writes:
> I don't see where such a strict Depends would reduce usefullness.
Now, users of kernel-tree have to download the upstream source once
per upstream release and the Debian patch once per Debian revision.
With a versioned dependency of kernel-tree on kernel-sourc
Hi,
Sven Luther writes:
> Could this not be solved by simply making the kernel-source
> kernel-tree kernel-patch-debian dependency strict ?
This is equivalent to dropping kernel-tree and kernel-patch-debian
altogether.
> After all, there is almost zero chance to have the patches in
> separate s
Hi,
Sven Luther writes:
> So what is the problem ?
The problem arises when stuff gets out of sync, i.e. applying the
latest revision of kernel-patch-debian to an older revision of
kernel-source doesn't result in the latest revision of kernel-source.
This was demonstrated nicely by the 2.4 buil
Hi,
Sven Luther writes:
> I think the kernel-tree did depend on the exact same version of the
> kernel-source and kernel-patch-debian packages,
kernel-tree depends on any revision of kernel-source and the latest
revision of kernel-patch-debian. Together, this allows one to get the
latest revisi
Hi,
Sven Luther writes:
> Well, if the patch replaces the old patch in such a way that there is no
> interaction with newer patches, this should be no major problem, right ?
It becomes a problem if you have an older revision of kernel-source
installed and wish to get the source tree to the late
Hi,
Sven Luther writes:
> Yeah, thanks, i had forgotten about this, will fix it later today.
It's already fixed.
> Let's wait one more day to be sure that other things don't come up.
Fair enough.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je
Hi,
Sven Luther writes:
> Modified: trunk/kernel/source/kernel-source-2.6.7-2.6.7/debian/patch
> es/marvell-pegasos.dpatch
Let me re-iterate: You must never, ever change dpatch files that have
already made it into uploads. Otherwise, you will certainly break
kernel-tree. See debian/README.NMU,
Hi,
Sven Luther writes:
> I have to update the marvell-pegasos.dpatch patch,
Keep in mind that you must not change patches that have been part of
previous uploads. An update has to go in as marvell-pegasos-2.dpatch.
> I have upto now refrained from doing the upload, since the changes
> there w
Hi,
Harald Dunkel writes:
> the patch [...] looks into /proc/modules (the user space interface
> for module management) to get a list of loaded modules.
This only works if you are building an initrd for a kernel with the
exact same module configuration.
> On the other side, the current mkinitrd
Hi,
Norbert Tretkowski writes:
> I just discovered that CAN-2004-0554 is still valid, at least for
> kernel-image-2.4.26-1-686 2.4.26-4 from unstable. I tested it on
> two machines, and both machines crashed when running crash.c.
This is related to Bug#262540. In fact, patch-2.4.26-3 has not b
Hi,
Ingo Juergensmann writes:
> Anyway, regarding to other mails regarding to this bugreport, I think you
> can now close this bug.
It's tagged as pending and will be closed on the next upload of
kernel-patch-powerpc. If anybody feels the need for it, feel free to
reassign to that package, or
Hi,
Jens Schmalzing:
> I have no idea how to construct those nifty URLs that you can click
> on,
Got it :)
http://svn.debian.org/viewcvs/kernel/trunk/kernel/powerpc/kernel-
patch-powerpc-2.6.7-2.6.7/patches/binutils.diff?view=auto>
Regards, Jens.
--
J'qbpbe, le m'en fquz
Hi,
Ingo Juergensmann writes:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109130201415594&w=2 is a
> better URL, because it doesn't trash patches.
I wouldn't be so sure about this, seeing the following result :)
> Anyway, the result:
>
> muaddib:/usr/src/kernel-source-2.6.7# patch -p1 <
tags 263057 pending
thanks
Hi,
Ingo Juergensmann writes:
> c&p'ed that patch to ppc-patch:
Obviously, the list archive interface ate a number of vital spaces.
> Please supply a working patch file
It's in svn now. I have no idea how to construct those nifty URLs
that you can click on, anyway
tags 263058 pending
thanks
Hi,
Troy Benjegerdes writes:
> I've confirmed that setting CONFIG_PDC202XX_FORCE=y resolves the
> problem.
Thanks for investigating this. I've checked the change into svn.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe
close 262390
thanks
Hi,
Troy Benjegerdes writes:
> This can be closed.
Okay, thanks.
> > Does the iPod work when you load the modules manually?
>
> If I load sbp2 manually, its fine FYI, when you plug firewire
> disks in, and sbp2 loads, how do you tell sbp2 to 'log out' of a
> firewire d
Hi,
Troy Benjegerdes writes:
> kernel-image 2.6.7-4 seems to fix the problem with the ipod.
Does this mean the bug can be closed? Or downgraded?
> However, hotplug finds and loads sbp2 when I have the ipod plugged in at
> boot, but not when I plug it in after booting. Is this a hotplug issue?
Hi,
Horms writes:
> Thanks, I have you resolved this or do you want me to look into it?
Please take care of this. I haven't looked at the patches at all,
just worked around the bug locally by disabling the scripts
altogether.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb
Hi,
Kilian Krause writes:
> Just some place i can check the list *BEFORE* downloading some 30MB
> off the net
The .diff.gz, containing all the patches complete with accurate
descriptions, is less than 500kB.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je p
[Cc trimmed, Reply-To trimmed further]
Hi,
Troy Benjegerdes writes:
> Do we have a mechanism for dropping patches as we move from
> unstable->testing->stable ?
Not really. When a certain revision of a package is uploaded into
unstable, it leaves the maintainer's hands. The passage from unstab
Hi,
Sven Luther writes:
> since there is a filename conflict between the openfirmware and prep
> objs files, i moved them both into subdirectories, which means that
> the future 2.6.7-3 will conflict with mkvmlinuz <= 6.
As far as I can see, the only conflicting file is misc.o. By
installing si
Hi,
Sven Luther writes:
> Jens, will you upload powerpc 2.6.7-3 too ? -2 will not be buildable
> because of the asfs patch move i believe ?
That's okay, the asfs patch moved in 2.6.7-2 already.
> I need to hear some info about possibly creating a new powerpc-small
> config for 2.6 oldworld mib
Hi,
Andres Salomon writes:
> I would like to get kernel-source-2.6.7-3 out tomorrow, if possible.
Go ahead.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Hi,
Bluefuture writes:
> > The low techie people I came across think that anything beside
> > graphics are "old computing" or recovery broken things... so a
> > bootsplash help they to trust the operating system (the computer
> > as whole object from their point of view).
>
> I'm totally agree o
Hi,
Thiemo Seufer writes:
> Everything not needed for boot should already be in modules anyway.
It's not that simple. There are lots of drivers in the vanilla kernel
that nobody bothered to modularize, plain and simple. Herbert has
done a tremenduous amount of this work already, but much remai
Hi,
Christian Heim writes:
> But I've tested [the vesafb patch] now for you.
>
> Doesn't compile at all.
Where did you get the kernel source tree from? The build Works very
well here, using kernel-source-2.6.7_2.6.7-2.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqu
Hi,
Sven Luther writes:
> Jens [...] is comaintainer of the 2.4 kernels.
Nope.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Hi,
[EMAIL PROTECTED] writes:
> "Me Og. Og wget. Og package. Og upload. Og no read. Og maintainer."
YMMD :)
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Hi,
[EMAIL PROTECTED] writes:
> > [..] prepare kernel-patch-amd64-2.6.7 packages
>
> Bad idea. Split the patch and get as much as possible merged upstream.
Of course, sorry for omitting it. Still, a kernel-patch package
should be prepared. Thing is, the kernel-patch source package for
powerp
Hi,
Frederik Schueler writes:
> Since the debian kernel packages now are being maintained by the
> debian-kernel maintainers team, what is going to happen to these
> inofficial packages once amd64 will enter sid?
>
> Do I have to ITP kernel-patch-amd64 and/or kernel-image-amd64?
I would sugges
Hi,
Marek Szyprowskiwrites:
> I've prepared a new version of my ASFS driver. Old 1.0beta4 or even
> 1.0beta3 I found in kernel-patch packages should be replaced by the
> new one as soon as possible
Thanks for letting us know. The latest version of the Debian kernel
packages use 1.0beta6, how a
Hi,
William Lee Irwin III writes:
> It won't take long for a problem report to roll in to justify turning it
> off in the .config anyway, so I'm not concerned if it's not immediate.
I only uploaded kernel-source anyway, so whoever does
kernel-image-i386 can still disable the config option.
Rega
Hi,
William Lee Irwin III writes:
> > Shouldn't we disable swsusp instead? The code is flakey at least and
> > eats quite a bit of memory that seems to be scare on the boot floppies.
>
> I'd be in favor of that also.
Ah, too bad. I'm just uploading a new build that fixes kernel-tree
(most imp
Hi,
Thibaut Varene writes:
> The main difference (the only one _really_ noticeable) stands at
> very early stage, when lilo loads the kernel (and the initrd now).
> The "Loading Linux..." dot-bar progress message that used to
> last a couple of seconds is now taking tens of secs.
This is ver
Hi,
Thibaut Varene writes:
> agreed, though "it used to work".
Once upon a time, the Linux kernel with all available IDE and SCSI
drivers compiled in fit on a floppy disk :)
> RE Jens' mail: the initrd used is the stock one, I didn't change
> anything (yet).
There is no stock initrd, the initr
Hi,
Thibaut Varene writes:
> I didn't pay much attention to that at that time, knowing it was the
> new default for debian kernels. But, I started giggling when I
> realized the total boot time (time before first login prompt) of the
> box was almost tripled (that's a P2 400).
How big is the in
Hi,
Sven Luther writes:
> Yeah, fine, and will we set this by default, or not ?
As long as we do not run the risk of accidentally clobbering any
existing /boot/vmlinuz- files, fine. That could be done through
more elaborate checks in the script itself or through a debconf
question, do it as yo
Hi,
Sven Luther writes:
> > Do you mean that by doing :
> >
> > mkvmlinuz /boot/vmlinux-2.6.7-powerpc 2.6.7-powerpc
> >
> > The right thing will happen, and that is creation of a
> > /boot/vmlinuz-2.6.7-powerpc ?
Yes, provided /etc/mkvmlinuz/output sets the variable output to
/boot/vmlinuz
1 - 100 of 176 matches
Mail list logo
